CLR AddIn Model in Paint.Net – 6 (AddInBase, AddIn and Deployment)

AddInView is an abstract class and AddIn should inherit from it. Here is the code for AddInView and AddIn.


namespace PaintDotNetAddInViews



    public abstract class PDNAddInView


        public abstract void Render();





namespace PaintDotNetAddIn



    public class PDNAddIn : PDNAddInView


        public override void Render()


            throw new Exception("The method or operation is not implemented.");





A few things to be noticed here. Since AddInView will be the base class of the AddIn, its attribute is actually named as AddInBase. The AddIn’s attribute requires a name string. This name string will help host to decide which AddIn to pick if there are multiple AddIns available. That is actually why we create the AddInSelectorConfigDialog. To repeat our versioning story, AddInView and AddIn won’t have dependency on either the Host or the contract.


As you may notice, we have not real implementation of the Render method. Since we don’t have depency on the Host (Paint.Net), we cannot use its data type. That would be a major task in my future blog.


Our AddIn deployment model is actually quite simple.

As long as you put the right component in the right folder and let the host know the root folder. Our discovery API will automatically discover the dlls and connect them together. Host developer does not need to deal with all the CLR Loader details at all.


Here is where I put all my dlls under my pipeline root. Please notice that AddIn is not considered part of pipeline. And we can have multiple AddIns for one pipeline. Each AddIn should have its own subfolder.


..>dir *.dll /s /B







We have discussed the full pipeline and AddIn in the previous blogs and this one. We have all the components. It is about the time to see everything in action.


Next topic will be Activation.

Comments (2)

  1. ppavan says:


       Thanks for this great series. One question I had was "Can one Add-In depend on another Add-In?" For example I could split up my add-ins into 2 individual addins. One of them would be the view and the other the data-access-layer. Can I say the view addin depends on the data-access addin? I have seen this functionality in Eclipse and also in #Develop and find it extremely useful to split up the addins that way.



  2. ZifengH says:

    If I understand correctly, you want presentation AddIn to control the data-access Addin.  That should be OK.  The presentation AddIn will have dual roles, one as an AddIn, one as a Host.

Skip to main content