Author: paranoidmike

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

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.

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

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:

• Customizing Context Menus in Office 2010 
• Customize the Office user interface in Office 2010
• How Do I: Create a WPF Control for Use Within Outlook 2010?
• Building WPF Data Controls for Outlook Addins Easily with VS2010

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

• Changes in the Security Model for Office Solutions
• Deploying Office Solutions to End User Computers
• Deploying Microsoft Office Solutions by Using Visual Studio 2010 and Windows Installer
• Office Add-in (VSTO) Performance Tips & Tricks
• Troubleshoot VSTO Add-In Load Failures

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

• ContextMenus Add-in for Office 2010
• Communicator Add In for Outlook 2007
• Out Loud for Outlook
• Outlook 2007 Add-in: Active Directory & CRM Resolver
• Office Development in Visual Studio 2010
• Deploying a VSTO 2010 solution for Office 2007/2010 using Windows Installer
• Microsoft Office 2010 Primary Interop Assemblies Bootstrapper Package
• SPlus Convert email thread to a follow-up Meeting Request
• Inbox Zero Outlook 2007 Addins
• Outlook Attachment Reminder for Outlook 2007/2010