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

问题描述

我写了一个MsBuild Task: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="..\Compil\MyTask.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，版本= 2.0.0.0，区域性=中性，PublicKey令牌= 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:\ windows \ microsoft .net \ framework \ v4.0 \来解决此问题，但是我不想这样做，因为在生成其他项目时会触发问题(不会将dep1.dll和dep2.dll复制到输出目录...).

I can solve this problem by copying dep1.dll and dep2.dll to c:\windows\microsoft .net\framework\v4.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:\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似乎没有在我的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="..\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>

推荐答案

您可以尝试使用Fusion Log Viewer(与Visual Studio一起安装的Fuslogvw.exe)来查看正在搜索哪些路径的程序集.您可能会找到另一个可以代替的文件夹.

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