Hi, I will demonstrate my problem through a concrete example.
I have been developing an Entity Framework based tool that currently supports every .net40<= release. Now, If I wanted to add .net45 specific features, I could just create a .net45 platform directory in the NuGet package and place a separate assemby in it. In
the past, Entity Framework releases were tied to the release of .NET framework releases. This is about to change, EF is going to be released separately.
The platform directory solution will not work anymore since my library has to be recompiled against EF6 separately too, and this follows that EF6 will become a NuGet package dependency. I do not want to enforce the users to have the latest release of
EF and I want to support legacy EF versions as much a possible.
So I would publish 4 different releases for my library:
- depends on .net 4.0
- depends on .net 4.5
- depends on .net 4.0 and ef 6
- depends on .net 4.5 and ef 6
How should I organize my Nuget package? Currently my best shot is to have a separate package id for 3 and 4, but I want to avoid this. Also, what should be the proper versioning schema for this?
Remember, my key requirement is to not enforce updating EF, so if someone executed a package update (e.g. update-package cmdlet) the process should not update the EF package, just download and reference the most appropriate release of my library. I could
not find out how to achieve this in Nuget.
This feature would be good for other framework too. Let's assume a company uses "Foo" as an essential component. A 3rd party developer is developing a "Foo.Ex" component that extends the functionality of "Foo". The company wants
to use the latest version of "Foo.Ex", but does not want to use the latest version of "Foo", because it contains some breaking changes (that might be completely unrelated to Foo.Ex).