Building an Outlook add-in: troubleshooting an add-in that won’t start

I made some changes to my code a couple of weeks ago and didn’t document them for myself, nor did I try to debug the code for a week or so.  So by the time I did try it out, I didn’t remember what I’ve done, and of course there’s some reason the add-in isn’t loading anymore.  It’s still listed among the 14 add-ins listed as “Loading Add-ins” as Outlook starts up, but the context menu isn’t available where it should be anymore.

Digging deep into Outlook 2010 to see what goes on with the add-in (Outlook File menu > Options > Add-Ins > COM Add-ins Go… button > click on the add-in in the list), the Load Behavior text says the following:

Not loaded. A runtime error occurred during the loading of the COM Add-in.

Google that error message, a few articles come back, and I bookmarked a couple to check on later.  I’ve reviewed them and tried the following:

  • Examined Registry entry (HKCU\…\Outlook\Addins\) to confirm two things:
    • LoadBehaviour setting is still = 3 (it is)
    • file path listed in Manifest value is still valid (it is)
  • Ensured add-in isn’t on the Disabled list (it isn’t)
  • Ran Dbgview.exe while loading Outlook to see if there are any obvious errors being thrown that aren’t otherwise being noticed (there aren’t any entries remotely related to my add-in)

  • Observed the following error:
    • Microsoft Office Application Add-In
      An add-in could not be found or could not be loaded.
    • Details button:

      Exception from HRESULT: 0x8004063E

    • ************** Exception Text **************
      System.Runtime.InteropServices.COMException (0x8004063E): Exception from HRESULT: 0x8004063E
         at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
         at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode, IntPtr errorInfo)
         at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor)
         at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.Microsoft.VisualStudio.Tools.Office.Runtime.Interop.IDomainCreator.CreateCustomizationDomain(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor)

  • Found a bunch of discussions referencing this error, and started with the first result:
  • Per instructions, I shut down Outlook, started VS2010, chose “Clean [project]” from the Build menu – this seems to have removed the HKCU registry entry for the add-in

Worked like a charm – next time I debugged the add-in, it came up exactly as I expected it to.

Additional Reference

Debugging in Application-Level Projects


Building an Outlook add-in: binding data to XAML (questions)

ToDo’s (from last post)

Need to figure out how to bind the NameValueCollection to the XAML for my WPF-based add-in.  Then I need to find my a** with two hands and a map.  And after that, perhaps I’ll look into the complexity of referral chasing to get the non-GC-replicated user attributes.

Bind AD Data to XAML

The more I look at this snarl of code I’ve pieced together from different samples, the more worried I get that I’ve created an intractable problem.  I have three major classes developed so far (plus the XAML):

  1. ContextMenuItem.cs – inherits Office.IRibbonExtensibility, and implements the IRibbon extensibility member and the Ribbon callbacks (i.e. the context menu click handler).  The click handler instantiates the Pop-Up window, converts the Outlook contact to an email address and runs the AD query.
  2. UserDetailsPopup.cs – implements the ElementHost WinForms object that wraps the WPF control.
  3. ActiveDirectoryUser.cs – implements the query against the Global Catalog, and returns a collection of requested data.
  4. UserDetailsLayout.xaml – implements the XAML UI in which we’d like to drop the requested data.

How should I store the data, and how can I get the XAML to consume it (and ensure it gets displayed in the UI)?

Where to Store the Data?

Let’s assume for the moment that the ContextMenuItem class gets instantiated when the user right-clicks on a contact, and doesn’t die until the context menu and/or the pop-up window it generates are all dead.  That means any Property of the ContextMenuItem will exist during that timeframe, and can be read by other members of the add-in.

So exposing the data the add-in needs as a read-only Property of the ContextMenuItem class seems the only smart way to go here.

How to “Push” Data to UI?

Next, we need some way to cause something in the pop-up window (the XAML, the C# code-behind for the XAML, and/or the WinForms ElementHost that contains the WPF control) to consume the Property’s data, and then refresh the UI of the pop-up window if necessary.

I’m used to the fairly simple .NET app development model, where the first class instantiated is the UI, and it “pulls” in all code calls until the UI receives a callback (user click or some other event) that performs an atomic function.  The best approach I can think of at the moment (given the classes I’ve constructed) is to create some function in either the UserDetailsPopup or the UserDetailsLayout (whichever’s code can cause the intended effect) that reads the ContextMenuItem’s property and then… what, “paints” the data into the XAML labels?  Writes it to a class-local collection to which the XAML is already bound at design time?  Or is there some other elegant feature of VSTO, WPF or .NET 4 that I am totally missing?

Here’s where my inexperience with (1) sophisticated design patterns or (2) WPF is coming to bite me on the butt.  However, it occurs to me that the fundamental problem isn’t WPF but rather a VSTO-and-Outlook-centric design pattern that ferries remote data to local content-driven UI.  Getting the data to the WinForms equivalent in this model must be the majority of the problem; pushing the data the last mile through the WinForms-to-WPF wrapper can’t be all that hard, can it?

Next Steps

So I guess my next quest is to find an Outlook VSTO code sample that creates a new WinForms object in response to user input (rather than all the examples that just graft VSTO code into an existing Outlook “Form” such as an email window, Appointment item and the like).

The final quest in making a functional object is to re-examine the WPF-in-ElementHost examples for Outlook VSTO add-ins, to see how external data gets bound or otherwise propagated into the XAML.

Building an Outlook Add-in: completing work on the Active Directory query

ToDo’s (from last post):

  • Implement the GC (domain-less) query, rather than orient to the current implicit binding to the user’s current domain
    • Big question to answer: are all the fields of interest being replicated in the AD GC?
  • Implement a reasonable collection that will be useful to the calling code, and return the user info in the return value
    • After 15 minutes in MSDN Library and some wide-swath google searches, it sounds like the NameValueCollection class is fairly suitable: hashtable-based, strings-only, and allows multiple values for a single key (which may come in handy later for multi-value directory data, of which AD allows a few)
  • Start testing this beast against the company AD

Y’see, this is one of the problems with doing code development in your spare time – I’m facing a major uphill climb, trying to remember (1) where I was going next, (2) where the next layer of function calls was supposed to get plugged into, and (3) which article I was reading that headed me down this design path.  Arrgh.

So I’m starting over with the first “article” (actually MSDN video demo) that caught my fancy, and downloaded the sample code.  I have an idea of (1) – to plug the utility class that scrapes AD for user data into the code that calls the Winforms-wrapping-WPF control, and display the user data in that blank context menu window I’ve already sketched out.  By wandering around the sample code, I’m hoping to figure out (2) without having to review every line of code and compare to my own design “pattern”.  Presumably by retracing the steps outlined in my blogs, I’ll be able to quickly stumble across (3) – again, without having to review every word I’ve written.

God I hope this works.

Acquiring the user’s Email Address

Fortunately, by looking in the sample code’s ThisAddIn.vb class, I’ve already discovered a helpful Function that I knew I needed somewhere.  A quick trip to a VB-to-C# converter and I’ll drop this into my own ThisAddIn.cs class.

However, there’s no direct property of an IMsoContactCard object that corresponds to the contact’s email address – for that I had to find this sample code that does a conversion.

D’oh! Nope, even that just ends up returning the X.500 version of the Exchange mail address.  Instead, I ended up back at this article that I’d read before, which provides a great GetSmtpAddress() function in VB.  Oh, *right* – which I’d already implemented in my project’s code a few weeks ago.  See what I mean about this “once a week coding” nonsense?

Here’s my completed OnClick() method for the Contact context menu item, that calls into my ActiveDirectoryUser class:

public void onGetUserDetailsClick(Office.IRibbonControl control)
        Office.IMsoContactCard card = control.Context as Office.IMsoContactCard;

        if (card != null)
            // Here's where we need to instantiate the UserDetailsPopup() object
            UserDetailsPopup UserDetailsInfoForm = new UserDetailsPopup();

            string emailAddress = GetSmtpAddress(card);
            ActiveDirectoryUser user = new ActiveDirectoryUser();
            NameValueCollection coll = user.getGcUserData(emailAddress);
            // Here's where we handle this edge case
    catch (Exception ex)
        // Handle the exceptions
        Console.WriteLine("Error spat out" + ex.Message);

Much later, after a couple of hours of debugging this slapped-together code, I’ve finally arrived at a method that’s finally deriving the output of live queries against AD.  And I have an answer to the big question: no, not all of the really useful attributes are being replicated to the GC.  The most obvious one that’s missing would be the job description-oriented attribute.  Of all the User object custom attributes *not* to replicate, why did they pick on this one?  Is it really so hard to believe that someone would want to query this value in a global directory?  Looks like I’m going to have to implement some referral chasing and see if that doesn’t tank the performance of the add-in.

Completed GC-querying Method

Here’s my GC-querying method call to derive the GC-replicated attributes (using “department” as substitute for the the custom attributes internal to the organization that I’m going after):

public NameValueCollection getGcUserData(string emailAddress)
    NameValueCollection returnValue = new NameValueCollection();
    DirectoryEntry gc = new DirectoryEntry("GC: ");
    DirectoryEntry _root = null;
    using (gc)
        //there is only 1 child under "GC: "
        foreach (DirectoryEntry root in gc.Children)
            _root = root;

    //Note: the filter must be searching for a GC replicated attribute!
    string filter = String.Format(
        "(mail={0}) ",

    DirectorySearcher ds = new DirectorySearcher(

    using (SearchResultCollection src = ds.FindAll())
        foreach (SearchResult sr in src)
            returnValue.Add("department", sr.Properties["department"].ToString());
    return returnValue;

Next Steps

Need to figure out how to bind the NameValueCollection to the XAML for my WPF-based add-in.  Then I need to find my ass with two hands and a map.  And after that, perhaps I’ll look into the complexity of referral chasing to get the non-GC-replicated user attributes.

Acknowledged: the two simple articles that saved my ass twice now

Extending the User Interface in Outlook 2010

Customizing the Context Menu of a Contact Card in Outlook 2010

Building an Outlook add-in: Context Menu of Contact Card in Outlook 2010

Before going *any* further with VSTO code, I am taking some very good advice I gave myself a couple of years ago and installing some of the VSTO Power Tools (just the VSTO_PT.exe package) – specifically to obtain the VSTO Developer Cleaner and the VSTO Troubleshooter.  I recall both of these being very helpful, the last time I went down this path.

Note also: I am *not* going to pursue the Office Interop API Extensions.  I am aware they’re targeted specifically at easing C# development of VSTO apps in Word, Excel and Outlook.  However, after reading PhillipHoff’s blog that “documented” them, the near-total lack of a deployment story is enough to encourage me to tough it out without ‘em:

“You are correct in that the User Guide does not explicitly state that you cannot use VSTO_PTExtLibs.exe to redistribute the extension assemblies, but as you found, the installer has a dependency check which prevents it from being used for that purpose.

“You have two basic options for distributing the extension assembly: either a custom installer that places it in the GAC or another common location, or side-by-side the referencing assembly.”

Heh, yeah right.  A year or two ago I feel down the rabbit hole of developing a custom setup package for a Word VSTO app add-in.  That sucked me dry for months, and I never got any satisfaction out of it (tho it’ll probably save me a couple of months this time around).  *Voluntarily* adding to my pain by trying to install a helper assembly of dubious provenance and poor support?  Not bloody likely my friends.


Creating a WPF Control for use within Outlook 2010

Diving back into this video tutorial.  Already stuck on one of the first steps – adding the WPF “User Control” to the ElementHost winforms container.  Even though I’m able to successfully build the project, there’s no WPF user control to add to the ElementHost (at least that’s what the ElementHost “Select Hosted Content” taskpane is indicating.  Google it is… searching on elementhost “select hosted content” none:

…actually, I just remembered how many articles I’ve been skimming are focused so strongly on .NET Framework 4, so first I decided to re-target the VSTO project to .NET 4.  For some reason that seems to have wiped out the piece of code that contained the ElementHost-including form, so perhaps that’ll clear up the problem I’ve been having.

I ended up Building the project and failing, needing to add a Reference to System.Xaml (from the .NET 4 namepsace) to one of the .CS files.  Once I did that, magically I was able to add either of the XAML user controls I’d tried to create as children of the ElementHost object.  Amazing.

I’m re-trying this approach with an Office Ribbon (XML) item as is outlined in Customizing the Context Menu of a Contact Card in Outlook 2010.  I change the button element’s id, label, and onAction XML parameters, then run this article’s VB-only code through a VB-to-C# converter to import into my code.  Each time I have to fill in a few blanks along the way – figuring out which method to add to my code, to which CS library, and matching some undeclared variable names and using statements up with orphaned code in the sample.  What moron would expect a “Visual How To” from Microsoft to ever run without a ton of band-aid work to actually fill in boring-but-essential components?

Once I figured out how this sample code would instantiate the Ribbon (XML) item, I only have two more tasks before I start binding the XAML to its data source:

  1. instantiating the XAML-encapsulated-in-WinForms control, and
  2. creating the Callback Methods that are hinted at (but not spelled out) in the Ribbon (XML) //TODO section (automatically generated by Visual Studio when I created the Ribbon (XML) object.

Yeah, that should be easy.  Callbacks – is that like in the theatre?  Hell, for all *I* know, (2) is where I *implement* (1).

Aha!  Apparently I’m not far off from the truth – the Walkthrough: Creating a Custom Tab by Using Ribbon XML says:

You must add onAction callback methods for the Insert Text and Insert Table buttons to perform actions when the user clicks them.

Right right right – so the meaning of “callbacks” is coming slowly back to me – at least in the context of button pushing. 🙂


Problem: UserControl doesn’t Show()

I spent some time looking for a suitable approach to rendering the WPF Element Host-ing user control, and tried a couple of approaches, but none work so far.  The approach I’ve landed on instantiates a new instance of the Class that hosts the ElementHost (here called “DataDetails”), then calls the .Show() method for the object instance, like so:

DataDetails dataDisplay = new DataDetails();

However nothing appears visible when I click the new context menu item in Outlook 2010.  Here’s what I’ve tried, none of which tells me why this won’t display:

  • follow the .Show() call with calling the BringToFront() method, in case somehow the user control was being hidden behind Outlook
  • added a straight System.Windows.Forms class to the project (called it my Debug window), then instantiate it as for the DataDetails class instance and call the ShowDialog() or Show() method [which works]
  • did a line-by-line debug of this area of my code [which proves that every line of code is being called – nothing skipped – but the ElementHost is still not showing up]

Re-examining the Debug vs. DataDetails objects, I’m pretty convinced that using the Form class is easy, but there’s some step I’m still missing when using the UserControl class.  This is borne out when I merely substitute “Form” in place of the original “UserControl” for the partial inheritance, like so:

public partial class DataDetails : Form


    public DataDetails() {  InitializeComponent(); }


Further Research References

Aside: the specific Context Menu I’m manipulating here is sometimes called the Persona Context Menu (at least by the article Extending the User Interface in Outlook 2010).  I have a feeling that will be a very useful phrases in my current research.

Other articles I’ll probably need to almost immediately:

Here are some other articles I expect I’ll need in the future:

Finally, here are some possible sources of working code that I’ve found in my travels:

Building an Outlook Add-in: customizing the Contact Card, other options?

[I’m working on an app for work – enable me to pull job title, team name, etc. from a proprietary internal database, since our Exchange Address Book doesn’t contain that info.  Just to set the context for what the h*** I’m up to.]

Did a broad search for “Outlook 2010 VSTO” to find some beginners’ guide to writing something that will run in Outlook 2010.  Lots of possible stuff to read, but this 20-minute video seemed like my best bet:

How Do I: Create a WPF Control for Use Within Outlook 2010

Yes the question should be asked: are you better off writing an Outlook 2010 add-in using WPF or a Windows Forms?  I haven’t yet found a definitive answer, and they may both be supported to some degree, but the majority of articles I stumbled across were using WPF not Windows Forms.  That *may* just be a tyrannical bias coming from Microsoft, where XAML is all the rage and you’re ‘not allowed’ to talk about legacy development there anymore.  Regardless, if I see WPF and Outlook 2010 mentioned more than a half-dozen times, that *has* to be supported pretty well, so I’ll go with that for now.

Contact Card

Next I need to know what kind of Outlook “object” I’m trying to attach to.  I am aiming for that new intermediate Contact panel that shows up when you double-click the email address of an email in your Inbox (this example borrowed from Microsoft Support):

Contact Card example

  1. It already has a tabbed interface, so adding another tab makes intuitive sense as a user.
  2. It’s the first interface you get to detailed info on a user, so it’s the fewest clicks to get to an extended UI I could add.
  3. It’s new in Outlook 2010, which (I hope) means that the Outlook Interop object model has implemented first-class .NET support for interacting with that object.  [As opposed to some of the legacy objects in Outlook for which there is pretty crappy support in the .NET Interop model.]

Searches for “Outlook 2010 new features” take me to pages like this, which refer to this new interface as “a new easy-to-access contact card”.  Digging into the official Outlook blog there’s a detailed article “Using the contact card to learn who someone is”, so I’m definitely on the right track.  Now if only this was the same nomenclature used in the Outlook object model (developer side of the world) – it’s rare that the underlying code and the marketing names ever get aligned, so I’m not surprised much anymore if I don’t get that fantasy fulfilled.  [Heh, and just to show how easy it could’ve been, I realize now that the Contact Card is available as a context menu item when you right-click the email address.]

So my next search – Outlook 2010 “contact card” “object model” – turned up an article called “Customizing the Context Menu of a Contact Card in Outlook 2010”.  Among other things, this article states that “The IMsoContactCard object is defined in the primary interop assembly, Office.dll, of the Microsoft Office object library, not in Outlook 2010.”  So this is apparently an Office-wide object, available to other Office apps – not just Outlook (though it’s entirely possible Outlook is the only app that bothered).

Which also happens to lead to a Code Gallery sample called “Outlook 2010: Visual How Tos: Code Samples” that includes the sample code.  Unfortuately the sample is adding a new entry to the context menu, not to the Contact Card itself (which is a mite confusing, as the object model doesn’t make a really clear distinction between the two).  HOwever, this gives me a great lead on what area of the object model to focus my attention on.  And worse come to worst, I can always start with a really crude hack of adding a context menu selection that just pulls up the internal directory data for the selected user (or as I’m seeing from the code sample, the “Recipient” – gotta get your nomenclature aligned when you dive into an Office object model exploration).

Next let’s see if anyone out there has been monkeying with this object or this part of the object model – searches on Stack Overflow turn up nothing, but MSDN Social Forums hits some info on:

And a search of MSDN Library for IMsoContactCard led to one non-reference article: Extending the User Interface in Outlook 2010.  According to this article, adding a new item to the context menu when you right-click an email sender or recipient is done using the ContextMenuContactCardRecipient context menu.

Given that these articles all seem to say that it’s impossible to extend the contact card itself, I find myself with two alternatives:

  1. Add a right-click menu option that pulls the internal directory info for the selected recipient.
  2. Add another tab to the ‘legacy’ Outlook Properties window (which was the default in Outlook 2007 & 2003 when you double-click on a user).

Context Menu vs. Properties window

Comparing Option (1) and (2), I come to these benefits & drawbacks:

  1. The programming for the Contact Card context menu was just added in 2010, which probably makes it behave more consistently and robustly than the COM-based crap that comes with legacy Outlook features.
  2. Adding a tab to the Properties window (form) would assist me more easily if I wanted to “crawl up the address book” (i.e. look for the same information on the managers of the recipient I’m exploring).  I find I *can* get to a context menu for the recipient’s manager, but it’s hellishly buried and I’d probably be one of three people who’d find it (or who’d bother taking this path).
  3. From my recollection, Office (and Outlook in particular) can be really picky about exactly how and when to dispose of objects – generally resulting (from <100% perfect code) in deadlocks, memory leaks or difficulties in shutting down the hosting app.  I would imagine the Interop Assemblies have a harder time communicating reliably with the legacy COM object model (e.g. Properties window) than with objects only recently introduced (e.g. Fluent UI).
  4. While the Office Interop Assemblies have been incredibly forgiving about providing backwards-compatibility to all the COM objects that have been accumulated over the decades, I have to believe that Fluent UI customizations have a better future in coming versions of Office than COM-based customizations.  This should be especially true of Outlook, since that team took a “wait and see” approach to the Fluent UI in the Outlook 2007 generation.  If they’re still on board, they’ve benefited from the delay *and* it is likely they’re more committed than if they’d gotten burned by jumping in early.
  5. If I’m reading this right, Office Communicator (probably 2007 R2 and later) implements support for the IMsoContactCard – so a Fluent UI approach might actually give us coverage in Outlook *and* Communicator.  I don’t know how useful that really would be, but it *sounds* cool.

Thinking as an end user, I’d find another tab on the Outlook Properties window more intuitive, but I’d also be extremely unforgiving if my Outlook user experience slowed down or destabilized.  I don’t like the Context Menu approach that I seem to be left with in customizing the Fluent UI, but I can be optimistic that a more integrated approach will become apparent as my research continues – and in the meantime I’ll have a Fluent UI-compatible set of code to build on.

Details: Fluent UI

All these articles I’m finding talk about these Contact Card customizations in terms of customizing the “Fluent UI”.  I’m not sure, but I had believed that this Fluent UI was primarily introduced as a wrapping layer of menu/ribbon ‘cleanup’ of the Office UI that was long overdue by Office 2007.  These references make it sound as if the Fluent UI is where all new UI improvements are “homed” in Outlook 2010.

As I dig a little further, there are some pretty clear indications this is true:

Customize the Office UI

In Office 2010, the Office Fluent UI is fully customizable. This includes the ribbon, the Quick Access Toolbar, and the built-in context menus. By using the flexible XML-based markup and callbacks, you can create context menus by updating Open XML Format files or by using add-ins that are created in Microsoft Visual Studio.

Customizing Context Menus in Office 2010

In Office 2010, you can customize built-in context menus just as you can the other components of the Ribbon UI. This XML-based context menu extensibility model is based on the familiar Ribbon extensibility model. This means that you can use the same XML markup and callbacks that you currently use to customize the Ribbon UI.

Encouraging, but not specifically helpful other than a lot of hand-waving and empty promises.  Having clear documentation on what the object model does is the critical piece, and all I’ve got here so far is a Context menu (which is hardly an intuitive UI approach).  However, if that’s what I’ve got then it’ll have to do.  Off to implement code based on Customizing the Context Menu of a Contact Card in Outlook 2010 and see how well that treats me.

ComponentChk.cpp – I resolved my first C++ compiler "fatal error"!

Yes, for those of you with even more grey in your beard/hair than I, this is probably a “meh” event.  However, for me, who’s always looked at C++ code and wondered how the H*** anyone could ever make sense of it, this is a big event.  [Patting myself on the back.]


I’m working on finishing up the Setup bootstrapper for my VSTO add-in Word2MediaWiki.NET.  I’m targeting Word 2003 and Word 2007 (despite Microsoft’s best efforts/worst neglect to the contrary), and I’m trying to achieve what many have done before, but which seemed impossible for me: allow the Setup.exe to detect which version of Word is installed, and then conditionally install the prerequisite software (i.e. the so-called Office PIAs) for whichever version of Word is discovered.

Problem 1: most folks in the VSTO space seem to think that, despite the fact that a version of the .NET framework is required to support VSTO, the Setup.exe that goes with your VSTO add-in install package should use UNmanaged code to detect whether the pre-requisites are installed.

Problem 2: I know squat about writing unmanaged code.

Problem 3: Microsoft’s VSTO & Office teams left it up as an exercise to the VSTO app developer to figure out how to assemble the amazing number of parts necessary to make a VSTO install work transparently to the end user.

Problem 4: There’ve been many articles written posthumously (I mean, long after VSTO v2 was released) on various aspects of automating VSTO-add-in installation, but none of them addressed the very inevitable scenario where the app developer needs to support both Word 2003 and Word 2007.  [Don’t even *think* about pre-2003 versions of Office — you’d have to be clinically insane.]

Manna from heaven

One ridiculously brave soul, Mark Hogan, actually took the time to not only figure out how to build such a conditional pre-requisite detection app in C++, but he was so overcome with glee that he beat Microsoft at something even they were too scared to do, that he published the full set of source code and XML configuration files for the entire world to use.

Now, masochist that I am, I took it upon myself to try to integrate the code that Mark Hogan published into the existing code that I’d already slotted into my Office PIA bootstrapper files.  However, I didn’t anticipate the foreseeable result that, because I’m coding this stuff in my spare time, and usually late at night, I would (a) not finish the integration work in one sitting, (b) forget what I’d originally set out to do and (c) forget to integrate any of the critical code that actually performed the conditional logic.

Mike chases his tail

Miraculously, I was left with a .CPP file that would compile and that appeared to be significantly different from the original file I started from, and that threw off an error code that created a spectacular wild goose-chase:

“Unable to satisfy all prerequisites for Word2MediaWikiDotNET.  Setup cannot continue until all system components have been successfully installed.”


“Prerequisite check for system component Microsoft Office 2003/2007 Primary Interop Assemblies (Word Only) failed.

See the setup log file located at ‘C:\DOCUME~1\msmithlo\LOCALS~1\Temp\VSD33.tmp\install.log’ for more information.”

And in the INSTALL.LOG file was the illusory answer:

Running external check with command ‘C:\DOCUME~1\msmithlo\LOCALS~1\Temp\VSD33.tmp\Office2003PIAor2007_WordOnly\ComponentChk.exe’ and parameters ‘/delete /save /word {1EBDE4BC-9A51-4630-B541-2561FA45CCC5}’

“Process exited with code 1607”

Setting value ‘1607 {int}’ for property ‘SupportedWordVersionInstalled’

Setting value ‘1607 {int}’ for property ‘PIAsRegistered’

This led me down the path of chasing InstallShield errors, since the only Google search results that looked at all related were things like these.  After a few days of trying to figure out how the InstallShield scripting engine could be related to a Visual Studio SETUP.EXE or custom C++ application, I finally got my brain back and tried to isolate where in the code or configuration files the problem existed.  That led me to a line of C++ code that threw ERROR_UNKNOWN_COMPONENT, which as it turns out also shares the 1607 error/exit value.

[The whole gruesome story is illustrated in the Bug I filed to myself here.]

Back to the original goal, with a new mission

Once I realized what I’d left out of the C++ code, I quickly got it to the point where I could try compiling it.  Now a new mission emerged – how to debug a C++ compiler error?

C:\>cl.exe /Oxs /MT /GS ComponentChk.cpp advapi32.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

ComponentChk.obj : error LNK2019: unresolved external symbol __imp__WaitForInputIdle@8 referenced in function “int __cdecl MyStart(char const *,char const *)” (?MyStart@@YAHPBD0@Z)
ComponentChk.exe : fatal error LNK1120: 1 unresolved externals

That command line (cl.exe /Oxs /MT /GS ComponentChk.cpp advapi32.lib) was derived from the original article from which we were all working (or stumbling around half-blindly, it felt to me).  I just ran this without a second thought, assuming that since Mark Hogan didn’t seem to mention any modifications to it, any errors it showed must’ve been my fault.

Where is “__imp__WaitForInputIdle@8” I wondered?  It didn’t show up in the source code when I searched for it, and nor did “int __cdecl MyStart“.

After staring at this for a while longer, I figured some substring searches would work, which after a few attempts finally showed me that I was actually looking for the code

WaitForInputIdle(pi.hProcess, INFINITE);

which is called in the function MyStart().  I tried some silly things first, of course, but I eventually realized that if WaitForInputIdle() didn’t exist as a named function in the source code, perhaps it existed in another library that wasn’t yet connected to the code?  A quick MSDN Library search told me this function was actually part of USER32.DLL, and it wasn’t too painful a leap of logic to try adding USER32.LIB to the compilation parameters, like so:

cl.exe /Oxs /MT /GS ComponentChk.cpp advapi32.lib user32.lib

And when I loaded up the now-successfully-compiled COMPONENTCHK.EXE into DEPENDS.EXE, it confirmed exactly what I expected to see:


Mark, many thanks to you, and my apologies for calling into question your mad C++ skillz.

Do you Wiki? Word2MediaWiki.NET first release is live!


I just wanted to let my faithful readers know that I have finally completed a beta version of the Word2MediaWiki.NET add-in for Microsoft Word 2003.

This’ll be useful to anyone that regularly contributes to Wikipedia, or those that have a bunch of Word documents that they’d like to share on Wikipedia.

It’s just as useful for any of the other hundreds of wikis that use the same server software as Wikipedia (known as MediaWiki), and it’ll be of interest to those folks who’ve used Word2MediaWikiPlus (from whose VBA source code I converted much of the basis of Word2MediaWiki.NET).

Grab a copy here:

And please, let me know about any issues or experiences you have with it by posting a Discussion item here:

"Go/No-Go" Decisions on MyPicasaPictures, Attensa Sync to Google Reader, W2MW++

I’ve done a lot of investigatory work in the last few lunar cycles of different development projects I’d dreamed up.  However, after the investigation and the internal decision making was completed, I didn’t do a good job of “closing the loop” with any of you who have wondered “what happened all those projects?”.

I haven’t thought much about the royal “you” in this work — I’ve been sharing the steps and findings, but recently I started to wonder what people would think in the future if they happened to search on something that led them to one of these projects’ articles.  I’d feel pretty frustrated trying to find out where these things led (if anywhere) and where (if anywhere) there might be code that came out of these efforts.

Well then, it’s time to close the loop on these — at least, as much as I am “decided” on any of these so far.  That said, I’m never committed to any particular decision like this if any new evidence surfaces in the future to challenge my assumptions.  So if anyone is interested in picking up where I left off on any of this, drop me a line to let me know (I’m always interested in this kind of experimental work), and if you’d like to bounce some ideas off me, or see if I’d be interested in participating, I’ll always be open to such inquiries.

MyPicasaPictures: No-Go

Bottom line: while the effort to understand the VMC development environment was instructional and probably honed my ability to figure out what to look for in future explorations, my overall impression of MCML is that it’s just too damned hard for amount of value I might derive from it.

That, plus the chronic and unresolved stability issues I’m seeing with Vista Media Center (exacerbated by the merciless complaints and teasing I receive from my wife, who keeps saying “The XP box was much more stable, wasn’t it?”) have pretty much convinced me to pave the box, downgrade to Windows XP and to give Beyond TV a try.  [Their SDKs and more open, flexible architecture look like the perfect place to invest .NET development efforts, and the customer satisfaction with Beyond TV seems far superior to Windows Media Center, at least based on my initial research.]

Attensa Sync to Google Reader: No-Go

I had already decided to move from Attensa for Outlook to NewsGator Inbox, and then a few weeks ago NewsGator announced that their previously $30 Outlook client would henceforth be available for FREE to any and all concerned.

While there was no conversion possible from Attensa to NewsGator (well, I could import the OPML, but I couldn’t sync the “read/unread” status of all my articles, nor transparently migrate old articles to the new folder structure), everything else about this has been a positive experience.  I’m totally addicted to the NewsGator Mobile Reader for iPhone, and the fact that it syncs with my Outlook “read/unread” status is just awesome.  Congrats, NewsGator!

Attensa, I wish you luck in trying to survive the competitive pressures from NewsGator.  If I didn’t know better, I’d guess this is the beginning of the decline for Attensa, even though I think their Outlook client is superior to the current NewsGator Inbox offering.

W2MW++: Undecided

When I first read about the “export to MediaWiki” capability in OpenOffice Writer 2.3, I quickly concluded that any work I or the rest of the community had done for an Office add-in would become a moot point.  [Amusing but not-entirely-inaccurate Spoonerism: my wife knew a guy who insisted that the term was “a mute point”.]

However, after using Writer 2.3 to convert a few relatively simple Word 2003 documents to MediaWiki format, I realize that they still have a long way to go to preserve real fidelity of layout and formatting in Word documents.  I have faith that they’ll get there, and that eventually Writer’s integrated engine will become the translation engine for .DOC & .DOCX, but I now feel like there’s a significant unmet need that the work I’ve invested so far in W2MW++ could still address, and that that unmet need will exist for quite a while yet.

That said, there’s one thing that’s been bugging me for a few months now: the name.  WordToMediaWikiPlusPlus is a clever extension of the Word2MediaWikiPlus project, and it makes obvious the heritage of W2MW++, but it makes it sound like the project is more “hardcore” than it really is.  If I had my druthers, I’d rename the project “Word2MediaWiki.NET” (W2MW.NET), to make it clearer that the project is based in .NET code, not C++.  I’d hate to think anyone would be disappointed by the fact that it’s written in one of these “shiny new” languages — there’s something more “honest” or “obvious” about using the “.NET” suffix instead.

Now all I have to do is figure out how to Rename all the dozens of “++” references throughout the project AND figure out how to get a CodePlex project renamed.  [THAT should be fun :)]

Office add-ins: VSTO or Shared? Why should I care?

I’ve noticed an interesting pattern in the VSTO Forum on MSDN.  Cindy Meister (the queen of VSTO & Word programing) will very often ask a poster whether they’re developing a Shared Add-in or a VSTO Add-in.  Nearly all the responses to such questions indicate that the poster has no idea, and I can’t blame them.  It seems that even if someone’s used the VSTO solution templates to create a new project targeted at Office applications, they could still end up inadvertently creating a Shared (or COM) add-in.

I finally got frustrated enough at trying to judge whether a question I’d ask would be “worthy” of the VSTO Forum, or would just be punted back to me to find an appropriate newsgroup — so I decided to figure out what’s the point of this once and for all.

I quickly discovered that Cindy has gotten this question in the past, and has summarized some of the differences here:

However, that still doesn’t answer the question of “Why should it matter whether my VSTO project actually turns out to be merely a Shared Add-in?”

  • Does it change the way that you’d use certain .NET classes — or does it limit the kinds of classes that can be used by a Shared Add-in?
  • Does it create incompatibilities on the deployed client — or does it require a different deployment approach for a Shared Add-in?
  • Do certain data types, methods for creating Event Handlers, or Office PIA-encapsulated APIs not work in a Shared Add-in that would work in a VSTO Add-in?

How can I tell whether the project I’m developing is a VSTO Add-in or a Shared Add-in?

  • Is there some set of Imports/Using statements that only work in one or the other (e.g. Imports Microsoft.Office.Core vs. Imports Microsoft.Office.Interop.Word)?
  • Do certain Visual Studio Templates lead to either Shared Add-ins or VSTO Add-ins (e.g. Visual C# > Office > 2003 Add-ins > Word Add-in vs. Visual C# > Office > 2007 Add-ins > Word Add-in vs Visual C# > Office > Word Document)?  Or is it only relevant if the template used is Other Project Types > Extensibility > Shared Add-in?
  • Once I’ve created the project/solution, and if I don’t remember 100%, is there some filename, configuration setting, unique Event or other property of the project that would definitively indicate that it’s VSTO vs. Shared (e.g. ThisAddIn.vb, ThisAddIn_WindowActivate())?

For me, the specific issue that I have been having issues with, and which I’m beginning to suspect has a different solution depending on “Shared” or “VSTO” (despite the lack of clarity or obviousness in any of the sample code you’ll find on the ‘net), is the specific means by which a custom Event Handler can be created for CommandBarButtons in a managed add-in for Word 2003.

I’ve personally seen both code like this (C#):

uiButton.Click += new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler(uiButton_Click);

and like this (VB):

    Private WithEvents uiButton As Microsoft.Office.Core.CommandBarButton

It’s entirely UNclear whether these are exactly equivalent, and if not, under what environmental conditions/constraints one is better than the other.  It’s also completely beyond me whether this would be considered part of a VSTO add-in or a Shared add-in.  Finally, I wouldn’t have a clue what I should do differently were I to know which type of add-in this was – would it affect which of these two handler-setup approaches I used?  What types of objects I should use?  Something else?

What if Google Reader had a sucky API…?

I’ve been thinking more about the idea of building a VSTO add-in for Outlook that could synchronize between Attensa for Outlook and Google Reader (I wrote previously about the idea here).

I’ve had a heckuva time trying to figure out how to build Web Services client code into a Windows client application.  There’s a ton of books out there documenting how to build the server side of Web Services; even the books and articles that talk about building Web Services client code, are really talking about consuming Web Services into another server application.  I finally figured out a query or two that gave us some leads, but it’s wasn’t exactly a slam dunk.

I’ve also had more trouble than I expected to figure out what the story is with Google Reader’s API.  Back in 2005 there was an effort by Niall Kennedy to reverse-engineer the then-current Reader API; at the time, the Reader team even commented a couple of times on the imminent release of the API.  Ever since then, there’ve been various inquiries but no further details to let folks know where they stood.  [Well, at least from the SOAP API standpoint.]

I’ve been getting more and more suspicious that Google no longer intends to document and release a SOAP-based API for Google Reader.  I finally became convinced of this when I stumbled on a not-terribly-related article by Scoble, where he caught us up on Google’s inauspicious switch from their original SOAP Search API to an AJAX Search API.

My take: despite some of the comments on Scoble’s article that imply he’s just being paranoid, I happen to think there’s merit to the theory that Google has no interest in developing APIs that don’t further their advertising revenue.  It’s not that I particularly dislike Google (I’m a big fan of many of their services), but after two years’ delay from when the Reader team was about to release their SOAP API anyway, it’s pretty hard to imagine that the great disappearing act is not in some way deliberate.

The fact that they developed and released the Reader AJAX API in less time demonstrates that they’re capable of getting a Reader API out in that timeframe, and the distinct lack of mention of any further API development (either on the Reader group discussion boards or on the Reader team’s blog) pretty much seals the deal for me.

So what’s an in-their-spare-time developer supposed to do at this point?

Google Reader: toss it…

From what I see of the Reader AJAX API documentation, it’s not meant as a full-fidelity API for manipulating the contents of a user’s Reader configuration, article read/unread status or even the list of blogs to which they’re subscribed.  I’m not terribly interested in placing an eight-article list of links (+ Google ads) in a VSTO add-in to Outlook.  Nor am I all that interested in trying to use an undocumented and unsupported (not to mention still-in-flux) SOAP API — it’s enough trouble for me to do something once, let alone every week or month when they decide to rip out something else.  It sure doesn’t help to hear someone who’s been keeping an eye on this space say things like Google is embarking on the “creation of de jure and de facto standards which are pitched as being great for customers but seem suspiciously like attempts at Fire & Motion.

Attensa Online reader: no more

I probably wouldn’t even be going down this road if Attensa had kept up their own online web-based feed server.  However, despite multiple positive reviews and different URLs that used to point to it, it’s gone the way of the dodo bird.  Heck, I’ve even lost access to Attensa’s own corporate feed server (to which they gave me an account last year after all the bug reports I’d sent them).

MyYahoo: no published RSS APIs

Many news reports repeat the “fact” that MyYahoo is one of the most popular online RSS readers on the ‘net.  I dug into its interface, documentation, and searched around Yahoo’s site for a while, but it was so obtuse it was hard to actually find any references to terms like RSS or OPML.  I’ve come to the conclusion that there’s either (a) no official API for MyYahoo feed reading, or (b) it’s just not something Yahoo has invested any effort into.  However, Niall Kennedy has documented some API characteristics, and I stumbled upon Yahoo’s general developer documentation (among which they mention that most APIs use the REST approach).  The Yahoo SDK provides C# & VB.NET samples for Yahoo’s various search properties but nothing more.

NewsGator Online: in a word, wow

According to a trip report from ETech 2006, the Newsgator API “uses standard protocols (SOAP) which can be consumed from any platform” and it “supports granular operations [add feed, mark item read, rename feed, etc]”.  The Newsgator Online API has documentation and even C# sample code here.  Newsgator also provides a web-based feed reader that’s optimized for iPhone (which is my ultimate online target) and a Windows Media Center-integrated web reader (which’d be a bonus for me with Vista Ultimate controlling my TV universe at home).  Hey, they even provide a Desktop client that integrates with the IE7/Windows RSS Store (though it’s unclear whether it syncs with NewsGator Online).  Plus there’s an Outlook-integrated client that has some of the capabilities of the Attensa Outlook client (though not the free price tag). unpublished API (or less?)

This one was mentioned on Wikipedia‘s article for Google Reader.  I wasn’t able to find anything on Rojo’s site about an API, but I did see a few sporadic mentions on the ‘net (e.g. Yuan.CC’s archives through 2005, a Rojo forum suggestion).  Unfortunately, as the discussion seems to center around “undocumented” APIs, I’m even less interested in this than in Google’s limited interface.

Bloglines: “it sucks a lot

According to the ETech 2006 trip report, “The Bloglines Sync API didn’t work for synchronization since it is mainly a read-only API for fetching unread items from Bloglines. However it is complicated by the fact that fetching unread items from Bloglines marks them as read even if you don’t read them in retrieving applications.”

NewsAlloy: cool but not there yet

Currently in Beta, this free web-based feed reader implements the “Blogroll API” (whatever that means), and provides both a rich web-based and a mobile interface.  Unfortunately, the developer has been struggling off and on to keep this project going, but it’s a really cool looking project.

Feedlounge: cancelled

Read here.

Gritwire: no idea

Gritwire Labs (where I’d expect mention of APIs to show up) doesn’t mention anything about APIs.  The author once mentioned “It relies on an XML API to receive and provide data to the backend”, but there’s little if anything else that would help me understand what this “API” is used for.

Conclusion #1: Build a Generic Sync add-in

I’d started my solution as a Google-Attensa app (heck, I’d named it GoogleReaderSyncToAttensa).  Now, after looking into this, and not seeing any one clear “winner” among the online web-based feed readers, I have decided that the only responsible thing to do is to build this add-in on the assumption that others’ll want to add their own web-based readers to the codebase.  Thus, all the direct button-to-codebehind and code-to-Attensa calls should be abstracted as much as possible to not tie the code to any one web-based reader.  The idea is to make it as *easy* as possible for someone to add their own assembly/class that encapsulates the necessary site-specific functionality, and (ideally) not have to rewrite any of the existing code, other than to call into the appropriate assembly/class.

Heck, if I was feeling really generous, I’d even consider abstracting the Attensa interface so that Microsoft’s IE7 Feeds interface could be used as the local client, or even the inevitable Google Apps offline reader.  However, I’m getting waaayyy ahead of myself with this kind of thinking.  I’m going to have a hard enough time abstracting the remote site interfaces, let alone try to wire the classes for “plug and play” with various local feed reading apps.

Conclusion #2: I Should Just Cough Up the $30 for Newsgator Inbox

At my core, I’m just a lazy guy.  If I can find a pre-built application to do most of what I want to do, then I’ll suffer with the pain of that rather than go off and “build” something myself.  That was the core lesson I learned from Comp Sci 1A03 (first-year programming) in undergrad, and my computing bias was solidified that way ever since.

After looking at the breadth and depth of offerings from Newsgator (SOAP API, REST API, Outlook client, Windows Feed Store integration, iPhone web client, Windows Media Center client, and broad support for synchronization among all the feed readers) it feels like a tough choice for me: spend a few months developing a synchronization framework between Attensa and one or more online feed readers, or spend the $30 on Newsgator Inbox and postpone development indefinitely.

I guess the big question is, am I more interested in learning how to code Outlook VSTO and Web Services (SOAP and/or REST), or am I really just interested in getting on with my RSS reading and work on something else?  I do have plenty of other development projects I can continue doing, and it’s not like I have all this spare time to devote to multiple concurrent development projects.  On the other hand, this is an interesting space for development, and (for those folks not paying $$ to Newsgator yet) there’s something to be said for laying the groundwork for a generic offline-online RSS synchronization framework.

I’m going to have to sleep on this for a while — this is not an easy choice.