问题标签 [fuslogvw]

我在基于表单的 C# 应用程序中进行了更改，其中我更改了一些对话框以不再处理资源的多个语言环境（放弃翻译所有文本）。此后，应用程序现在无法加载，因为它显示 (FUSLOGVW)：

什么/为什么要构建然后需要一个 .resources 文件？

谢谢 - 戴夫

我创建了一个文件夹 C:\FusionLog 并尝试在 Log Settings Custom Path 字段中输入它，如下所示。但是，当我尝试输入反斜杠 C:\FusionLog\ 时，我收到以下错误消息。我尝试研究这个问题，但找不到解决方案。

日志路径错误

日志设置

我有一个带有多个可见 COM 类的 .NET DLL SigToolNet.DLL。它引用了原生 C++ 静态库 FTDIVCPLIB 的 .NET DLL FTDIVcpLibNet.DLL 包装器，而后者又引用了第 3 方原生 DLL ftd2xx.dll。SigToolNet.DLL 已成功注册 32 位 regasm

旁注，我不知道为什么它给我这个警告，因为 SigToolNet.dll 是代码签名的。在安装了 VS2019 的开发系统上运行时，引用 SigToolNet.DLL 中 COM 可见类的应用程序 TestHarness.exe 成功运行。但是，当 SigToolNet.DLL 安装在另一台计算机上时，我在运行时在调用 COM 可见方法之一 (DetectDevice) 的第二次调用时出现异常

所有引用的 DLL 包括 FTDIVcpLibNet.dll 都位于 SigToolNet.DLL 所在的同一文件夹中，该文件夹也是它的注册位置。

我尝试在 3 台不同的计算机上运行，​​在 Windows 7 和 Windows 10 上均出现相同的失败结果。它成功运行的开发系统正在运行 Windows 10。

我还尝试使用程序集绑定日志查看器 (fuslogvw.exe) 跟踪程序集加载失败

我觉得这个日志令人困惑。它说它无法找到 SigToolNet.dll，但它似乎正在与 TestHarness.exe 相同的文件夹中寻找它。它应该在 C:\Release 中寻找它，这是 SigToolNet.dll 成功注册的地方。此外，报告的异常不是找不到 SigToolNet.dll，而是找不到 FTDIVcpLibNet.dll。第一个位置不应该是注册 SigToolNet.dll 的同一个文件夹吗？

我在 VS2019 中使用了远程调试，并且能够在调用第一个方法 Init 时在 SigToolNet 中设置断点和单步。但是由于调用执行之前的异常，第二次调用 DetectDevice 的断点永远不会发生。

所有 .NET DLL 都使用 .NET 4.8

我一直无法确定为什么它在开发 SigToolNet.dll 并安装了 VS2019 的系统上成功运行，但在其他系统上却没有。

我们有一个 .NET Framework 4.6.2 应用程序（间接地，通过传递依赖）使用 NuGet 包Microsoft.Extensions.DependencyInjection版本3.0.3。

此 NuGet 包版本 3.0.3 包含 Microsoft.Extensions.DependencyInjection.dll 程序集版本 3.0.3。它还依赖于 NuGet 包 Microsoft.Extensions.DependencyInjection.Abstractions 版本 3.0.3。此“抽象”NuGet 包包含 Microsoft.Extensions.DependencyInjection.Abstractions.dll 和程序集版本 3.0.3。到目前为止，一切都很好。

但是：Microsoft.Extensions.DependencyInjection.dll 程序集版本 3.0。3具有对 Microsoft.Extensions.DependencyInjection.Abstractions.dll 3.0 版的二进制引用。0 .

为什么这行得通？那不应该是对 3.0 版的引用吗？3 ? 我还检查了这些包/程序集（3.1.16）的较新版本，并在那里发现了同样的怪异之处。

我问是因为我们有两个应用程序变体，都使用同一组 DLL。在一种变体中，它在运行时失败，并出现错误提示它无法加载 Microsoft.Extensions.DependencyInjection.Abstractions 程序集版本 3.0.0。我认为这个错误是意料之中的。在另一个变体中，它有效，但我无法解释原因。

没有一个应用程序在其 exe.config 文件中具有 Microsoft.Extensions.DependencyInjection 相关 DLL 的程序集重定向。这两个应用程序都针对 .NET Framework 4.6.2。据我所知，程序集和程序集引用是强名称的，因此程序集版本应该很重要。我们没有使用 Assembly.LoadFrom （或类似的东西）来加载程序集。

我错过了什么？.NET CLR 是否忽略了程序集版本的第 3 位？是否有可以打开/关闭此行为的秘密开关？

我已经尝试使用fuslogvw来追踪错误但没有成功。我刚刚注意到，对于工作变体，它写入了以下文件

这是文件内容：

任何帮助真的很感激！

我们的 Visual Basic 6 应用程序引用了 SMARTCef.dll（com-visible .NET 程序集）

在我们的 beta 测试人员的机器上，我们将此应用程序存储在 \Beta 和 \Prod 文件夹中，并且运行应用程序的快捷方式将 SMARTCef.dll 注册为 ``` regasm /codebase /tlb SMARTCef.dll `

Beta 版本为 1.1.3.0，未签名并按预期运行。Prod 版本为 1.0.0.1，未签名且不再成功运行，因为从已签名的 v 1.1.1.0 更新 \Beta。

我不得不删除强名称，因为 SMARTCef.dll 现在引用了一个没有也不会被签名的内部 nuget。

fuslogvw.exe 显示以下引用旧版本 SMARTCef.dll 的绑定错误。

...这是错误的近似值，因为它位于防火墙后面，我无法复制/粘贴

问题

1. 这表示 VB6 应用程序需要签名的 1.1.1.0，但只能找到 1.0.0.1。自从该应用程序的 prod 版本在 1.1.1.0 甚至存在之前于 7 月部署以来，这怎么可能？
2. 为什么它不期望也安装并为 \Beta 构建工作的未签名 1.1.3.0？
3. 如何/我可以强制 VB6 始终查看它自己的文件夹以加载 SMARTCef.dll 文件？

绑定失败的日志如下所示： BinderLogEntry

这似乎是说 12.0.0.0 已转换为 12.0.3.0 （这是我指定和想要的），但随后似乎正在使用 12.0.0.0 （并说它找不到它）。

Newtonsoft.json.dll 的属性如下所示：

为什么它仍在寻找 12.0.0.0 ？