OctoPack'ing 1 project in a solution with multiple OctoPack-enabled projects

(Jesse Beard) #1

I have a solution with several OctoPack-enabled projects. When building against individual projects using msbuild and setting the RunOctoPack variable = True, etc., all projects in the solution that are using OctoPack get packaged. I’m not sure there is direct support to control this. In TeamCity, my VCS root points at the solution level, so all source is on disk for the entire solution when building, but msbuild is only targeting a single .csproj. Any way to target a single project with OctoPack and have the others not run aside from manually manipulating files?

(james.glinsek) #2

I have this problem too now. My scenario sounds pretty much the same. We have one solution with many projects. Some projects are deployable apps/sites (via OctoPack and Octopus) and others are just class libraries.

We have one Project that is a Console/Service application which takes a project reference to one of our Web Application projects. Both are now deployable independently via Octopus. However, since adding Octopack to the Web App, the Console app ends up with 2 artifacts (a nupkg for the Web App and a nupkg for the Service) and given that the console app is alphabetically after the Web App, the service nupkg is not available in the nuget feed from TeamCity.

Example:

When I build the Web App, (TeamCity build version 1.0.40) I get an artifact called AWeb.App.1.0.40.nupkg

When I build the Console App, (TeamCity build version 1.0.80) I get 2 artifacts, one called AWeb.App.1.0.80.nupkg and another called SomeConsole.App.1.0.80.nupkg.

So, the end result is really screwed up.

In Octopus, the latest version of SomeConsole.App is no longer shown when I try to create a new release for this project. But, when I create a new release for the Web.App, the version created by the Console App build is shown (which is not at all what I want).

So, at this point, I can’t deploy my SomeConsole.App at all and I can deploy the Web.App but the versioning for that thing is now a mess.

Any suggestions or workarounds?

(james.glinsek) #3

OK, so some more information about my situation.

The reason my SomeConsole.App wasn’t showing up in the feed in Octopus was a separate issue (some kind of naming issue with NuGet packages and Console apps - my console app was in the feed with 3 different names somehow and now sure why - but once I found the right one this is working again).

Also, as a workaround to the versioning mess with the web app, I changed my Build Number Format for the Web App to 2.0.{0} (instead of 1.0.{0}) and left the Build Number Format at the default for the Console App. So, the Web.App still ends up with a bunch of extra versions in the list, but the 2.0.x version appear at the top of the list and the invalid builds (from building the Console App) end up buried in the middle of the list which makes things tolerable.

Would still like to have a better solution to this problem though.

(Paul Stovell) #4

A workaround for this would be to modify the .csproj files to do something like:

In the Web.csproj file:

<PropertyGroup>
    <RunOctoPack Condition="'$(OctoPackWebApp)'=='true'">true</RunOctoPack>
</PropertyGroup>

In the Console.csproj file:

<PropertyGroup>
    <RunOctoPack Condition="'$(OctoPackConsoleApp)'=='true'">true</RunOctoPack>
</PropertyGroup>

Then when calling MSBuild, instead of passing /p:RunOctoPack=true, you could pass /p:OctoPackConsoleApp=true OR /p:OctoPackWebApp=true. This should scope the settings to the project rather than the solution.

If one project is being built when another is built, this might be because a dependency exists between the projects and MSBuild is building the dependent projects first.

Paul

(Jesse Beard) #5

Paul your workaround actually sounds pretty good to me. I will try it immediately tomorrow and see how it goes.

(james.glinsek) #6

Thanks for the quick response Paul. Great product, great support.

Your solution works perfectly. In my case, I only needed to modify the Console app (and associated TeamCity build) since it is the project with the reference to the Web app. And based on my MSBuild logs you are correct about MSBuild and what is causing this.

(corina) #7

Hi, guys!

I also have this problem. I did what Paul said in his answer, but, somehow, Octopus is not packing the files anymore, therefore, there is no “push” instruction, and the package cannot be found on the Octopus Server. What is strange is that in Jenkins, the build finishes with Succes, although the Octopack is never run.

Thanks,
Corina.

(Dalmiro Grañas) #8

Hi Corina,

Thanks for reaching out. Could you share us your build log from Jenkins, along with the csproj file of the project you do want to pack?

You can send us that info to support@Octopus.com if you dont it public on this thread.

Thanks!

Dalmiro

(system) closed #9