In the AddIn discovery blog, we already knew that we could get a collection of AddInToken from discovery API. AddInToken stores the full pipeline information and can be used to activate an AddIn. Before host start to activate an AddIn, it has many decisions to make, like in-process or out-of-process, in existing AppDomain or in a new AppDomain, and choice of security level. In the Paint.Net scenario, we can pick a very simple implementation, which tells the activation API to start an AddIn in a new AppDomain and give it FullTrust permissions. Here is the code.

 

public override void Render(EffectConfigToken parameters, RenderArgs dstArgs, RenderArgs srcArgs,

           Rectangle[] rois, int startIndex, int length)

        {

            AddInSelectorConfigToken effectToken = (AddInSelectorConfigToken)parameters;

            AddInToken token = effectToken.AddInToken;

            if (token != null)

            {

                AddInHSV hav = token.Activate<AddInHSV>(AddInSecurityLevel.FullTrust);

                hav.Render(parameters, dstArgs, srcArgs, rois, startIndex, length);

            }

        }

 

We are using FullTrust here because current Paint.Net effect supports unsafe code and give Effect module really high trust. We do support all kinds of permission set sandbox for our activation. You can even host an AddIn in an ExecutionOnly AppDomain. Our activation API played very well with CLR security model to make sure that there is no security elevation here (I mean we tried our best).

 

Paint.Net has the host in the default AppDomain which has FullTrust. We can actually do AddIn activation in a PartialTrust AppDomain. Of cause you won’t be able to create AppDomain with higher trust level than the Host itself. And activation of out-of-process AddIn will always demand FullTrust for security reasons.

 

One nice feature we have is that AddInToken is marked as Serializable. There are customers who want to host one AddIn in another AddIn. Since AddInToken is serializable, it could be passed from Host to AddIn and let the dual-role AddIn to call hosting API as well.

 

With all the code in these series of blogs, we can actually run a dummy AddIn and do nothing useful so far. However, we are still missing one critical part to manage AddIn’s lifecycle. We call it AddInController.

 

Next topic will be AddInController.