JeffGaroutte.net

Recently I replaced my Surface Pro 2 with a Surface Book.  With that change I felt I should start writing again and I had a slew of topics in mind… So I went to download Windows Live Writer and found that it had reached the end of its lifecycle.  In an attempt to keep people on current, supported and secure software Microsoft removed the Windows Essentials 2012 download from their site.  I have no desire to go backwards in time…  Well not for WLW at any rate. So Microsoft has killed WLW and that left me in a bit of a bind.  When I started this blog back in 2008 I choose to write my own blog engine.  It was not because I thought I could do better than the people at Sitecore, Orchard, dotnetnuke, WordPress or Joomla; it was because

1. I did not want to spend thousands on a personal blog solution (sorry Sitecore)
2. I wanted a .net solution (Sorry WordPress and Joomla)
3. I needed a project to play with that I could keep tinkering with without worrying about getting so far away from the main branch that merging or upgrades would be difficult.

So I wrote my own.  One of the first requirement decisions I made was that I wanted to support a content editing API and not build an interface for editing in the blog engine itself.  I found the MetaBlogApi and that Windows Live Writer supported it so I checked that requirement off my list.  But with WLW being unsupported I now find myself without a way to create content, right?

Nope, I did not build support for WLW, I built support for the MetaBlogAPI.  WLW was an editor that supported the API. So I need a new editor that supports the MetaBlogApi.  Fortunately for me, Open Live Writer was forked from WLW and appears to be nearly identical to WLW. 

Including a lack of support for including zip files easily which lead me to write my own plugin for file uploads in WLW.   OLW is a .net application and open source so I thought… Why not pull down the code, look at the plugin support and update my plugin.  After all, they have an add plug-in button in the UI, and plug-in options so why should this be impossible. 

Brain: Come along Pinky

Pinky: Why Brain? what are going to do tonight?

Brain: The same thing we do every night; Try to take over the world.

Of course sometimes the impossible is just a way of saying you have to keep trying…

I started by coping my old plug-in source and replacing the WindowsLive.Writer.Api.dll with the OpenLiveWriter.Api.dll in the lib directory and project references.

After renaming the project and solution I changed the default namespace, assembly name, targeted CPU and the target .net framework.

And it compiled… Now will it blend? I mean work.

This is where I ran into the first problem.  Where do I put it?  WLW had a directory when plugins went, but OLW does not seem to have one by default.  

Because OWL is open source I had pulled down the code; after a little digging I found it was checking to see if a directory stored in “PluginDirectory” and “PluginDirectoryLegacy” existed and load any plugins from both of them.   But OLW uses the same code to load plugins from both locations; so why there would be two of them is a bit odd.  Because I am not a fan of anything named Legacy I opted to go to chase down the PluginDirectory.  I found it resolves to a property in the PostEditorPluginManager which returns Path.Combine(ApplicationEnvironment.InstallationDirectory, "Plugins").  In theory, if I find the exe and add a directory named Plugins in that folder my plugin should be able to load.

The plugin loads but it fails horribly when you try to add a file

System.IndexOutOfRangeException: Index was outside the bounds of the array.
    at FilesForOLW.Settings.get_FileName()
    at FilesForOLW.FilePlugin.CreateContent(IWin32Window dialogOwner, ISmartContent newContent)
    at OpenLiveWriter.PostEditor.ContentSources.ContentSourceManager.
         PerformInsertion(IContentSourceSite sourceSite, ContentSourceInfo contentSource)

DOH! Since this code worked for WLW I am going to guess there was a slight change.  In the stack we can see our settings is dying while getting the file name, the code “_content.Files.Filenames[0]” is our likely culprit.  It is possible that the code is being called before the file is being added by OLW.  By Replacing the default file name with “New File” it seems to be much happier.

So now we can add the

That gives us back all the functionality we had in Windows Live Writer. 

The thing is I do not remember how the whole plugin works; it is simple code and that is not the issue.  It has been several years since I wrote this code and I did not document it at all.  Which is really a shame.  I suspect I may find some things I need to tweak with the plugin to accommodate some minor differences between WLW and OLW but at least I do not have to write a new Editing GUI for my blog engine.

By using the MetaBlogApi - in a project I started almost 10 years ago – I was able to abstract all of the content editing of a “CMS” out of my application and start using a different editor without changing any of the code in my blog engine.  Interfaces, abstraction and well designed APIs can help protect your software from the ravages of time and allow you to change entire components without impacting each other.  Adding a Plugin framework to your application (like WLW and OLW) allows other developers to extend your software in ways you may not have thought of or considered important. 

Happy coding!