We're writing Python modules in C++ using Visual Studio 2010 Professional. We output Debug and Release modules in a different directory, and a configuration file for the Python part of our code determines which version is loaded.
During development in C++ I often switch between Release and Debug configurations. Sometimes I forget to update the Python config file, and then I build in Debug but the Release version is still being loaded.
What I would like is to automatically update the configuration file, so that when I switch the VS2010 Solution configuration from Release to Debug (and the other way around), the Python configuration file is automatically updated accordingly.
Update: the solution consists of roughly two dozen projects, and there is no single project that will always be built. I could use a pre-buld command, but I would have to add it to each and every project, which I'm trying to avoid.
Is this possible, and if so, how?
Kind regards,
Sybren
Visual Studio has pre- and post-build events. Those give access macro's that also give you the build mode (ConfigurationName).
You could update the Python config file in the pre-build command.
Things like
if $(ConfigurationName) == Debug
are possible.
In some projects I used this in combination with batch/cmd files that take the $(ConfigurationName) as a parameter.
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.
I'm a solo developer running Visual Studio 2008 and looking into MSBuild to improve my build process.
Almost all of the tutorials I've found so far have plenty of information about writing a build file. However I'm having a lot of trouble finding out how to integrate MSBuild into Visual Studio. Maybe MSBuild is only used with something like CruiseControl but that's overkill for me as a single developer.
Where should the build file live in a Visual Studio project and how can I run it from within the IDE?
Visual Studio executes MSBuild automatically for projects it supports.
If you right click on a project and unload it, you can then edit it in Visual Studio. Reload (right click on project again), force a (re)build to test your changes. An alternative is to edit the project file in an external editor and Visual Studio will detect saves and offer to reload the project for you.
Sounds like you're on the right track, and if you are considering writing Targets or custom MSBuild Tasks, take the time to separate them from your current project so that you can re-use them. Don't re-invent the wheel though, the two main complementary MSBuild projects are MSBuild Community Tasks and MSBuild Extension Pack.
Update: Judging from your comment on Mitch's answer, you might also want to consider adding a new Configuration element or custom properties to a project. A new MSBuild Configuration (something other than the default Debug/Release) could run unit tests, build documentation, or whatever you want automated. A custom MSBuild property would allow you to use normal Debug/Release Configuration and extend it to automate more of your build process, just depends on what you want. Either approach could also be driven from the command line.
As others have noted, MSBuild is already available when you install Visual Studio.
If you want to integrate into VS2008: Running MSBuild from Visual Studio
MSBuild is the build engine used by Visual Studio to process the files included in a project.The Visual Studio project files themselves (**.csproj* for C#, and .vbproj for VB, for example) are in fact MSBuild scripts that are run every time you build a project.
Your .csproj file is a MSBuild file. So you are actually using it already.
You may of course wish to create a separate build file to have more control, especially within a continuous integration or nightly build say.
If you simply wish to edit your project build file then you can use the IDE to edit some settings such as pre and post build actions or edit the Xml itself by unloading project and right click and editing.
You can use your current .vcproj files to build your project with MSBuild. However, as MSBuild is not directly supported (at least for vc++) vcbuild is used instead (internally).
In VS2010 all project files are MSBuild based...
This is an older article about some simple extension points from the msbuild team
How To: Insert Custom Process at Specific Points During Build
Also, don't forget you can use the MSBuild SideKick for developing and debugging your (local) msbuilds, available for free at http://www.attrice.info/msbuild/
I'd suggest you call msbuild as a post build step. Then you can put your build script somewhere in your solution and call it.
<windowsdir>\Microsoft.NET\Framework\v3.5\MSBuild.exe c:\temp\MyProject\mybuildfile.proj
The easiest way is probably to invoke your custom build script using a post-build step. Right click project, choose "Build Events" and call msbuild with your custom msbuild file from there.
I use the msbuild template to intergrate with visual studio
http://msbuildtemplate.codeplex.com/
I know very little about visual studio so the answer to this one might be simple; but is it possible to change settings in the project using command line switches to avoid having different project files for minor changes ? As I want to trigger automatic builds changing settings through the ui is not possible.
For example something like /MyOwnSetting="something"
and then have the project file use that.
There is no command line switch that will modify the project file, If you want to have different setting the way to go is to use configurations.
Each project can have many configurations (Release/Debug for example) and when you compile a project file you can specify which configuration to build.
The last part of you question is a bit unclear.
Here are some Visual Studio Command Line Switches (for v2.0 ... see other links on that page for other versions of Visual Studio).
I have prebuild events on the installer to rebuild the projects with the appropriate configuration etc.
If I right-click build/rebuild on the WiX (3.0) project in visual studio it all builds fine, but if I try to run MSBuild on the wixproj file the pre-build events will throw errors.
I can instead call Candle and Light on the wixproj but it won't run the pre-build events.
The prebuild events rely on the macros provided by VS and I'm not sure how to get around that other than creating another project and basically just use the prebuild event of the project which just screams hack.
Another problem is that I need to feed in a self-updating version number into WiX from the command line.
I was planning on using just a csproj to handle the version number and updating it and just shelling to the MSBuild and Candle and Light, but the problem is that I don't know how to access the solution directory from code other than hard-coding it in
We found it easiest to use a utility to edit the project itself and to dump all the pre-build and post build events before we build it with our autobuilder (in our case VisualBuild).
This leaves us with a nice and juicy build process that doesn't rely on any nasty hacks in the IDE and give us full control over where source comes from and where built components go to.
I'm using a different way that works well for me, which I described here.
I maintain the version number in a batch file, which just writes it into an environment variable
I create my release builds by running a batch file that first calls the "version number" batch file (so I have the version number in an environment variable called %VersionNumber%) and then executes an MSBuild project file
The MSBuild project file builds the solution, and I get the version number for the .exe in the .csproj file by reading it from the environment variable if it exists (and then I use MSBuild Community Tasks to create an AssemblyInfo file with the version number in a pre build event)
This means that the .exe has version 0.0 when built from Visual Studio, but Im fine with that because I create all my releases from the batch file.
To create a relase build with WiX setup, I execute another batch file, which just calls the "build" batch file mentioned above, and then calls the WiX utilities candle and light to build the actual setup.
candle uses this .wxs file to create the setup, where I again get the version number from the environment variable: $(env.VersionNumber)
the final .msi file created by light includes the version number in its file name because I pass the file name (including the environment variable with the version number) as an argument: -out release\msi\bitbucket-backup-%VersionNumber%.msi
It took me a while to figure all this out in the beginning, but now I release all my projects in a similar way.
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.