1
Vote

version should be optional in .nuspec file

description

Currently the version is a required element in the nuspec files. Since we (and probably other people as well) build the nuget packages on the build server, we always call nuget.exe pack mypackage.nuspec -version x.y.z.

It would be cleaner if the version could be omitted from the nuspec file. The scenarios could then be:
Given the version element is specified in nuspec file with value 1.0.0
When executing nuget.exe pack without the -version parameter 
Then the nuget package should have version 1.0.0
Given the version element is specified in nuspec file with value 1.0.0
When executing nuget.exe pack with the parameter -version 2.0.0
Then the nuget package should have version 2.0.0
Given the version element is not specified in nuspec file
When executing nuget.exe pack with the parameter -version 2.0.0
Then the nuget package should have version 2.0.0
Given the version element is not specified in nuspec file
When executing nuget.exe pack without the -version parameter 
Then the error "Version is required" should be thrown

comments

dotnetjunky wrote Jul 29, 2013 at 12:42 PM

You can set the version as <version>$version</version>

FilipDeVos wrote Jul 29, 2013 at 2:48 PM

$version refers to the assemblyversion, which is not the actual version of our component (due to strong naming requirements).

dotnetjunky wrote Jul 29, 2013 at 3:49 PM

I know, but if you pass the -version argument to the pack command, it will be applied to the $version$ token.

FilipDeVos wrote Jul 29, 2013 at 5:14 PM

ah, excellent, didn't know that one.

FilipDeVos wrote Jul 29, 2013 at 5:37 PM

Well, actually, executing nuget pack mypackage.nuspec -version 2.0.0 will overwrite whatever version is specified in the .nuspec file (including the $version substitution).

dotnetjunky wrote Jul 29, 2013 at 6:50 PM

Yes. Isn't that what you want?

FilipDeVos wrote Jul 29, 2013 at 8:34 PM

This is not really what we want.

We can not use the AssemblyVersion for package version because we need to keep a stable revision. (So we can copy paste deploy new revisions of a strong named dll).
This means we create the package on the build server with the AssemblyFileVersion as package version, but currently that means the "version" stored in the nuspec file has no correspondence with the actual desired version of the package (unless the file is kept up to dat manually) and any "dummy" version stored in there will bite us in the future.

If we can omit the version from the nuspec file it is clear; if someone calls nuget pack without specifying a version number, the operation will fail.

FilipDeVos wrote Jul 29, 2013 at 8:47 PM

I am happy to code this if the feature is accepted.

dotnetjunky wrote Jul 30, 2013 at 6:26 AM

I'm still not clear. If you set the version with the $version$ token, and always pass the -version parameter to the pack command, it achieves what you want. You will not get the version from VersionAssembly attribute.

Am I missing something?

FilipDeVos wrote Jul 30, 2013 at 8:07 AM

The issue is that people mess things up. Currently it will silently grab the version in the nuspec file. There is no option to make the command fail when somebody makes a mistake (and thus notify them that they made a mistake).

The only way I have now to make sure that things look ok when somebody makes a mistake is enforcing that the version in the nuspec file is kept in sync with the assemblyfileversion (with a build action I suppose).

dotnetjunky wrote Jul 30, 2013 at 7:15 PM

OK, I agree this is a reasonable change. Please feel free to work on it. Let us know if you need any help.

dotnetjunky wrote Jul 30, 2013 at 7:16 PM

Please make sure the change only impact the nuget.exe 'pack' command, and not to the core library.

FilipDeVos wrote Jul 30, 2013 at 8:16 PM

Will do

jeff_winn wrote Aug 6, 2013 at 7:28 PM

I ran into something similar myself a few minutes ago. Basically, we're doing local deploys of our internal assemblies to a folder and using nuget to update them to our applications on an ad-needed basis.

Simply using <version>$version$</version> in the nuspec file isn't enough since all of our common assemblies use the same assembly version so we don't have to constantly update the config files. We only do that when we do a major or minor change to this common area. If all we have is this one token replacement, it makes it very difficult to cycle one of the DLLs that needs a patch without having to redeploy everything.

For example:
You've got two assemblies, each that cycle independently of each other, say A.dll and B.dll, and B.dll has a dependency to A.dll. If you have the following in your dependencies section of the B.nuspec:
<metadata>
  <version>$version$</version>
  <dependencies>
    <dependency id="A" version="$version$"/>
  <dependencies>
</metadata>
If you're tied to the version number here, you'll inadvertently force the dependency for B to require the new version as well in A, even if you're only making a minor revision change to B. What I found is by adding another token for replacements $fileversion$ and putting that in the <version/> element, you can keep the assembly version the same at 1.0.0.0 while allowing the file version to increment to 1.0.0.1 and not have to push out more than 1 update to your local NuGet folder.

All I did was add the new token fileversion, put that in my version element in the nuspec, and get it wired up to the metadata objects so it could be pushed around in the code and used.