我有另一个这些“无法加载文件或程序集或其依赖项之一”的问题。
附加信息:无法加载
文件或程序集
“Microsoft.Practices.Unity,
Version = 1.2.0.0、文化=中立,
都31 bf3856ad364e35”或
它的依赖项之一。在位于
程序集的显式定义可以
不匹配程序集引用。
(异常来自HRESULT: 0x80131040)
我不知道是什么导致了这种情况,也不知道如何调试它来找到原因。
我在我的解决方案目录.csproj文件中做了一个搜索,我有Unity的每个地方:
参考
包括= " Microsoft.Practices.Unity,
Version = 2.0.414.0、文化=中立,
都31 bf3856ad364e35,
processorArchitecture = MSIL”
在我的任何项目中都找不到任何与1.2.0.0相反的参考。
我该怎么解决这个问题呢?
我在这个问题上也浪费了几个令人沮丧的小时。我们不得不更新我们的. net框架版本,并开始得到多个“无法加载文件或程序集或其依赖项之一”的dll,这些dll多年未更改。奇怪的是,在错误消息中搜索的版本都非常旧。例如,它正在搜索Newtonsoft。Json版本为6.0.0,而我们已经使用8.0.1很多年了。
回到这些古老的版本不是一个选择,无论如何,在我们的网络中有一堆bindingRedirect元素。配置文件,应该重定向到旧dll到新dll的调用。回滚。net版本可以消除这些错误,但我们需要新版本。这是怎么回事?
web中的<runtime>元素。配置文件包含元素:
<assemblyBinding appliesTo="v2.0.50727"
xmlns="urn:schemas-microsoft-com:asm.v1">
似乎被忽略的dependentAssembly元素包含在其中。
罪魁祸首是appliesTo属性。这意味着bindingRedirect只应用于. net 2.0.50727版本。当我们更新. net Framework版本时,我们所有的bindingRedirect元素都被忽略了。
在我们的案例中,解决方案是完全删除appliesTo属性。
Juntos的答案是正确的,但你也应该考虑:
对于unity v2.1.505.2,不同的AssemblyVersion和AssemblyFileVersion属性被指定:
AssemblyFileVersion被NuGet使用,但是CLR并不关心它!
CLR将只使用AssemblyVersion!
因此,您的重定向应该应用于在AssemblyVersion属性中指定的版本。因此应该使用2.1.505.0
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
参见:
AssemblyVersion, AssemblyFileVersion和AssemblyInformationalVersion之间有什么区别?