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:

http://blogs.msdn.com/b/vsod/archive/2008/04/22/troubleshooting-com-add-in-load-failures.aspx

  • 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)

http://social.msdn.microsoft.com/forums/en-US/vsto/thread/f2f2a8f6-3ed5-4c1f-ab6b-17120e64f13d/

  • Set the VSTO_SUPPRESSDISPLAYALERTS=0
  • 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: http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/d0ffb791-43bb-41f3-a2ca-c22bd959f4c3
  • 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 http://msdn.microsoft.com/en-us/library/ms269003.aspx

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)
{
    try
    {
        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();
            UserDetailsInfoForm.Show();

            string emailAddress = GetSmtpAddress(card);
            ActiveDirectoryUser user = new ActiveDirectoryUser();
            
            NameValueCollection coll = user.getGcUserData(emailAddress);
        }
        else
        {
            // 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;
            break;
        }
    }

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

    DirectorySearcher ds = new DirectorySearcher(
        _root,
        filter,
        null,
        SearchScope.Subtree
        );

    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();
dataDisplay.Show();

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.]

Situation

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.”

Details:

“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.

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

/out:ComponentChk.exe
ComponentChk.obj
advapi32.lib
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:

image

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!

Snippy0001

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:

http://www.codeplex.com/Word2MediaWikiDotNET

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

http://www.codeplex.com/Word2MediaWikiDotNET/Thread/List.aspx