所以我以前从未见过这个问题，也不知道从哪里开始解决这个问题。
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的事情吗？
对于赏金，我正在寻找永久的解决方案。
So I have never seen this issue before and don't know where to begin troubleshooting the issue.
Cannot register assembly "obj\Debug\MyProject.Vsto.dll".
Loading this assembly would produce a different grant set from other instances.
(Exception from HRESULT: 0x80131401)
Where do I start to troubleshoot this?
I should mention this is a VS2008 environment with VS2008 SP1 and this solution is:
1. A VSTO Excel 2007 Project (C#)
2. A Data Access / Service Layer DLL (C#)
3. An MbUnit test project for #2 (C#)
UPDATE:
I should add this did work fine for several months. The only thing that I have changed in the last week or so is I have started working on the code via Team Foundation Server (TFS).
UPDATE 2:
Deleting the .suo file worked for a little while. Now I'm getting same error again.... hmmm. Guess I'll close the project delete the .suo again.
UPDATE 3:
VS2008 will allow me to compile the solution once. The second time I try I get the error.
If I exit, delete the .suo file, and reopen I can compile one time again. Any thoughts to the cause? Is this an VS2008 SP1 thing?
For the bounty I'm looking for the permanent solution.
发布评论
评论（8）
仅供参考...看起来像 CLR HRESULT （中间的 13 表示这一点）。
根据此博客文章：很多HRESULT代码...具体的HRESULT是
SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343
最有可能的是某个错误的进程在程序集上持有一个打开的句柄，并阻止编译器放置新的句柄。 鉴于更新＃3，该进程可能是 devenv.exe ...这对于缩小范围没有帮助，但它可能是一些随 VS 关闭的后台进程（例如调试器托管进程）。
假设文件中存在某些内容...要调试此类内容，第一步是从 SysInternals 工具集。 在其中您可以使用“查找”来确定哪个进程打开了该文件的句柄。 当您遇到此问题时，我希望它会显示 devenv.exe 中打开的句柄。
在 procexp 中，您可以执行关闭句柄这一高度危险的操作。 之后，在不关闭的情况下再次尝试这些步骤。 如果问题没有重现，那么您就知道您关闭的句柄是问题的原因。 如果其他事情顺利的话……那个“高度危险”的步骤可能就是原因。
如果您知道哪个进程有打开的句柄，那么您需要看看是否可以防止它遇到句柄的明显泄漏。 我会检查项目设置...包括复制文件的任何内容的调试设置。 如果有一个名为 VSHosting 进程的调试器设置...将其关闭。
祝你好运。
Just FYI ... that looks like a CLR HRESULT (the 13 in the middle indicates that).
Acording to this blog post:A lot of HRESULT codes... That specific HRESULT is
SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343
Most likely some errant process is holding an open handle on the assembly and preventing the compiler from laying down a new one. Given update #3 that process is probably devenv.exe ... which is unhelpful in narrowing it down, however it could be some background process which shuts down with VS (such as the debugger hosting process).
Assuming something is holding on the file ... to debug this type of thing the first step is to open procexp.exe from SysInternals toolset. In it you can use Find to determine which process has a handle open to the file. I'd expect it to show a handle open within devenv.exe when you hit this issue.
From within procexp you can do the highly dangerous thing of closing the handle. After that try the steps again without shutting down. If the problem doesn't repro then you know the handle you closed was the cause of the problem. If anything else happens well ... that 'highly dangerous' step was likely the cause.
If you know what process has the open handle then you need to see if you can prevent it from hitting the apparent leak of the handle. I would check the project settings ... including the debug ones for anything that copies the files. If there is a debugger setting called VSHosting process ... turn that off.
Good luck.
我做了一些谷歌搜索，发现 MSDN 论坛上的这篇文章可能对您有用（也可能没有）。
它提到了一些应该安装的 Windows 更新补丁（如果您使用的是 Vista）以及解决方法（如果您使用的是 XP）。 尽管该帖子提到了 Silverlight 的问题...错误是相同的，所以也许？
祝你好运！
I did some Googling and found this post on MSDN Forums which may (or may not) prove useful to you.
It mentions a few Windows Updates patches that should be installed (if you're on Vista) as well as a workaround if you're on XP. Although the post is referring to problems with Silverlight... the error is the same, so maybe?
Good luck!
我还没有看到确切的错误，但如果有从不同位置加载的 DLL 的另一个副本，则可能会发生类似的错误。
我会搜索一下是否还有该 DLL 的其他副本
I haven't seen that exact error, but similar errors can occur if there's another copy of the DLL that gets loaded from a different location.
I'd do a search to see if there's any other copies of that DLL lying around
那么它创建了 dll 但之后不喜欢使用它？ 如果是这种情况，您是否尝试在 Reflector 中打开 dll，看看第一次编译和第二次编译之间可能存在哪些差异？
另一个想法 - 在第一次成功构建后您是否尝试过清理/重建？ 您是否在每次编译时更新版本号？ 我想知道是否引用了过时的文件，但在第一次编译后进行了更新。 此时参考文献与预期不符。
另一个随机的想法 - .suo 文件通常包含与您的个人计算机相关的信息。 与编译相关的内容不应保存在该文件中 - 它应该保存到 .sln 中。 .suo 是根本原因似乎很奇怪......
So it creates the dll but doesn't like to use it afterward? If that's the case, have you tried to open the dlls in Reflector to see what differences there might be between the first and second compilation?
Another thought - have you tried a clean/rebuild after the first successful build? Are you updating the version numbers on each compile? I'm wondering if an outdated file is being referenced, but updated after the first compile. At which point the references don't match the expected ones.
Another random thought - the .suo file generally contains info related to your individual machine. Something related to the compilation shouldn't be saved in that file - it should go to the .sln instead. It would seem odd that the .suo is the root cause...
看来你开发了一个 ms-office 扩展。 然后您应该安装最新的COM Shim Wizard。 VS2008 的下载是 这里。
托管 Office 扩展应相互隔离。 MSDN 上的这篇文章解释了为什么以及如何。
我假设您的 .dll 不是隔离的，因此您会得到“Security-share-error”：
开发 Office 扩展一开始看起来很简单，但后来....
Thomas
seems that you develop an ms - office extension. Then you should install the latest COM Shim Wizard. Download for VS2008 is here.
Managed Office extensions should be isolated from each other. This article on MSDN explains why and how.
I assume that your .dll is not isolated, and therefore your get that "Security-share-error":
Developing office extensions looks so simple at the beginning, but then ....
Thomas
我看过这个 线程 这似乎突出了一些类似的问题。
如何排除故障？ 我想说首先检查您的应用程序是否可以生成此类错误消息。 然后检查您的软件所依赖的库或系统是否可能有故障（然后寻求支持或社区支持）。
祝你好运。
I have seen this thread which seems to highlight some similars issues.
how to troubleshoot? I would say first check that if your application could generate this kind of error message. Then checked if the libraries or system your software relies on could be faulty (then ask for support or community support).
Good luck.
这有点超出了我的范围，但我确实找到了以下 链接，该链接表明您在 .net 2.0 中遇到了已知缺陷。
我从微软建议的解决方法中复制了以下内容：
很抱歉，如果您已经在搜索中找到了这篇文章，但我没有看到这里提供它作为解决方案。
This is a little outside my area but I did find the following link which suggests that you are encountering a known defect with .net 2.0.
I copied the following from the suggested work-around from microsoft:
Sorry if you've already found this article in your searching but I didn't see it offered here as a solution.
你不会弄乱系统时间吧？ 这样做可能会弄乱你的程序集。
You're not messing with the system time are you? Doing that can mess up your assemblies.