Closed mot256 closed 11 years ago
Versioning + Strong-named assemblies + nuget delivery = nightmare
See Issue #2 for a discussion on this. If you can find a better way to handle the issues, I'd be glad to tackle it.
What I can gather from the post at NuGet is that (and I must admit I have not read the whole thing) it will only be a problem if a NuGet package references assemblies other than that of the .NET framework (e.g. when it references other NuGet packages it self). Ok, so that may be a problem if say other Nuget packages start using the EventSourceProxy package, and I use that other Nuget package(s) and another version of the EventSourceProxy package. But what I can gather is that the latest version of NuGet would auto create assembly re-directs to "solve" the problem, you just need to make sure that public interface of future EventSourceProxy assemblies are backward compatible. But that would need to be a rule even if the EventSourceProxy assembly is not strongly named (or else we will run into the age old DLL hell; which I think is now just called an assembly hell by the look of things).
If I recall properly, the consensus was that if the assemblies are compatible (i.e. new versions are backward-compatible), then the best strategy for strong named assemblies was to keep the assembly version the same and just update the file version.
When an incompatible version is released, then you update the assembly version so things can bind separately.
Same old assembly hell. :)
I have noticed that the EventSourceProxy assembly's version stays at version 1.0.0.0 and does not match the version of the NuGet release. Not a problem for me now, but may result in versioning issues in the future.