编译的.NET绑定重定向当我尝试编译一个实用程序时，使用我们客户端的文件时出现以下错误。程序集“*A*版本2.0.1.2”使用“*B*版本1.1.39.0”，这是比引用的程序集“*B*版本1.1.32.0”更高的版本。我们的客户可以毫无问题地使用这些DLL，因为我们有一个在运行时生效的绑定重定向配置文件：为了提供一些背景知识，DLL存在于单独的解决方案中，因此一些引用是文件引用而不是项目引用，这就是我所拥有的一起生活！是否有在编译时有效的等效绑定重定向？我尝试使用调试DLL（版本1.0.0.0）进行编译，并将源回滚到上面的相关版本，但在运行时出现以下错误：Thelocatedassembly'smanifestdefinitiondoesnotmatchtheassemblyreferenceMaybebuild服务器的配置与我的机器不同，但这似乎不起作用......我怀疑它是否可以根据需要“修复”。如果您阅读该编译错误的文档(https://msdn.microsoft.com/en-us/library/416tef0c.aspx)，您会发现您可以更新代码以使用相同的版本，或者参考这同时编译两个版本（在您的情况下不是一个选项）。想象一下，版本1.0.0.0包含方法MyMethod()，但版本1.0.0.1包含MyMethod(String)，第一个版本由程序集A使用，第二个版本由您正在编译的程序集使用。您希望编译器如何处理这个问题？在运行时，当您使用绑定重定向时，仍然只会加载程序集的一个版本。在这里，您不拥有程序集A的代码（您正在引用它，而后者又引用MyMethod），并且对程序集1.0.0.0的引用嵌入在A的清单中。长话短说-我想解决它的唯一方法是使用引用与您相同版本的B的程序集A。这是很常见的事故。Nuget包很可能是麻烦制造者，其中log4net和NewtonSoft.Json位居榜首。现代版本的MSBuild知道如何解决这个问题。使用“工具”>“选项”>“项目和解决方案”>“生成并运行”>“MSBuild项目”生成输出verbosity=verbose时可以看到的内容。我将展示它在VS2015上的样子，重现您的确切问题场景。ResolveAssemblyReference任务开始变得有趣：1>任务“ResolveAssemblyReference”...1>主要参考“B，Version=1.1.32.0，Culture=neutral，PublicKeyToken=null”。1>解析文件路径为“c:projects2BCopybinDebugB.dll”。1>在搜索路径位置“{HintPathFromItem}”找到参考。1>找到相关文件“c:projects2BCopybinDebugB.pdb”。1>本次引用的ImageRuntimeVersion是“v4.0.30319”。1>主要参考“A，Version=1.0.0.0，Culture=neutral，PublicKeyToken=null”。1>解析文件路径为“c:projects2AbinDebugA.dll”。1>在搜索路径位置“{HintPathFromItem}”找到参考。1>找到相关文件“c:projects2AbinDebugA.pdb”。1>本次引用的ImageRuntimeVersion是“v4.0.30319”。还有一堆.NETFramework程序集。在任务结束时，它注意到依赖于新版本的B：1>Dependency"B,Version=1.1.39.0,Culture=neutral,PublicKeyToken=null"。1>解析文件路径为“c:projects2BbinDebugB.dll”。1>在搜索路径位置“c:projects2BbinDebug”找到参考。1>对于搜索路径“c:projects2BbinDebug”。1>考虑过“c:projects2BbinDebugB.winmd”，但它不存在。1>为“A，Version=1.0.0.0，Culture=neutral，processorArchitecture=MSIL”所要求。1>找到相关文件“c:projects2BbinDebugB.pdb”。1>该引用不是“CopyLocal”，因为它与另一个同名引用冲突而失去了冲突。1>本次引用的ImageRuntimeVersion是“v4.0.30319”。1>“B，Version=1.1.32.0，Culture=neutral，PublicKeyToken=null”与“B，Version=1.1.39.0，Culture=neutral，PublicKeyToken=null”之间存在冲突。1>"B,Version=1.1.32.0,Culture=neutral,PublicKeyToken=null"被选中是因为它是主要的并且"B,Version=1.1.39.0,Culture=neutral,PublicKeyToken=null”不是。1>依赖于“B，Version=1.1.32.0，Culture=neutral，PublicKeyToken=null”的引用[c:projects2BCopybinDebugB.dll]。1>c:projects2BCopybinDebugB.dll1>项目文件项包括导致引用“c:projects2BCopybinDebugB.dll”。1>B，Version=1.1.39.0，Culture=neutral，processorArchitecture=MSIL1>Referenceswhichdependon“B，Version=1.1.39.0，Culture=neutral，PublicKeyToken=null”[c:projects2BbinDebugB.dll].1>c:projects2AbinDebugA.dll1>项目文件项包括导致引用“c:projects2AbinDebugA.dll”的项目。1>A，Version=1.0.0.0，Culture=neutral，processorArchitecture=MSIL1>完成执行任务“ResolveAssemblyReference”。注意它如何尝试决定是使用版本1.1.32.0还是1.1.39.0。它更喜欢旧版本，因为它是“主要参考”。换句话说，您的项目引用它和1.1.39.0不太重要，因为它是A的间接引用。项目构建干净，没有抱怨。为什么这对你不起作用完全不清楚，命名你的VS版本非常重要。具体什么时候加的我记不清了得到这个功能，是前阵子的事了。大约VS2010或VS2012。因此，通过将您在计算机上获得的构建跟踪与我发布的进行比较，尝试获得成功。如果这只是一个普通的旧VS版本问题，那么您当然可以通过更新它来获得更多优势。您的查询的答案是否定的，没有办法在编译时进行绑定重定向。此时，假设您可以将所有项目引用更新到同一版本（或者在签入源代码管理之前已经这样做），构建应该会顺利进行。但是，您在这里要求解决方案，所以我会提出建议。减轻这种痛苦的一种可能方法是将每个“独立DLL解决方案”打包到一个NuGet包中。您不必将它们发布到NuGet存储库中，您可以使用专用的NuGet源（例如MyGet），甚至托管您自己的源。将文件包含在提要中后，将正确的版本添加到项目中会更容易一些。使用NuGet的主要优点是您不需要将二进制文件签入源代码管理，因此它们不会与.csproj或.vbproj文件中引用的版本号不同步。如果您使用NuGet包还原设置它，每个包的正确版本将在编译时自动安装，因此无论它在哪台机器上构建，都可以保证以相同的方式构建。您还可以考虑将一些单独的解决方案整合到一个单一的解决方案/构建过程中，以在NuGet包之间同步版本号/二进制文件，以便在之前很容易判断其中一个版本是否落后于其他版本（因此需要更新）报到）。当然，NuGet并不完美，需要花费一些精力来设置，即使那样您在保持版本同步方面也可能会遇到一些问题，但是将它们更新到正确的版本要容易得多。如果我理解正确，您将有一个引用特定版本程序集B的旧程序集A同时，您正在构建实用程序C，它使用两个程序集-A和B您应该能够使用相同的程序集B以下步骤两个不同的版本。不是编译时重定向，但它应该工作：添加程序集A对项目C的引用，设置SpecificVersion=true；添加程序集B版本1.1.39.0对项目C的引用，设置SpecificVersion=true；创建postbuildevent，将assemblyB1.1.39.0version1.1.39.0添加到项目输出路径/bin/B_1.1.39.0/B.dll；添加以下绑定重定向并使用codeBase元素从定义位置为版本1.1.39.0指定程序集B；现在你的旧程序集A应该很高兴，因为你的输出文件夹中有程序集B版本1.1.32.0。您的实用程序C应该很高兴，并使用程序集B特定版本1.1.39.0并且您提供了一个自定义位置来查找它。希望能帮到你！您可以通过确保编译器错误在程序集B之外不可见来包装编译器错误，方法是确保它们是从程序集A包装的，然后您可以依赖程序集B，使用A到B并使用bindingRedirect来确保程序集A加载正确的DLL版本。你的里程会有所不同，但它有效。以上就是《C#学习教程：.NET绑定重定向编译》的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场，如涉及侵权，请点击右边联系管理员删除。如需转载请注明出处：
