Project shows as out of date when built inside different solution.

Question

Apologies if this is a duplicate of http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/520a0fbf-3816-4298-9608-f236cf604417, but it seems like it might be slightly different.

I’ve noticed a new behavior with VS 2010 which seems different from VS 2008:

Solution 1 contains project A.
Solution 2 also contains project A.

Load solution 1, make a change to project A and build.

Load solution 2 and build, project A will be treated as out of date.

Go back to solution 1 and build again, project A will be treated as out of date.

And so on and so forth…

The issue seems to be that, in VS 2010, a project which is built as part of one solution will show up as out of date when built from another solution, even when nothing in that project has changed.

It won’t really rebuild any source, but it will seem to perform some copying and a do a few quick operations. It will also run any post-build steps. It will not show the project as ‘up to date’ in the output window. Building a second time from the same solution will then show that everything is up to date.

I compared the differences in the output folders between the two build runs and discovered that the key issue is the contents of the ‘XXX.lastbuildstate’ file for the shared project.. This file contains the full path to the solution which was last used to build the shared project, so it seems like VS 2010 considers a project’s up-to-date status to only have meaning in the context of a particular solution. Interestingly, one can prevent the redundant build by hacking this file so that it contains the path to the whichever SLN will be used for the next build.

Is this expected behavior? Is there anything I can do to avoid this?

Thanks.

Answer 1

Hi Mr.Mammal,

Most likely, you have some files included in the project but they are missing from the disk.

You can 'discover' this by going to the "include file view" and clicking on each include file in turn untill you find the one that VS can not find. You then ADD that file (as an existing item) and delete the reference that can not be found and everything is ok.

You also can take a look of this blog, which has some information related to up to date change:http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx

Up to date check change

When you hit F5, you may run into the situation that Up to check dialog always coming up even after a fresh rebuild. You can refer to thisblog:http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx to troubleshoot the problem. Most likely, the issue is caused by the fact that some files are listed as part of the project files but are missing on the disk. Because these files are part of the project files, the new up to date check mechanism will check for their existence. If the files are not on the disk, the up to date check will assume that a new build is needed. The fix is to remove the files from the project files if they are not on the disk.

Please mark the useful reply as answer.

 

Best regards,

Lucy

---

Lucy Liu [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

Hi Lucy,

Thanks for the response. Unfortunately, missing files is not the problem for me. I should have been more clear in my original post that I’d already looked into that potential fix. Within a particular solution, everything is working just fine. Once I build, everything remains up to date inside that one solution on subsequent builds. However, if I switch from that solution to another solution which includes a common project, the build will be out of date in the other solution. Here’s a more clear timeline:

1.)    Load two instances of Visual Studio 2010.
2.)    In instance 1, load Solution 1 which contains project A.
3.)    In instance 2, load Solution 2 which also contains project A.
4.)    In Solution 1, touch a file in project A then build. Project A will show as out of date as expected and will build.
5.)    In Solution 1, build again, everything will show as up to date and no build will happen.
6.)    In Solution 2, build. Project A will show as out of date, which is NOT expected. Some build steps will happen.
7.)    In Solution 2, build again, everything will show as up to date and no build will happen.
8.)    In Solution 1, build. Project A will show as out of date, which is NOT expected. Some build steps will happen.

…and this can go on forever. To summarize, a project which is common to multiple solutions will show as out of date any time it was last built in a different solution. I went into some detail in my previous post about how this seems to be related to the lastbuildstate file. I hope my description was clear.

Thanks.

Answer 3

Hi Mr.Mammal,

I cannot reproduce this issue.

The following are what I have done:

1.)     Load two instances of Visual Studio 2010.

2.)     In instance 1, load Solution 1 which contains project A.

3.)     In instance 2, load Solution 2 which also contains project A.

4.)     In Solution 1, add a file to project A then build. Everything is ok. At the same time the Solution 2 shows somethings like “The filter file for project A has been modified outside the environment. Do you want to reload the filters structure for disk? ……”

Please describe this issue in detailed,

 >>4.) In Solution 1, touch a file in project A then build. Project A will show as out of date as expected and will build.

What a file do you touch? Is it an existing file? Does this file created by VS2008 or VS2010?

If I have misunderstood anything, please feel free to let us know. And provide some screenshot.

Thank you for your understanding!

 

Best regards,

Lucy

---

Lucy Liu [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 4

Hello Lucy,

Here’s how I was able to reproduce the issue starting from a clean slate:

1.) Create a new Visual C++ MFC application solution with all default settings. Call this TestApp1. Leave this instance of Visual Studio running.

2.) Launch another instance and create another solution with exactly the same settings. Call this TestApp2.

3.) In the TestApp2 solution, add the TestApp1.vcxproj project file such that the TestApp2 solution contains both the TestApp1 and TestApp2 projects.

4.) Go back and forth between the two solutions and build, you should notice that TestApp1 shows as out of date any time when it was last built from the other solution. You will also notice that the timestamp of the TestApp1 executable will be updated during the builds, indicating that the file is being overwritten.

Hopefully you can now reproduce this behavior. Thanks.

Answer 5

Hi Mr.Mammal,

I have tested it in my 2 computers,  but I still cannot reproduce this issue.

You can try the following workarounds:

1. If we reboot the operating system to safe mode, do we have the problem? This can help to isolate whether any other applications are interfering with Visual Studio. Note that some features (like IIS) are not available under safe mode. Please check whether this can apply or not. In addition to safe mode, we can also suggest “clean boot”: http://support.microsoft.com/kb/310353.

2. If we create a new user account, do we have the problem? This can help to isolate user profile corruption related causes.

3. If we disable Add-ins (e.g. “Tools” | “Add-in Manager”) and run “devenv.exe /safemode”, do we still have the problem? This can eliminate the possibility that third party Add-ins are causing problems.

4. If we use “devenv.exe /resetsettings”, does it solve the problem? It restores Visual Studio default settings.

5. If the problem remains, we can use Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. It can restore the Visual Studio Installation into its original state.

 

Best regards,

Lucy

 

 

---

Lucy Liu [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 6

Hi Mr.Mammal,

I temporary make my last reply as answer. You can unmark it if they provide no help.

Thank you for your understanding!

 

Best regards,

Lucy

---

Lucy Liu [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 7

Hi Lucy,

I'm currently busy on projects right now and don't have time to try the suggestions. I'm just ignoring the issue for now, because it's more of an inconvenience rather than a serious problem. I'll probably revisit this issue at a later time. Thanks for your help.

Answer 8

Hi,

 

I have the same problem too. 

I have about 5 solutions that shares mostly the same DLLs (about 10 projects each), each solutions generate a different application based on the same API.  Just hitting "Build" on each solutions cause it to being build again.  If it's built within the same solution, no problem, but the fact that the project is being built in a solution, cause it being rebuilt in another solution.  It has nothing to do with missing files.

I tried to enable logging and it shows the following message :

"Project not up to date because the last build has different evaluation fingerprint. "

Which make sense, but not very practical since I know the code wasn't changed at all.  It's not a serious problem, but very annoying, especially when a lot of projects are inclued.  If there's a fix for this, to remove the "fingerprint", let me know.

Thank you.

Answer 9

Hi Lucy,

I have the same issue, too. 

I tried to reproduce this issue and found the steps that Mr. Mammal said is correct, but "Solution 1" and "Solution 2" should be in different folders. If those two solution are in the same folder, everything looks OK.

Would you please check this issue again? This is really annoying.

Thank you.

Answer 10

I also get the same problem between two solutions for a project called ILicense. Here's the output when it thinks that it need to build the file:

   1>------ Build started: Project: ILicense, Configuration: Debug Win32 ------
   1> ILicense-vs2010.vcxproj -> C:\Development\Main\Source.Code\ILicense\..\..\Libs\Debug-Win32\ILicense.lib
   ========== Build: 1 succeeded, 0 failed, 40 up-to-date, 0 skipped ==========

So it never actually build anything, it just refreshes the library.

I think that I found the problem. In my Objects folder, there's a file called ILicense.lastbuildstate that contains the following 2 lines when I build it with my Source.Code solution:

   #v4.0:v100:false
   Debug|Win32|C:\Development\Main\Source.Code\|

When I buld it with my Source.Net solution, it's updated to contain

   #v4.0:v100:false
   Debug|Win32|C:\Development\Main\Source.Net\|

No other file in the Objects folder is touched. If I manually edit this file to switch between Source.Code and Source.Net, I can force the other solution to "rebuild" the ILicense project in the same way as if it were really build.

So it looks to me like this file stores the solution that last built the project and is what is causing project sharing between solutions to be very inconvenient.

Is there some way around this? Does Visual Studio 2010 not support referencing projects in multiple solutions?

Answer 11

Hi,

I also have the same problem. I don't understand how technical support can't reproduce this as the instructions supplied are very clear. TacoChang is right in saying that the solutions must be in different folders.

This problem is a violation of the concept that a solution is just a collection of projects and that you can have as many solutions as you want. We have lots of solutions which are autogenerated so you can use the most convenient. This issue is a real pain.

It looks like a fundamental msbuild thing.

Cheers,

James

Answer 12

I have the exact same problem. We have multiple apps that share the same projects, including client and server apps. We need to work on different apps concurrently, and rebuilding the same projects in each app every time we switch solutions is a real time killer. 

Answer 13

That won't help anyone here but just in case additional comments could help tech support to move on, I noticed the same behaviour/problem on our applications... Would be good to know that someone is investigating.

Answer 14

I have submitted a bug report here: https://connect.microsoft.com/VisualStudio/feedback/details/772826/projects-just-built-in-another-solution-are-out-of-date#details

Included is a zip file with three solutions that reproduce the problem. 

Also, when the projects I use at work are out of date because of this issue, every single source file for the out of date projects are compiled again. That takes a lot of time.

Answer 15

Lucy, I have attached some project files at the address above that reproduce this. You should be able to reproduce this easily now.