Logo HeaderGraphic
"... A Yankee in the Land of The Long White Cloud, Aotearoa ..."

Registry and x64 

OK, I’ve been bit by this issue before, but again I forgot:

When is

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\PublishPlugins\YourPublishingPlugin]
<>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\PublishPlugins\YourPublishingPlugin
?

Why of course when

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\PublishPlugins\YourPublishingPlugin]
=
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Live\PublishPlugins\YourPublishingPlugin

I can hear you say… Whaaaaa?  Me too, for about 45 minutest (“I must be typing something wrong in the .reg file because the Live Gallery isn’t seeing it”).  First up some background.  I’ve started a new blog (http://www.tutira.com/blogs) where I’m detailing my new House Construction project (I wanted to do a HomeTime or This Old House video, but my Partner wasn’t willing to video me).  So we are taking LOTS of photos, and we manage our photos in Windows Live Photo Gallery.  So in the morning I fire up the Gallery, find the photo I want to blog about then I fire up Windows Live Writer, then I click insert Photo and then I have to browse to the folder where the photo I previously decided to blog about is located…

Well that’s just too many steps, I should be able to from the Gallery, select a photo and hit “blog about this photo” and that should take me to Live Writer.  The more I thought about this the more convinced I became this should have been a built-in part of the live family of products, but it wasn’t!  I figured it must be hard.  So I decided this would be a good candidate for me to write it up as a publish plug in for the Live Photo Gallery.  Turns out, it’s really easy!  Getting the information on how to interact with the two different products is the hard part, but once you figure that out, the only real “code” you need to get the thing to work is:

public bool PublishItem ( System.Windows.Forms.IWin32Window parentWindow , string mediaObjectId ,
    Stream stream , XmlDocument sessionXml , IPublishProperties publishProperties ,
    IPublishProgressCallback callback , EventWaitHandle cancelEvent ) {

    List<string> photosToPublish = new List<string>( );


    var publishSessionInfo = XElement.Load( new XmlNodeReader( sessionXml ) );
    var itemSet = publishSessionInfo.Element( "ItemSet" );

    if ( itemSet != null ) {
        foreach ( var item in itemSet.Elements("Item") ) {

            photosToPublish.Add( item.Element( "FullFilePath" ).Value );
        }
    }

    var writer = new WindowsLiveWriterApplicationClass( );
    writer.BlogThisImageFileList( "" , photosToPublish.ToArray( ) , "" );

    return true;

}

Anyways if this seems like something you would like to have yourself, you can download the my plug-in from here

But back to the issue this blog is about.  In order to get your plug-in to work, you need to register your plug-in information for the Live Photo Gallery to use at the Registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\PublishPlugins].  The Gallery looks in that registry entry every time it starts up to find Publish plug-ins.  Well that’s where it looks on a “normal” machine but not on x64.

So there I am, following the Live SDK instructions on how to publish my plug-in to the Photo Gallery but putting in my registry key.  What’s worse, I use the example sample program included in the sdk, run it’s install utility and the sample program works, but it’s entry ISN’T located in the place they say to put plug-in information.  So I investigate the setup program they included with the sample and this is what I see

<RegistryKey Root='HKLM' Key='Software\Microsoft\Windows Live\PublishPlugins' Action='create'>
  <RegistryKey Key='$(var.Product_Name)' Action='createAndRemoveOnUninstall'>
    <RegistryValue Name='AssemblyPath' Type='string' Value='[INSTALLDIR]$(var.File_Name)'/>
    <RegistryValue Name='ClassName' Type='string' Value='$(var.RegistryKey_ClassName)'/>
    <RegistryValue Name='FriendlyName' Type='string' Value='$(var.Product_Name)'/>
    <RegistryValue Name='IconPath' Type='string' Value='[INSTALLDIR]$(var.File_Name),-32512'/>
  </RegistryKey>
</RegistryKey>

So it’s time for RegEdit Edit | Find, which on my machine can take a long time (hey it’s a dev machine, the registry is just a little full). And thus I find out that the sample plug-in is registered in the registry, just not where it says it will be according to the setup program.

On a x64 machine thing’s happen just a little differently; when a 32 bit application attempts to access anything under the [HKEY_LOCAL_MACHINE\SOFTWARE\] on a x64 machine, it is automatically (and behind the scenes) redirected to [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\].  NOW THAT JUST ISN’T FAIR!  Sorry to shout but that is really a bad design decision on Microsoft’s point.  I (sorta) understand why they wanted to isolate 32 bit reg stuff from 64 bit but to insert a key in the MIDDLE of a registry path… if you forget, heaven help you!  The correct design feature should have been to create a new root key called [HKEY_WOW_64_32] and then replicate the other hkeys under that.  At least then every time you opened RegEdit, you would immediately get a reminder that “oh yeah, 32 bit apps don’t put the registry stuff in the “real” hive keys”

So anyways, I changed my registry path for the plug-in and it worked.

Enjoy.

 
Posted on 11-Nov-09 by Matthew C. Hintzen
Bookmark this post with:        
Tags: