Error Compiling Program in Visual Studio 2008

Question

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.

Answer 1

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!

Answer 2

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

dir MyProject.*.dll /s

Answer 3

Hi,

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.

Answer 4

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...

Answer 5

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.

Answer 6

Hi,

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":

Isolation. If you do not use a standard COM shim (such as the Visual Studio Tools for Office loader) or provide your own custom COM shim, your extension DLL loads into the default application domain along with all other un-shimmed extensions. All DLLs running in the same application domain are vulnerable to potential damage caused by any other DLL in the same application domain. Also, any un-shimmed add-in that crashes in a host application disables all other un-shimmed add-ins for that application.

Developing office extensions looks so simple at the beginning, but then ....

Thomas

Answer 7

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:

The problem will occur when marshaling an object by value between two appdomains in the same process where the type of the instance is generic, the generic template type is defined in mscorlib, one or more of its instantiating types is not defined in mscorlib and multi-domain loader optimization has been enabled in one domain but not the other.

Unfortunately this bug was discovered too late and didn't make the bar for the V2.0 product. There are some workarounds however:

This bug is specific to an optimized version of the in-process, cross-appdomain remoting channel and therefore can be avoided by switching this optimization off for the process. This can be achieved either by setting the the following environment variable in the command window where the test will be executed:

set complus_UseNewCrossDomainRemoting=0

Or by setting the HKEY_CURRENT_USER\Software\Microsoft.NETFramework\UseNewCrossDomainRemoting registry value (a DWORD) to 0 (or the version in HKEY_LOCAL_MACHINE).

These are a bit heavyweight, but it's also possible to fool the optimized path into avoiding just the specific call that transfers the problematic object. To do this add a dummy out parameter to the call (for various technical reasons the optimized path doesn't implement out parameters yet).

You can also avoid using an mscorlib defined generic type. In the repro case presented this is simple enough since you can just subtype List:

[Serializable]
public class MyList<T> : List<T>
{
}

(Just replace all uses of List with MyList).

Finally, the problem shouldn't occur if both appdomains are using the multi-domain optimization. You can't set the default domain's loader optimization after you're already running it but you can either set it externally (I believe via the unmanaged hosting API or a config file, though I'm not an expert in either, sorry) or by creating a new domain (with multi-domain opt) within your code and transferring control to it (via a call on an MBRO object in that domain).

Sorry if you've already found this article in your searching but I didn't see it offered here as a solution.

Answer 8

you're not messing with the system time are you? doing that can mess up your assemblies