"always rebuild" due to C++/CLI referencing COM in same solution

Question

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.

Answer 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.