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

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.

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.

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).

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:

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.