Cannot version packages in a multi-project solution

I have a solution with 2 MVC projects which map to 2 projects in OctopusDeploy. I’m creating a nuget package for each solution in a TFS build. TFS build workflow is also taking care of versioning the assemblies for me. All that works great, however, of the two nuget packages that get created only one has the correct version number in the package name while the other is stuck on 1.0.0. I’ve done everything imaginable but can’t get it to update. I even tried creating a simple dummy project but it looks like it the version doesn’t apply when there are more than 1 packaged projects in a single solution. I’m ultimately trying to have my assembly version, nuget package version and Octopus Release version match.

Has anybody run into something similar?

UPDATE This appears to be an issue with OctoPack version 3.0.20. v3.0.19 packages and versions as expected.


How are you setting the version number of the NuGet package currently? Using /p:OctoPackPackageVersion=XYZ?


Hi Paul,
No, i’m not using the OctoPack switch for versioning. Basically my setup is as follows. I have a global assembly info file shared between 2 MVC projects. I’m using TfsVersioning build template to find the shared file, modify the assembly version attribute and build the solution.

My .nuspec packages contain 1.0.0 for both packages. When i check the drop folder after build i’m actually seeing the assembly version matching the version in the nuget package name for one project (My.Project.UI.1.0.5165.43108,nupkg), but the other one remains at 1.0.0 (My.Other.Project.UI.1.0.0.nupkg)

I initially thought there is an issue with the second project, so i added a dummy web project to the solution and set it up for nuget package creation. I saw the exact same issue. One project gets versioned. The new one does not.

I’m also using the following build file from TFS. I don’t think it’s an issue, but here it is for what it’s worth.


<?xml version="1.0" encoding="utf-8"?>

$(MSBuildThisFileDirectory)bin Release OutDir=$(OutDir); Configuration=$(Configuration); @@@

Finally figured it out and it appears to be a bug in the latest OctoPack release.
One of the projects was referencing v3.0.19 while the one that wasn’t generating the correct version was v3.0.20. Downgrading to v3.0.19 fixed the issue. Does anybody know what’s up with the latest release?


When you don’t specify the version explicitly, there are three places OctoPack can get it from:

AssemblyVersion attribute
AssemblyFileVersion attribute
AssemblyInformationalVersion attribute

In OctoPack 2.X, we always took it from AssemblyVersion. In 3.0.19, we added the ability to get it from AssemblyInformationalVersion, falling back to AssemblyVersion, but there was a bug - it actually fell back to AssemblyFileVersion instead. So in 3.0.20 we fixed it - we now use AssemblyInformationalVersion, then AssemblyVersion.

When you set the version of the assembly in your solution level file, which attribute are you setting?