WLW Picture Post Plugin 1.0.0.7 Released (Windows Live Writer Beta 2 Release)

I've updated and released v1.0.0.7 of my Windows Live Writer Picture Post Plugin

The primary update in this version was to get it working in Windows Liver Writer Beta 2 (WLW B2).

Release Notes

PLEASE NOTE: This version only works with Windows Live Writer Beta 2

Better implementation of the WLW B2 fix (this time using the AssemblyResolve event. See below for the dirty details)
Added Preview Feature
- Now you can preview how the picture/thumbnail will look prior to inserting it (to make sure the selected thumbnail size is what you had in mind, etc).
Changed initial plugin behavior - canceling the initial file selection dialog also cancels the Upload Picture Dialog
- So now you don't have to click Cancel twice...
Added Plugin version number to the dialog Title (This was fun too... again, see below for more details)
Added Visit FlickrNet linklabel
- To give additional credit to the library that without which coding this plugin would have been much harder...
Fixed layout/dialog resize with the Insert As label and combobox

This plugin still needs some polishing, but it works and does for me what I need it to do (which is quickly upload pictures to Flickr/23hq and insert them into the WLW post)...

Once Zooomr Mark 3 is stable, I'll again see about adding Zooomr support (I need to find a way to get a Developer Key)

Here are some screenshots from this new version.

WLW B2 Dependant Assembly Resolution Notes

Background:

I was having an dependant assembly load issue. With WLWL B2, my plugin wasn't able to find the FlickrNet assembly and was gacking. And probably rightly so...

When I started using FlickrNet I was worried about file collisions with other WLW plugin's with used it (like Flickr4Writer, etc). I didn't want to worry that I might overwrite a newer version or have another plugin's install overwrite mine (or worry about version comparability, etc). I wanted to be sure that the FlickrNet version I was using was always what I intended. And while FlickrNet is strong named, I didn't want to GAC it (for xcopy deployment simplicity).

So what did I do? A slimy hack... I renamed the FlickrNet.dll to WLWPicturePost.FlickrNet.dll. And it seemed to work okay, until now...

In hindsight, I now feel that was officially "bad" (Ya think? To rename a strongly named DLL. I should have used another approach).

And now with WLW B2, this hack came back to bite me.

Resolution:

To resolve this, I'm now creating a private bin "WLWPicturePost" subfolder in the Windows Live Writer\Plugins folder and putting my correctly named FlickrNet.DLL in there. And doing another hack... sigh.

To enable my plugin to find FlickrNet in it's new subfolder, I had add the following code snip;

AppDomain.CurrentDomain.AppendPrivatePath( _ AppDomain.CurrentDomain.SetupInformation.PrivateBinPath & "\WLWPicturePost")

The issue is that AppendPrivatePath is deprecated and will likely go away in the future.

I tried changing my plugin's App.config, adding runtime dependantAssemply redirection, codebase href, updating the probe, etc, but no joy (because it's an assembly inside another .Net App?). Can't use PrivateBinPath because that only works when creating a new AppDomain. I tried hooking into the AssemblyResolve event, but... well... I got lazy and didn't work too hard on getting that to work.

So at least AppendPrivatePath works, but....

Anyway, I'm not TOO worried about the deprecated usage though... The .Net 2 framework base will be with us for another couple years at least (since .Net 3 & 3.5 all include 2.0 as their base), so I don't have to fix this today. But I have to say this current solution just doesn't smell all that good to me...

Probably the AssemblyResolve event will be the right way. Or probably even better, GAC'ing FlickrNet (since it's already strongly named, GAC'ing it solves my version concern, and any user installing a Plugin already has to have rights to write to the Program Files folder, so will likely have to be admin elevated anyway...?).

[...the next day...]

I woke up this morning and just didn't feel right with my AppendPrivatePath solution...

So after a quick SearchDotNet I found this Microsoft Knowledge Base article, "How to load an assembly at runtime that is located in a folder that is not the bin folder of the application", which was exactly what I needed.

A few minutes later, I had a "good" working solution to my dependant assembly issue. Yeah! I feel much better now... :)

Plugin Version in the Title Notes

I like putting an app's version number into it's Title text. I've found it makes my support life easier. I never have to ask a user, "what version are you using..." when they send me a screenshot (nor do I have to guess).

Usually it's as easy as putting the below line in the Form_Load event;

Me.Text = Me.Text & " (" & My.Application.Info.Version.ToString & ")"

Well guess what happened when I did this for this plugin? I got a version number all right. The WLW Version number! (12.0.1183.516). Dogh!

Well I KNOW my assembly has it's own version number, all I had to do was find a way to get at it.

After a bit of playing around (and looking at the work down in the above AssemblyResolve event handling), this is the solution I found...

Imports System.Reflection

.... Form_Load ...

Dim objExecutingAssembly As [Assembly]
objExecutingAssembly = [Assembly].GetExecutingAssembly()
Me.Text = Me.Text & " (" & objExecutingAssembly.GetName().Version.ToString & ")"