New Windows Live Writer Plug-in Submission Process

I just received an email from Microsoft about changes to the submission and and hosting of Windows Live Writer plug-ins.  It goes into effect on September 10, 2010 (one month from now).  Live Writer is a great blogging tool and it has a nice API for extending it’s functionality.  If you use Live Writer, you should check out the plug-ins at Windows Live Gallery.

I submitted a SmugMug plug-in a couple of years ago.  It will need to be resubmitted.  Actually, I’ll probably rewrite it.  I’m sure it’s obsolete by now.  Here are the contents of the email.

Dear Windows Live Writer plug-in authors,

On behalf of the Windows Live Writer team and all of our customers, thank you for the valuable contributions your plug-ins have made to the Writer experience.

We’re writing to let you know that Writer’s plug-in hosting and submission processes are changing.  Note: Existing plug-ins currently hosted on Windows Live Gallery will need to be resubmitted using the new process outlined below.  In the future, should you wish to provide additional plug-ins for Writer, we request that you also submit your plug-ins using this process.

We hope that you find the new plug-in submission process and hosting solution simple and lightweight. New plug-in submission process:

1. Author uploads plug-in MSI installer to Windows Live SkyDrive using his/her Windows Live ID (email address).
2. Author emails wleplugins@microsoft.com (Windows Live Essentials Plug-ins) including the following information:
   • Author name
   • Author Windows Live ID (that will host the plug-in MSI)
   • Author contact email address
   • Plug-in name
   • Plug-in description
   • Plug-in category (pick only one):
     • Formatting/clipboard
     • Post publishing
     • Pictures
     • Buttons
     • Other content
     • Miscellaneous
   • URL to plug-in MSI on SkyDrive
3. Writer team verifies that the plug-in works as described.
4. Writer team updates public list of Writer plug-ins that will include information on the plug-in and a link to the installer that is hosted on the author’s SkyDrive.
5. Writer team notifies plug-in author that plug-in has been listed.

We value your efforts and want to ensure that your plug-ins will continue to be accessible for the many people interested in them.  In order to do this, we need you to resubmit any existing plug-ins on Windows Live Gallery using this new process by September 10, 2010. You will be able to add more plug-ins after this date, but we need you to move existing plug-ins by then.

Please email us with any questions or concerns about the new plug-in submission process at wleplugins@microsoft.com. Other support requests should be directed to the Windows Live Solution Center.

Thanks,
The Windows Live Writer Team

Just when I thought my SmugMug plugin was finished...

After tackling the Wix learning curve, I have an installer for my SmugMug plugin does usual things: check for .NET 2.0, install the files, add the registry key to register the plugin, and support upgrading in place.  One step closer to releasing this plugin for Windows Live Writer.

Meanwhile, over at SmugMug, a security issue of sorts popped up.  Don MacAskill, the CEO of SmugMug, blogged about it with great detail and openness and I'm not going into it here.  At any rate, in response to what was perceived to be a security, SmugMug is implementing some changes to their API.  The changes were fairly trivial to implement so it made sense to augment my plugin's code to be compliant with the updated API.

With their recent changes, I saw that my plugin was no longer displaying images for one of my test galleries, where it had worked before.  I spent a hour or so trying to track it down in my code, when the clue light finally flickered above my head.  I logged into my SmugMug account and examined the properties of that gallery. 

Sure enough, for that gallery, the "allow external links" option was set to "No".  This meant that even though my plugin would return valid URL's for the images in that gallery, SmugMug would send back a blank page for those URL's.  I augmented my call to get the gallery list to check the properties for each gallery and filter out the ones that did not allow external linking.

I thought that there would be performance hit for making a web service call for each gallery.  It wasn't really noticeable at all.  That's what I love about SmugMug, their API performance is damn fast.

At any rate, I was hoping to finally push this plugin out the door by now, but I'm going to take a few more days and beat on the code.

Using Wix for my Live Writer Plug-in

I finally have version 1 of my Smugmug gallery plug-in completed. The next step is to do the installer. To get a plug-in up on the Windows Live Gallery, it must have an installer that meets the requirements on the Gallery Developer Center page. A content plug-in has to meet these requirements:

1. Content Plugins must be built using either the .NET 1.1 or .NET 2.0 frameworks.
2. Content Plugins must be packaged and submitted as a Microsoft Installer (*.msi).
3. If you use the .NET 2.0 framework, the installer must link to the .NET 2.0 download site or use the Visual Studio 2005 Bootstrapper. The Bootstrapper detects and downloads the correct .NET 2.0 framework.
4. Your installer must copy the assembly to the "Plug -ins" sub-directory of the Windows Live Writer installation directory.
   

I have #1, my plug-in uses the .NET 2.0 framework. Number 2 is that it must be packaged using a Windows Installer .msi setup. I'm still figuring out the best way how to implement #3, but I'm not sweating it. With #4, I'm not doing it that way. The alternative method is to install the plug-in in your own folder and write a registry key to Software\Windows Live Writer\PluginAssemblies (HKLM or HKCU) with the name of your plugin and the path to it. That way you don't have to worry about where Live Writer was installed to. In fact that page is probably obsolete, there is an MSDN article that covers the registry method.

Let's start with the .msi requirement.

I looked that the "Setup Project" template in VS 2008. Um, no thanks. After 30 minutes of playing with it, I started getting annoyed. It felt awkward and non-intuitive. Granted, most things with Windows Installer are awkward and non-intuitive, but I couldn't get fast handle on "Setup Project" template. It was easy enough to get the files installed, but getting the registry written correctly was a task I just couldn't figure out. After two years of doing .msi with Wise For Windows and now InstallAware, I have a pretty good idea of an .msi is supposed to work.

I decided to knock out an setup with InstallAware. It took about 5 minutes and worked perfectly. But it was 1.2 MB in size. That seemed excessive to deploy 45K for two assemblies. Frankly any installer will be excessive, but I have to follow requirement #2. I have lots of love for InstallAware and it's my tool of choice for application installs, but it still bothers me to have a setup that 26 times larger than the files being deployed.

With VS's "Setup Project" and InstallAware out of the picture, I decided to check out WiX. WiX stands for WIndows Installer XML and is an open source toolkit for building .msi setups from an XML source file. The current version, 3, installs nicely into VS 2008. It installed so nicely, I didn't need to be concerned with how to run the Candle (the WiX compiler) or Light (the WiX linker). There is also a .msi decompiler, named Dark. It will emit Wix source code from a .MSI or .MSM file.

WiX source code is pretty intimidating when you first look at it. if you have no experience with authoring Windows Installer, it will be hard to grasp at first. The WiX site has a nice tutorial, but it's for version 2 and uses syntax that's deprecated in version 3. Fortunately, I was able to google the differences and I was able to get a working installer in about an hour. It's not handling step 3 completely, but it is terminating the install if .NET 2.0 is not available.

The size of the .msi is much smaller, about 220k. Still way too large, but it's as about as small as I'm going to get for a .msi file. So far, I'm very impressed with WiX. Once you start getting the hang of the syntax, it's very clear on how to setup a proper .msi file. There's even a open source editor called WixEdit. I didn't need it for this task, but I think I make take at peek at it at another timer.

Enough people are using it so that I was able to google for the bits I needed. Morten Lyhr had a great post on how to detect the .NET Framework. I figured out how to write the registry key from a post by Chris Jackson. Bonnie (one of the Live Writer developers) had a good sample WiX file for installing a plug-in. While I didn't follow her pattern, it did give me a tour of the neighborhood. Mike Stall has a good post that covers the basics. I think I need to spend some time reading the blogs of the WiX developers, they have a build a really cool tool.

Tech Tags: Windows+Live+Writer plugin installer msi Wix

Copying files with VS 2008's port-build event under Vista

I'm still working on my SmugMug plugin for Windows Live Writer. I've ported it from VS 2005 to VS 2008, that was trivial. I'm at the point where I want to debug the plugin while it's being loaded from Live Writer. Normally, this is pretty straight forward. You use the post-build event to copy the plugin's files to the Live Writer plugin folder. For my plugin, I used the following build event:

xcopy /D /R /Y "$(TargetDir)s*.dll" "C:\Program Files\Windows Live\Writer\Plugins"

The next step is to go into the Debug settings for the project and set the Start Action to Start external program, setting it to the path to the Live writer executable. On my machine, that would be:

C:\Program Files\Windows Live\Writer\WindowsLiveWriter.exe

With that set, all I need to do is to press F5 and my plugin gets built, copied to the Live Writer plugin folder, then Live Writer gets launched. Sounds good, but when I did a test build to verify the files would get copied, I got the following error message:

"XCOPY /D /Y /R "C:\dev\DotNet\LiveWriter\SmugMug4WindowsLiveWiter\SmugMug4WLW\bin\Debug\s*.dll" "C:\Program Files\Windows Live\Writer\Plugins\"
" exited with code 4. SmugMug4WLWPlugin

Code 4? I had to get Mr Peabody to look that one up for me. DOS 3.2 ring a bell? At any rate, exit code 4 for xcopy is "Initialization error (not enough memory, invalid syntax, path not found)". That actually was a clue to what the problem was, I was just missing the obvious. I tried pasting that xcopy command into a Take Command shell window and it ran without errors. So the syntax was correct, something was blocking it.

D'oh! I'm doing this under Vista. Joe User can't just copy files into "program files" space, that's no longer allowed. Only administrators have write access to "program files" and I'm running VS2008 without elevation. I run my Take Command shell as admin, so of course it can write to the plugins folder.

To get around this, I decided to punch a hole through Vista's default rights for that folder and give everyone and their dog full access to it. I tried doing it through icacl, but I wasn't getting the syntax right. So I just opened up explorer, selected the plugins folder, right-clicked and selected "Properties". I then selected the "Security" tab and then selected Users under "Group or user name". Next, I clicked the edit button, to bring up the edit dialog for the access rights. I selected "Full Control" and then clicked "Ok" all the way home.

That fixed it. VS2008 was able xcopy my plugin without any errors.

Tech Tags: vs2008 post+build+event Code+4 xcopy Vista icacls