9
votes

Trying to get my Service Fabric application building on a build server. When I build the .sln file, the sfproj's Package target is not run. As expected. I cannot seem to get MSBuild to run this target.

First, the only targets available when building against the .sln file are the standard Build and Publish targets.

Second, building against the .sfproj itself DOES get the target running. However, because of the mismatch of $(BuildPlatform), the projects referenced by the .sfproj do not build correctly. The .sfproj has a x64 platform. Most of my other projects are Any CPU.

This is less of a Service Fabric question and more of a general MSBuild question, I suppose. I'm looking for a solution that does not require me to unify all my project's Platform options. Service Fabric REALLY IS x64 only, and my other projects REALLY ARE Any CPU.

[EDIT]

I solved this. What I did was add a new Target to the .sfproj file, called MaybePublish, and I set it as one of the default targets. MaybePublish has a Condition for '$(Package)' == 'true'. It has DependsOnTarget set to Package. Basically, this target optionally packages the Service Fabric application, if a property is set when building the solution.

It occurs to me this is probably how the DeployOnBuild stuff works in the Web publishing projects. The Service Fabric target files should have this type of support by default.

5
Please move your answer from the question to an answer and consider accepting it.Tom Blodget

5 Answers

9
votes

To help clarify wasabi's answer. Here is what I did to get this working.

I added the following Target to my *.sfproj file

<Target Name="CreatePackage" Condition="'$(CreatePackage)' == 'true'" DependsOnTargets="Package" />

I also modified the Project element DefaultTargets attribute value to be Build;CreatePackage.

To create the package as part of my automated build, I included /p:CreatePackage="true" as an argument to my build solution step.

3
votes

You can also perform the package step by running MSBuild on the sfproj with the /t:Package switch.

1
votes

I solved this. What I did was add a new Target to the .sfproj file, called MaybePublish, and I set it as one of the default targets. MaybePublish has a Condition for '$(Package)' == 'true'. It has DependsOnTarget set to Package. Basically, this target optionally packages the Service Fabric application, if a property is set when building the solution.

It occurs to me this is probably how the DeployOnBuild stuff works in the Web publishing projects. The Service Fabric target files should have this type of support by default.

0
votes

Try the following commands:

msbuild yours.sfproj & msbuild /t:Package yours.sfproj

The first part builds the SF project as well as all its referenced projects. The second part packages the SF application.

0
votes

This can happen after if the reference to Microsoft.VisualStudio.Azure.Fabric.MSBuild.x.x.x has the incorrect version number for example if you have just created your cluster application and then run a Update-Package from the Package Manager Console.

Check your package folder. The name of the folder "Microsoft.VisualStudio.Azure.Fabric.MSBuild.x.x.x" should match the reference in the sfproj file. If the build number does not match, do a search and replace in your sfproj file.

You should now be able to build your project