msbuild test.sln /t:project /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
Notice that what is assigned to /t
is the project name in the solution, it can be different from the project file name.
Also, as stated in How to: Build specific targets in solutions by using MSBuild.exe:
If the project name contains any of the characters
%
,$
,@
,;
,.
,(
,)
, or'
, replace them with an_
in the specified target name.
You can also build multiple projects at once:
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
To rebuild or clean, change /t:project
to /t:project:clean
or /t:project:rebuild
MSBuild actually works through the use of projects not the solution. The solution is only used to parse it into a temporary project file in MSBuild internally. You should be able to just build the project of interest directly through MSBuild by executing the following command.
"msbuild testproject /p:Configuration=Release /p:Platform=x86"
There is one major issue I know you could run into using the project directly instead of the solution: if you use the solution to express dependencies between the projects, instead of adding the references to the project and letting the build system work out the dependencies automatically.
If you are enforcing a build order 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. You really should treat the sln file as a group of projects to make working in Visual Studio easier and not as a build input.
Posting as information to future seekers
Add the following to the build script and run it once. This will generate the exact targets and other information that msbuild will actually use.
Ex: If you have .
in the project name or folders msbuild will expect _
in place of the .
.
set MSBuildEmitSolution=1
After getting the information update the build script with the required details.
In order to do this, you need to know what the project's target-name is, not necessarily the project name.
One way to find this out is to use MSBuild against your SLN with intended parameters after setting a special environment variable called MSBuildEmitSolution
to the value of 1
.
set MSBuildEmitSolution=1
msbuild my_stuff.sln /t:rebuild /p:Configuration=Release /p:Platform=x64
I recently had to do this due to a very specific name for a target in nested directories. So from my generated file, my_stuff.sln.metaproj
I found this line:
<Target Name="Utils\Firewall\FirewallUtils:Rebuild">
That means the command-line to use ends up being,
msbuild my_stuff.sln /t:Utils\Firewall\FirewallUtils:Rebuild /p:Configuration=Release /p:Platform=x64
Just to add additional information, executing msbuild in the project folder will by default build the project file since its the only one there.
>msbuild
There are many variations of using msbuild this way. You can specify the proj file directly.
>msbuild helloworld.csproj -t:Build.
Review the msbuild documentation for usage, proj file requirements, as well and the benefits of building the project instead of the solution.
MS MSBuild Documentation
There are benefits to building this way as mentioned by mark-smith above.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With