I have a requirement for compiling large number of projects (some of them having dependency one to other). Of course I can put them under single solution file under Visual Studio and manage the compilation. But the existing solutions isn't configured in such a way. Also I feel the build scripts are better efficient to manage them.
But I could not find any proper tools to convert the Visual Studio Project files which contains all my required settings in an MSBuild Script file. Adding each and every files manually is a tedious task.
My questions are
Are there any tools which exists to create and manage MSBuild text file?
Can I give project files as is to the MSBuild script for compilation?
If I have to manually specify the source files, how can I sync up the project files and MSBuild script file on adding new files later?
Is it possible to leverage the multi-core CPUs with MSBuild to compile independent projects in parallel?
The alternative of using MSBuild traversal projects is illustrated in the following article. You may want to give this a read:
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx
You can give project files as is for compilation but you have to take care of correct build order and it is not simple for large number of projects and you cannot build in parallel.
The best solution for you is to use your current solution to build using MSBuild
msbuild YourSolutionFile.sln /p:Configuration="Debug";Platform="Any CPU"
If you want to build in parallel add /m:2 /p:BuildInParallel=True parameters into command line. More info
msbuild YourSolutionFile.sln /m:2 /p:Configuration="Debug";Platform="Any CPU";BuildInParallel=True;
Related
I have recently converted a mid-sized Visual Studio 2005 solution to Visual Studio 2010.
One of the projects contains files which are not C/C++ files and are compiled using a batch file running a custom build tool. The output of the custom build step is some C++ files, which must be compiled after that.
The output of the custom build step in the properties for the relevant files is correctly set to the generated C++ files.
The problem is that sometimes VS2010 tries to compile the generated C++ files before the files with the custom build step, which means in a clean build it fails to find the C++ files and fails. If I try building several times eventually it would compile the custom files and then the build will succeed, but this is obviously not a good solution for automated build.
In VS2005 there is no problem building this project, but VS2010 fails to determine the correct compile order from the outputs of the custom build step. Is there another way to force correct compile order in VS2010?
Visual Studio supports parallel builds, it can build more than one project at the same time. This will not work properly if it cannot properly see the dependencies between projects. A custom build can certainly be a troublemaker here. The number of parallel builds is configurable, setting it to 1 would be a very crude but effective workaround. Tools + Options, Projects and Solutions, Build and Run, "maximum number of parallel project builds" setting.
But don't do that, parallel builds can be a huge time saver. You fix this kind of problem by setting project dependencies explicitly. Right-click the project that uses the generated C++ files in the Solution Explorer window and click Project Dependencies. Tick the check box for the project that produces the C++ files. In case it is relevant to other readers, check this answer for a way to create a project that only does the custom build step and nothing else.
Visual Studio 2008 by default executes custom build tools first. The order can be changed via right click menu on project with command "Tool Build Order". This facility is not available in Visual Studio 2010. I do not know of a work-around.
Consider using Visual Studio 2010's "Properties >> Configuration Properties >> Build Events >> Pre-Build Event" as the place where you should issue command(s) to build source files that must be compiled first. In the Command Line field, call upon the cl.exe compiler or use a small external makefile to compile those files. Visual Studio will then compile the rest of your project following this initial step.
I resolved my problem when I noticed that my custom build step runs for only one file at a time. It runs for the next file on the next build etc.
The reason apparently is that my custom build steps are calling a batch file and VS2010 creates one temporary batch file to execute all custom build files.
The solution was pointed in this discussion:
http://social.msdn.microsoft.com/Forums/en-HK/msbuild/thread/ca392036-ebdb-4812-930e-f90aa445cca5
It is simply to prefix all calls to batch files with a "call" statement, thus not terminating the execution of the master batch file prematurely.
What is common way of doing this?
Maintaining a separate build file (nant by example) costs time but Will not lock you in to Visual studio.
Do most developers build with the Visual studio solution or do they have to use the nant build file.
What are the best practices?
What I do is use the proj files rather than sln files. MSbuild processes them just fine.
This way you have the best of both worlds. You are not locked into VS, but you do not have to maintain 2 copies of your build files either
It depends on your project...
I have multiple solutions that i want to build as one product, so i use msbuild / nant to include them all.
Another reason to use a build file is when you have more actions you want to execute when the CI server builds the project and you don't want those actions to be executed when the developers build the solution (Copying files for deployment or setting assembly version for example)
In general, i think that unless you have a reason to use a build file, you can just use the sln file
We have a solution file that contains some solution folders: libraries, unit-tests, applications, etc.
With Visual Studio 2010 we can build only the projects of a given folder by right-clicking on it and using "build" or "rebuild".
This is perfect on the developers' workstations, and we'd like to do the same on the continuous-integration server which uses MSBuild.
So, can we build a solution folder with MSBuild?
Or will we have to create a dedicated solution for each folder?
The conclusion of the below responses is that there isn't any built-in way to do that, but some workarounds:
create a dedicated solution with only the selected projects,
use a dedicated csproj that will build the selected projects,
add a new project which will reference the selected projects in the existing solution file.
I've chosen to use a dedicated solution file as it is the less intrusive and tricky way, though not the more flexible (the dedicated .csproj solution should offer full control).
Yes, you can build Solutions folders using MSBuild.
msbuild "framework.sln" /t:First\Project:Build
will build the project in the folder called First. However, disk folders and solutions folders must match (I tried it for my solution where they don’t first).
So all you'd have to do is choose a project that has all the other projects in that folder as dependencies.
Also see:
MSBuild command-line reference
The short answer is:
Yes, if you want to build specific set
of projects (grouped together in a VS
solution) with plain MSBuild you will
have to create a dedicated MSBuild
.proj for each specific set of
projects you want to build.
You will not have to create (and maintain) Visual Studio solutions to support your build, but in the end it's the same (an MSBuild .proj vs. a Visual Studio solution).
I have a similar scenario with a set of 60+ .NET projects (.btprpj BizTalk). For developing in Visual Studio, these projects are currently organized in 12 Visual Studio solutions.
For automated build and deploy I created a set of 50+ MSBuild .proj scripts to target every single component (or set of components) I need.
MSBuild offers a lot of possibilities for automating all the stuff around the actual build of the Visual Studio projects (export from version control systems, etc.).
I've inherited a body of Visual C++ source that consists of about a dozen sub-projects. One of these is an empty "MakeAll" project that depends on all the others, so I can build the entire project by setting the MakeAll project active and selecting "Build All."
I'd like to automate this process, and coming from a linux environment, my instinct was to generate a Makefile and build from the command line. The IDE will generate .mak files for each of the sub-projects, but not for the top-level MakeAll. (I'm assuming this is because it contains nothing but dependencies.)
The linux answer would be a Makefile that simply descends into each of the sub-projects and executes make in each one. But a quick look at the .mak files showed that each wants to be told which of several configurations to use -- and apparently some use Debug, some use Release, and some use configurations concocted by a previous developer.
What's the accepted way to build a set of projects like this from the command line?
Thank you!
You don't have to use make - if you have everything as solution files (.sln) then you can automate the build by using the msbuild tool:
msbuild solution.sln
Also, why do you have a "MakeAll" project? Visual Studio doesn't require this kind of hackery, just do a "build all" and it will build everything satisfying dependancies just like a typical "make all" rule would.
What is the difference between Build Solution and Batch Build in Visual Studio 2008?
The key point which seems to be missed in both the existing answers is that batch build allows you to build multiple configurations of each project (e.g. you can build debug and release configurations with a single operation).
With a normal build, you have to use the configuration manager to select just one configuration for each project.
in addition to what has been mentioned so far, batch build allows a combination of projects or configurations to be stored as a preset for easier future access.
Batch build allows you to build any project that you select, and a Solution build only builds the projects that are part of the active solution.
You can customise what projects are part of a solution build by going to menu Tools → Configuration Manager.
Another nice thing about batch build is that it lets you build a configuration different than the current one. It is handy for solutions that take a while to switch.
Building the solution is the same as batch building all projects. Both methods respect the solution's dependencies.