CSharpCodeProvider uses obsolete Assembly.Load method which takes permission information from assembly instead of appdomain - by Anonymous12345999

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 535189 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 2/21/2010 7:14:52 PM
Access Restriction Public


The problem occurs when using the Microsoft.CSharp.CSharpCodeProvider type (located in System.dll) to compile source on the fly and generate new assemblies in memory. When CompilerParameters.GenerateInMemory is set to true, the CompileAssemblyFromSource method eventually calls down to Assembly.Load(byte[], byte[], Evidence), which has been obsoleted in .NET 4. 

The documentation for that method states that when a null is passed for the Evidence, it will take the security permissions from the calling application domain. In fact, it takes the security permissions from the calling Assembly.

Now, I cannot use GenerateInMemory in a separate sandboxed AppDomain because no matter what permissions I give to the sandboxed domain the newly compiled assembly will bypass them and take those of the parent Assembly. At the very least, the documentation for the Assembly.Load method is incorrect.
Sign in to post a comment.
Posted by Microsoft on 3/25/2010 at 11:55 AM
Thanks for reporting this issue - the fix you're looking for would require API additions in the CodeDOM space, which is technically a feature. As such, I'll be logging this request as a CodeDOM feature proposal for the next version of the .NET Framework (and closing this item).

Thank you again for your feedback.

Andrew Dai
Program Manager, Common Language Runtime
Posted by Anonymous12345999 on 3/23/2010 at 9:12 AM
OK, that's fine, I can use the workaround for now. In fact I've been using it since I filed this issue.

Thanks for your help.
Posted by Microsoft on 3/23/2010 at 9:07 AM
Sorry, Mike, I pasted the wrong text. :-( I've reactivated the bug and assigned it to development. I can't say what the chances are of a service pack release. This seems low impact to me, but I don't make those decisions. I can say that the feature is viewed as reasonable and useful.

Posted by Microsoft on 3/23/2010 at 9:01 AM
The workaround in .NET Framework version 4 is to compile the assembly to disk, instead of in memory. When the on-disk assembly is subsequently loaded into the application domain, it gets the trust level of the application domain.
Posted by Anonymous12345999 on 3/22/2010 at 10:07 PM
Yes, that would be good. Any chance on this making it the next service pack?
Posted by Microsoft on 3/22/2010 at 9:09 PM
Mike -- It doesn't look like you can do this with an in-memory assembly, because there's no way to create one without loading it. The workaround for now is to generate an assembly on disk. When you load that assembly into the application domain, it's loaded with the application domain's security.

Being able to specify that the security for in-memory assembly should come from the application domain rather than from the generating assembly is a very reasonable and low-cost feature request. Do you want to turn this bug into a request for that, in a future release?

Posted by Microsoft on 3/19/2010 at 3:46 PM
You're quite right. This was handed off to me as a doc bug, and I was just looking at that aspect of it. Let me see what I can find out.

Posted by Anonymous12345999 on 3/19/2010 at 3:10 PM
This doesn't help me with my original issue though, which is that generated executables can't be loaded into partial trust app domains because they bypass any security restrictions that may exist in them.
Posted by Microsoft on 3/19/2010 at 2:03 PM
Thanks for pointing this out, Mike! As you surmised, the documentation was incorrect. If you pass null Evidence, the evidence of the calling assembly is used, just as in the .NET Framework 3.5. We have updated the documentation; the correction will appear on MSDN in the near future.


Posted by Microsoft on 2/22/2010 at 7:05 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)