The current List&Label version is included in the namespace. I.e.
combit.ListLabel20
combit.ListLabel20.ListLabel
While there might be some good reasons to do it this way this is pretty much inque for every other third party library I know in the .NET eco system.
Let's say I am planning to write a DataProvider or any other List&Label extension and publish it on NuGet I have to compile it agains every single ListLabel version because
Absolutely valid request, however we have many customers who work with multiple versions in parallel. Think of large applications that are updated step by step. Changing to one namespace would prevent this from working. However I’m curious to read what others think about this.
Since you already deploy multiple versions of List&Label maybe it would be a good solution to keep everything as usual but for nuget switch to a more modular approach with a combit.listlabel.core package (without version in it’s namespace) and multiple extension packages (combit.listlabel.dataproviders / combit.listlabel.mysqldataprovider / combit.listlabel.sqlitedataprovider) with it’s own dependencies.
I absolutely aggree with @Juergen_Steinblock.
In my web project I need only the listlabelXY.dll and not the listlabelXY.web.dll. Because we use the browser integrated pdf UI. Also I use only one data provider. So I would prefer modular nuget packages.
I think, the version number is also not neccessary in the assembly name.
I’ll put the “modular package” approach on the radar of our deployment team. However, we’ll probably not be able to remove the version number from the assemblies and namespaces as many fellow developers would kill us if we removed the possibility to have several versions in parallel .
You should consider the Version independent assembly optional. Besides the version specific assemblies
combit.ListLabelXX.dll
there could be another version
combit.ListLabel.dll
which would be updated with every version.
This way I could still use
combit.ListLabel23.ListLabel (Version 23.x)
combit.ListLabel24.ListLabel (Version 24.x)
combit.ListLabel.ListLabel (Version 24.x but will be updated to 25 etc.)
in the same assembly without breaking the current approach for everyone else but still have the choice to just use generic combit.ListLabel.ListLabcel class.
As a benefit updates would be easier and even publishing version independet extensions to nuget would be possible.
Good idea indeed. However, it would bring in a huge number of conditionals in the source code as we’d have to change the namespace names (and all references to namespace names), too, depending on the current build configuration. Currently, I’m getting 1195 hits when searching for combit.ListLabel25 in our .NET code base. All of those would need to be changed/wrapped in #if ... #else...#endif statements . While you can easily change the default namespace, there doesn’t seem a way to switch it based on a build parameter (or I’m too blind to find it).
One option might be to wrap a using namespace alias on top of each file into ifdef and then use the alias everywhere.
.
. While you can easily change the default namespace, there doesn’t seem a way to switch it based on a build parameter (or I’m too blind to find it).