Home Dashboard Directory Help
Search

Visual Studio 2012 - MSBuild incremental build not detecting changes by IanNewson


Status: 

Closed
 as By Design Help for as By Design


6
0
Sign in
to vote
Type: Bug
ID: 770784
Opened: 11/12/2012 2:06:43 AM
Access Restriction: Public
0
Workaround(s)
view
2
User(s) can reproduce this bug

Description

I have customised an MSBuild project so that the default target is a new target named similarly to 'BuildWithExternalReference'. This new target calls two other targets; the first is a custom target called something like 'BuildExternalReference' which builds a DLL using an external tool. The DLL that is built is a reference for the main project, which is built using the normal 'Build' target. I have setup the Inputs and Outputs attributes for the 'BuildExternalReference' target so the Inputs reference the source files and the outputs reference the resulting DLL.

In both Visual Studio 2012 and Visual Studio 2010 the build works correctly the first time it is invoked. However, on subsequent builds if I change the external source files (referenced by the 'BuildExternalReference' target Inputs attribute) then Visual Studio 2012 simply reports 'Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped'. Visual Studio 2010 continues to work perfectly. In addition, building from the command line with MSBuild.exe works perfectly.
Details
Sign in to post a comment.
Posted by Arieh Schneier on 2/25/2014 at 7:38 PM
I have the same issue (using VS2013 here), I tried setting "DISABLEFASTUPTODATECHECK" to true in the project file, but that caused the project to always think its out of date. Ie every time I press build I get:
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
I now never get:
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
Which means every time I run VS asks me if I want to build the project because it is out of date...

Is there any way to get this to work?

Posted by Microsoft on 12/17/2012 at 1:54 PM
Yes, the DISABLEFASTUPTODATECHECK property applies to C++ projects in VS 2010 as well.
Posted by GregM on 11/15/2012 at 5:55 PM
Does this also apply to C++ projects in VS2010?
Posted by Microsoft on 11/15/2012 at 5:50 PM
Thank you for your feedback. This is due to a change in VS 2012 where C#/VB projects now do a "fast up-to-date check" that allows them to skip the build, rather than forcing the build all the time. One downside, however, is that fast up-to-date check does not take into account custom targets, which is why your incremental change was not detected. If you wish to disable the "fast up-to-date check" please set "DISABLEFASTUPTODATECHECK" to true either as an MSBuild property in the project file or as an environment variable in the environment you launch VS from.
Posted by GregM on 11/14/2012 at 8:02 AM
I am seeing this EXACT same behavior between VS 2010 and the command line with a new target I just created to update a bunch of generated files using a target marked as BeforeTargets="ClCompile". We're not yet building with VS2012, so I don't know if VS2010 and VS2012 are behaving the same way here.

I've modified the external source file both within the same instance of VS2010 and within another instance. In both cases, the command line build picks up the change, and the Visual Studio doesn't. As above, it "knows" that the project is already up-to-date and doesn't try to build it.

I set the logging to diagnosting, and even used DebugView to capture the output (I have VS configured to send the extra output so I can get reports of which files are missing), and there is nothing indicating that MSBuild is being called at all.

Deleting one of the generated files which gets compiled by this project is enough to trigger the target to be used, but modifying one of the Input files for the Target is not.

Is there something special I need to do on the Target for Visual Studio to recognize that the project is dependent on the Input files?
Posted by Microsoft on 11/13/2012 at 12:09 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been reproduced and has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Microsoft on 11/12/2012 at 2:50 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)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
MSBuildIssueExample.zip 11/12/2012 19 KB