Managing support for older versions of .NET

Topics: General
Jul 27, 2012 at 6:08 PM

I've had some people complaining lately that trying to install my package (AutoMapper) for their project fails: 

Could not install package 'AutoMapper 2.1.267'. You are trying to install this package into a project that targets '.NETFramework,Version=v3.5', but the package does not contain any assembly references that are compatible with that framework. For more information, contact the package author.

But this version of the .NET Framework is supported by a previous version of a package. However, it's an older version of the project, and I don't want to bundle in an old version targeting an older framework to every new package.

To the package consumers, they ask why I don't support v3.5, but I do. Just not in the latest version.

Jul 27, 2012 at 6:15 PM
NuGet does not handle that scenario (checking which framework and then searching through older versions until it finds one that works). There are probably a few workarounds, but the best idea that comes to mind is for one to create a meta package named AutoMapper.Net35 (or something like that) and give it a dependency on the last version of AutoMapper that supported .NET 3.5

For illustrative purposes, say it was version 2. You would want that to be an exact version dependency as in:

<dependency id="automapper" version="[2.0.0]" />

Jul 27, 2012 at 6:25 PM

Interesting. Is this something that's worth adding an issue for? Because it now puts the burden on package consumers to know that they need to pull that older version. But maybe the searching is good enough to show that.

Jul 27, 2012 at 6:37 PM
Ugh. That is a horrible long term solution

-d

On Jul 27, 2012, at 13:16, "ferventcoder" <notifications@codeplex.com> wrote:

From: ferventcoder

NuGet does not handle that scenario (checking which framework and then searching through older versions until it finds one that works). There are probably a few workarounds, but the best idea that comes to mind is for one to create a meta package named AutoMapper.Net35 (or something like that) and give it a dependency on the last version of AutoMapper that supported .NET 3.5

For illustrative purposes, say it was version 2. You would want that to be an exact version dependency as in:

<dependency id="automapper" version="[2.0.0]" />

Jul 27, 2012 at 6:37 PM
Edited Jul 27, 2012 at 6:41 PM

I'm interested to know if you think there might be other options. Now that I think about it a bit more, we have curated feeds in nuget gallery. Wouldn't it be really nice if there was a way that differently targeted packages could automatically be added to curated feeds (per framework)? That would be a good issue to submit IMHO.

Curated feeds exist now for different IDEs. Here's the original discussion where curated feeds are talked about a bit: http://nuget.codeplex.com/discussions/354463 and here's the feature documentation - https://github.com/NuGet/NuGetGallery/pull/462
Jul 27, 2012 at 6:40 PM
Dru, I agree that it is. I know that long term folks want to eclipse support for frameworks, and folks using those frameworks should have a nice way of continuing to use NuGet without issues like this particular one. I think right now this is an issue because the impression is given that someone should continue to support new versions in all frameworks and that is not a viable real world option.
Developer
Jul 27, 2012 at 6:46 PM

When you search for packages, the server does get what target framework your project's targeting but we ignore it. Until recently, the server did not have access to this metadata, but we do capture it now so we should probably start using this. This way when a user searches for AutoMapper, we would show the highest version that targets your project's framework instead of the latest version all the time. 

In the meanwhile, a hackier workaround for the discoverability issue might be

a) Add an empty lib directory to your package that targets net35. We will now assume that this package targets 3.5.

b) Add a dependency to your package pointing to Automapper.net35. http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Dependencies_in_version_2.0_and_above

This way people installing the package in 4.0 or higher get the right binaries, and people using 3.5 would get the binaries from the 3.5 dependency. 

Jul 27, 2012 at 6:50 PM
Sounds like there has been a lot of progress in this area. Someone is thinking over there. ;)