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.

Found: Minimum permissions to edit Site Columns in SharePoint 2010

Our organization has a requirement to delegate the maintenance of a number of Site Columns (re-used throughout our business application) to colleagues who do not have Site-wide responsibilities or authority.  We didn’t want to simply grant one of the all-powerful permissions/groups (such as Site Collection Administrators, Site Collection Owner, [Site] Owners, or just granting Full Control) as that would leave them open to accusatory questions every time the site or application started behaving badly.  We’d like them to be able to act fairly autonomously, without having to worry that they could cause unintentional damage to the site or application due to excessive permissions.

Knowing that most every Microsoft product has a rich, granular set of DACLs applied at every object level, and having exercised some of the rich permissions available in SharePoint 2010, I was pretty sure there should be a way to combine some permissions together to enable Site Column edits, without giving away the farm.  However I was unable to find any documentation or research that definitively asserted they knew what those permissions were.

Finally I asked my colleague Dale Cox to pair up with me and, together with four hours and an experimental sub-site, we were able to work out a tight sub-set of permissions that (a) definitely allow Site Columns edits to propagate to inheriting Lists and (b) were ratcheted down stepwise until we were comfortable there was no place lower to go.

Permissions: Summary

There are two sets of permissions we tested for: site-level permissions needed to edit an existing Site Column (that is being used as a column in one or more Lists in the SharePoint site), and List-level permissions needed to propagate Site Column changes down to inheriting columns in a List.

The former permissions *only* exist at the site level (even though some permissions in the permissions set are labelled “site permissions” and others “list permissions”) – we’ve found there are *no* permissions that can be managed directly related to Site Columns, but only indirectly via the site-level permissions.

That we also require the latter permissions was surprising at first (once we configured the inheritance, why should we need ongoing permissions on every inheriting List?), but that’s just a design decision that Microsoft’s SharePoint team made.  It means we have to manually *track* all the Lists that inherit changes from Site Columns, and make sure our site column maintenance people have enough permissions to the Lists.

Site-level Permissions

  • Manage Lists (labelled “List Permissions”)
  • View Items (labelled “List Permissions”)
  • Add and Customize Pages (labelled “Site Permissions”)
  • Browse Directories (labelled “Site Permissions”)
  • View Pages (labelled “Site Permissions”)
  • Open (labelled “Site Permissions”)

List-level Permissions

  • Manage Lists (individual permission – which includes View Items, View Pages and Open)
  • Contribute (permission set)

There is one case we did *not* explicitly test for, but found was part of the resultant permissions we arrived at: creating a new Site Column.  While we believe this probably requires only a subset of the site-level (site and/or List) permissions, we didn’t spend the extra cycles to isolate the minimum permissions needed there.  Perhaps it’s implied in the results, and if we need to know we’ll pursue it, but it’s not something we needed to know right now.

Steps We Followed To Distill These Permissions

We had to work as a team to test each permissions combination, as I’d found early on that as soon as I removed myself from the all-powerful groups, I was unable to restore myself or change permissions later on.  I manipulated the permissions, and Dale ran the test cases.  I pre-created the following groups in our experimental site and assigned them specific site-level permissions, to make it easy to switch from one permission set to another:

Group name

Permission Levels assigned to group (custom permissions included)

Approve Approve
Design Design
Manage lists Manage Lists (Manage Lists, View Items, View Pages, Open, Manage Personal Views)
Manage web site Manage Web Site (View Items, Manage Web Site, Add and Customize Pages, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open)
Site viewers Contribute, Read, View Only
Edit Site Columns (Add and Customize Pages, Browse Directories, View Pages, Open)

 

  1. Dale’s starting position:
    • Permissions: member of Site Viewers group
    • Result: can view site Libraries and Lists but cannot even load the Site Columns page (/_layouts/mngfield.aspx)
  2. Added Dale to “Manage Lists” group
    • Result: can load Site Settings page but still cannot access Site Columns page
  3. Removed Dale from “Manage Lists” group, added to “Manage web site” group
    • Result: Can load Site Columns page but cannot edit site columns
  4. Granted Dale the Contribute permission on one of the Lists that inherits a Column definition from the Site Column being tested.
    • Result: can still load Site Columns page but still cannot edit the site column being tested
    • Dale even tried just updating the site column definition without propagating the change to the inheriting Lists, but that still didn’t work
    • NOTE: from here onwards we started making a point of trying to separate out the ability to edit the site column definition from the ability for that site column definition to propagate to inheriting lists
  5. Removed Dale from “Manage web site” group, added to “Approve” group
    • Result: Dale cannot load Site Columns page
  6. Added “Manage Web Site” permission to a new permission group called “Approve + MWS”
    • That is, copied the “Approve” permission group, then checked the “Manage Web Site” permission (and left the dependent permissions that came with it)
    • Result: Dale can load the Site Columns page, but cannot commit changes to any Site Columns
  7. Removed Dale from “Approve + MWS”, added Dale to “Manage Hierarchy” group
    • Note: while the difference in included permissions between “Manage Web Site” and “Manage Hierarchy” is large, still the “Manage Hierarchy” permission set is a superset of “Manage Web Site”
    • Result: Dale can access the Site Columns page, but cannot commit changes to Site Columns
    • However, we noticed that Dale can create a new Site Column, and can edit that new Site Column
    • Dale attempted just a non-propagating edit with one of the existing Site Columns, and was successful.
    • Theory: current permissions on the Lists that inherit from the existing Site Columns are what’s blocking the previous Site Column edits
  8. Granted to Dale “Contribute” permission on all of the three Lists which inherit from the existing Site Columns
    • Result: Dale cannot commit a propagating edit on an existing, inherited Site Column
    • Theory: the individual permission “Manage Lists” is what’s needed on each inheriting List for the Site Column propagation to succeed
  9. Granted to Dale “Design” permission (which includes the individual “Manage Lists” permission) to one of the three inheriting Lists
    • Result: Dale could not commit a propagating edit on an existing, inherited Site Column.  Further, the change did not even inherit to the inheriting List (where the permissions needed for propagation could have allowed the change).
    • Theory: propagating edits to a Site Column are a transactional request – if the request doesn’t succeed on every inheriting List, then the edit “transaction” is rolled back, rather than partially succeeding.
  10. Changed the following permissions to all three inheriting Lists: changed from “Design” + “Contribute” to “Manage Lists” + “Contribute”
    • Result: Dale’s propagating edit finally succeeded!
  11. Decided to go back over the site-level permissions to determine whether there was an unknown interaction between the site-level and list-level permissions that we didn’t account for.
  12. Kept the List-level permissions as-is, but changed Dale’s site-level permissions – removed him from “Manage Hierarchy” and added him to “Approve + MWS” group.
    • Result: propagating edit failed, and non-propagating edit failed.
  13. Removed Dale from “Approve + MWS” group, added Dale to Design group (which has Design permissions set).
    • Result: propagating edit succeeded.
  14. Compared the permissions between the “Design” and the “Manage Hierarchy” permissions groups, and found the following eight permissions in common:
    • Add and Customize Pages
    • Browse Directories
    • View Pages
    • Browse User Information
    • Use Remote Interfaces
    • Use Client Integration Features
    • Open
    • Edit Personal User Information
  15. Analysis of these permissions, looking for the “secret sauce” that they share:
    • The “Manage Web Site” site-level individual permission isn’t the one that Dale needs (as it isn’t part of the Design permission set, and yet Dale was still able to propagate the edit when he had the Design permission)
    • Based on the descriptions of each individual permission listed above, the most likely candidate is “Add and Customize Pages”
  16. Created a new Group called “Edit Site Columns”.  Created a new permissions set called “Edit Site Columns”.  To that permissions set, we added only “Add and Customize Pages”.  Removed Dale from Design group, added him to Edit Site Columns group.
    • Note: when “Add and Customize Pages” is checked, the following permissions were automatically checked: “Browse Directories”, “View Pages”, “Open”, “View Items”.
    • Result: propagating and non-propagating edits failed.  Adding a new Site Column also failed.  Dale could access the Site Columns page.
  17. Added back all eight site-level permissions that were in common between the Design and Manage Hierarchy permissions sets.
    • Note: the “Edit Site Columns” permission set at this point doesn’t include any of the List-level permissions that I’ve so far ignored.  Continued failure means that to edit Site Columns, a user needs some of these “list permissions” assigned at the site level.  [Confused yet?]
    • Result: propagating and non-propagating edits failed.  Dale is still able to access the Site Columns page.
  18. Re-examined the “list permissions” that were included in both of the site-level permissions sets (Design and Manage Hierarchy) that were successful for Dale:
    • Manage Lists  –  Create and delete lists, add or remove columns in a list, and add or remove public views of a list. 
    • Override Check Out  –  Discard or check in a document which is checked out to another user. 
    • Add Items  –  Add items to lists and add documents to document libraries. 
    • Edit Items  –  Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries. 
    • Delete Items  –  Delete items from a list and documents from a document library. 
    • View Items  –  View items in lists and documents in document libraries. 
    • Open Items  –  View the source of documents with server-side file handlers. 
    • View Versions  –  View past versions of a list item or document. 
    • Delete Versions  –  Delete past versions of a list item or document. 
    • Create Alerts  –  Create alerts. 
    • View Application Pages  –  View forms, views, and application pages. Enumerate lists. 
  19. Added all of the above permissions to the “Edit Site Columns” permission set except View Items.
    • Result: propagating edits were successful.
  20. Stripped down the site permissions from the “Edit Site Columns” permission set to leave only the following: ACP, Browse Directories, View Pages, Open.
    • Result: propagating edits were successful.
  21. Stripped out a number of List-level permissions from the “Edit Site Columns” permission set to leave only the following: ML, VI.  Left the site permissions as in the last step.
    • Result: propagating edits were successful.
  22. Wanted to ensure this result is reproducible, so we created a new permissions set “Edit Site Columns – Confirmation”, added the same permissions to this new set (i.e. ML, VI, ACP, BD, VP, Open),  created new group “Edit Site Columns – Confirmation”, granted the new permission set to the new group, added Dale to the new group and removed him from the older “Edit Site Columns” group.
    • Result: all operations were successful – view Site Columns page, commit propagating and non-propagating edit of inherited Site Columns, add new Site Column.

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