Csla 6 fluent configuration - should all of it be in the Microsoft.Extensions.DependencyInjection namespace?

[TheCakeMonster]

We've got a bit of a mixture of namespaces going on in amongst the fluent configuration code. Some is in Csla.Configuration and some is in the Microsoft.Extensions.DependencyInjection namespace.

It feels like a slightly strange thing to do to use someone else's namespace; it risks class name clashes, so it's not something we are used to doing. However, it does seem to be fairly common practice for a library's configuration code to be in the Microsoft.Extensions.DependencyInjection namespace, so that it almost automagically appears in intellisense in Startup.cs/Program.cs.

The benefit of the consistency across all of it is that either all the configuration is available, or none of it. At the moment I think I saw some be unavailable until I added the Csla.Configuration namespace, but some subset of it be available straight away. This is always a bit of a risk with extension methods that are in a different namespace to the types they extend.

I recommend a change to achieve consistency. I suggest Microsoft.Extensions.DependencyInjection as the thing to change it to, but Csla.Configuration would make sense too.

[rockfordlhotka]

I'd rather have the CSLA types be under the Csla namespace to avoid the issue you discuss. Polyfills would be the exception, otherwise I think people shouldn't be intruding into others' namespaces.