Have you lost time because Visual Studio always thought that a project was out-of-date? Recently had a customer who faced this issue. He migrated his project from VS2008 to VS2010. Rebuilt the whole project and tried to run. He saw this message box pop up…
If you click ‘Cancel’ and do a build, then in the output window you’ll see this…
1>—— Build started: Project: TestAlwaysCreateIssue, Configuration: Debug Win32 ——
1>Build started 3/12/2013 6:24:04 AM.
1> Creating “Debug\TestAlwaysCreateIssue.unsuccessfulbuild” because “AlwaysCreate” was specified.
This message is quite confusing and doesn’t give a hint as to what actually is wrong and why the project is being re-built! Visual Studio internally decides the project is out-of-date and hence decides to build again before execution.
You won’t lose time if the project is a small one but think about a solution having numerous projects a build/relink is going to take forever to complete (I’ve faced this personally for some reason this rebuild issue vanished after sometime).
So what causes this false rebuild?
To figure why Visual Studio decides that project is out-of-date you’ll have to enable project system logging in visual studio. See following blog on how to enable this feature in Visual Studio.
http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx, for convenience I’ll paste in here relevant part from the blog…
To enable logging in the Visual C++ project system you just have to add a snippet to a .config file:
- Since it can be difficult to recover from a damaged devenv.exe.config file, consider copying the file to devenv.exe.config.original before modifying it so you have a backup copy you can revert to if things go awry.
- Open a text editor with admin privileges.
- Open your %PROGRAMFILES%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config file. Note this will be in %ProgramFiles(x86)% on 64-bit Windows.
- Add this snippet to your devenv.exe.config file just below the <configSections /> block:<system.diagnostics> <switches> <add name="CPS" value="4" /> </switches> </system.diagnostics>
- Save the text file.
Above block of xml will enable diagnostic logging of build activities in Visual Studio. To view the diagnostic logs from Visual Studio you should either have a debugger hooked onto visual studio or you should have DebugView. DebugView is a tool that helps viewing application output which the application does via OutputDebugString API.
Output in DebugView should look like as follows once you enable project system logging in Visual Studio. Screenshot…
Now follow these steps…
- Start DebugView
- In DebugView window search for the string ‘missing’, better still to save the DebugView log entries and open it in notepad.
- In this case we found the following message…
 Project ‘C:\Projects\TestAlwaysCreateIssue\TestAlwaysCreateIssue\TestAlwaysCreateIssue.vcxproj’ not up to date because build input ‘C:\PROJECTS\TESTALWAYSCREATEISSUE\TESTALWAYSCREATEISSUE\NONEXISTENT.H‘ is missing.
- Copied above line of text from DebugView. The message clearly says why visual studio thinks the project is not up-to-date! The reason being nonexistent.h file is missing from disk.
- The file nonexistent.h file was deleted from disk on purpose to reproduce this issue.
Its quite easy to reproduce the issue, just add a .h file from disk to the project and then rename/delete this file, rebuild and build. You’ll see that Visual Studio says the project is not up-to-date. See below screenshot…
Resolution is quite easy, just remove the non-existent file from the project.
While many of you like creating XAML using our visual tools, many prefer creating XAML in the code editor as well. Your feedback was heard loud and clear and we have taken a crack at the top XAML editor feature requests in Visual Studio 2013. This blog post describes the new editor features in detail and how you can use them!
IntelliSense for Data Binding
IntellISense for properties of the current data context is now available in binding expressions. In order for the editor to resolve the properties we require the data context to be specified on the view and not set in code-behind. If you choose to specify the DataContext in code-behind you can set the design-time DataContext in the view and we will able to piggyback off that for resolving properties in binding expressions.
Furthermore for getting binding IntelliSense in resources like data templates which may be defined in external resource dictionaries you can either choose to set the design time DataContext on the data template or if you navigate to the data template using Go To Definition (F12) we will do the work required to copy the right DataContext over. It saves you from having to explicitly set the design time DataContext on the data template.
IntelliSense with resolved DataContext
IntelliSense with design time DataContext