MsBuild 没有在好目录中查找自定义任务的二级依赖 [英] MsBuild does not look in the good directory for custom task's second-level dependencies

问题描述

我写了一个 MsBuild 任务:MyTask.在我的解决方案中，我有 Task 项目和其他项目.MyTask 引用了一个项目(比如 ProjA)，该项目引用了第三个程序集，比如(dep1 和 dep2).

I wrote a MsBuild Task : MyTask. In my solution, I have the Task project and others projects. MyTask references a project (say ProjA) which references third assemblies, say (dep1 and dep2).

所有项目都构建良好，我将输出放在一个目录(编译)中.在这个目录中，我有我想要的所有 dll:MyTask.dll、ProjA.dll、dep1.dll、dep2.dll 和其他.

The projects all builds well and I have the outputs in one directory (Compil). In this directory i have all the dll's I want : MyTask.dll, ProjA.dll, dep1.dll, dep2.dll and others.

在我的 MsBuild 文件中，我包含自定义任务程序集:

In my MsBuild file i include the custom task assembly with :

<UsingTask AssemblyFile="..CompilMyTask.dll" TaskName="CreateSitesCss" />

然后我调用 MyTask 程序集的一个任务.该调用执行良好，但 MsBuild 抱怨找不到 dep1 和 dep2 程序集(尽管它们位于同一目录中):

Then I call a task of the MyTask assembly. The call is well executed but MsBuild complains about not finding the dep1 and dep2 assemblies (although they are in the same directory) :

错误:无法加载文件或程序集 'dep1, Version=2.0.0.0, Culture=neutral,PublicKey Token=9109c11469ae1bc7' 或其依赖项之一.系统找不到指定的文件.

error : Could not load file or assembly 'dep1, Version=2.0.0.0, Culture=neutral,PublicKey Token=9109c11469ae1bc7' or one of its dependencies. The system cannot find the file specified.

我可以通过将 dep1.dll 和 dep2.dll 复制到 c:windowsmicrosoft .netframeworkv4.0 来解决这个问题，但我不想这样做，因为它会在构建其他项目时触发问题(不会将 dep1.dll 和 dep2.dll 复制到输出目录...).

I can solve this problem by copying dep1.dll and dep2.dll to c:windowsmicrosoft .netframeworkv4.0 but I don't want to do this because it triggers problems when building other projects (won't copy the dep1.dll and dep2.dll to the output directory...).

有没有人遇到同样的问题，或者更好的解决方案?

Has anybody the same problem, or better, a solution?

编辑

这是Fusion Log Viewer的输出

Here is the output of 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:WINDOWSMicrosoft.NETFrameworkv4.0.30319clr.dll
Running under executable  c:WINDOWSMicrosoft.NETFrameworkv4.0.30319MSBuild.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = HEADOFFICEbaumann
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:WINDOWSMicrosoft.NETFrameworkv4.0.30319MSBuild.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:WINDOWSMicrosoft.NETFrameworkv4.0.30319configmachine.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 似乎没有在我的 Compil 目录中查找 dep1.dll 和 dep2.dll，即使它在其中找到 ProjA.dll...

And If I copy MsBuild.exe in the directory where all my dll are, it works fine...
MsBuild does not seem to look for dep1.dll and dep2.dll in my Compil directory even if it finds ProjA.dll within...

编辑

关于我的绑定是如何完成的:MyTask 通过以下方式引用 ProjA 项目:

As to how my bindings are done : MyTask references the ProjA Project by :

<ProjectReference Include="..ProjAProjA.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>..Dependenciesdep1dep1.dll</HintPath>
</Reference>
<Reference Include="dep2, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..Dependenciesdep2dep2.dll</HintPath>
</Reference>

推荐答案

您可以尝试使用 Fusion Log Viewer(fuslogvw.exe，随 VisualStudio 安装)查看正在搜索哪些路径以查找程序集.您可能会找到另一个可以使用的文件夹.

You might try the Fusion Log Viewer (fuslogvw.exe, installed with VisualStudio) to see which paths are being searched for the assemblies. You may find another folder that can be used instead.

如果 dep1 和 dep2 是第三方程序集或不会更改的内部程序集，您始终可以将它们放入 GAC.这是我通常在构建服务器上避免的事情，但如果您只将它们用于构建助手而不是生产安装，那应该不是问题.

If dep1 and dep2 are third-party assemblies or internal ones that won't change, you could always throw them in the GAC. This is something I generally avoid on a build server, but if you are only using them for build helpers and not production installs it shouldn't be an issue.

部分绑定可能是原因.您是否使用 Assembly.Load 来使用 ProjA?从您提供的日志来看，它似乎无法加载 ProjA - 甚至无法尝试加载 dep1 或 dep2.

The partial bind might be the cause. Are you using Assembly.Load to use ProjA? From the logs you provided, it looks like it is failing to load ProjA - it is not getting far enough to even try loading dep1 or dep2.

这篇关于MsBuild 没有在好目录中查找自定义任务的二级依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！