New System.AddIn Features in March’s Orcas CTP [Jesse Kaplan]


Some of you may have noticed already but for those who haven’t I’d like to announce one of the major new System.AddIn features that made it into March’s Orcas CTP. We’ve now made it possible for hosts to activate add-ins in a seperate process with the same ease as in a seperate AppDomain. We’re very excited about this feature because we weren’t sure we could get it into Orcas and now that it’s here and you can activate add-ins in their own processes you can use existing OS features to gain better reliability in the face of misbehaving add-ins: you can ensure that the host never crashes when the add-in does, limit the amount of memory available to each add-in process, and even lower the priority of these process to protect against CPU hogs.


 


If you go back to our very first blog post we showed you the few lines of code needed to activate each add-in in its own AppDomain:


AddInStore.Update(addinPath);


IList<AddInToken> tokens =


AddInStore.FindAddIns(typeof(AddInType), addinPath);


foreach (AddInToken token in tokens)


{


token.Activate<AddInType>(AddInSecurityLevel.Internet);


}


 


 


Well, to activate each add-in in its own process you don’t even need to add a line of code:


 


AddInStore.Update(addinPath);


IList<AddInToken> tokens =


AddInStore.FindAddIns(typeof(AddInType), addinPath);


foreach (AddInToken token in tokens)


{


token.Activate<AddInType>(new AddInProcess(), AddInSecurityLevel.FullTrust);


}


 


It’s also very easy to group add-ins in the same external process with different AppDomains:


AddInStore.Update(addinPath);


IList<AddInToken> tokens =


AddInStore.FindAddIns(typeof(AddInType), addinPath);


AddInProcess  sharedProcess = new AddInProcess();


foreach (AddInToken token in tokens)


{


token.Activate<AddInType>(sharedProcess , AddInSecurityLevel.FullTrust);


}


 


One downside with running add-ins out-of-process is that there are a few security demands that come out of remoting and serialization that require that both the host and the add-in run in FullTrust domains. Sandboxing of AppDomain isolated add-ins is still fully supported, but process isolated ones will need full trust.


As part of this work we also refactored the System.AddIn namespace out of System.Core and into it’s own assembly. If you’ve been playing with this you’ll need change your projects a bit and add references to System.AddIn v3.5.


We’ll be going into more detail on what happens when you activate both in and out of AppDomain and how we manage the lifetime of these AppDomains and processes later, but for now please play with the bits and let us know what you think.


 


 


 


 

Comments (9)

  1. Anonymous says:

    Over 2 years ago when I got intreduced to C# 2.0 and generics I wrote an Extensibility Application Block.

  2. Anonymous says:

    "One downside with running add-ins out-of-process is that there are a few security demands that come out of remoting and serialization that require that both the host and the add-in run in FullTrust domains."

    May be host add-in in second domain configured with lower trust?

  3. Anonymous says:

    Hi,

    I’m excited about the new System.AddIn namespace. Our company wrote a custom application server hosted by an nt service. Plugins are loaded to seperated AppDomains, Remoting is used to overcome appdomain bounds.

    So far so good 😉 But when an add in (in our case Plugin) crashes (unhandled) the nt service crashes as well, not a service that one can call application server when it crashes 4 times a day because of bad implemented add in, right?

    Is there anything I can change to let my appserver survive while a plugin dies?

    Thanks for your time

    Chris Richner

  4. Garry Trinder says:

    Re: Partial Trust in Remote Process

    It would be possible for you to activate a full trust add-in in the remote process and then have that add-in activate a low trust add-in in the same remote process. As long as all communication back to the original host process happens through the high trust add-in  it would be possible to build this.

    Re: Reliability in the face of crashing add-ins

    One of the main reasons we added out-of-process hosting of add-ins was to provide even more reliability to the host when add-ins fail. As long as the host has catch blocks around its calls into the add-in and can recover if an exception is thrown, there is no way for the add-in to take down the host: even an out-of-memory or a stack overflow in the add-in process will let the host keep going.

     

    –Jesse

  5. Anonymous says:

    "there is no way for the add-in to take down the host"  is only valid for out-of-process hosted addin, right? As far as I know in .net 2.0 an unhandled exception takes down all loaded appdomains, even if just one is affected by the exception.

    Is this correct?

    Why does iis / asp.net behave different? Is there something different in the clr hosting env?

    Thanks for reading and optionally answering my questions 😉

    Chris

  6. Garry Trinder says:

    Your correct Chris, running the add-in out of process is what makes it possible to prevent unhandled exceptions in the add-in from tearing down the host as well.

    If you use the native clr hosting APIs it is possible to start up the CLR and control the behavior of unhandled exception, but those apis can be quite difficult to use and have other side effects.

    I don’t know the details of how IIS/ASP.net works but I believe what they do is run all code in the w3wp process and put a catch block around all calls into the user code: if the user code (the web site) throws an exception on one of the iis/asp.net initiated threads then asp.net can catch it and report it, if the web site throws an unhandled exception on a different thread I believe that the w3wp process gets torn down and then restarted. I don’t think they try to use the native clr hosting api’s to prevent process teardown on unhandled exceptions.

  7. Anonymous says:

    I see, thanks

    Looking forward to System.Addin namespace, do you use wcf internally for addin communication/hosting?

  8. We build upon remoting.

  9. Anonymous says:

    System.AddIn in Framework V3.5 is about building hosts that load plug-in Add-Ins with functionality around…