MSBuild maxcpucount > 1 Причины ошибок сборки

Я пытаюсь построить около 600 проектов, некоторые из них.net 2.0, некоторые 3.5. Я использую 32-разрядную версию Windows 2003 Enterprise Edition со всеми последними обновлениями Windows.

Создает нормально, когда maxcpucount равен 1. Если я увеличу его, чтобы попытаться улучшить производительность, он получит ошибочные ссылки. Когда я смотрю на ссылки проекта, откуда произошла ошибка, кажется, что они должны быть построены по порядку.

Ниже я привел пример ошибок, которые вызывают сбой сборки. Не зацикливайтесь на названиях проектов или относительных путях, потому что я изменил это, чтобы у меня не было проблем с моим работодателем.

Это похоже на то, что относительные ссылки проекта не могут быть должным образом разрешены, когда более чем одно ядро ​​создает решение.

"C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (ResolveProjectReferences target) ->
     C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning : The referenced project '..\..\Manager\Manager.csproj' does not exist.


   "C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (CoreCompile target) ->
     FileProcessor.cs(18,39): error CS0234: The type or namespace name 'Manager' does not exist in the namespace 'TheNamespace' (are you missing an assembly reference?)

Я не использую msbuild для файла решения. Я использую подстановочные знаки, чтобы выбрать все файлы csproj, а затем подаю их в msbuild. Для разработки у нас есть несколько решений, которые мы используем для различных компонентов системы. 95% - это ссылки на проекты, единственные двоичные ссылки - для основных утилит

Источник

2 ответа

Чтобы MSBuild мог работать с несколькими ядрами / процессорами, он должен иметь возможность заранее определить, каковы все зависимости. Как правило, это означает, что вам нужно, чтобы все ваши проекты были в одном огромном решении, и все ваши ссылки должны быть ссылками на проекты, или настроить несколько решений и настроить их для построения в правильном порядке.

Похоже, что вы работаете с единственной версией решения прямо сейчас, поэтому вам нужно убедиться, что все ваши ссылки на другие проекты правильно настроены как ссылки на проекты, а не ссылки на пути к файлам.

Я не нашел хорошего способа проверить это с помощью графического интерфейса, поэтому вам, вероятно, придется выгрузить и отредактировать один из файлов проекта, который не создается в multicpu, чтобы взглянуть на xml.

Ссылка на проект должна выглядеть так:


<ProjectReference Include="..\..\Manager\Manager.csproj">
      <Project>{C0F60D74-3EF9-4B49-9563-66E70D0DDF43}</Project>
      <Name>Manager</Name>
</ProjectReference>

и ссылка на путь к файлу будет выглядеть так:


<Reference Include="Manager.dll, Version=2.0.0.0, Culture=neutral, PublicKeyToken=e79aa50eb4f67b0c, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>....\Manager\Manager.dll</HintPath>
</Reference>

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

Источник

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

Источник
Другие вопросы по тегам