Home » .Net Framework

regasm 4.0 generates error for DLL on a mapped network drive

Calling regasm from .NET Framework 4.0 generates an error for a DLL that is on a mapped network share.  This occurs during our debug builds on developer machines (we actually call a utility that wraps around regasm to perform COM-based registration).  The error is:

RegAsm : error RA0000 : Could not load file or assembly 'file:///m:\<file being regasmed>' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

I can work around this issue by modifying regasm.exe.config to include the loadFromRemoteSources element.  This seems like an annoying change for something that seems like a fairly common task.

Is there some better way to enable this?




14 Answers Found


Answer 1

It is possible that the account you are using to execute builds  does not have the relevant drive  mapping.

I would opt for UNC paths, e.g. \\server1\path\file.

My questions are:

Can you try a UNC path instead? Does that regasm  command work  using an interactive login? (i.e. checking that dependencies  are accessible) Can you interactively login with the same account that the build is using and run the command?


Answer 2

The drive  is mapped  to M: as we use ClearCase as our source control system.  If you're using a dynamic view, that's how it works.

The execution is occurring in an interactive login.  This is simply a developer  running a compilation in Visual Studio.  The end of the compilation kicks off our utility  that tries to call  regasm.  regasm fails with the message in my original email.


Answer 3

It would be better if you could post the command and parameters that you are running against regasm.

The tlb parameter should point to a folder that will be available when any user attempts to instantiate the registered library.

While it is possible to keep the library on a network  drive, it is not recommended, unless it is DCOM.

Another thing to concern yourself with is code access security. When an executable is loaded from a network drive  the CAS is downgraded to partial trust. If your library requires full trust, it won't work.

You can try this test. Create a new VS project. Add a reference to the library on the remote drive and change  it to "Copy local = false". Make sure there are no local copies. Can the VS project successfully use that library?


Answer 4


I took a look at this and reproduced it as well. Based on what I found, it appears to be due to the security changes for the CLR in .NET 4.0. For more information, take a look at this link:


What's happening is that when Regasm.exe attempts to load  the assembly  on the remote share, it fails with a FileLoadException with an inner System.NotSupportedException. Here is the relevant output from when I debugged this on my machine.

0:000> !pe 029d99a4
Exception object: 029d99a4
Exception type:   System.NotSupportedException
Message:          An attempt was made to load an assembly from a network  location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable  CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
InnerException:   <none>
StackTrace (generated):
StackTraceString: <none>
HResult: 80131515

Note the NotSupportedException points you to the relevant help topic which discusses the use of <loadFromRemoteSources> in the application's config  file.

It looks like you are already doing that, so if your utility  is going to spawn regasm.exe directly then I think you already have the best solution.

Another solution would be if you could simply check the option in Visual Studio for "compile with COM Interop". This seems to work  for me when building the DLL to the remote location (VS does not use regasm  when registering an assembly).

Hope this helps,

Keith Fink
Microsoft Communities Support


Answer 5

I found this helpful, thanks  Keith

Answer 6

So the first thing to try is to add the

[assembly: SecurityRules(SecurityRuleSet.Level1)]

attribute to your DLL assembly  properties, effectively switching off .NET4 security-transparent CAS.

If this works, it proves that the problem is about .NET4 CAS. Then you have to decide if you are happy leaving it switched off.


Answer 7

  I'm running into the same problem. [ regasm  was successful over a network  share in .net 3.5.]
  And here's the reason why I would like to use regasm  [and dont have the option modify regasm.exe.config]

Given that my COM interop assembly  [strong named] has to be registered [ as part of a product] for use on other client's machines
 while deploying, ideally I would like to continue using regasm [or some equivalent].

Also, technically if regasm is loading strong named assemblies , should this load  be successful or any different ?

Finally what are the alternate solutions to regasm ?

1. I create a myproduct.reg file  and am thinking of running it with the unc path since that does not involve regasm loading the exe  over a network.

2. [assembly: SecurityRules(SecurityRuleSet.Level1)]
   attribute to your DLL assembly properties, effectively switching off .NET4 security-transparent CAS.

   Where do I do this, is this an entry in AssemblyInfo.cs ?

3. Using VS [2010] to compile with COM interop.
   Dont seem to see this option on project properties. Is this the COMVisible attribute in AssemblyInfo.cs that you are referring to  ?

   >> Another solution would be if you could simply check the option in Visual Studio for "compile with COM Interop".
   >> This seems to work  for me when building the DLL to the remote location
   >> (VS does not use Regasm when registering an assembly).

   What does VS use for registering COM interop assemblies [other than regasm?]

   Any feedback will be really helpful.


Arun M


Answer 8


(1) Your registry file  may successfully add the entries into to registry, but code access security will still be a problem when your calling  client tries to instantiate it.

(2) Yes, in the AssemblyInfo

(3) I think the regasm  tool does this for you. The only thing I can think of that helps COM interop registration  is the GUID specified in the GuidAttribute and the type specified in the InterfaceTypeAttribute of the AssemblyInfo.


Answer 9

Just a minor note on #3, VS does not use Regasm when registering the assembly  for COM. Rather it is done by an in-process call  to RegisterAssembly.


Keith Fink
Microsoft Communities Support


Answer 10

Thx Guys.

  I went with a myproduct.reg solution since that seems to be the only working/practical solution.

Btw, internally wherever my app. was calling  Load/LoadFrom, I've modified it [UnSafeLoadFrom] so that when the app. is loaded/run over a network  it does not have similar issues as regasm  due to .NET 4.0 security changes.


 I guess another option could have been creating my own flavor/version of regasm

using interop registration  services as pointed in the earlier resposnse.





Answer 11

Hello everyone,

I am also facing the same issue  as mentioned above. I try to regasm  a .Net 4 framework  assembly over the network  and am getting the following error:

RegAsm : error  RA0000: Could not load  file or assembly  'filename with path' or one of its dependencies. Operation is not supported. <Exception from HRESULT: 0x80131515>

This used to work  with .Net framework 3.5. I could not understand, the fix mentioned for this problem for .Net 4.0 framework as mentioned above.

Please advise, how to get around this error.









Answer 12

The fix I was explaining was...

Add the


[assembly: SecurityRules(SecurityRuleSet.Level1)]


attribute to your DLL assembly  properties, effectively switching off .NET4 security-transparent CAS. To find this, look in the Properties folder in your project and open the AssemblyInfo.cs file.


Answer 13

Hi Johan,

I tried this out and it still fails for me. The DLL builds  successfully for me, but if I run regasm  against it, it still fails with the same System.NotSupportedException / FileLoadException. Did you try it out? Just wondering if I missed something. Otherwise, the only other solutions I see are:

Use loadFromRemoteSources as Kevin mentioned. Write your "regasm" that calls into RegistrationServices.RegisterAssembly.

Hopefully, I just missed something though; as your solution would be the easiest.


Keith Fink
Microsoft Communities Support


Answer 14


Yes the LoadFromRemoteSources worked for me. In addition, I created my own registration  assembly code and its working fine for me.





<< Previous      Next >>

Microsoft   |   Windows   |   Visual Studio   |   Sharepoint   |   Azure