所以我以前从未见过这个问题，也不知道从哪里开始解决问题。
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的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吗？
对于赏金，我正在寻找永久的解决方案。
答案 0 :(得分：3)
仅供参考......看起来像CLR HRESULT（中间的13表示）。 根据这篇博客文章：A lot of HRESULT codes...具体的HRESULT是 SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343
很可能一些错误的进程在程序集上持有一个打开的句柄，并阻止编译器放置一个新句柄。鉴于更新＃3，该进程可能是devenv.exe ...这对缩小范围没有帮助，但是它可能是一些后台进程，它会关闭VS（例如调试器托管进程）。
假设文件中存在某些东西......要调试此类事情，第一步是从SysInternals工具集打开procexp.exe。在其中，您可以使用“查找”来确定哪个进程具有对文件打开的句柄。当你遇到这个问题时，我希望它能在devenv.exe中显示一个句柄。
从procexp中你可以做出关闭句柄的高度危险的事情。之后再次尝试这些步骤而不关闭。如果问题没有重现，那么您知道关闭的句柄是问题的原因。如果发生其他任何事情......可能是“非常危险”的一步。
如果您知道哪个过程有打开的手柄，那么您需要看看是否可以防止它碰到手柄的明显泄漏。我会检查项目设置...包括复制文件的任何调试。如果有一个名为VSHosting进程的调试器设置，请将其关闭。
祝你好运。答案 1 :(得分：1)
我做了一些谷歌搜索，发现this post on MSDN Forums可能（或可能不）对您有用。
它提到了一些应该安装的Windows更新补丁（如果你在Vista上），以及如果你在XP上的解决方法。虽然帖子指的是Silverlight的问题......错误是一样的，所以可能吗？
祝你好运！答案 2 :(得分：1)
我没有看到确切的错误，但是如果从另一个位置加载另一个DLL副本，则会发生类似的错误。
我会进行搜索以查看该DLL的其他副本是否存在
dir MyProject.*.dll /s
答案 3 :(得分：1)
所以它创建了dll，但之后却不喜欢使用它？如果是这种情况，您是否尝试在Reflector中打开dll以查看第一次和第二次编译之间可能存在的差异？
另一个想法 - 你是否在第一次成功构建后尝试了清理/重建？您是否在每次编译时更新版本号？我想知道是否正在引用过时的文件，但在第一次编译后更新了。此时引用与预期引用不匹配。
另一个随机的想法 - .suo文件通常包含与您的个人计算机相关的信息。与编译相关的东西不应保存在该文件中 - 它应该转到.sln。 .suo是根本原因似乎很奇怪......
答案 4 :(得分：1)
似乎你开发了一个ms-office扩展。然后你应该安装最新的 COM Shim Wizard 。下载VS2008为here。
托管Office扩展应彼此隔离。 This article on MSDN解释了原因和方法。
我认为您的.dll不是孤立的，因此您会得到“安全共享错误”：
隔离。如果您不使用 标准COM垫片（如Visual 用于Office加载器的Studio工具）或 提供您自己的自定义COM垫片，您的 扩展DLL加载到默认值 应用程序域以及所有 其他未整理的扩展。所有DLL 在同一个应用程序域中运行 很容易受到潜在的伤害 由任何其他DLL引起的 应用领域。还有，任何 未填充的加载项崩溃了 主机应用程序禁用所有其他 未加衬垫的加载项 应用
开发办公室扩展在开始时看起来很简单，但随后......
托马斯
答案 5 :(得分：0)
我已经看到这个thread似乎突出了一些类似的问题。
如何排除故障？我会说首先检查一下你的应用程序是否会产生这种错误信息。然后检查您的软件所依赖的库或系统是否有问题（然后请求支持或社区支持）。
祝你好运。答案 6 :(得分：0)
这有点在我的区域之外，但我确实在.net 2.0中找到了以下link which suggests that you are encountering a known defect。
我从microsoft建议的解决方法中复制了以下内容：
编组时会出现问题 两个值之间的对象 appdomains在同一个进程中 实例的类型是通用的， 通用模板类型已定义 在mscorlib中，一个或多个 实例化类型未在中定义 mscorlib和多域加载器 优化已在一个中启用 域而不是其他域。
不幸的是发现了这个错误 为时已晚，没有成功 V2.0产品。有一些 但是解决方法是：
此错误特定于优化 进程中的版本， 跨域应用程序远程通道和 因此可以通过切换来避免 这个过程的优化。 这可以通过设置来实现 以下环境变量 在命令窗口中进行测试 将被执行：
set complus_UseNewCrossDomainRemoting=0或者通过设置 HKEY_CURRENT_USER \ SOFTWARE \ Microsoft.NETFramework \ UseNewCrossDomainRemoting 注册表值（一个DWORD）为0（或 HKEY_LOCAL_MACHINE中的版本。
这些有点重量级，但确实如此 也有可能欺骗优化 避免只是具体的道路 呼叫转移有问题 宾语。为此，添加一个虚拟 呼叫参数（适用于各种 技术原因优化路径 尚未实现参数）。
您还可以避免使用mscorlib 定义的泛型类型。在repro 案例介绍这很简单 因为你可以只是子类型List：
[Serializable] public class MyList<T> : List<T> { }（只需将List的所有用途替换为 MYLIST）。
最后，问题不应该发生 如果两个appdomains都使用 多域优化。你不能 设置默认域的加载器 你已经优化了 运行它但你可以设置它 外部（我相信通过 非托管主机API或配置 文件，虽然我不是专家 或者，抱歉）或创建一个新的 域内（具有多域选择） 你的代码和转移控制 它（通过调用MBRO对象） 那个领域）。
很抱歉，如果您在搜索中找到了这篇文章，但我没有在此处看到它作为解决方案。
答案 7 :(得分：0)
你不是在搞乱系统时间吗？这样做会搞乱你的装配。