MsBuild не ищет в хорошем каталоге зависимости второго уровня настраиваемой задачи

Я написал задачу MsBuild: MyTask. В моем решении есть проект Task и другие проекты. MyTask ссылается на проект (скажем, ProjA), который ссылается на третьи сборки, скажем (dep1 и dep2).

Все проекты создаются хорошо, и у меня есть результаты в одном каталоге (Compil). В этом каталоге у меня есть все необходимые DLL: MyTask.dll, ProjA.dll, dep1.dll, dep2.dll и другие.

В моем файле MsBuild я включаю сборку настраиваемой задачи с:

<UsingTask AssemblyFile="..\Compil\MyTask.dll" TaskName="CreateSitesCss" />

Затем вызываю задачу сборки MyTask. Вызов выполняется хорошо, но MsBuild жалуется, что не находит сборки dep1 и dep2 (хотя они находятся в одном каталоге):

ошибка: не удалось загрузить файл или сборку «dep1, версия = 2.0.0.0, культура = нейтральный, PublicKey Token = 9109c11469ae1bc7» или одну из их зависимостей. Система не может найти указанный файл.

Я могу решить эту проблему, скопировав dep1.dll и dep2.dll в c: \ windows \ microsoft .net \ framework \ v4.0 \, но я не хочу этого делать, потому что это вызывает проблемы при сборке других проектов (выиграл ' t скопируйте файлы dep1.dll и dep2.dll в выходной каталог ...).

Есть ли у кого-нибудь такая же проблема или лучше решение?


ИЗМЕНИТЬ

Вот результат Fusion Log Viewer

*** Assembly Binder Log Entry  (19/10/2010 @ 17:52:45) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = HEADOFFICE\bbaumann
LOG: DisplayName = ProjA
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: ProjA | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA.DLL, because the location falls outside of the appbase.
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA/ProjA.DLL, because the location falls outside of the appbase.
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA.EXE, because the location falls outside of the appbase.
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA/ProjA.EXE, because the location falls outside of the appbase.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA/ProjA.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA.EXE.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA/ProjA.EXE.
LOG: All probing URLs attempted and failed.

И если я скопирую MsBuild.exe в каталог, где находятся все мои dll, он будет работать нормально ...
MsBuild, похоже, не ищет dep1.dll и dep2.dll в моем каталоге Compil, даже если он находит ProjA. dll внутри ...


ИЗМЕНИТЬ

Что касается того, как выполняются мои привязки: MyTask ссылается на проект ProjA следующим образом:

<ProjectReference Include="..\ProjA\ProjA.csproj">
   <Project>{ED61DCC3-D759-4D44-B802-A6A46F328402}</Project>
   <Name>ProjA</Name>
</ProjectReference>

ProjA ссылается на две зависимости с помощью

<Reference Include="dep1, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\Dependencies\dep1\dep1.dll</HintPath>
</Reference>
<Reference Include="dep2, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\Dependencies\dep2\dep2.dll</HintPath>
</Reference>

person Benjamin Baumann    schedule 09.09.2010    source источник
comment
возможный дубликат Использовать настраиваемые задачи MSBuild из того же решения?   -  person Ruben Bartelink    schedule 10.09.2010
comment
Неа. Я видел тему, на которую вы ссылаетесь. В этом случае msbuild не может загрузить сборку задачи из-за неправильного пути. В моем случае задача хорошо загружена, первая зависимость (ProjA) тоже, но зависимости 2-го уровня (dep1 и dep2) нет.   -  person Benjamin Baumann    schedule 10.09.2010
comment
Вы когда-нибудь находили подходящее решение этой проблемы? Думаю, сейчас у меня такая же проблема.   -  person theDmi    schedule 27.02.2015
comment
У меня точно такая же проблема. Вероятно, есть способ указать папку, в которой msbuild.exe должен искать ссылочные сборки настраиваемой задачи.   -  person Egor Okhterov    schedule 14.04.2016


Ответы (2)


Вы можете попробовать Fusion Log Viewer (fuslogvw.exe, установленный вместе с VisualStudio), чтобы увидеть, по каким путям выполняется поиск сборок. Вы можете найти другую папку, которую можно использовать вместо этого.

Если dep1 и dep2 - это сторонние сборки или внутренние, которые не изменятся, вы всегда можете добавить их в GAC. Это то, чего я обычно избегаю на сервере сборки, но если вы используете их только для помощников сборки, а не для производственной установки, это не должно быть проблемой.

Изменить: причиной может быть частичная привязка. Вы используете Assembly.Load для использования ProjA? Судя по предоставленным вами журналам, похоже, что не удается загрузить ProjA - он не успевает даже попытаться загрузить dep1 или dep2.

person Pedro    schedule 01.10.2010
comment
Я попробую Fusion Log Viewer, это даст более конкретный результат, чем комментарии из microsoft.csharp.targets. Что касается GAC, то dep1 и dep2 - это проекты, которые мы создаем, поэтому библиотеки DLL меняются. Вот почему я предпочитаю вручную копировать их в msbuilddir и потом удалять ... - person Benjamin Baumann; 02.10.2010
comment
Спасибо за вашу помощь. Я отредактировал свой пост со своими конфигурациями привязки. Я загружаю сборки не по коду, а только по конфигурации. Я думаю, что журнал кажется, что он не может ПОЛНОСТЬЮ загрузить ProjA (фактически, зависимости dep1 и dep2), что согласуется с сообщением об ошибке MSBUild: не удалось загрузить файл или сборку dep1, версия = 2.0.0.0, культура = нейтральная, токен PublicKey = 9109c11469ae1bc7 ' - person Benjamin Baumann; 20.10.2010
comment
Я даю вам награду, Педро, потому что вы мне больше всего помогли, но я до сих пор не могу ответить: «(Спасибо, Педро. - person Benjamin Baumann; 26.10.2010
comment
У вас есть образец (с кодом), показывающий эту проблему? Если мне удастся получить копию, я смогу помочь с отладкой. - person Pedro; 27.10.2010

Я мог бы предложить пару обходных путей.

  1. ILMerge, это позволит вам объединить несколько сборок в одну сборку.

  2. Вы можете добавить вторичную ссылку в свое решение, даже если вы ее не используете, это скопирует ее в папку bin.

  3. создать еще одну цель для запуска после компиляции, чтобы скопировать отсутствующую сборку в папку

Надеюсь это поможет.

Иэн

person Iain    schedule 20.10.2010
comment
Я знаю ILMerge, и это могло бы решить проблему. Но я буду использовать его только в последнем варианте (возможно, я даже предпочту скопировать MSBuild.exe в каталог). Что касается вариантов 2 и 3: файлы находятся в выходной папке, они помечены как частные (copylocal в VS) и все в порядке. Я делал это несколько раз с проектами DLL C # без вреда. Но с настраиваемой задачей MSBuild MSBuild, похоже, не ищет сборки второго уровня в текущем каталоге ... - person Benjamin Baumann; 20.10.2010
comment
Вы когда-нибудь добивались прогресса в этом? У меня такая же проблема почти 7 лет спустя! (stackoverflow.com/questions/44976387/). Я тоже собираюсь попробовать ILMerge. Я использую VS2015 и Msbuild 14.0. - person Mark Matten; 10.07.2017