OctoPack creates NuGet packages with the wrong assembly version

I have two projects A and B. Both references System.Net.Http.Formatting.dll, but A via ASP.NET and B by Web API installed via NuGet. So project A references V4.0 while project B references 5.2. When NuGet packages are created, project A and B both are packed with v4 so project B fails on production.

The automatically generated nuspec file for project B shows that the assembly is being copied from the solution’s root directory instead of the project’s own directory. One thing I don’t understand is that project B is built after A and it’s NuGet Restore enabled so by the time B is built the assembly must have been replaced by V5.2. The solution root folder has V5.2 so I have no idea where the v4 is coming from. Maybe cached?

Is there a way to instruct OctoPack to pack assemblies from each project’s own folder instead of the root folder of the solution? I would think it’s natural to pick up files from project’s own folder because OctoPack is installed at project level.

One other thing is that OctoPack behaves correctly when I build it on my local machine using MSBuild. But it fails on TFS build.

Hi!

Thanks for getting in touch. Looking at the OctoPack source code I can see where the binary files are being added to the .nuspec file: https://github.com/OctopusDeploy/OctoPack/blob/master/source/OctoPack.Tasks/CreateOctoPackPackage.cs#L177

It looks like it should be grabbing the private assemblies from each project. I have not used TFS in quite some time personally, but I do recall that it used to build all projects into the same output folder. If that’s the case here, it would explain the mixed up private assemblies.

The one argument against that theory is that you mentioned you could see the path in the .nuspec file.

Could you post through the two different .nuspec files, one created by TFS and one by your development machine? The differences might help us diagnose what is going wrong.

One other thought is that perhaps the OctoPack source code might help you diagnose what is going wrong more quickly than going back and forth with me over email? Octopack doesn’t do anything terribly complex, it just tries to decide what should be packaged based on the project content.

Hope that helps!
Mike

Michael,

Yes, you’re right. It looks like it’s because the built assemblies are dumped in the same directory in TFS but I still don’t understand why the project builds later picks up an assembly from the project builds before. I’ll probably have to look at the source code when I have time.

I’ve found two ways to solve this issue. Either by setting GenerateProjectSpecificOutputFolder to true or using nuspec file to speficy the location for each project that need to package. I landed on the second option because the first option requires too much disk space.

By the way, I’d like to have a way to instruct OctoPack to pick assemblies from specific location so I don’t have to use nuspec file manually.

Thanks for your help.
Jake

Hi Jake,

I’m glad that worked out OK. I typically end up using an option like GenerateProjectSpecificOutputFolder because it behaves most like our local development environments, disk space notwithstanding, but that’s just my preference.

There is an option with OctoPack where you can specify a .nuspec file, and it will use that as a baseline and merge other content on top of that: OctoPackEnforceAddingFiles

Hope that helps!
Mike