0

I have a problem similar to VS2010 always thinks project is out of date but nothing has changed (I'm also on VS 2010):

I Enabled C++ project system logging which told me that:

00000727    29.93245506 [5864] Project 'C:\foo.vcxproj' 
not up to date because 'C:\foo\INTEROP\INTEROP.bar.1.0.DLL' 
was modified at 01/22/2014 11:02:49, 
which is newer than 'C:\foo\RELEASE\METAGEN.WRITE.1.TLOG' 
which was modified at 01/22/2014 16:02:30.

This is apparently telling me that foo project must be rebuilt because either bar.dll or the interop have changed.

  • foo is a C++/CLI project.
  • bar is a COM DLL.

  • foo has bar.dll as one of it's references.

    1. I haven't rebuilt bar.dll (date for the dll file is yesterday).
    2. I haven't modified any settings in project foo (to affect interop).

My question is: Why is Visual Studio deciding the interop is out of date and triggering a re-build on every single run of the application?

Note: This is a web application. foo is directly referenced from the web. bar is not directly referenced by the web.

EDIT:

I've created a simple look-alike solution with just 4 projects (2 for COM, website, and C++/CLI assembly). It seems the C++/CLI assembly always updates the INTEROP.bar.*.DLL file every time any build is triggered. This doesn't seem to be the case in the solution having problems.

This was my mis-understanding: I thought the interop DLL should only be updated if 1) the reference is re-added. 2) The COM object being referenced (possibly just the API) changed.

Apparently, interop.dll is updated every build of caller.

Finally this wording is extremely confusing to me and seems incorrect:

A was modified at 11:02:49, which is newer than B which was modified at 16:02:30.

How could something from 11:02 be "newer than" something from 16:02? (almost feels like a backwards >= / <= check)

PS - I'm not adding the example solution here, because it doesn't fail like the real solution does.

Community
  • 1
  • 1
  • It rebuilds because the auto-generated interop assembly is clearly out of date. You leave no guess whatsoever why re-generating it doesn't update the date on the interop.bar.1.0.dll file. Try deleting it yourself. – Hans Passant Jan 22 '14 at 18:51
  • The issue is not with the COM reference you added, it is with the interop assembly that was generated from the type library embedded inside the COM dll. C:\foo\INTEROP\INTEROP.bar.1.0.DLL is that interop assembly. It contains .NET compatible declarations of the methods implemented by the COM server. It has the wrong date, that's why it keeps rebuilding. I cannot guess why the date doesn't update when it gets re-generated, file system tunneling could be an explanation but your question doesn't give any leads. Delete that file by hand and see what happens. – Hans Passant Jan 23 '14 at 15:15
  • A timestamp that's 5 hours in the past does *not* give a strong hint that it is "updated too much". I'm running out of ideas to get you to delete that file. – Hans Passant Jan 23 '14 at 15:21
  • @HansPassant See the added answer if you like... I was trying to delete that file, but perhaps I wasn't doing it the right way or in the right order. (The log statements from VC++ seem self-contradictory, but if no one ever hits this problem, and they shouldn't, we shouldn't have been doing this, then it's a moot point) –  Mar 17 '14 at 19:13

1 Answers1

1

Sorry for the confusion. It looks like I was leaving out one level of indirection in the dependencies. The chain was: ASP.NET Website -> C++/CLI Assembly -> COM DLL -> C/C++ Native DLL. All in a single solution.

We ended up refactoring to move all the COM DLL code into the C++/CLI Assembly changing it to merely: Web -> C++/CLI Assembly -> C/C++ Native DLL. At this point the problem went away.

It's not a very satisfying answer, but I don't have enough spare cycles to really dig into it now that it's no longer causing trouble.