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.
Related
I have a question regarding the difference I have noticed when building a solution file using MSBuild from command line and when doing it inside Visual Studio 2013 Update 4. The solution file I am using contains a lot of projects.
Case: Using MSBuild
After successfully building the solution file, if I try to build it again, MSBuild notifies me that the projects are up-to-date and it doesn't try to compile any source files, which is evidently the expected behavior. Nevertheless, it actually tries to execute or goes through the targets in the Build step trying to determine whether the Output files are out-of-date and this occurs for every project that is existent in the solution. Even though it doesn't build the solution again, the process of checking time stamps of files for each project actually takes quite a long time.
Case: Using Visual Studio
When doing it inside Visual Studio, after a successful build, if I try to build the solution again, then it automatically notifies me that the projects are up-to-date. It actually takes few seconds to return this output. Looking at the build output, I noticed Visual Studio doesn't really execute targets in the Build step to conclude that the projects are up-to-date. So I figured it must be using something different to check the statuses of the projects.
I really want to bridge the performance gap between these two "worlds". I would appreciate any help or hints in regards to how Visual Studio is performing this check or ways I could implement something similar in MSBuild.
Cheers!
Is there way to run PC-Lint either for a specific file or for the whole project in CMake-generated Visual Studio projects?
Currently I'm able to run PC-Lint per-project by creating custom targets using Kitware's script, but in my environment linting the whole project may take up to 10 minutes. So, I would also like to have a possibility to lint a specific source file only (and to choose that file from Visual Studio).
I was thinking, if PC lint could be used as custom "compiler" and to create for my target another project_LINT target that uses the lint "compiler". Then I could maybe select individual files to be "compiled". Or is this idea doomed? :)
I've created a custom fxCop Rules and integrated them in visual studio 2010 by following
this tutorial
Everything seemed to work just fine except that the fxCop rules are running only on the first build after I make any change in the source code (even just adding a space). Additional builds, (without making any changes in the source code) do not produce any FxCop warrning.
I'm guessing it has something to do with that fact c# MSbuild "Build" target doesn't really re-compile if the source files timestamps are the same as the last compiled assembly timestamp
How can I make the FxCop Code Analysis to run every build?
A couple of things come to mind:
Because as you say, MSBuild may decide the build target is up to date, you could try running FxCop as a post-build step.
Code Analysis creates a .CodeAnalysisLog.xml and .lastcodeanalysiscucceeded file fore each analysed file. Maybe deleting these files before building would also help.
I've written a VS addin which intercepts Visual Studio's build command and uses another build system to do a build. I've got my build showing errors in the right format so that you can click on them in VS but the one step remaining for completely seamless integration is to prevent VS's "run" or "debug" commands from whining the it doesn't think the project is built (when of course it is) does anyone know how I can trick VS into thinking the project is built?
Shortly, MSBuild / Visual Studio checks what is output of defined targets in configuration of particular project. Next it compares timestamp of file(s) specified as target output with timestamps of all files specified as input for that particular target. If input is more up-to-date than output, then it requests to regenerate output (re-compile source code or re-link object files, etc.)
How I can trick VS into thinking the project is built?
Update timestamp of input files, namely source files (.cpp, .cs) or binary files like .obj used as input for linker and other files that are of your interest.
Sometimes I do it manually issuing the following command using touch utility from GnuWIn32
touch myfile.obj
Visual Studio uses the date/time stamp of the source files. If the source file is more up-to-date then the compiled binary located in bin\debug or bin\release, Visual Studio will rebuild the solution.
Sometimes, the rebuild process can fail, the quick solution is to delete the intermediate debug files *.pdb within the solution's bin\debug or bin\release folder. Then issue a build on the solution.
Hope this helps,
Best regards,
Tom.
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.