Extending your Applications with MAF/VSTA Addins - Part IV

I left off at the point where I needed to register my AddIn application as a host, and then I was going to move on from there. I originally planned on giving you yet another detailed explanation of everything I did... but unfortunately I think I am going to summarize a bit here. You'll find out why when I get to the end of the story.

The next step after creating the new application is to create proxies from the source application. To do this, I issued the following command as given to me by the SDK walkthrough:
proxygen /l:"(full path to my .EXE file)" /c:AddInHostProxy.cs /o:AddInHostOM.xml

This seemed to work.. gave me a couple warnings but then the SDK mentions that it would do this. Then, following more of the SDK instructions, I go into the AddInHostOM.xml file and add isExcluded=true to the end of the <Class/> element for my HostedApplicationRoot class.
Next I continue following the SDK and re-run the proxygen command line. This time I change /o: to /i: , supposedly using the modified Object Model Descriptor file (AddInHostOM.xml) to further refine the proxy to include what needs to be included and exclude what should be excluded. Couple more warnings, but it gives me a new AddInHostProxy.cs file, so I figure all is well.

Next, I create a new class library called AddInHostLib. Into this class library I add the proxy generated in the previous steps and add all of the references to the DLLs that the SDK indicates I need to add (System.AddIn.Contract, System.Windows.Forms, Microsoft.VisualStudio.Tools.Applications.Adapter, Microsoft.VisualStudio.Tools.Contract). I attempt to compile. no dice. Errors all over the place, complaining about members that don't exist, abstract inherited members that have not been implemented -- you name it, I had a compile-time error for it. So I go back into the AddInHostOM.xml file and start doing some more tweaking. Long story short, 2 hours later I had a completely ravaged XML file that had been stripped of virtually all its content, and I re-ran the proxygen command line tool... and it eventually compiled. Two Hours Later.

Next, I gave the Assembly a strong name with a password protected key file and I'm off to the races. I followed the walk-through for creating Visual Studio project templates using the projectgen.exe tool. I had to re-do this step about 4 or 5 times ,following the SDK's directions to the letter. Finally, after manually copying some files to where I thought they should've gone in the first place, the project templates show up in my list of general C# project types.

So, I create a new project of type "AddInHostDemo Add-In" and I add a line to give me a simple MessageBox when the addIn starts up:

using System;
using System.Windows.Forms;

namespace AddInHostDemoAddIn1
{

    public partial class HostApplication
    {
         private void HostApplication_Startup(object sender, EventArgs e)
         {
             MessageBox.Show("My custom plug-in started up... the application must have found me!");
         } 

        private void HostApplication_Shutdown(object sender, EventArgs e)
        { }
 
 // VSTA-generated code snipped out

    }
}

So that's the bulk of my add-in. I actually found the process of writing the add-in itself FAR more appealing than in enabling the host application for add-in support (that's how it should be...but the gap is bigger than it could be, in my opinion. After I built this plug-in, I copied it to the directory that the LoadAddIns() method in the host application would be looking for and fired it off. Sure enough, I saw the message box.

My overall opinion of the current state of building applications that support AddIns via the VSTA technology is that I'd probably rate it a 3 out of 5. The technology behind it is quite good, and it provides some very powerful and flexible extensibility options for applications where extensibility is a large concern. That said, if all you want to do is fire off a single method from a remote DLL, this architecture is not for you. If, on the other hand, you want to give plugins the ability to manipulate an exposed object model in order to be able to inject behavior into predictable locations throughout your application - VSTA is definitely the way to go.

I am dissapointed with the complexity of the process, because I know it can be FAR less complex. I am dissappointed with the fact that the developers, and probably the SDK sample developers, still have a "COM" mindset about API development. The whole thing feels very COM-like, and that turns me off. It is very hard to get past the COM-like nature of the system and move into the actual code. I think that at this point, this system is not ready for prime time. First, following the SDK walkthrough leads you into a pit of endless despair unless you know enough to infer what they really meant when they gave instructions. Secondly, the complexity is a barrier for many people. I would probably have to go through this entire process to to three full times again in order to feel comfortable enough with VSTA add-ins to recommend them or not recommend them as a viable solution for current problems.

Feel free to make up your own mind. For me, I'm waiting for another CTP and I will try the entire process again to see if its any smoother. If it isn't, I might just write my own plug-in system. Anyone with the technical ability to create applications that are VSTA Add-in aware is also smart enough to build their own less complicated plug-in system in roughly the same time it takes to complete the walkthrough. That fact is what bugs me about this setup. Until that fact changes, I think they have a lot of work to do.

tags: maf  vsta  addins  macros  netfx3  plugins  howto  

links: digg this    del.icio.us    technorati    reddit