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.
Related
My project has 15 projects and 1 solution file
If my source code has not been modified, Visual Studio prompts me if I want to build the 15 project files?
There is a box to say not to display it again, I'm not sure why Visual Studio thinks the code is out of date?
Thanks for the feedback
If my source code has not been modified, Visual Studio prompts me if I
want to build the 15 project files?
No. If your code has not been changed, it will always show up-to-date, not build. VS has the feature of incremental build.
Note: you should click Build button rather than Rebuild. Rebuild will execute clean and then build, so it will always execute the whole build process.
Once you do not modify the resource files, MSBuild will detect that the project has not changed and does not need to be built again, turns out to up-to-date.
Therefore, under normal circumstances, MSBuild will not build again without changing the project.
There is a box to say not to display it again, I'm not sure why Visual
Studio thinks the code is out of date?
In fact, it should not happen.
If you have not made any changes to the project but the build still displays out-of-date, you have to check the diagnostic build log and find it out.
Enter Tools-->Options-->Projects and Solutions-->Build and Run--> set MSBuild project build output verbosity to Diagnostic . And then build your project to find the cause out.
Maybe you have set Copy To Output Directories of some files to Copy always or you have lost the files for inputs and ouputs, .... so on.
How can an incremental build using IncrediBuild detect when a source file has been deleted?
When I modify a source file it will be recompiled and the corresponding dll relinked -- but deleting the same file does nothing, even when a complete rebuild would fail. How can IncrediBuild be instructed to check for deleted files?
UPDATE
I understand that Visual Studio behaves the same way, so it is not really a bug of IncrediBuild. Nonetheless I seek to remedy this situation in a Good Way. Considering that the files being deleted are known, perhaps it is possible to implement a script that removes the corresponding object files or similar. Or perhaps there is a better way?
Modifying a source file and deleting a source file are two different things.
The scenario you are describing is a proper incremental build behavior and you will see the same behavior when building with Visual Studio (without IncrediBuild). When deleting a file and then performing an incremental build, a link step will be executed by the build system and fail whether you are using IncrediBuild or regular Visual Studio builds.
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.
My dev environment at work consists of a Visual Studio 2005 Solution with many sub-projects (by "project" I always mean VS project). Some of the projects build libraries which are used by other projects. By convention, a fair amount of test-related code ends up in header files which end up getting modified frequently. I've noticed that when I hit F7 to Build the solution, Visual Studio does not detect changes to header files that are in library projects. It will report that everything is up to date when it's not. To force it to rebuild the libary, I have to change (touch) one of the .c files in that particular project, or do Rebuild All which is quite slow.
Is there something I can change in the Solution or project settings to change this behavior so Build works as expected? I've actually gone so far as to hack together a script that "touches" one of the library .c files in a library when it detects an .h file has been updated, but there has got to be a VS solution to this.
Are the header files actually members of the library project - not just in an include file search path?
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.