Visual Studio 2017反复建立项目

Question

I have a big solution (~ 450 projects), where some projects are building over and over again, although I haven't changed anything.

When I change build output verbosity to diagnostic it says:

Project 'ProjectA' is not up to date. Missing input file 'C:\\Src\\Project.Core\\Bin\\Release\\ProjectB.dll'

ProjectA dependes on ProjectB and I'm building configuration Debug , so why is Visual Studio checking for the file ProjectB.dll in the Release -folder? ProjectB.dll gets built and copied in the correct folder (debug)!

The output path is the same for every project (c# and c++):

<OutputPath>$(SolutionDir)Bin\$(Configuration)\</OutputPath>

This is just an example. Multiple projects in my solution have this weird behavior. Seems like the c++ projects are causing this, but I have no clear evidence.

Here are my Process Monitor analysis of the file accesses:

UPDATE 1:

ProjectA (C# project) references ProjectB (C++ project) using a ProjectReference :

<ProjectReference Include="..\..\ProjectB.vcxproj">
   <Project>{F2F4C146-8A98-432B-BB9F-A06C4B4162CF}</Project> 
   <Name>ProjectB</Name>
</ProjectReference>

UPDATE 2:

There's this setting for .NET Core projects:

Is there something similar for projects targeting .NET Framework?

UPDATE 3:

Seems like the code for the FastUpToDateCheck for C#-projects is in the csproj.dll assembly. Since it's a native assembly, I can't look into the code. That's a pity.

Answer 1

The problem is not all of your projects are in the solution file ( .sln). Given that you are using project references. ie <ProjectReference
When some of the projects are in the solution file ( .sln), and they reference another project outside of the solution file, MSBuild will build the other project, but not with the configuration you are building. It always or usually (a bug) will build using the opposite configuration you are using.

Super Duper annoying bug btw.

As a work-around you could just declare an ItemGroup with all your projects, and just pass that straight to MSBuild and not use a solution at all.

<ItemGroup>
   <Files Include="**\*.csproj" />
   <Files Include="**\*.vcxproj" />
</ItemGroup>

<Target Name="Build">
   <MSBuild Projects="@(Files)" Properties="Configuration=Debug" />
</Target>

If they all use <ProjectReference , then MSBuild will automatically determine the order that they get built in.

Or you could just create a solution that has everything in it.

Answer 2

I ran into the same Issue as you. I do not have a fix - just a workaround which works with msbuild 15 and up. Same as you I found no way to pass the correct target output path from the clr project to the csproj ProjectReference element or any of its targets.

Add the following code somewhere in the Directory.Build.targets ( link ) for your solution and the update checks will work.

All that happens is that the dll will be copied from the OutputPath to the IntermediateOutputPath which allows the FastUpToDateCheck to find it.

I have found no issues with doing it this way even though I consider it "hacky". It might cause issues if you have very "non standard" build paths / configuration

  <Target Name="CopyClrToProjectOutputForFastUpToDateCheck" AfterTargets="AfterBuild" Condition="'$(CLRSupport)' == 'true' And '$(Language)' == 'C++'">
    <Message Text="Copying CLR Project output to intermeidate output path so that csprojs have the change to do fastuptodatecheck  $(OutputPath)$(TargetFileName) to $(IntermediateOutputPath)$(TargetFileName)"/>
    <Copy SourceFiles=" $(OutputPath)$(TargetFileName)"               DestinationFiles="$(IntermediateOutputPath)$(TargetFileName)" />
  </Target>