Can't build two nuget packages with different values for the same octopack commandline parameter

Legacy Uncategorised
1

I have a teamcity build configuration with 3 build steps:

  1. NuGet installer, points to a .sln file
  2. Build web application - MSBuild runner targeting project1.csproj (for simplicity) where a project1.nuspec file with a sections exists as well
  3. Build class library - MSBuild runner targeting project2.csproj, again, a project2.nuspec file with a section exists as well

Both project1 and project2 have octopack installed, and are configured with, respectively:
/P:Configuration=Release /p:OctoPackNuGetProperties=suffix=Release /p:OctoPackEnforceAddingFiles=true
and
/P:Configuration=Release /p:OctoPackNuGetProperties=suffix=Release /p:OctoPackEnforceAddingFiles=false

What I want to achieve is:
The web application in step 2) is built with octopacks “default include files” AND the few selected files I have specified in the section - and the output is placed in Project1.nupkg
Secondly, the class library is built without the “default include” - so only the files specified in the sections should be present in the Project2.nupkg package.

What I experience is:
The value of the last OctoPackEnforceAddingFiles=false is applied to BOTH build steps. So either I get both packages with ONLY the files specified in the nuspec files, or I get both packages with “default files” AND the nuspec specified content.

What have I tried?
If i disable the last build step (3), I can get the output in build step 2) the way I want it by toggling the true/false command line parameter. So that part works. As soon as I enable the last build step, it is the value of the command line parameter in that build step, that determines how both build steps behave.

Does anyone have an idea how to proceed? Build step 3) produces output that I dont want in the nupkg file, so I have to set OctoPackEnforceAddingFiles to false. And I want project1 to have everything “default included” as well, so that one needs to have it set to true.

Any help would be very much appreciated :slight_smile:

Best regards
Jan Hansen

2

Hi Jan,
When you run the build on the solution level, only the one set of Octopack arguments that are supplied are used during Octopack’s execution, even though its installed separately on each project at that level. To force the projects to be packaged using octopack with different arguments, you will need to adjust the PropertyGroup section of the .csproj file.
For example in project2.csproj

<PropertyGroup>
<OctoPackEnforceAddingFiles>true</OctoPackEnforceAddingFiles>
</PropertyGroup>

etc.
Check out this thread for a sample config by Henrik (provided for a slightly different but related problem) that would be set on the .csproj itself. The key is that these different configs need to be set in the project files themselves. Give this a go and let me know if you run into any further problems.
Robert

3

Hi Rob

Thank you for your prompt response!
We might be misunderstanding each other here - I don’t run the build on a solution level - only the first build step, in order to restore the nuget packages used by the entire solution. No octopack parameters are specified here.
After that, the two second build steps (MSBuild runner) builds on a csproj-level, with individual octopack parameters. Like this

  1. restore nuget based on .sln file
  2. build project1.csproj /p:OctoPackEnforceAddingFiles=true
  3. build project2.csproj /p:OctoPackEnforceAddingFiles=false

no matter the value of the parameter in build step 2, it is always the value from build step 3 that is effective for both build steps. Kind of strange, I think, it looks like an error.

However, specifying the desired behaviour directly in the two csproj files as you suggest actually works, so my problem is solved for the time being. Still, I suspect that an error in either octopack or teamcity is lurking just below the surface. Is this the correct forum to verify and report that?

Again, thanks a lot for your help!

Best regards
Jan

4

Hi Jan,
Glad to hear you have your builds working correctly now. So that I can try and uncover the root problem however, could I get you to please send through more detailed screenshots/info regarding how you have your build set up. It seems quite strange that there would be any sort of leakage between different steps like that. If there is something inherently wrong with TC or OD then it would be definitely good to know!
Thanks again for your feedback,
Cheers
Robert

5

Hi Rob

I’ve prepared some screenshots for you as well as some .csproj and .nuspec files.

I’ll try to explain the setup :slight_smile:

There are now 4 build steps (see “build steps overview”). The last two are practically identical, just different “customization modules” to the system. I suddenly got another strange error - we might see that later if we fix the first one here, so I have disabled the last step for now while debugging this. In short, this is what I have:

  1. restore nuget packages, points to a .sln file which has 4 csproj files (DAL, UI, custom1 and custom2)
  2. build UI, points to .csproj, has octopack nuget package installed
  3. build custom1, points to .csproj, has octopack nuget package installed

What works:
It works if I add the OctoPackEnforceAddingFiles property to the .csproj files mentioned (not the DAL.csproj - it is only a project reference) as you suggested, and I specify “true” for the UI (build step 2) and false for the customization build (step 3). This gives me the desired result:

  • The UI package contains all default content files AND the ones I specify in the .nuspec file
  • The Custom package contains ONLY the files specified in the releavant .nuspec files.
    This is illustrated in “build 22 artifacts”. This is what i want.

What doesn’t work:
Then I went ahead and commented the XML notation out in the csproj files, and added, respectively, to the build configurations

  1. no commandline parameters, no change (see build step 1 configuration)
  2. /p:OctoPackEnforceAddingFiles=true (see build step 2 configuration)
  3. /p:OctoPackEnforceAddingFiles=false (see build step 3 configuration)

i.e. the same as what I had previously specified via XML.

The output of this build is illustrated in “build 23 artifacts”. As you can see, both packages now ONLY contains what is specified via the .nuspec file. So it looks like the last commandline is somehow applied to both build steps.

So, now I change the parameter in step 3 from “false” to “true” and rebuild in teamcity. You can see the revised configuration in “build step 3 configuration - 2”
The output of this build is illustrated in “build 23 artifacts - 2” and as you can see both packages now contains ALL content AND what is specified via the nuspec file.

Last attempt: I change the parameter in step 2 from “true” to “false”, while I keep the paremeter in step 3 as is, i.e. “true”. Now we should get less content i the UI package, and too much in the custom packages. The revised step 2 configuration is in " build step 2 configuration - 2" and the build output is in “build 23 artifacts - 3” - as you can see this is identical to the previous artifacts listing.

So, all in all: the first parameter (in step 2) is ignored as the latter (step 3) seem to override it. Strange.

I have attached all the screenshots, build logs, csproj files and nuspec files for your “investigative pleasure”… :slight_smile: If you need anything else, please let me know.

investigation.7z (1 MB)

6

Hi Jan,
One cause that has been suggested is that potentially your second project, since it has a dependency on the first, is possibly triggering octopack to execute on the first project but passing through the “wrong” parameter (as a result of it being called via the 2nd step). By hard coding the value as I suggested this fall through wont be taking place. When project1 is rebuilt as a result of the dependency in project2, the artifact that were produced as a result of step1 (where project 1 was built on its own) may be getting overridden. Perhaps check timestamps, or try to put a delay between the steps to give you enough time to check if the project1 package is indeed getting overwritten. This may explain the behaviour you are seeing.
Cheers,
Robert

7

Hi Rob

A bit late - but you were spot on. I’ll leave the “hardcoded” values in the .csproj files - it is not a problem in any way, as long as I understand what happens :slight_smile:

Thanks a lot for your help!

/Jan