1

When running from a network share, my application throws the following exception:

That assembly does not allow partially trusted callers.

My application references two DLL files:

  • BitFactory.Logging.dll
  • FileHelpers.dll

I'm not sure which one it is having problems with.

  • AllowPartiallyTrustedCallersAttribute: Read up on it, but I do not have the source for either of the DLL files, so I'm not able to add the attribute to those DLL files.

  • CASPOL.EXE: added my network share using a few variations, such as caspol -machine -addgroup 1. -url \\netserver\netshare\* LocalIntranet nothing seems to affect.

I've used CASPOL hack before, with .NET 3.5, however, it seems to not work with .net 4.0 now. Can anyone suggeest on how I can bypass this "Partially Trusted Caller" check?

Thanks.

Nasir
  • 10,935
  • 8
  • 31
  • 39

1 Answers1

13

.NET 4.0 has changed the default rules for security policy. You'll need to create or modify the App.config file for this application.

Code access security (as configured by CASPOL) is now ignored by default in .NET 4.0. If you want to enable it you need to add the following to your app.config file:

<configuration>
   <runtime>
      <!-- enables legacy CAS policy for this process -->
      <NetFx40_LegacySecurityPolicy enabled="true" />
   </runtime>
</configuration>

You can configure .NET 4.0 to treat code from the network using LoadFrom as fully trusted with the following configuration item:

<configuration>
   <runtime>
      <!-- Treat assemblies from network locations as fully trusted. -->
      <!-- Caution: Do not point this loaded gun at your foot. -->
      <loadFromRemoteSources enabled="true" />
   </runtime>
</configuration>
user2864740
  • 60,010
  • 15
  • 145
  • 220
Jeffrey Hantin
  • 35,734
  • 7
  • 75
  • 94
  • I'm not using "LoadFrom" explicitly, only added references to the DLLs in question. neither of the options above seem to have any effect. – Nasir Nov 23 '10 at 21:07
  • @nsr81 Is your executable strong-named? – Jeffrey Hantin Nov 23 '10 at 22:35
  • no it wasn't. Everything is good after I signed the executable using *.snk key file. – Nasir Nov 24 '10 at 19:24
  • @Jeffrey Hantin Hi, I have tried the method you guys posted above, it didn't work out for me. I generated a key using sn.exe. Then configure Sign the assembly for each project with this key. At the end, it still complains that the third party assemblies (i.e. FileHelpers.dll) don't have a strong name. Did I miss steps somewhere? Thanks a lot! – Candy Chiu Mar 16 '12 at 17:31
  • @Candy A signed assembly cannot take a dependency on a non-signed third party assembly -- that's a compilation error with no way around it. – Jeffrey Hantin Mar 16 '12 at 23:36
  • @Jeffrey Hantin Thanks. I now see that the problem is the third party libraries were compiled with <= .NET 3.5 & unsigned, while my project is compiled with .NET 4.0. Is there a way out of this at all? If you prefer, my question is here: http://stackoverflow.com/questions/9743267/net-4-0-third-party-library-causing-that-assembly-does-not-allow-partially-tru Thanks. – Candy Chiu Mar 19 '12 at 12:25
  • caspol. Seems like a capsule to get headaches – Nezam Aug 26 '15 at 22:41