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.
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.
Please hear me out as this question has been modified extensively.
I have an msbuild target that I want to execute after each project in my solution is built from the IDE. I can easily do this by creating an msbuild replica of my solution, but you can't use it within visual studio. You can go through the projects properies as specify an after build process, but this is quite tedious, especially if you have more than 2 projects.
Is there a better way to execute a target for all projects in a solution within the IDE? I just can't believe that VS2010 doesn't give you an easier option.
BTW, does VS 2012 Beta support a full MsBuild file instead of the brain dead solution file?
What I get from your question is that you've extended the build process and then created a 'shadow' msbuild file that does what the solution file normally ends up doing during build. As you are aware, solution files are a rather unfortunate visual studio only concept. That issue is nearly impossible to work around.
The idiomatic approach to this problem is leave the solution file alone and modify the individual .csproj files to include the custom build steps that each project would need to be completed according to your process. NuGet does this when you use it, so does NotifyPropertyWeaver. (NuGet works around the solution issue by introducing a '$(SolutionDir)' property)
As an aside, I'm not sure how valuable 'building an installer' is to the individual developer on your team and including in the build seems like it adds friction rather than removes it.
If this is for a custom build server, there's no need to use the solution file at all if you don't mind keeping the two in sync and I'd wholeheartedly recommend that approach.
You can debug msbuild using the visual studio IDE.
There is an undocumented registry switch to enable. See this thorough msdn article:http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx
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;
Is there a way to integrate StyleCop in a NAnt script such that the build fails if there are too many style violations?
There doesn't seem to be a NAnt task for StyleCop, but we've found StyleCopCmd. However this only seems to generate an XML file as output that we'd have to parse. Is there some easier solution?
Yes - I set StyleCop up at work just last week! (I didn't use anything other than StyleCop...)
Basically, all I needed to do, was to get StyleCop working in Visual Studio 2008, making sure that my codebase passed all of it's warnings, and then changed the setting in the .csproj file to make it's findings Errors, instead of Warnings.
Then, when I ran the same NAnt script, the build should pass as before.
But the trick is to go back into your code, violate one of the rules but quit out of VS2008 and then run your build script. The code should fail the StyleCop rule and fail your build.
Hope this helps!
You don't need to do anything with NAnt at all.
You just have to two things once:
add two lines to every .csproj file
include the StyleCop files in your project and put them into source control
You can find a more detailed description of the process here:
http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/24/source-analysis-msbuild-integration.aspx
After that, StyleCop will run on EVERY build, no matter on what machine (and without installing it on each machine) and no matter how the build was started (from Visual Studio, from MSBuild...).
So, as long as NAnt calls MSBuild to actually build the solution, StyleCop will run as well.
In case you don't want to do it thru MSBuild, you can do it using StyleCopCLI http://stylecopcli.sourceforge.net/
Will Visual Studio choke on customized .csproj files?
For example, I wanted to add a Target to update the version number in all AssemblyInfo.cs files. I plan to invoke this from the command line with MSbuild.
As another example, I would like to include the build timestamp into the compile, like so. This would be a pre-compile step (I guess), and unlike the example above, this one would run from within a build inside Visual Studio.
Will VS be ok with this?
As long as the code is a valid MSBuild extension, Visual Studio should be able to handle it. Under the hood the project files are really just MSBuild files and MSBuild does the dirty work of the VS build system. So as long as the file remains a valid MSBuild file it should be just fine.
Yes it does allow customizations. We integrated FxCop with our release-mode builds this way.
It will complain when you first load the project file after it's been edited, saying "it's been tampered with, do you wish to continue loading?" Just hit yes and continue on your merry way. It also lets you check a box to ignore the rest of the projects in the solution for the same warning.