我通过nuget有一个带有依赖关系B的项目A.依赖B来自另一个团队，超出了我的直接控制范围。
B的nuget包包含B的依赖项，包括Common.Logging v1.2。这将通过B的nuget目标文件（类似<Copy SourceFiles='@(PackageBManagedFiles)' DestinationFolder="$(TargetDir)\"/>）
实际上，我还要求在项目A中引用Common.Logging，但是后来的版本为3.0。我已经使用nuget添加了这个，并且Visual Studio 中的引用看起来确定。
由于我需要两个版本的Common.Logging，我在app.config文件中添加了assemblyBinding，类似于：
<dependentAssembly>
<assemblyIdentity name="Common.Logging" publicKeyToken="xxx" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
理想情况下，我希望将Common.Logging的3.0版本放在我的bin目录中。
但是，版本1.2最终会出现在我的bin目录中 - 因此应用程序无效。
我尝试使用post build事件覆盖回3.0版。在post构建事件（类似dir $(TargetDir) > dir.txt）期间将bin目录的内容回显到文件显示文件副本已经起作用，但是在构建完成时，旧版本的文件又回来了到位。
这表明构建的顺序如下：
将依赖项复制到位
运行后构建事件
nuget目标文件运行包B
这表明我可以用Common.Logging 3.0创建我自己的nuget包，其中包含一个目标文件，用于复制旧的1.2 dll文件顶部的新3.0 dll - 但前提是我能保证nuget包的顺序/ targets文件在。中运行。
在构建之后如何将Common.Logging 3.0导入我的bin目录的任何想法？
答案 0 :(得分：0)
通过创建一个包含Common.Logging 3.0的新nuget包，通过目标文件复制到位，并命名nuget包zzzCommonLoggingToBeInstalledLast，我“修复”了这个。
注意到nuget似乎按字母顺序排在packages.config，这可以在本地/构建服务器上可靠地完成工作。
有点黑客，但是添加它，因为它最终是一个有用的快速解决方案，我可以添加一些注释来解释nuget包中的黑客，以便其他开发人员了解这是为了什么。如果有人有更好的解决方案，我很乐意删除这个答案。