Extending your Application with MAF/VSTA AddIns

VSTA (Visual Studio Tools for Applications) is essentially the managed .NET version of Visual Basic for Applications. We can now use C# to create our own application plug-ins and to allow for such extensibility within our host applications. In the past, I've had to create all of my plug-in code by hand. I created code that would take classes out of Assemblies and load them into their own AppDomain and allow them to execute. I've even gotten fancy enough so that I could iterate through a list of all the loaded plug-in AppDomains. VSTA takes this a few hundred steps further. The System.AddIn namespace provides all of the "loader" functionality that I've had to hand-code in the past. Beyond that, your applications can now integrate with VSTA (Visual Studio Tools for Applications), a lightweight VS IDE, and actually provide VS project templates to your third party integrators and developers. In addition to providing the basic functionality of being able to load plug-ins, you can expose your application's object model to the third-party plugin. Another rather astounding feature of this whole thing is that VSTA will let you create managed plug-ins or unmanaged COM plug-ins.

You can even have the VSTA IDE pop-up directly within your application to allow programmers to create addins on the fly and to allow end users of your application to create macro recordings! The possibilities are pretty endless. The only problem is making sense of the whole thing. There are so many possibilities that its hard to keep your head above water when looking through the documentation. The problem I had was that VSTA and the AddIn support is currently part of the Visual Studio SDK, which is huge.

In the next couple of articles I am going to create a standard Windows Forms application that doesn't do much fancy, and then I am gradually going to expand on it to make it do more and more related to plug-ins. There is a sample in the VS 2005 SDK called ShapeApp, and a lot of what I will do will be similar to that. I think the main difference between my sample and ShapeApp is that I don't plan on exposing a really big object model, and I want to try and do a couple of things that ShapeApp doesn't do. Hopefully I won't run into a wall and find out that what I want to do is impossible...but learning that will be valuable regardless :)

So, to take a regular application and allow for add-in support, you need to follow the following steps:

1. Add references to the VSTA and AddIn Assemblies to your application:
1. Microsoft.VisualStudio.Tools.Applications.Adapter
2. Microsoft.VisualStudio.Tools.Applications.AddInManager
3. Microsoft.VisualStudio.Tools.Applications.Contract
4. System.AddIn.Contract
2. Create a Host Item Provider. Addins communicate with the host application through a proxy. The proxy obtains objects through the host item provider. This is the key that unlocks access to your host application's object model and provides that object model to the addin. I will go into more detail on this in the next article where I go through the process of addin enabling an application.
3. Add a QueryContract method to the host item provider. This is essentially a factory method that returns the current instance of the host item provider.
4. Add a GetHostObject method to the host item provider class. This method is used to give the calling addin a reference to an adapter object that implements IRemoteObjectContract. On the managed side of the addin architecture, this method returns a RemoteObjectAdapter instance that is essentially responsible for marshalling between the addin and the host application. The RemoteObjectAdapter class provides access to manage objects that cross AppDomain and process boundaries. Think of it as a Remoting Broker on Steroids...only it didn't get caught...and doesn't have any negative side effects of prolonged use...
5. Round out the host item provider with a few more methods. These methods deal with obtaining remote hash codes, and performing a RemoteEquals operation on proxy class instances...basically busywork that will have to be done every time you build addin support, but the methods are also easy to implement.
6. Use the Addin API (System.AddIn) to load the compiled AddIns from loosely coupled, partially trusted Assemblies.
7. Use the proxygen.exe class to create a host map file and stub code for creating in-memory canonical type mappings. Involves using the TypeInfrastructureManager class that you'll see plenty of in the next article.
8. Register your application as an AddIn host (creates some Registry key settings)
9. Create Visual Studio Project Templates for third party developers based on the generated proxies using projectgen.exe.

That's what you need for basic support. The steps above don't prepare your application for loading the VSTA IDE and creating plug-ins on the fly while the application is still running.

So, in the next article, I am going to show you a Windows Forms application that has a pretty simple object model. I'll then walk you through the process of exposing that object model to addins, show you the meta-data XML files and the proxies created, show you how to register the application as an AddIn host, and how to do what you need to do in order to let another developer take over and start creating addins.

After that, we'll create an addin and integrate it with the host application and see how things work. I am learning this stuff just like you are, so hopefully we'll all find out that VSTA is the answer to our plug-in prayers and it will hold up to my tests and yours. We'll see!!

tags: maf  vsta  addins  macros  plugins  netfx3  

links: digg this    del.icio.us    technorati    reddit