AddInView is an abstract class and AddIn should inherit from it. Here is the code for AddInView and AddIn.
public abstract class PDNAddInView
public abstract void Render();
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.