Two-way communication between AppDomains inside of IIS Requests

I’m working on an ASP.NET app, and we want to add the ability to call customer script during some of the requests. Since we don’t trust this script, we are spawning a child AppDomain inside of our IIS request which has limited permissions, and loading both the customer assembly and a Script Runner assembly. The customer script can do things like change the description of a business object or change a status code to an error if certain criteria are met. Because the changes are so varied, I can’t encompass them in a single object that gets returned from a method call. As the script is running, I need it to alter values in objects inside of the Request that launched this child.

This post recommends using NetNamedPipeBinding, but I’m growing concerned that it isn’t appropriate for code running inside of IIS where multiple requests could be running concurrently. Would I set up a new host for each IIS request? Set up a static host for the entire process, and then use endpoints to make sure that the correct child talks with the correct request? Is this the right technology?

If this isn’t the right technology, what is? This post tells you how to retrieve the handle of the parent AppDomain, but many of those seem to use mscoree.dll, and generally I was under the impression that COM and IIS didn’t mix terribly well. This post talks about wiping out your initial AppDomain and creating a new one. Perhaps that’s not necessary in IIS?

Is there a way for a child AppDomain to efficiently execute methods inside of the Request object that spawned it, and if so what is it?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

I think I’ve found a simple technique for a child AppDomain to alter the state in the parent AppDomain without using WCF or mscoree.dll. Rereading the first post above, I see he does mention it as a possibility, but rejects it for reasons that are not clear to me. The trick is to create an object derived from MarshalByRefObject in the parent, obtain an ObjectHandle to it, and then pass that ObjectHandle to the child AppDomain. The child can then unwrap the handle to get a proxy, and can then call methods which will alter the state of the object in the parent. Here’s a code sample:

class Program
{
    public class ParentFacade : MarshalByRefObject
    {
        public List<string> Collection { get; set; }
        public void AddElement(string el)
        {
            Collection.Add(el);
        }
    }

    public class ChildFacade : MarshalByRefObject
    {
        public void AlterParentState(ObjectHandle handle)
        {
            var parent = handle.Unwrap() as ParentFacade;
            parent.AddElement("Message from child");
        }
    }

    static void Main(string[] args)
    {
        var child = AppDomain.CreateDomain("child");
        var childFacadeType = typeof(ChildFacade);
        var childProxy = child.CreateInstanceAndUnwrap(childFacadeType.Assembly.FullName, childFacadeType.FullName) as ChildFacade;

        var parentColl = new List<string>();
        var facade = new ParentFacade();
        facade.Collection = parentColl;
        var facadeHandle = new ObjectHandle(facade);
        childProxy.AlterParentState(facadeHandle);

        foreach (var item in parentColl)
            Console.WriteLine(item);
    }
}

This code shows that a method in the child was able to alter the state of objects in the parent. This particular example isn’t terribly useful, but this is very powerful when you are setting up a sandbox, and include .dll’s in the child assembly that you don’t trust. The untrusted assembly can call methods in the ChildFacade and thereby alter the state in the parent in a controlled and safe way.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0