4

I have a VS2012 solution with a VS2010 C++/CLI project that depends on a VS2012 C# project. When I build the C++/CLI project it ALWAYS builds the C# project even when no changes have been made to it.

Looking at the DbgView output using the method here I see the following message:

Project 'H:\Workspaces\xxxx\ProjectA\ProjectA.vcxproj' not up to date because 'H:\WORKSPACES\xxxx\ProjectB\BIN\X86\DEBUG\ProjectB.DLL' was modified at 06/02/2014 13:05:30, which is newer than 'H:\Workspaces\xxxx\ProjectA\bin\Debug\ProjectA.lib' which was modified at 06/02/2014 13:05:29.

Where:

  • ProjectA is the VS2010 C++/CLI project
  • ProjectB is the VS2012 C# project

Under Common Properties >Framework and References I have the following settings:

  • Copy Local False
  • Copy Local Satellite Assemblies False
  • Reference Assembly Output True
  • Link Library Dependencies True
  • Use Library Dependency Inputs False

What's causing the the DLL and the LIB file to have different timestamps? Is there anything I can change in my settings to prevent this?

Community
  • 1
  • 1
openshac
  • 4,966
  • 5
  • 46
  • 77

2 Answers2

3

Project 'H:\Workspaces\xxxx\ProjectA\ProjectA.vcxproj' not up to date

That explains why your C++/CLI project gets rebuilt. Doesn't have anything to do with your C# project. And of course it is getting rebuilt, its dependencies changed.

You haven't yet found the trigger for your C# project getting rebuilt. Look backwards.

Do avoid these outdated C++ build logging hacks. It is not your C++ project that is the problem anyway. Favor changing the MSBuild verbosity to Detailed. Tools + Options, Projects and Solutions, Build and Run. And focus at the output that shows you why the C# project needs rebuilding, that's the one you care about.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Well spotted, we actually had some C++ libraries which had Copy to Output Directory set to "Copy always" instead of "Copy if newer". We do now have an additional issue with the C++/CLI library regarding signing but I'll raise that as a separate issue if I can't fix it. – openshac Jun 09 '14 at 13:20
0
  1. Not a direct solution, but a close second. Try installing .NET Demon from Redgate.
  2. Do you have pre-build events set in the ProjectB? This also could be causing this error.
  3. If you know you will not be changing ProjectB or you know that changes will be rare, you can just try and remove it from build in the properties of the solution.

Does this help at all?

martin
  • 289
  • 1
  • 6