.net - Visual Studio 2008 中的错误编译程序

Question

所以我以前从未见过这个问题，也不知道从哪里开始解决这个问题。

Cannot register assembly "obj\Debug\MyProject.Vsto.dll".
Loading this assembly would produce a different grant set from other instances. 
(Exception from HRESULT: 0x80131401)

我从哪里开始解决这个问题？

我应该提到这是一个带有 VS2008 SP1 的 VS2008 环境，这个解决方案是：
1. VSTO Excel 2007 项目 (C#)
2. 数据访问/服务层 DLL (C#)
3. #2 (C#) 的 MbUnit 测试项目

更新： 我应该补充一点，这几个月都可以正常工作。上周左右我唯一改变的是我已经开始通过 Team Foundation Server (TFS) 编写代码。

更新2： 删除.suo文件工作了一段时间。现在我又遇到了同样的错误....嗯。猜猜我会关闭项目.suo再次删除。

更新 3： VS2008 将允许我编译一次解决方案。第二次尝试时，我得到了错误。如果我退出，删除.suo文件，然后重新打开，我可以再次编译一次。对原因有什么想法吗？这是VS2008 SP1的东西吗？

对于赏金，我正在寻找永久解决方案。

score 3 · Accepted Answer

仅供参考...看起来像 CLR HRESULT（中间的 13 表示）。根据这篇博文：很多 HRESULT 代码......具体的 HRESULT 是 SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343

很可能一些错误的进程在程序集上持有一个打开的句柄并阻止编译器放置一个新的句柄。鉴于更新＃3，该进程可能是 devenv.exe ......这对缩小范围没有帮助，但是它可能是一些后台进程，它与 VS 一起关闭（例如调试器托管进程）。

假设文件中有东西……要调试这种类型的东西，第一步是从 SysInternals 工具集中打开procexp.exe。在其中，您可以使用 Find 来确定哪个进程具有打开文件的句柄。当您遇到此问题时，我希望它会在 devenv.exe 中显示一个打开的句柄。

在 procexp 中，您可以执行非常危险的操作，即关闭句柄。之后在不关闭的情况下再次尝试这些步骤。如果问题没有重现，那么您知道您关闭的手柄是问题的原因。如果其他任何事情都发生得很好......那个“高度危险”的步骤可能是原因。

如果您知道哪个进程具有打开的句柄，那么您需要查看是否可以防止它触及句柄的明显泄漏。我会检查项目设置......包括任何复制文件的调试设置。如果有一个名为 VSHosting 进程的调试器设置...将其关闭。

祝你好运。

score 1 · Accepted Answer

我做了一些谷歌搜索，并在 MSDN 论坛上发现了这篇文章，这可能（或可能不会）证明对您有用。

它提到了一些应该安装的 Windows 更新补丁（如果您使用的是 Vista）以及一个解决方法（如果您使用的是 XP）。虽然帖子指的是 Silverlight 的问题......错误是一样的，所以也许？

祝你好运！

score 1 · Accepted Answer

我还没有看到确切的错误，但如果有另一个从不同位置加载的 DLL 副本，可能会发生类似的错误。

我会搜索一下周围是否有该 DLL 的任何其他副本

dir MyProject.*.dll /s

score 1 · Accepted Answer

所以它创建了 dll 但之后不喜欢使用它？如果是这种情况，您是否尝试在 Reflector 中打开 dll 以查看第一次和第二次编译之间可能存在哪些差异？

另一个想法 - 您是否在第一次成功构建后尝试过清理/重建？您是否在每次编译时更新版本号？我想知道是否引用了一个过时的文件，但在第一次编译后更新了。此时参考与预期不匹配。

另一个随机想法 - .suo 文件通常包含与您的个人计算机相关的信息。与编译相关的内容不应保存在该文件中 - 它应该转到 .sln 。.suo 是根本原因似乎很奇怪......

score 1 · Accepted Answer

似乎您开发了一个 ms - office 扩展程序。然后你应该安装最新的COM Shim Wizard。VS2008 的下载地址在这里。

托管办公室扩展应相互隔离。MSDN 上的这篇文章解释了原因和方法。

我假设您的 .dll 不是孤立的，因此您会得到“安全共享错误”：

隔离。如果您不使用标准 COM shim（例如 Visual Studio Tools for Office 加载程序）或提供您自己的自定义 COM shim，您的扩展 DLL 将与所有其他未填充的扩展一起加载到默认应用程序域中。在同一应用程序域中运行的所有 DLL 都容易受到由同一应用程序域中的任何其他 DLL 造成的潜在损害。此外，任何在主机应用程序中崩溃的未填充插件都会禁用该应用程序的所有其他未填充插件。

开发办公室扩展一开始看起来很简单，但后来......

托马斯

score 0 · Accepted Answer

我看过这个线程，它似乎突出了一些类似的问题。

如何排除故障？我会说首先检查您的应用程序是否可以生成这种错误消息。然后检查您的软件所依赖的库或系统是否有问题（然后寻求支持或社区支持）。

祝你好运。

score 0 · Accepted Answer

这有点超出我的范围，但我确实找到了以下链接，这表明您遇到了.net 2.0 的已知缺陷。

我从微软建议的解决方法中复制了以下内容：

当在同一进程中的两个应用程序域之间按值封送对象时会出现该问题，其中实例的类型是通用的，通用模板类型在 mscorlib 中定义，其一个或多个实例化类型未在 mscorlib 中定义，并且多域加载器优化已在一个域中启用，但在另一个域中未启用。

不幸的是，这个错误被发现得太晚了，并没有成为 V2.0 产品的标准。但是有一些解决方法：

此错误特定于进程内跨应用程序域远程处理通道的优化版本，因此可以通过关闭进程的此优化来避免。这可以通过在将执行测试的命令窗口中设置以下环境变量来实现：
set complus_UseNewCrossDomainRemoting=0
或者通过将 HKEY_CURRENT_USER\Software\Microsoft.NETFramework\UseNewCrossDomainRemoting 注册表值（一个 DWORD）设置为 0（或 HKEY_LOCAL_MACHINE 中的版本）。

这些有点重量级，但也有可能欺骗优化路径，从而避免只传输有问题的对象的特定调用。为此，在调用中添加一个虚拟输出参数（由于各种技术原因，优化路径尚未实现输出参数）。

您还可以避免使用 mscorlib 定义的泛型类型。在呈现的重现案例中，这很简单，因为您只需子类型 List：
[Serializable]
public class MyList<T> : List<T>
{
}
（只需用 MyList 替换 List 的所有用途）。

最后，如果两个应用程序域都使用多域优化，则不应出现该问题。在您已经运行它之后，您无法设置默认域的加载器优化，但您可以在外部设置它（我相信通过非托管托管 API 或配置文件，尽管我不是这方面的专家，抱歉）或通过在您的代码中创建一个新域（使用多域选项）并将控制权转移给它（通过调用该域中的 MBRO 对象）。

抱歉，如果您已经在搜索中找到了这篇文章，但我没有看到它在这里作为解决方案提供。

score 0 · Accepted Answer

0

你不会弄乱系统时间吧？这样做会弄乱你的程序集。

于 2009-03-04T17:17:56.437 回答

.net - Visual Studio 2008 中的错误编译程序

8 回答 8

Related

Reference