Partager via

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

  • Article

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

  • Anonymous
    March 08, 2007
    Over 2 years ago when I got intreduced to C# 2.0 and generics I wrote an Extensibility Application Block.
  • Anonymous
    March 15, 2007
    "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?
  • Anonymous
    March 16, 2007
    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 timeChris Richner
  • Anonymous
    March 16, 2007
    The comment has been removed
  • Anonymous
    March 19, 2007
    "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
  • Anonymous
    March 20, 2007
    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.
  • Anonymous
    March 20, 2007
    I see, thanksLooking forward to System.Addin namespace, do you use wcf internally for addin communication/hosting?
  • Anonymous
    March 21, 2007
    We build upon remoting.
  • Anonymous
    August 29, 2007
    System.AddIn in Framework V3.5 is about building hosts that load plug-in Add-Ins with functionality around...