我在InitializeComponent-方法处获得文件加载程序异常（第一次机会），或者调试器在多个WPF用户控件的xaml根的x:Class属性处中断。尽管异常会使导航速度减慢很多，但一切都很好。
这是异常消息：
无法加载文件或程序集"Company.Solution.UserInterface，Version=0.1.5568.25577，Culture=neutral，PublicKeyToken=45069ab0c1581ce"或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。（HRESULT异常：0x80131040）
这是Fusion日志：
Assembly manager loaded from: C:WindowsMicrosoft.NETFrameworkv4.0.30319clr.dll
Running under executable D:DevelopmentProductMainsrcCompany.Product binDebugProduct.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:DevelopmentProduct MainsrcCompany.Product binDebugProduct .vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFrameworkv4.0.30319configmachine.config.
LOG: Post-policy reference: Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
我的项目结构有一个根项目，它引用了一个模块项目（异常发生在其中）。模块项目本身引用了作为上述探测目标的项目"Company.Product.UserInterface.dll"，该项目包含一些资源/控件/样式/基元/转换器等
如何摆脱FileLoadExceptions？
另一个更完整的Fusion日志：
=== Pre-bind state information ===
LOG: DisplayName = Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Product.vshost.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:DevelopmentProductMainsrcCompany.ProductbinDebugProduct.vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFrameworkv4.0.30319configmachine.config.
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:DevelopmentProductMainsrcCompany.ProductbinDebugCompany.Product.UserInterface.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18123, Culture=neutral, PublicKeyToken=45069ab0c15881ce
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
异常发生时，SolutionExplorer中引用的程序集版本为0.1.5577.18123（在所有引用..UserInterface.dll的解决方案中。我不知道是谁在查找0.1.5577.18122，此版本从未存在）
如果我运行一个新的重建，我会得到相同的错误，Fusion会查找（我从来没有这个版本号）：
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18465, Culture=neutral, PublicKeyToken=45069ab0c15881ce
找到的版本是：
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18466, Culture=neutral, PublicKeyToken=45069ab0c15881ce
Visual Studio版本是2013 Ultimate，该项目是在.net4.5上生成的，程序集版本是在生成过程中自动生成的。我把构建日志上传到tinyupload，因为它太大了。完整的Fusion日志可以在这里的pastebin找到。
Version=0.1.5577.18122
这个自动生成的版本号告诉一个故事，版本号的最后两部分不是任意的。它们基于部件生成的日期和时间。内部版本号是根据自2000年1月1日以来的天数生成的。修订号是自午夜以来的秒数*2，没有夏令时校正。
因此，我们所知道的事实是，18122年大会于3月30日下午2点12分34秒建成。2秒后的下午2点12分36秒，它再次被建造起来。在它被用作构建另一个项目的引用程序集之后，CLR吐出了项目符号。
这不应该发生，一个项目在一个生成会话中只能生成一次。要找出发生这种情况的原因，需要深入了解MSBuild跟踪。您可以通过"工具+选项"、"项目和解决方案"、"构建和运行"生成所需的工具。将"MSBuild项目生成输出详细信息"设置更改为"详细信息"。MSBuild现在变得非常健谈，并告诉您它决定构建项目的原因。如果你在树林里迷路了，试图解码它的输出（有很多），那么将它复制/粘贴到粘贴箱中，并在你的问题中链接到它。
对于这样的不幸，没有太多好的解释。较旧的VS版本使得意外地在项目之间创建循环依赖关系变得过于容易。您可以使用"构建+清理"将其清除。重建解决方案现在失败，并且告诉哪个引用程序集是麻烦制造者。不过，您正在使用.NET 4，所以至少要使用VS2010。因此，微软在没有任何警告的情况下增加了更多的检查，以防止这种情况发生。不确定它是否在所有情况下都是可靠的，例如，如果你不单独依赖MSBuild，它可能会被愚弄。在具有"连续集成"功能的构建服务器上并不罕见。
我们需要构建跟踪来为您提供可靠的诊断。
建议1
是否存在导致加载旧版本dll的循环引用？（事实证明这不是重点，但由于历史原因，我留下来了）。与此答案相关的
建议2
您可以尝试创建发布服务器策略吗？下面是一个需要添加到app.config文件中的示例。
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Company.Solution.UserInterface"
publicKeyToken="45069ab0c15881ce"
culture="en-us" />
<!-- Redirecting to version 0.1.5568.25577 of the assembly. -->
<bindingRedirect oldVersion="0.0.0.0-0.1.5568.25577"
newVersion="0.1.5568.25577"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
此处对进行更详细的解释
建议3
用于对程序集进行签名的密钥是否发生了任何更改？
建议4
作为对我最初建议的一个小改动。您已声明有3个项目引用Company.Solution.UserInterface。能否确认所有3个项目都引用了该程序集的同一版本？