After the other days debacle with Nostalgia and Flickr I looked to simplify my picture posting process for this blog. My requirements are simple: something like right-click an image, and then click "Send to Flickr" or something similar. I figured that someone must have written this already.... but no, I came up dry.
I figured I'd have to write my own version against the Flickr APIs (which are vast!). However, during my initial investigations I found out two interesting things:
- You can post images to Flickr via email, and
- There is a Windows Live Writer plug-in for Flickr images (WLW is the text editor that I use to write all my posts).
Armed with this information, I managed to completely streamline my image uploading process with zero code on my part! Good enough... for now.
With that, I del.icio.us'd the appropriate links and figured that I would blog about my experience, share the solution, with you dear Reader, and seek your opinion on the matter. Then it occurred to me that there must be a Windows Live Writer plug-in for del.icio.us... my search began anew. But, again, I came up dry (well, I found one, but it really sucked).
By this time my interest was really piqued with regards to Windows Live Writer plug-ins; I wondered what it would take to write a plug-in with my exacting requirements:
- It must be a WPF front-end (nothing else will do)
- It must use XLinq for the back-end (experiment)
- It must be FxCop and Microsoft Source Analysis compliant (as I want to ship it, to you dear Reader)
- The UI should "suck-less" and follow as many Tufte principals as makes sense for an application of this type (experiment)
When I started out on this adventure I was far from sure if the WPF approach was even possible; Windows Live Writer is a Windows Forms based application, therefore the plug-ins must also be WinForms. However, you can load WPF controls into WinForms using some fancy interop, so I was confident I could make something work. But, what I really wondered was:
Is it possible to load a WPF Window from WinForms?
I wanted to write something like:
private void buttonOpenDialog_Click(object sender, EventArgs e)
MyWpfWindow dialog = new MyWpfWindow();
if (dialog.ShowDialog() == true)
Where the buttonOpenDialog method was inside a WinForms application. It turns out that this is not only possible but it also work extremely well.
I wanted to use XLinq given that the data will be coming from del.icio.us, in the form of an RSS feed, and I want to filter the results locally XLinq seemed like a perfect fit, and indeed it has been:
IEnumerable<LinkItem> result =
from i in this.xdoc.Element(rdf + "RDF").Elements(rss + "item")
select new LinkItem
Categories = i.Element(dce + "subject").Value,
Date = (DateTime)i.Element(dce + "date"),
Description = i.Element(rss + "description").Value,
Link = i.Element(rss + "link").Value,
Title = i.Element(rss + "title").Value
This is a simple query to deserialize the RSS feed into a list of custom LinkItem class, which is then used by the WPF UI.
To load the RSS feed in the first instance is as simple as:
this.xdoc = XDocument.Load(
That forms the basis of the back-end provider.
Next is the static code analysis tools. The main difference between the two tools I have chosen is that FxCop reports on the assemblies (post build), whereas the Source Analysis tool does what it says on the tin, and looks at the source text files (pre build).
The important aspect to understand here is that I'm not looking for a zero bounce with these tools. It may be possible, and indeed I did nearly achieve a zero bounce with the Source Analysis tool, I was finally thwarted due to the way WPF works. As was the case with this code, sometimes you simply cannot obey all the rules and still compile!
The rules are there to help you, not hand-cuff or hurt you, remember to only apply the rules that make your code better, cos aiming for 100 percent compliance in my experience means less than optimal code; not to mention the extra time required to chase down the last 1 or 2 percent of the violations, that is time better spent on shipping new features.
So with that in mind, here is my analysis of the remaining FxCop rules that I have no intention of fixing and why:
Note also that there is a way to suppress the violations in your source code for FxCop (and other static code analysis tools?), using code analysis attributes and providing compile time hints, which in production code, I strongly recommend you do. That way (1) you formally acknowledge the rule violation, (2) you also explain why the rule is ignored, and (3) most importantly, you explain why as close to the code as possible.
(If anyone is interested in how to achieve the suppression of FxCop rules in this way with attributes then drop me a line an I'll knock a "how-to" post together).
And finally, the Tufte analysis. This is probably the most subjective part of the work I've done for this plug-in; but I honestly believe that this UI is one of the best I've done.
This is the bit where I would most appreciate feedback:
In the final analysis I'm happy with the result, the code is available in two different forms:
This is the first time that I've released code in this way, so your feedback would be greatly appreciated. Enjoy!