When we decided to tackle the project of making Microformats easier to consume, we were naturally drawn to Windows Live Writer (WLW) as a content publishing mechanism.  By targeting WLW, we were able to target all blogging platforms, as opposed to writing specific add-ins for each different blogging platform. It is a great piece of software that comes highly recommended.

I found writing the Windows Live Writer Plug-in to be quite simple and straight forward.  I was impressed with their plug-in model in terms of placing a .dll in a directory and having WLW load that .dll on your behalf. Very elegant. 

To get started, I thought this video on Channel9 was informative and gives a good overview of doing WLW plug-in development. It’s pretty straightforward. You just need to add a reference to the WindowsLive.Writer.Api.dll. Then, once I got into actually doing development, I found the the Windows Live Writer plug-ins project indispensable in terms of getting started. There’s some great projects in there.  I also found myself turning to the WLW SDK quite a bit, especially for dealing with deployment of the plug-in, since we install it ourselves as part of our installer. 

Here’s a gotcha I hit: if you’ve installed the latest beta of Windows Live Writer, your WindowsLive.Writer.Api.dll will be a later version than folks who haven’t installed the beta. This will cause problems. (Who says .net is free from dll hell?) Be sure to add a reference to the older version (12.0.1367.1128) and not the newer version (14.0.5025.904).

One thing to keep in mind when doing development is that you have to attach to the WLW process from Visual Studio if you want to debug into your plug-in. 

Another thing that someone had done in the codeplex project, which I learned from, was to add a post-build step to my plug-in which automatically copied it to the plugins directory for WLW. That way, you can immediately see reference the latest

XCOPY /D /Y /R "$(TargetPath)" "C:\Program Files\Windows Live\Writer\Plugins\"

Of course, if your program files is on a different drive, this won’t work.  Also, it is a little confusing, because the beta of Windows Live Writer installed into C:\Program Files\Windows Live Writer but later versions installed to C:\Program Files\Windows Live\Writer. So, if you are still using the beta, you’ll need to modify this.

Similarly confusing is the way to get your plug-in up on the Windows Live Writer Gallery.  First off, realize that you have to create an .msi, which is relatively easy using the Setup and Deployment template in Visual Studio or using the WIX installer.  I used the Setup and Deployment template as opposed to WIX (more on WIX to come in a future post).  Ironically, we used WIX to build the installation for Oomph overall, which, in retrospect, I wish I’d have gone ahead and used, but that was another learning curve that I just didn’t feel like hitting. A couple gotchas here withthe Setup and Deployment template in VS: first, be sure to remove the dependency on the WindowsLive.Writer.Api.dll, as there is no need for you to be redistributing that. Second, you’ll want to make sure that the user installs the plug-in to the WLW plug-ins directory.  To do so, modify the DefaultLocation in the Application Folder to the following: [ProgramFilesFolder]\Windows Live\Writer\Plugins.  The other option here would be to  set a reg key in

HKCU\Software\Windows Live Writer\PluginAssemblies

With the string value of “Oomph.ContactsPlugin=[the installed location to the ContactsPlugin.dll file]”

Then, you can stick the .dll where ever you want to on the user’s file system.

Once you create the .msi, you should be good to go; you can upload the .msi to the WLW gallery and then, after it is reviewed, see it live!

One final thing: thanks to Tim Heuer for doing some clean up on the plug-in, which shipped with Oomph 1.1.