The significant bit is this: Solutions that currently work well on .NET 5 should continue to work as expected on .NET 6.
What we’ve done
Here is what we have done to verify our compatibility with .NET 6:
We have run our suite of automated tests in the NServiceBus repository while targeting .NET 6 in the test projects. After fixing a handful of references to methods made obsolete in .NET 6, all our automated tests pass.
We have verified that all of our multi-targeted samples will build against .NET 6 and have tested a selection of samples handpicked to test a variety of components.
While we have not yet run all of the tests for every single one of our component libraries against .NET 6, we believe that the tests we have run provide the greatest insight into .NET 6 compatibility without unreasonable cost.
What to look for
As we get closer to Microsoft’s November 9 launch date for .NET 6, we will continue to re-run our tests as each new .NET Preview is released. If we find anything of concern, we’ll update this post. Otherwise, “no news is good news.”
As soon as the final version of .NET 6 is released, we’ll begin the labor-intensive effort of validating the automated tests for all of our component libraries.
Is there a specific aspect of .NET 6 that concerns you or a new language feature you’d like to see support for in a future version of NServiceBus? Feel free to let us know in this thread or send us a support case, and we’ll be happy to help.
We have completed another round of analysis of NServiceBus compatibility with .NET 6. This time we tested compatibility with .NET 6 Release Candidate 2, recently released.
What we’ve done
Here is what we have done to verify our compatibility with .NET 6:
Is there any expected release date for .NET 6 support? We would love to start building on .NET 6 but NServiceBus is the only dependency we have that doesn’t fully support it yet.
A group of people is actively working on it as we speak. For example, NServiceBus 7.5. is going to be updated through this pull request. Most master/main branches (that target the next major are already targeting .NET 6).
Once the mentioned pull request is merged we can update all the downstream packages and start the release process.
I’m one of the people currently working on .NET 6. It’s pretty labor intensive to update each of the 50+ projects to run our test suites against .NET 6 as well as .NET Framework and .NET Core 3.1, but we’re getting closer every day.
We actually won’t be doing too many releases. The components themselves are multi-targeted for .NET Framework and for netstandard2.0 so they run on .NET 6 without a new package. If you wanted to start running them on .NET 6 in a staging environment right now, you could most likely do that now.
Thanks for the update! Good luck with the rest of the upgrade!
I’ll take a look at upgrading our services which run on Azure App Services but we also host on Azure Functions so I believe we do need the .NET 6 targeted libraries to be able to build a 4.x Azure Function with NServiceBus. Is that right?
We want to give an update on our progress supporting .NET 6.
At this time, we have completed updating our continuous integration process for most of our components to build and test using .NET 6. We have validated that you can safely use nearly all NServiceBus components with .NET 6, with the exception of the following that we have not yet fully validated:
NServiceBus.Persistence.Sql
Particular.TimeoutMigration
We have released new packages for our Azure Functions integration because running Azure Functions in .NET 6 requires a new version of the Functions host. See the release announcement for more information.
In the next few weeks, we will be releasing .NET 6 versions of our .NET command-line tools.