Assembly does not allow partially trusted caller

Question

How do I change my library to allow partially trusted callers?

I get the following error:

Server Error in '/' Application.

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.

Source Error: [No relevant source lines]

Source File: App_Web_kzj7vfkn.2.cs
Line: 0

Edit

After some more looking at the problem it seems like it's System.Web.UI.ClientScriptManager that causes the problem

Management

Any idea which library? Is App_Web your code? (Like App_Web.aspx) – Earthshine

the library is xVal webforms. It's strange, because I got it running at another site. – Management

Actually it seems like it's System.Web.UI.ClientScriptManager that causes the problem.. – Management

Answer 1

Assuming you have access to the sources of your library.

• Give the library you are trying to call a strong name.
• Add [assembly:AllowPartiallyTrustedCallers] to the library that you are trying to call.
• Create a code group to set permissions to the library

A pretty good and detailed explanation is given here Also read the links at the bottom to get a better understanding.

There is a possibility that not your assembly is the problem but you are calling another assembly that does not allow partially trusted callers. At runtime you can use fuslogvw to find which assembly is giving you the problems. If this is the problem and you have the sources of this assembly you need to also apply the [assembly:AllowPartiallyTrustedCallers] attribute to that assembly, if you don't have the sources the only option I know of is to replace the troublesome library.

Hacksaw

I have the source, but I have trouble creating a key pair, since I'm using the express versions and don't have access to the vs command prompt. – Management

I am not entirely sure and don't have an express version at hand but I believe the express editions have a signing tab (project properties) that you can use to create a strong named assembly – Hacksaw

What if you don't have access to the source? – Haifa

Hi Ray, I think it is wise to open another question and see if somebody has a better answer for you. As I said in my answer if you don't have sources the only option I knew of in 2010 was to use another assembly. Since .net 4.0 there might be a possibility using sandboxing but I do not know enough about it to answer your question. See here msdn.microsoft.com/en-us/library/8skskf63.aspx for a first introduction. – Hacksaw

For anyone still having this: if you're running a command line app: right click the project > settings > security > uncheck "Enable ClickOnce Security Settings". – Glendoraglendower

The original 'detailed explanation' link now appears to be dead... Here it is on the wayback machine: web.archive.org/web/20150212170137/http://support.microsoft.com/… – Bregenz

Answer 2

In my case -

This solved a similar problem:

I had to go to my dll properties,
And press the Unblock button:

Papery

Answer 3

I know its quite late to answer, but I would like to add one more answer just to help future visitors.

My Scenario

I was implementing CCavenue Payment gateway in my asp.net application when I had this issue becuase CCavenue encryption MCPG.CCA.Util

Please add the following lines in web.config

<system.web>

  <trust level="Full" />

</system.web>

Flytrap

Answer 4

I know this is a very old question but I just ran into this issue and was able to fix it using a different method than the accepted answer and since this is the first result on google when searching for the error message I think it will be useful to others if I share my solution.

The issue I was running into came about when I attempted to integrate with a piece of hardware. The hardware had its own installer which would register a DLL into the GAC. The DLL it installed had 2 dependency DLLs but for some reason when the installer was run it was not registering the dependency DLLs.

Basically the scenario was that the Entry DLL was registered in the GAC and its two dependency DLLs were not registered in the GAC but did exist next to the executable.

When I ran my program and attempted to use the piece of hardware, the program was looking for the entry DLL next to the executable, which it could not find. The program would then go to the GAC, where it would find the entry DLL. Once inside the DLL for the hardware it would eventually try to use the dependency DLLs which were not in the GAC but were next to the executable. Calling out of the GAC to the DLL that was next to the executable was throwing the partially trusted caller error.

I resolved this by placing a copy of the entry DLL next to the executable.

I was curious as to what scenarios would work and what would cause the security error and I've found these are the scenarios that worked as expected:

1. All three of the DLLs next to the executable.
2. All three DLLs in the GAC.

The only scenario that consistently failed was when any layer was inside the GAC and any of the dependency DLLs were outside the GAC.

Failed Scenario #1:

1. Entry DLL in the GAC

2. DLL #2 and DLL #3 next to the Exe

   • Fails siting DLL #2 as the faulting DLL.

Failed Scenario #2:

1. Entry DLL and DLL #2 in the GAC

2. DLL #3 next to the Exe

   • Fails siting DLL #3 as the faulting DLL.

Failed Scenario #3:

1. Entry DLL and DLL #3 in the GAC

2. DLL #2 next to the exe

   • (Predictably) Fails siting DLL #2 as the faulting DLL.

I did not test it but I think its a safe assumption to say that if the entry DLL and DLL #3 had been next to the executable and DLL #2 had been in the GAC then it would have faulted with DLL #3 being sited as the problem.

Hedwighedwiga

Answer 5

I also got the similar problem, I tried all the above answers but none worked for me. Apparently my case was different, In my case the framework was 3.5. I changed it to 4 or above and it worked for me.

Obnoxious

Answer 6

Here's yet another possible solution, depending on the library you're using and your setup: Make sure you're running your program from a "local" drive.

I ran into this error message when running my program in a VM in a folder shared between host and guest OS, with the library dll present beside the exe. Copying the folder to a drive local to the guest OS fixed the issue.

It makes sense that this would cause a trust issue, but a more helpful error message would be nice.

Errick