Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0

The MSDN Magazine site just put up my article, Do You Trust It? Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0, as a preview of their November security issue.  In the article I cover various techniques for safely hosting Add-Ins which may or may not be trusted, starting from the basic Assembly.Load technique and moving onto sandboxing, transparency, and AppDomainManagers.  I'd say it's worth a read, but then I might be a little biased as well 🙂

This issue also features an article by Mike Downen covering the various enhancements to CLR security in v2.0.

November 2005 MSDN Cover

Comments (12)

  1. Eric Marthinsen says:


    Great article. Do you have a complete set of sample code?



  2. Eric Marthinsen says:


    Do you have a complete sample solution that describes your techniques? It would be great to see how everything fits together.



  3. Releasing a sample here is a great idea — I’ll look into doing that.

    Glad you liked the article!


  4. Alex says:


    Great article. Thank you.

    One thing keeps bothering me. Where would you define IAddIn interface in the case of separating addins by subdirectories? The assembly where interface is defined has to be present in each add-in directory, right?

    So, as Eric noticed it would be nice to have a sample code.



  5. A simple sample is definately a todo item 🙂

    In the subdirectory case, you might want to consider putting IAddIn in the GAC.


  6. Yishai says:

    I am trying to convert a 1.1 sandboxing application to use the techniques in this article for 2.0.  The existing application uses AppDomain.ExecuteAssembly to call the client code in the sandbox AppDomain, but this doesn’t seem to work with the 2.0 simple sandboxing API.  I get a security exception for the demand of a FileIOPermission to read the file containing the client assembly.  I tried giving MyComputer zone in the top-of-stack evidence parameter to CreateDomain, while the grant set corresponds to the Internet zone, but that didn’t help.  (The code that calls ExecuteAssembly has full trust.)  It seems like the 2.0 Framework is changing the grant set in the new AppDomain before loading the client assembly.  Does this mean I can’t use ExecuteAssembly to load client code in a sandbox?



  7. Funny you should mention it, this is the next topic on my todo list on the whiteboard.  I’ll probably do a full write up on Monday, but basically you should make sure the AppBase of the domain points to the location of the EXE you’re trying to run and use ExecuateAssemblyByName instead of ExecuteAssembly.


  8. Yishai says:

    Thanks a lot, great tip.  It now works, except that I had to add an unrestricted UIPermission to the grant set.  This is not a problem for this particular application, but could be for others.  Is there a way around this?

    — Yishai

  9. Hi Yishai,

    Console applications require unrestricted UI permission in v2.0 of the CLR (  I’d bet that this is the problem you’re running into.


  10. leng says:

    In the MSDN article you mention to use a seperate AppDomain (c.q. application base), either one for all add-ins or one per add-in. Is there an upper limit for the number of AppDomains that can be created per process and/or system? How many AppDomains are typically running on a system?

  11. Casper Jensen says:

    Hi Shawn

    Have you released the source code for this great article?



  12. Which part of the code would you be looking for?  How to use the AppDomainManager?


Skip to main content