Visual Studio 2017 снова и снова строит проект

Question

У меня есть большое решение (~ 450 проектов), где некоторые проекты строятся снова и снова, хотя я ничего не изменил.

Когда я изменяю детализацию сборки на diagnostic, это говорит:

Проект 'ProjectA' не обновлен. Отсутствует входной файл 'C: \ Src \ Project.Core \ Bin \ Release \ ProjectB.dll'

ProjectA зависит от ProjectB, а я собираю конфигурацию Debug, так почему же Visual Studio проверяет файл ProjectB.dll в папке Release? ProjectB.dll создается и копируется в правильную папку (отладка)!

Путь вывода одинаков для каждого проекта (c # и c ++):

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

Это всего лишь пример. Несколько проектов в моем решении имеют такое странное поведение. Похоже, что проекты C ++ вызывают это, но у меня нет четких доказательств.

Вот мой Process Monitor анализ доступа к файлам:

ОБНОВЛЕНИЕ 1:

ProjectA (проект C #) ссылается на ProjectB (проект C ++), используя ProjectReference:

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

ОБНОВЛЕНИЕ 2:

Эта настройка для проектов .NET Core:

Есть ли что-то подобное для проектов, нацеленных на .NET Framework?

ОБНОВЛЕНИЕ 3:

Похоже, код для FastUpToDateCheck для C # -проектов находится в сборке csproj.dll. Поскольку это нативная сборка, я не могу заглянуть в код. Жаль.

Answer 1

Я столкнулся с той же проблемой, что и вы. У меня нет решения - просто обходной путь, который работает с msbuild 15 и выше. Как и вы, я не нашел способа передать правильный целевой выходной путь из проекта clr в элемент csproj ProjectReference или любую из его целей.

Добавьте следующий код где-нибудь в Directory.Build.targets ( ссылка ) для вашего решения, и проверки обновлений будут работать.

Все, что происходит, это то, что dll будет скопирован из OutputPath в IntermediateOutputPath, что позволяет FastUpToDateCheck найти его.

Я не нашел никаких проблем с этим, хотя я считаю это "хакерским". Это может вызвать проблемы, если у вас очень нестандартные пути сборки / конфигурация

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

Answer 2

Проблема не во всех ваших проектах в файле решения ( .sln). Учитывая, что вы используете ссылки на проекты. т.е. <ProjectReference
Когда некоторые проекты находятся в файле решения ( .sln) и ссылаются на другой проект вне файла решения, MSBuild создаст другой проект, но не с созданной вами конфигурацией. Он всегда или обычно (ошибка) будет собираться с использованием противоположной конфигурации, которую вы используете.

Между прочим, Super Duper раздражает ошибку.

В качестве обходного пути вы можете просто объявить ItemGroup со всеми вашими проектами и просто передать это прямо MSBuild и вообще не использовать решение.

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

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

Если все они используют <ProjectReference, то MSBuild автоматически определит порядок, в котором они встроены.

Или вы можете просто создать решение, в котором есть все.