MSBuild maxcpucount> 1 Вызывает ошибки сборки - PullRequest
Новая
       31

MSBuild maxcpucount> 1 Вызывает ошибки сборки

5 голосов
/ 12 декабря 2008

Я пытаюсь построить около 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% - это ссылки на проекты, единственные двоичные ссылки - для основных утилит libs

Ответы [ 2 ]

5 голосов
/ 18 декабря 2008

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

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

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

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


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

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

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

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

0 голосов
/ 29 апреля 2010

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

...