Nservicebus: Obsolete all ConfigurationSections

[timbussmann]

as part of the .net core compatibility ConfigurationSection is currently not supported by the .net standard 2.0 and need to be removed. As all core APIs using ConfigurationSections provide a code first API and should start warning users to move over to those in the v6 timespan, there are two options, depending on the state of the state of .net core compatibility in the next major:

• Remove the configuration sections completely. This doesn't allow us for better obsoletion errors in v7 as we usually do for obsoleted APIs.
• Mark the ConfigurationSections as obsoletes which throw exceptions and keep the reference to ConfigurationSections until v8.

Please note that the Message Endpoint Mappings don't have a 1:1 replacement APIs which means:

• The code first routing APIs don't accept "transport addresses" (e.g. "sales@machineA"). Only logical endpoints (e.g. "sales") can be configured, all further transport specific mapping needs to be configured via transport specific APIs.
• Publishers need to be registered via dedicated API for transports using message driven pubsub.

Transport maintainers, can you please double check and raise your concerns or ensure the transports code first API will be able to handle the migration of users using message endpoint mappings? @Particular/rabbitmq-transport-maintainers @Particular/azure-maintainers @Particular/sqlserver-transport-maintainers @Particular/nservicebus-maintainers

we also need to remove the WithConfig extension in the testing framework which will no longer be needed as part of this step.

[bording]

The interesting thing about ConfigurationSection is that it does look like it's supported in .NET Core 2.0, just not .NET Standard: https://apisof.net/catalog/System.Configuration.ConfigurationSection

So, If we wanted to, we could split this out instead. Core would be a .NET Standard assembly, and then we'd have an NSB.ConfigSections package that was a mult-targeted project that could would have .NET Core and .NET Framework assemblies, so you could use it from either platform.

[bording]

Also, from the perspective of the RabbitMQ transport, this should have no impact that I can think of.

[andreasohlund]

So, If we wanted to, we could split this out instead. Core would be a .NET Standard assembly, and then we'd have an NSB.ConfigSections

Given the large amounts (assumption) of users that makes use of the current message mappings I think this would greatly reduce friction and frustration on their part. So 👍 for considering this.

Perhaps we could make it more restricted to a NSB.MessageMappings that only contains the mappings?

[timbussmann]

I'm 👎 for a Nsb.MessageMappings package. I think FileBasedRouting already provides the same API with a better schema.

e.g. I don't want to continue supporting the weird routing inheritance by MessageEndpointMappings. The goal was clearly to get rid of those. I'm very open to ideas which improve the migration scenario though.

[adamralph]

^{🎩 @Particular/rabbitmq-transport-maintainers}

I agree with @bording in that the RabbitMQ transport should be unaffected, and we don't need to add anything to it to support the config options that will be removed.

---

🎩 ^general

Big 👍 to removing config sections. An awful configuration method, which I have a deep hatred of.

[SeanFeldman]

No impact on Azure transports as we've encouraged from the latest versions of all Azure packages to move to code based configurations and on the transport level deprecated config sections.

[bording]

With the merging of #4716, this has been completed. All the ConfigurationSections have obsoletes that will be removed in v8.