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