Namespace and assembly names when porting .NET code between platforms and technologies

Question

I have a few (over 50) .NET Framework assemblies that I've developed over time. I've always followed the convention to name my assemblies after the root namespace in the application. For example, I have an app called Bundt, so its root namespace is Incipit.Bundt. Assemblies in this application are named Incipit.Bundt.ModellingEngine, Incipit.Bundt.ModelDesigner, etc.

Now I am planning to port some of this code to .NET Core. In addition, some of these assemblies are WinForms applications, which I will be porting to WPF. My intention is to keep both versions of the software, the old and the new, and use them in different scenarios.

I am not sure how namespaces and assembly names should be handled when porting. Should I keep them the same, or should I rename them to reflect the new platform (Core rather than Framework) or technology (WPF rather than WinForms)?

For example, I want to port the Incipit.Bundt.ModellingEngine library from .NET Framework to .NET Core. Should I keep the same namespace and assembly name, or shall I change it? Similarly, I want to port the Incipit.Bundt.ModelDesigner WinForms executable from .NET Framework to .NET Core, and make it a WPF application. Again, should I change the namespace and assembly names to reflect this?

Any pointers to porting best practices will be very welcome. Thank you.

Answer 1

Question #1

Should I keep the same namespace and assembly name, or shall I change it?

Let's split this question to two:

• What problems could it cause if I would use the same naming?
• Which naming would generate more work on the consumer-side?

Let's start with the former one. It is unlikely that someone wants to use both of your assemblies in the same application

• Either choose the old one or the new one
• So, this could not cause assembly ambiguity

What about the latter one? Let's suppose that your ported library can support .NET Standard 1.2. That allows us to use this library in a .NET Framework 4.6+ applications.

• If that application can upgrade without any naming caused breaking change then that's the best
• If the application upgrade requires refactoring on the using statements then that's not that good

Side-note: If you can port your library to .NET Standard 2.0 (which supports apps with 4.6.1+ .NET FW) then there is a good chance to deprecate the old library and use everywhere the new one.

Question #2

Should I change the namespace and assembly names to reflect this?

As far as I understand your example you can't use the new library in Winforms application and you can't use the old one in WPF. So, they can't be used in the same application.

This question is more opinion-based IMHO. You can definitely use the same name and will not cause any harm. But if you would rename it then that could give clarity where it suppose to be used.

Question #3

This question is raised by me

What if I publish these assemblies via nugets?

Well in this case it can cause problems if you would like to use the same name, because you can't have multiple nuget packages with the same name.

How to solve this problem? Here are the options:

• Use the same assembly and namespace names but use different nuget package name via the .nuspec file
• Use different major version for the new ported library