1

I have a solution with many projects, about a dozen of which have Octopack installed and packages are being produced correctly when TeamCity runs msbuild /p:RunOctoPack=true /p:OctoPackEnforceAddingFiles=true. As you can probably tell from the p:/OctoPackEnforceAddingFiles flag, each project with Octopack installed also has a nuspec file.

The problem we're having is that Octopack is not honouring the nuspec placeholders as specified at https://learn.microsoft.com/en-gb/nuget/reference/nuspec#replacement-tokens. The one we want to use right now is $id$ which should equal the assembly name of the project being packaged. Instead, when we run Octpack, that $id$ token is empty.

I can see at https://octopus.com/docs/packaging-applications/creating-packages/nuget-packages/using-octopack#UsingOctoPack-Replacementtokens that Octopack allows one to manually override these tokens, but that doesn't help me since Octopack is run on the solution, but I need the name of the project that is being packaged.

What can I do to get around this issue? At the moment we essentially have the project name hardcoded in the nuspec files, but this is becoming brittle and unwieldy and we'd like to fix it.

Richiban
  • 5,569
  • 3
  • 30
  • 42

2 Answers2

2

I have this working by adding the following to the csproj file

  <PropertyGroup>
      <OctoPackNuGetProperties>id=$(AssemblyName)</OctoPackNuGetProperties>
  </PropertyGroup>

This passes the assembly name through as id to Octo.exe, which will in turn pass it through to NuGet.exe via its -Properties argument.

Shannon Lewis
  • 76
  • 1
0

Have you tried not providing the $id$ section at all in NuSpec? Octopack should try and generate it (it knows what it is being applied to)?

Alternative could be to use the pre-build event with the $(ProjectName) macro to update the relevant nuspecs. In your case, depending on your build process, potentially sticking to a solution wide pre-build process to update all nuspec's.

P.S. I personally stepped away from using Octopack and currently employ Fake (F# Make).

Alex M
  • 2,410
  • 1
  • 24
  • 37
  • Thanks for your answer @Alex M. I'm vaguely familiar with Fake, but I'm curious as to how this could replace Octopack? As far as I can imagine right now, even if we used Fake for our build process the Fake pipeline would still call Octopack at some point. – Richiban Mar 09 '18 at 10:40
  • 1
    A note, I'm not advocating for you to stop using Octopack, as it might involve some setup effort, but basically octopack is just a wrapper around nuget.exe. If you get rid of it then all you need to do is pack the required files manually, where `Fake` is closer to native approach. – Alex M Mar 09 '18 at 12:15