When do I need to pass MSBuild a solution file?

Question

From the command line, when would I call MSBuild directly on a project, and when would I call MSBuild on the projec's sln file, passing /t:Build /t:ProjectName?

Example: I have a simple solution containing several projects (A, B, C, ...). Development is done through the VS GUI, by opening and working with the solution.

Now, in a specific automated case, I want to build just project B from the command line:

What should I call?:

(a) MSBuild "my.sln" "/t:Build" "/t:ProjB" "/p:Configuration=Release" "/p:Platform=Any CPU"

(b) MSBuild "ProjB.vcxproj" "/t:Build" "/p:Configuration=Release" "/p:Platform=Any CPU"

• Will there be any difference in the outcome?
• Could there be any additional setting in the sln file that gets missed this way? (I certainly don't see any additional info in our VS2015 sln file.)
• If the solution is large, but ProjB has little interdependencies with other projects in the solution, will one option be faster in general?

Answer 1

What should I call? Will there be any difference in the outcome? Could there be any additional setting in the sln file that gets missed this way?

It`s deepens on how did you express the dependencies between projects, use the solution to express dependencies between the projects or add the references to the project?

If you use the solution to express dependencies between the projects, you should call the command line (a). If you call the command line (b), the dependencies projects will be ignored. Because the solution file is used to parse it into a temporary project file in MSBuild internally, so if you build the project by ProjB.vcxproj, those dependencies info will be ignored.

For example, I created a solution with three projects, TestSample, TestSampleB, TestSampleC. Using the solution to add the TestSampleB, TestSampleC reference to TestSample (Right click your solution->Properties->Common Properties->Project Dependencies):

When we build the project TestSample with (b) command line, only the project TestSample was built, TestSampleB, TestSampleC were ignored.

MSBuild "TestSample\TestSample.vcxproj"

When we call the (a) command line, all dependencies project were built:

MSBuild "TestSample.sln" /t:"TestSample"

If you add the references to the project (Right click project->Add reference), you can call both of two command lines. All dependencies project will be built.

So, If you express dependencies between the projects using the sln file, I recommend working those dependencies directly into the proj files and removing them from the sln. This will allow you to invoke any proj file from MSBuild directly and the projects will all build independently without any additional work.

If the solution is large, but ProjB has little interdependencies with other projects in the solution, will one option be faster in general?

If the build project does not have interdependencies with other projects in the solution, build this project will be faster than the whole solution.

Hope this helps.

Answer 2

I can, so far, identify these issues:

• Quite obviously, if you have additional sln based dependencies, these will simply be ignored.
  • In this day and age, you really should work with project2project dependencies, but I think there's some semi valid reasons to stick with solution deps in some cases.
• Macro Values. Starting with $(SolutionFileName)and quite everything else that starts with solution. If your project, or its dependencies, use any of these: subtly different result may ensue.

• Platform. Oh my. You see, they way solution platforms work, they're basically just a named container to group together project platform selections.

  What this means is, esp. for C++, that when invoking the sln file it might very well be that you need to specify a different platform. For example, with the solution, you'd build 'Mixed Platforms' or maybe 'Any CPU', but for the project you actually need to specify x64 or Win32.

  So the Platform that needs to be passed might have to differ.