publishing multiple versions of nuget package

Nov 2, 2011 at 4:32 PM

i have a v1.0 nuget package that I've been publishing to a private feed and have noticed that when i have a 1.0.1.0 published and come along and publish a 1.0.2.0 then users viewing the available packages will only see the latest published version in the nuget package manager visual studio extension.

I'm now ready to start work on a v1.5 release of the nuget package but need/want to keep the v1.0 package accessible on my private feed so that only users requiring the v1.5 release work changes and feature additions need select and use that version.

Is there a recommended solution for getting multiple minor and/or major versions of a nuget package advertised in a nuget private [ and public ] feed so vsix package manager lets them choose and nuget.exe install command line processing selects the correct version as well?

Coordinator
Nov 2, 2011 at 5:48 PM

Hi Robert,

I didn't understand the last part of the question. What does the "vsix package manager" have to do with anything here?

As to the rest of the question, right now there's no way to do that other than to make them separate packages with unique IDs. The NuGet dialog only shows the latest version of a given package. If you want to install a previous version, you can drop into the Package Manager Console and install any version of a package.

NuGet 1.6 will support a feature for marking packages as "pre-release" which would allow you to have 1.5 in the feed, but 1.0.2 would still show up for everyone else. Only those who use the -prerelease flag would see 1.5.

Nov 2, 2011 at 8:38 PM

When i mentioned "vsix package manager" i was referring to the Nuget.Tools.vsix extension that adds the <project> |  "Manage Nuget Packages..." UI.

Sounds like in this case i need to incorporate major.minor version details in the .nuspec <id /> element.

One possibly problematic result of the current setup.  Lets say i add a nuget package using the gui, say a version 1.0.4.0, and then configure my project to use a "nuget install ..." prebuild event so that on other dev/test wks and tfs build machines it will automatically pull down the package versus using source control to maintain the binaries.   In that case if i come along and publish a 1.0.5.0 then the "nuget install ..." commands are going to pull down the latest 1.0.5.0 drop, even if i leave the 1.0.4.0 package on the publishing drop site, and as a result the hint path settings in the csproj file will no longer be correct as they contain the version in the path.   Is that a known issue or is "nuget install ..." smart about pulling down the specific package version and not the latest published drop?

Thanks for details on nuget 1.6 -prerelease behavior.   Sounds like that addresses allowing vNext release work scenarios to happen without breaking folks bound to currently shipping release.

Developer
Nov 3, 2011 at 12:16 AM

Sounds like in this case i need to incorporate major.minor version details in the .nuspec <id /> element.

That doesn't sound right. Users wouldn't be able to upgrade between versions in that case. If that is what you intended then you should look at a more meaningful convention to define your packages.

nuget install ..." prebuild event so that on other dev/test wks and tfs build machines it will automatically pull down the package versus using source control to maintain the binaries. In that case if i come along and publish a 1.0.5.0 then the "nuget install ..." commands are going to pull down the latest 1.0.5.0 drop

If you're using the package restore feature or installing by pointing to a packages.config file, we will not auto-update your packages. The version that is installed by nuget.exe is the specific version that is specified in packages.config.