You may already know that .NET 7 is going to be released around November 2022. Most of the times, we are so busy in looking for new and exciting features, that many times, we tend to forget about the breaking changes that may cause issues while migrating existing codebase to the new .NET version.

This article provides high level information about three important breaking changes (at least I felt they were important), that you may face most likely if you want to migrate. For detailed information, you can refer the breaking changes page on MSDN.

API Controller actions try to infer parameters from DI

Prior to .NET 7, if an API action needed to resolve a type registered in the dependency injection container, the parameter was needed to be decorated with FromServiceAttribute. Without this attribute, the framework was trying to resolve the parameter from the request body data.

From .NET 7, the framework implicitly tries to resolve the parameters from the types registered in DI. The rules are as given below:

• If binding source is explicitly specified, that binding source is used.
• If the complex type is registered in the DI container, the type is resolved implicitly from the DI
• If the type is not registered in DI container, then the type is resolved from the body
• If any route parameter matches the parameter name, then the parameter value is resolved from the path.
• If none of the above rules match, then the parameter is resolved from the Url query string.

The documentation also suggests that there are very less changes that anything will break due to this change. In case, the application breaks due to this, you can disable this implicit resolution of APIcontroller actions, by specifying DisableImplicitFromServicesParameters to true in API Behavior options. The code example to set this flag is given below in the last issue.

Microsoft.Data.SqlClient updated to 4.0.1

This change was introduced in .NET 7 preview 2.

Microsoft.Data.SqlClient package can be used by any .NET based application to interact with SQL Server. This version (4.0.1) of the NuGet package has been released since past few months already. Now, .NET 7 uses this newer version since preview 2.

What is so special about Microsoft.Data.SqlClient version 4.0.1 ?

For connecting to any database, a connection string is required. The connection string has various parts – each part is basically a setting which is used to connect to database. Some of the common settings are

• Database server (IP address / server name)
• Database Name
• User Id and Password (or any other credentials to connect to database server).

In addition to these settings, the connection string also has a setting namely – Encrypt. This setting suggests if the connection to database server is encrypted or not. In the newer version of the package, this setting, Encrypt, has been set to true, by default.

What does it mean ?

It means that by default, when this assembly is trying to initiate the connection, it will try to open an encrypted, secured channel. As mentioned in release notes of this package, this change was required as the usage of cloud-based database is growing and it is recommended to use secured connections with cloud based databases.

So, if the database does not support secured connection, then you will get an exception when the application is trying to connect to database. That’s why it is very important to know about this breaking change. The fix is simple. There are two ways to fix that exception:

• First option is to enable secured connections
• Second option is to explicitly set Encrypt setting to false in connection string

SignalR Hub – Try to resolve parameters from DI

This is an important breaking change to note as many applications use SignalR now a days.

The SignalR hub can have methods and the parameters to those methods can be resolved based on the data / message sent by client. Even if the type is registered in dependency injection container, the preference was given to the message sent by client.

As per new behavior, if a type is registered in dependency injection container and the client is also sending that type as message, then client gets into an error. It’s because the framework will give preference to load the type from the DI container.

There may be very less chances of registering the type in DI if the type corresponds to the message sent by client. Hence, this change is very less likely to break the application. In case the application is broken, set the flag DisableImplicitFromServicesParameters as shown in below code:

I hope you find this information helpful. Let me know your thoughts.