Different results when running MSBuild within Visual Studio or from console. - by Hoschie0815

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 677499 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 6/29/2011 3:13:32 AM
Access Restriction Public


For a Visual C++ project (no CLR support) I created a simple custom .targets file and added it to the project through the "Build Customization" dialog. 

The custom target simply takes all files within a specific folder (say "Configuration") and copies them to a folder with the same name in the output directory. 

Thereby MSBuild should do an incremental build, i.e. it should only copy the files if they have been changed.

If I run MSBuild from the console for the project the incremental build works correctly. If I run it inside Visual Studio I always get the message that the project is up to date, even if I changed my custom files. 

I found an answer by looking into the book "Inside the Microsoft Build Engine, Second Edition".

On page 280 they actually saying that the IDE does a "fast up-to-date check" on the project-level. It only spawns a project build and does a more fine-grained check on the individual tasks if this rough project-level check fails.

I expected that Visual Studio simply hosts MSBuild, i.e. you use the IDE to edit your .proj files and when you build them Visual Studio just invokes MSBuild to do the up-to-date check for all build targets. I think this way it would be much clearer.

I got a workaround by following the suggestions here, but it is not a really satisfying solution since I always have to add all the files to the project and set the Custum Build Tool property which is easy to forget:

Sign in to post a comment.
Posted by jamiemthomas on 9/30/2011 at 7:15 AM
I second this question. How do I make it work as expected? I may have the opposite problem in that I am trying to modify an output assembly after compile, but I cannot figure out how to do this without triggered Visual Studio to rebuild the entire project. Obviously my output (in the obj\debug directory) is more up to date than the inputs, but Visual Studio still triggers a full build of the project. I want to play by the rules but I cannot find where the rules are written down...
Posted by Amir Gonnen on 8/21/2011 at 1:59 AM
Suppose I want to play by the spirit and help the fast up-to-date check work correctly.
How do I add a file tracker log that could affect Visual Studio "fast up-to-date check" process?
Posted by Microsoft on 7/25/2011 at 11:13 PM
Incremental build happens when a VS feature called "fast up-to-date check" detects dirtied files. The purpose of fast up-to-date check is to prevent running full incremental build for performance reasons. For highly customized projects there is always a way to trick it so it does not work.

Basically there are two choices:
1. Play by the spirit and help the fast up-to-date check work correctly. In some cases this means adding a file tracker log around your targets/tasks
2. Disable the fast up-to-date check (just set a property DisableFastUpToDateCheck to true along with customization).

If you have a target that blindly copies one folder to another (i.e does not declare the files in the folder as project items) that inherently is not maintainable. We have no way to track addition of new files to the folder (even if there are T-Log files) and thus fast up-to-date check always detects no changes. Since MSBuild always does an incremental build without reliance on fast up-to-date check, you see the changes incorporated into the new build via command line.
Posted by Microsoft on 6/29/2011 at 3:21 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)