142

I want the commandline for building a particular project of a solution using msbuild like we do with devenv.com.In devenv.com we can specify a project of a solution using following commandline 

devenv.com /Build Release|x86 test.sln /project "testproject"

Using the above commandline i can build the testproject in the test.sln using devenv.com.What is the commandline for msbuild for the same solution.

Thanks

mystack
  • 4,910
  • 10
  • 44
  • 75
  • Any reason you aren't just passing the testproject itself to msbuild? – Mark Smith Dec 17 '12 at 14:45
  • 4
    Since I can no longer edit my comment. What i mean is reference the project directly instead of the solution. "msbuild testproject /p:Configuration=Release /p:Platform=x86" – Mark Smith Dec 17 '12 at 14:53
  • different time i have to build different projects.using devenv.com it is easy by specifying the project of that solution – mystack Dec 17 '12 at 15:05
  • If that's the only issue you have, you should be able to use msbuild to build the needed projects at the correct times. You already have different commands you execute at different times on the solution, so why not just reference the projects at the proper times with different msbuild commands? If your projects are set up correctly they should figure out all of their references without using the sln file. – Mark Smith Dec 17 '12 at 15:15
  • 2
    Possible duplicate of [Build only one project in a solution from command line](https://stackoverflow.com/questions/5558080/build-only-one-project-in-a-solution-from-command-line) – StayOnTarget Jul 07 '17 at 11:46

5 Answers5

245
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

Scott
  • 4,458
  • 1
  • 19
  • 27
Easton L.
  • 2,904
  • 1
  • 14
  • 15
  • 116
    One important note: if your project has a '.' in the name, you'll need to replace it with a '_' when specifying it with /t – Watusimoto May 05 '15 at 21:28
  • 5
    @easton For building multiple projects, the synthax was for my msbuild to repeat the `/t` parameter for each project to build: `msbuild test.sln /t:project /t:project2` – Philippe Jul 02 '15 at 10:23
  • 1
    @Philippe Thanks for the information, it can be that for different version of msbuild, the syntax is different. Would you mind to share the version of msbuild and visual studio. – Easton L. Aug 11 '15 at 09:41
  • The last one at the moment, so version 4.0 – Philippe Aug 11 '15 at 09:45
  • 1
    `error MSB4057: the target build "v8" does not exist in the project` is all I get, VS 2013 Ultimate. Details: http://stackoverflow.com/questions/32078468/error-msb4057-the-target-v8-does-not-exist-in-the-project – CodeManX Aug 19 '15 at 01:47
  • 53
    Also, if you are using a solution folder, you have to prefix the project name with the folder name and a slash. Like @Watusimoto mentioned above, if you have periods (.) in the name, you have to replace them with underscores (_). I ended up with something like this: `/t:SlnFolder\My_Project_name`. – Travis Parks Nov 04 '15 at 13:12
  • @Watusimoto do you have a source for this? What you've suggested helped me, but I'd like to know why. – shortstuffsushi Mar 10 '16 at 22:27
  • 34
    @TravisParks: Also might be worth mentioning that "solution folder" does _not_ refer to a file system folder but rather a folder in the Solution Explorer view. – joshbodily May 06 '16 at 21:52
  • 5
    I also had to replace '(' and ')' with '_' in the folder name (GYP generated projects). I guess it's all the special characters are replaced with underscore. – Maxime Jun 13 '16 at 01:49
  • How about a project inside a solution folder, with dots and spaces. If I move the project from solution folder i can build it, if not than there is no way that I could guess that worked for me...argh. – Ibrahim ben Salah Mar 21 '18 at 15:40
  • One additional thing: If you build the solution, "Any CPU" is ok but if you build the project (csproj directly instead of the sln) I needed to use AnyCPU without the space. I obviously had the reverse problem here. – Yepeekai Jan 24 '19 at 15:36
  • If the project is in a folder with dots: avoid the dots. For example if the project is in the abc.def\ghi, use `/t:abcdef\ghi` – joseangelmt Apr 17 '20 at 15:52
  • @EastonL. Happy to see that my question and your answer helps a lot of people. Thanks Again after 8 years :-) – mystack Dec 10 '20 at 08:11
  • My issue was that I had a ; (semicolon) at the end of the last project too, in the /t stuff. – mathkid91 May 07 '21 at 21:57
22

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.

Ben
  • 54,723
  • 49
  • 178
  • 224
Mark Smith
  • 1,085
  • 8
  • 19
  • 4
    Please point to how build order can be enforced from the proj files. Thanks. – ProgramCpp Nov 19 '15 at 09:22
  • 5
    Here is another problem with using the project name directly. For example, you have 5 projects in your solution. Some projects have DebugPro configuration and other projects don't have it. If you build a project with the configuration that all projects have everything is file but only solution file know which project configuration to use for each project if you selected solution configuration DebugPro. – Alex Oct 28 '16 at 17:36
  • @ProgramCpp When you add references from one project to another, it automatically figures out that the referenced project needs to build first. – jpaugh Jun 21 '17 at 16:04
  • Another disadvantage of this approach is that relative path in the project are resolved relative to solution file. Once you build project directly relative path will change. Output might be elsewhere and unit tests might lookup wrong directories. – Tomas Kubes Jan 27 '19 at 12:45
  • Problems may also appear if you use solution variables in project configuration, like $(SolutionDir) – Alex Che Aug 07 '19 at 14:22
9

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.

Liam
  • 27,717
  • 28
  • 128
  • 190
freshprinze
  • 134
  • 2
  • 10
  • 6
    ` If you have '.' in the project name or folders msbuild will expect '_' in place of the '.'.` – hdev Jan 12 '17 at 09:44
6

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
kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
  • 2
    This was what I needed. Hint if you don't want to run this: your target is the folder structure from the current path to your project file, minus the project file extension (`.csproj` in my case). I <3 SO! – No Refunds No Returns Oct 04 '19 at 00:04
1

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.

C J
  • 144
  • 8