Office Development with Visual Studio : Office 2010

Using Office 2010 Extensibility Schemas with VSTO addins for Beta 2 (Stephen Peters)

VSTO Team — Fri, 04 Dec 2009 22:06:00 GMT

Office 2010 brings in many new features to the Ribbon and Backstage extensibility. In order to take advantage of those changes in VSTO addins, you will need to update your ribbon XML projects to use the new Office 2010 schema.

First, you will need to see if the schema is installed. To do this, look in “C:\Program Files\Microsoft Visual Studio 10.0\Xml\Schemas\1033” (you might need to modify this to point to your Visual Studio installation directory). If customui14.xsd is there, you can skip ahead to the next paragraph. Otherwise download the schema from here, and install it in the directory above. When you are done, double check to make sure that the custom14ui.xsd file is there.

Go to the Ribbon XML item that you want to use on Office 2010. For this blog post I am going to use a Word 2010 addin with a single Ribbon XML item, but the same code can work with any VSTO project with only minor modifications.

At the top Ribbon1.xml, there is a line

  <customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui" onLoad="Ribbon_Load">

You will want to replace the URL with

  http://schemas.microsoft.com/office/2009/07/customui

If you look in the properties window for the XML document, the schema for the document should now point to the customui14.xsd that was installed. Now we can play around with it a bit. Under </ribbon> in Ribbon1.xml, add the following code:

  <backstage>
    <tab id="VSTOTab" label="VSTO Tab" insertAfterMso="TabInfo">
      <firstColumn>
        <group id="VSTOGroup" label="Hello From VSTO!">
          <topItems>
            <button id="AddMoreCowbell"
              label="Add More Cowbell"
              onAction="AddMoreCowbell" />
          </topItems>
        </group>
      </firstColumn>
    </tab>
  </backstage>

We will also need to add the callback to Ribbon1.cs:

public void AddMoreCowbell(Office.IRibbonControl control)
{
    System.Windows.Forms.MessageBox.Show("Fever Cured");
}

And, of course, the integration in ThisAddin.cs

protected override Microsoft.Office.Core.IRibbonExtensibility CreateRibbonExtensibilityObject()
{
    return new Ribbon1();
}

Run your add-in, and when you go to the backstage, you will find the backstage tab that we just added:

Now that you have the schemas set up, you can read up more on extending Backstage and new Ribbon features here:

Microsoft Office 2010 Technical Articles

- Customizing the Office 2010 Backstage View for Developers

- Ribbon Extensibility in Office 2010: Tab Activation and Auto-Scaling

Office 2010 Custom UI Schema (repost from above)

Office 2010 Beta & SharePoint 2010 Beta Now Available to the Public (Beth Massi)

VSTO Team — Wed, 18 Nov 2009 18:54:34 GMT

Monday Office and SharePoint 2010 Beta were released to MSDN/TechNet subscribers. Today it was announced at PDC that these are available to the rest of the public! Come and get it…

Office 2010 Beta

SharePoint 2010 Beta

These Betas are compatible with Visual Studio 2010 Beta 2 which was released to the public a few weeks ago. We’ve also started a series on Channel 9 on SharePoint development in Visual Studio so check that out starting with:

Overview of SharePoint Development in Visual Studio 2010

Also check out…

Office 2010 resources

SharePoint 2010 Resources

And stay tuned here for more posts on Office Development with Visual Studio 2010!

Enjoy,
-Beth Massi, Visual Studio Community

Office 2010 Application Compatibility Program (Beth Massi)

VSTO Team — Wed, 28 Oct 2009 16:46:10 GMT

If you missed it, Office announced a compatibility program to help IT and developers who have built add-ins make a seamless upgrade to Office 2010. We want you to have a successful and seamless migration to Office 2010 for your VSTO solutions. The program provides tools for environment assessment, code scanning and remediation assistance, and an update to the document conversion tools introduced with Office 2007.

Check out Michael Kiselman’s post for more details on the program that will be available in early December.

Enjoy,
-Beth Massi, Visual Studio Community

Channel 9 Interview: John Durant on Developing Managed Applications for Office 2010 in Visual Studio 2010 (Beth Massi)

VSTO Team — Thu, 17 Sep 2009 21:41:19 GMT

Robert Hess posted an interview yesterday on Channel 9 with John Durant on Developing Managed Applications for Office 2010 in Visual Studio 2010. When you have 20 minutes you should check it out.

John provides some highlights as to what he’ll be showing in his PDC sessions, and some of the new features that developers can look forward to in Office and Visual Studio 2010.

Enjoy,
-Beth Massi, Visual Studio Community

Will your VSTO addin run on Office 2010 64-bit? Yes, probably. (Christin Boyd)

VSTO Team — Thu, 06 Aug 2009 01:05:00 GMT

The Visual Studio team is designing the runtime components for Office 2010 so that your Visual Studio Tools for Office 2005 and Visual Studio 2008 .NET addins, document solutions and spreadsheet solutions will run on 64-bit Office 2010. These runtime components will ship with Office 2010, so your end-users won’t even have to download a new runtime! How easy is that? There are a few rare exceptions that I’ll discuss in this blog entry.

The miracle of managed code allows you to write C# or Visual Basic .NET code that compiles to “Any CPU” using the Compile setting in your Visual Studio project. Your code compiles to MSIL with Visual Studio, and then at runtime it gets JIT compiled to the correct chip set, either AMD, Intel, 32-bit or 64-bit. The first exception to this wondrous technology is the oldest versions of .NET Framework 1.0 and 1.1 will not enable this 64-bit transformation.

The other thing to lookout for is calls to process invoke (p/invoke) in your code. If you try to call native API methods using p/invoke you could have issues with your VSTO solution running properly on 64-bit Office 2010.

You will have problems if your code makes deliberate calls to p/invoke a Win32 API that does not have exactly the same signature (method name, parameter list, and DLL name) of an equivalent Win64 API. This is true for any solution you write regardless of targeting Office as the platform. You can find a ton of information in MSDN and blogs by such luminaries as Scott Hanselman about writing Windows API calls so that they will run on either 32-bit or 64-bit Windows. Here is a generalized code snippet for handling cases where the method name or the DLL name is different:

//YourFunction has the same name, parameters, and DLL name in 32bit and 64bit
YourFunction();

Import("LIBRARY", EntryPoint = "YOURFUNCTION", CharSet = CharSet.Unicode)]
private static extern bool YouFunction();



//In some cases, the method name is different in Win32 API and Win64 API, 
//so use the following code block in stead of the above 3 lines of code.
if (Marshal.SizeOf(typeof(IntPtr)) == 4)
{
    YourFunction32();
}
else if (Marshal.SizeOf(typeof(IntPtr)) == 8)
{
    YourFunction64();
}



Import("LIBRARY32", EntryPoint = "YOURFUNCTION32", CharSet = CharSet.Unicode)]
private static extern bool YourFunction32();

Import("LIBRARY64", EntryPoint = " YOURFUNCTION64", CharSet = CharSet.Unicode)]
private static extern bool YourFunction64();

Resources:

Here are more resources to help you author your solutions today so that they will run without needing a recompile when your users install 64-bit Office 2010.

MSDN Library Visual Studio 2005 article on developing 64-bit Applications

MSDN Library Visual Studio 2008 article on developing 64-bit Applications

How to access the “real” x64 registry from a Win32 .NET Application – Part I

The Myth of .NET Purity, Reloaded

For migrating your really old apps with lots of native calls to .NET, try checking if your native calls have an equivalent .NET call:

Microsoft Win32 to Microsoft .NET Framework API Map

Interoperating with Unmanaged Code

Finally I should mention that this is my last post (for a while at least) on this blog because I am leaving Microsoft. I’m going to work on a charity project teaching robotics programming to high school kids in my “inner city” neighborhood for at least the next 6 months. The project is called Team Xbot! Keep an eye on these kids as they go on to good colleges and great jobs in the next few years!

Sincerely, Christin Boyd, Program Manager

Demonstrating how to sync Facebook events to Outlook

VSTO Team — Wed, 05 Aug 2009 19:59:07 GMT

Every once in a while, we learn of neat apps that have been created with the Office development tools in Visual Studio. In an Outlook 2007 add-in, Jake Ginnivan combined WPF and the Facebook API to respond to Facebook events from a Ribbon. In addition, this add-in works in Outlook 2010 and has been deployed with ClickOnce. He’s written about this in two parts:

Writing a Facebook event synchroniser for Outlook 2007+ Part 1

Writing a Facebook event synchroniser for Outlook 2007+ Part 2

If you have come across other VSTO apps, feel free to leave a link in a comment here.

Mary Lee, Programming Writer.

32bit Visual Studio and 64bit Office (Christin Boyd)

VSTO Team — Thu, 11 Jun 2009 22:44:05 GMT

Visual Studio 2010 will ship with a 32bit version, and no 64bit version. My team built a very smart layer into Visual Studio 2010 to enable designers and debuggers that work with 64bit Office 2010 and 64bit SharePoint Server 2010.

For a good explanation of why the Visual Studio team chose to only build a 32bit version for the next release, you can find a blog post by Rico Mariani titled “Visual Studio: Why is there no 64 bit version? (yet)”

SharePoint Server 2010 will be 64-bit only. You can learn more about the requirements of Microsoft SharePoint Server 2010 on the SharePoint Team Blog entry “Announcing SharePoint Server 2010 Preliminary System Requirements” If you plan to build solutions for the next generation of SharePoint Server, then I recommend budgeting to purchase 64bit hardware.

-Christin Boyd, Program Manager, Visual Studio

Sign up for Office 2010 Technical Preview

VSTO Team — Tue, 12 May 2009 20:36:36 GMT

I’m at TechEd in LA, but it seems I could get just as much excitement just watching the Twittersphere today and watching #tela09 tags! And my feet are killing me. So be glad you’re sitting at your computer instead of walking around Los Angeles! Let me give you some highlights for Office developers:

Watch the Keynotes which include Office 2010 demos. Also some interviews on Office and SharePoint on the same TechEd site.

Office 2010 The Movie: Countdown to Awesome is the new site where you can watch a slick video and more importantly, click the Sign up for the Microsoft Office 2010 Technology Preview. When you click the link they show you the “fine print” which I will now print in large font:

By registering you are signing up to be considered for the Technical Preview Program, you will be waitlisted for consideration to be invited into the Technical Preview Program. We will notify invitees in early to mid July.

“What does that mean?” you ask. Well, it means that Microsoft wants to collect a wide variety of customer-types and ensure that our TechPreview covers all the different types of customers. For example, the sign-up form asks if you will test the Tech Preview at Home or Work. Be honest in your answer because we truly want to get perspectives from all types of Office users. Similarly the survey asks the size of your company and if you read Japanese. There is no trick to get invited.

If you don’t get invited, then don’t fret. We’ll give you some useful information on this blog and other Office blogs to help you prepare your business for the future. For now, I encourage you to build great solutions for Office using all of the resources at Microsoft including Visual Studio, VBA, Open XML SDK, code samples, Forum support, Code Gallery, and the Office Developer Center.

Sincerely, Christin Boyd, Program Manager

Developing for Office and SharePoint Server 2010 (Christin Boyd)

VSTO Team — Fri, 01 May 2009 23:08:42 GMT

I get a lot of questions about the future.

When will Office and SharePoint release? First half of 2010.
Is VSTO part of Microsoft’s long term strategy? Yes! The Office tools shipped in VS 2008 and will ship in VS 2010 with lots of cool new improvements. We strongly encourage and support .NET development on the Office and SharePoint platforms.
Will there be better Team Development tools for Office and SharePoint developers? Yes! Future blog posts will tell you more.
Are there any pricing changes? See below note on SharePoint Designer.
Can I get Office 2010 Beta or SharePoint Server 2010 Beta? Yes, eventually. A few thousand enterprises, small businesses, developers, ISVs, Partners, schools and families have been invited to join an early private “technical preview” beta, and the rest of the world will get to test a later public beta. No dates have been announced. Read the Computer World article on the Office Beta.
Should I sanitize my keyboard to prevent the H1N1 flu? Yes, but don’t put it in the dishwasher like my internship roommate did after a cola spill. It was hilarious, and half the keys still worked!

In the coming months you will see a few more blog posts about the future and plenty of blog posts about developing today with Visual Studio 2008. For now, I’d like to review all of the official posts that Microsoft has released about developing SharePoint Server 2010 solutions:

Press Release on SharePoint Server 2010

SharePoint Designer is now FREE

Soma’s blog post “SharePoint tools support in Visual Studio”

Official Visual Studio 2010 home page

PDF of the Official Visual Studio 2010 Product Overview

Channel9 Interview with the Lead Program Manager designing the Office and SharePoint tools in VS 2010

If I’ve forgotten any of the official Microsoft announcements in this post, then please leave a comment with a link. Thanks!

-Christin Boyd, Program Manager

My Word Add-In Creates Duplicate Menu Items. Make it Stop! (Norm Estabrook)

VSTO Team — Fri, 06 Mar 2009 20:33:19 GMT

So I want my add-in to place a custom command into the shortcut menu. The shortcut menu is that cool menu that appears when you right-click a document. Great, so I read some articles in MSDN, write some code, run the add-in and voila there it is! I give it to my buddy, he is proud of my accomplishment and and installs my add-in. Now he hates me because every time he opens up Word, a duplicate menu appears. Where did I go wrong?

Well actually, I didn’t do anything wrong. It’s just that Word requires a little more attention when it comes to handling menus. I guess you can say that Word is a bit more “needy” than other Office applications. But being “higher maintenance” does not have to mean “higher maintenance costs”. Hopefully this post will get your friend talking to you again.

My code

Here is the code that did not work for me. BTW – I will paste in both Visual Basic and C# examples for this post.

[Visual Basic]

Private MyApplication As Word.Application
Private WithEvents myControl As Office.CommandBarButton

Private Sub ThisAddIn_Startup _
(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

    MyApplication = Me.Application
    AddMenuItem()

End Sub

Private Sub AddMenuItem()

    Dim menuItem As Office.MsoControlType = _
        Office.MsoControlType.msoControlButton

    myControl = CType(MyApplication.CommandBars("Text").Controls.Add _
       (menuItem, 1, True), Office.CommandBarButton)

    myControl.Style = Office.MsoButtonStyle.msoButtonCaption
    myControl.Caption = "My Menu Item"
    myControl.Tag = "MyMenuItem"

End Sub


Sub myControl_Click(ByVal Ctrl As Microsoft.Office.Core.CommandBarButton, _
                    ByRef CancelDefault As Boolean) Handles myControl.Click

    System.Windows.Forms.MessageBox.Show("My Menu Item clicked")

End Sub

[C#]

private Word.Application myApplication;
private Office.CommandBarButton myControl;

private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
    myApplication = this.Application;
    AddMenuItem(); 
}
 
private void AddMenuItem()
{
   Office.MsoControlType menuItem = 
        Office.MsoControlType.msoControlButton;

    myControl = 
        (Office.CommandBarButton)myApplication.CommandBars["Text"].Controls.Add
        (menuItem,missing, missing, 1, true);

    myControl.Style = Office.MsoButtonStyle.msoButtonCaption;
    myControl.Caption = "My Menu Item";
    myControl.Tag = "MyMenuItem";

    myControl.Click += 
        new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler
            (myControl_Click);

}

void myControl_Click(Microsoft.Office.Core.CommandBarButton Ctrl, 
    ref bool CancelDefault)
{
    System.Windows.Forms.MessageBox.Show("My Menu Item clicked");
}

Why my code does not work as expected

Here is one issue I can see right off the bat. Note this line of code for adding a control:

myControl = CType(MyApplication.CommandBars("Text").Controls.Add _ (menuItem, 1, True), Office.CommandBarButton)

I set the last parameter of the Add method to True. This value specifies that I want my control to be temporary. I am trying to tell Word not to save the control so that duplicate menu items won’t be added every time Word opens. Only there is a problem here. Word ignores this parameter (at least for controls in a CommandBar collection anyway). So I can keep it set to true, but it really means false. Lovely.

So what is happening? Well, Word is actually saving your new menu command to the Normal.dot template every time a new instance of Word opens – hence the duplicates.

What can I do about this?

There are probably a billion creative ways to stop the duplicate menus from appearing, but here are three tips that work really well. Here they are:

Check for duplicates before adding an item (control) to a menu.
Always set the customization context of the application to the same document or template before adding or deleting a control.
Because there are no temporary commands in Word, use a custom template to save the commands.

Tip # 1: Check for Duplicates:

This one is pretty easy. Just add code to your add-in that looks for a control that has the same tag as the control you are about to add. If one exists, perform one of the following actions:

Don’t add the control (It is already there).
Delete the control. Then you can add it.

I modified my code to delete the control. Here is my code.

[Visual Basic]

Private Sub RemoveExistingMenuItem()

    Dim contextMenu As Office.CommandBar = _
    MyApplication.CommandBars("Text")

    MyApplication.CustomizationContext = customTemplate

    Dim control As Office.CommandBarButton = contextMenu.FindControl _
        (Office.MsoControlType.msoControlButton, System.Type.Missing, _
         "MyMenuItem", True, True)

    If Not (control Is Nothing) Then
        control.Delete(True)
    End If

End Sub

[C#]

private void RemoveExistingMenuItem()
{
    Office.CommandBar contextMenu = myApplication.CommandBars["Text"];
    myApplication.CustomizationContext = customTemplate;

    Office.CommandBarButton control = 
        (Office.CommandBarButton)contextMenu.FindControl
        (Office.MsoControlType.msoControlButton, missing,
        "MyMenuItem", true, true);

    if ((control != null))
    {
        control.Delete(true);
    }

}

Tip #2: Set the Customization Context

The customization context of the application tells Word where to save your customizations. To specify the customization context, set the CustomizationContext property of the Application object.

By default, Word uses the Normal.dot template as it’s customization context. This is not reliable and can change. If you do not explicitly set the context, you might search for controls saved to one context such as a document, delete controls from another context such as a custom template and then add the control to another context such as Normal.dot.

To avoid these issues, always set the customization context of the application to the same document or template every time you search for, delete, or add controls to a menu.

Note that in a Word document-level customization, it is probably best to set the customization context to the active document. That way when the user uninstalls the customization, the document and the menu commands that pertain to that document disappear as expected.

In Word application-level add-in, the best practice is to use a custom template for reasons mentioned later on in this post.

In the following example, I highlighted in bold the line that sets the customization context. Further along in this post, I will show you where I got customTemplate.

[Visual Basic]

Private Sub AddMenuItem()

    MyApplication.CustomizationContext = customTemplate

    Dim menuItem As Office.MsoControlType = _
        Office.MsoControlType.msoControlButton

    myControl = CType(MyApplication.CommandBars("Text").Controls.Add _
       (menuItem, 1, True), Office.CommandBarButton)

    myControl.Style = Office.MsoButtonStyle.msoButtonCaption
    myControl.Caption = "My Menu Item"
    myControl.Tag = "MyMenuItem"
    customTemplate.Saved = True

    GC.Collect()

End Sub

[C#]

private void AddMenuItem()
{
    myApplication.CustomizationContext = customTemplate;
    Office.MsoControlType menuItem = 
        Office.MsoControlType.msoControlButton;

    myControl = 
        (Office.CommandBarButton)myApplication.CommandBars["Text"].Controls.Add
        (menuItem,missing, missing, 1, true);

    myControl.Style = Office.MsoButtonStyle.msoButtonCaption;
    myControl.Caption = "My Menu Item";
    myControl.Tag = "MyMenuItem";

    myControl.Click += 
        new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler
            (myControl_Click);

    customTemplate.Saved = true;

    GC.Collect();

Also – a quick tip – set the Saved property of the template to true after you add the control. This stops that annoying prompt from appearing that asks if you would like to save your customizations to the template.

Tip #3: Use a Custom Template

It is very difficult to delete a control before the add-in shuts down. For example, if you attempt to delete a control in the ThisAddIn_Shutdown event handler, you will receive a not so helpful COM exception. You will get similar results in the Quit event of Word.

That is because the template that you are using as your application’s customization context is not writable in either of those event handlers. So if you cannot easily delete the control when Word closes, that means that the control will always live inside of the template.

This is a problem if you are using Normal.dot to persist the controls. Here is why. Let’s say the user decides that he does not want to see your command in a menu anymore. With a caption such as “My Menu Item”, can you really blame him? So the user uninstalls your add-in. However, the menu command still lives in Normal.dot! When that user opens his document in Word, "My Menu Item” still appears. Doooh! Here comes the support calls!

The way around this is to provide your own custom template to store customizations such as custom menus and menu items. Your setup application can remove the template along with add-in. That way when the user uninstalls the add-in, they also remove the template that contains the menu items.

In the following example, I retrieve a custom template from the users documents folder. Yes, your setup application will probably use a different location to place the custom template, but this is just for an example.

[Visual Basic]

Private Sub GetCustomTemplate()

    Dim TemplatePath As String = Environment.GetFolderPath _
        (Environment.SpecialFolder.MyDocuments) + "\MyCustomTemplate.dotx"
    Dim install As Boolean = True

    For Each installedTemplate As Word.Template In MyApplication.Templates
        If installedTemplate.FullName = DirectCast(TemplatePath, String) Then
            install = False
        End If
    Next

    If install = True Then
        MyApplication.AddIns.Add(TemplatePath.ToString(), True)
    End If

    customTemplate = MyApplication.Templates(TemplatePath)

End Sub

[C#]

private void GetCustomTemplate()
{
    object TemplatePath = Environment.GetFolderPath
        (Environment.SpecialFolder.MyDocuments) +
        "\\MyCustomTemplate.dotx";
    object install = true;

    foreach (Word.Template installedTemplate in myApplication.Templates)
    {
        if (installedTemplate.FullName == (string)TemplatePath)
        {
            install = false;
        }
    }
    if ((bool)install)
    {
        myApplication.AddIns.Add(TemplatePath.ToString(), ref install);
    }
    customTemplate = myApplication.Templates.get_Item(ref TemplatePath);

}

Drum roll please .. I present the complete example

To provide context, here is the complete sample:

[Visual Basic]

Public Class ThisAddIn

    Private MyApplication As Word.Application
    Private WithEvents myControl As Office.CommandBarButton
    Private customTemplate As Word.Template

    Private Sub ThisAddIn_Startup _
    (ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

        MyApplication = Me.Application

        GetCustomTemplate()
        RemoveExistingMenuItem()
        AddMenuItem()

    End Sub

    Private Sub GetCustomTemplate()
        Dim TemplatePath As String = Environment.GetFolderPath _
            (Environment.SpecialFolder.MyDocuments) + "\MyCustomTemplate.dotx"
        Dim install As Boolean = True

        For Each installedTemplate As Word.Template In MyApplication.Templates
            If installedTemplate.FullName = DirectCast(TemplatePath, String) Then
                install = False
            End If
        Next

        If install = True Then
            MyApplication.AddIns.Add(TemplatePath.ToString(), True)
        End If

        customTemplate = MyApplication.Templates(TemplatePath)

    End Sub

    Private Sub RemoveExistingMenuItem()

        Dim contextMenu As Office.CommandBar = _
        MyApplication.CommandBars("Text")

        MyApplication.CustomizationContext = customTemplate

        Dim control As Office.CommandBarButton = contextMenu.FindControl _
            (Office.MsoControlType.msoControlButton, System.Type.Missing, _
             "MyMenuItem", True, True)

        If Not (control Is Nothing) Then
            control.Delete(True)
        End If

    End Sub


    Private Sub AddMenuItem()

        MyApplication.CustomizationContext = customTemplate

        Dim menuItem As Office.MsoControlType = _
            Office.MsoControlType.msoControlButton

        myControl = CType(MyApplication.CommandBars("Text").Controls.Add _
           (menuItem, 1, True), Office.CommandBarButton)

        myControl.Style = Office.MsoButtonStyle.msoButtonCaption
        myControl.Caption = "My Menu Item"
        myControl.Tag = "MyMenuItem"
        customTemplate.Saved = True

        GC.Collect()

    End Sub

    Sub myControl_Click(ByVal Ctrl As Microsoft.Office.Core.CommandBarButton, _
                        ByRef CancelDefault As Boolean) Handles myControl.Click

        System.Windows.Forms.MessageBox.Show("My Menu Item clicked")

    End Sub

    Private Sub ThisAddIn_Shutdown() Handles Me.Shutdown

    End Sub

End Class

[C#]

public partial class ThisAddIn
{
    private Word.Application myApplication;
    private Office.CommandBarButton myControl;
    private Word.Template customTemplate;

    private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
        myApplication = this.Application;

        GetCustomTemplate();
        RemoveExistingMenuItem();
        AddMenuItem();
    }

    private void GetCustomTemplate()
    {
        object TemplatePath = Environment.GetFolderPath
            (Environment.SpecialFolder.MyDocuments) +
            "\\MyCustomTemplate.dotx";
        object install = true;
        foreach (Word.Template installedTemplate in myApplication.Templates)
        {
            if (installedTemplate.FullName == (string)TemplatePath)
            {
                install = false;
            }
        }
        if ((bool)install)
        {
            myApplication.AddIns.Add(TemplatePath.ToString(), ref install);
        }
        customTemplate = myApplication.Templates.get_Item(ref TemplatePath);

    }

    private void RemoveExistingMenuItem()
    {
        Office.CommandBar contextMenu = myApplication.CommandBars["Text"];
        myApplication.CustomizationContext = customTemplate;

        Office.CommandBarButton control =
            (Office.CommandBarButton)contextMenu.FindControl
            (Office.MsoControlType.msoControlButton, missing,
            "MyMenuItem", true, true);

        if ((control != null))
        {
            control.Delete(true);
        }

    }

    private void AddMenuItem()
    {
        myApplication.CustomizationContext = customTemplate;
        Office.MsoControlType menuItem =
            Office.MsoControlType.msoControlButton;

        myControl =
            (Office.CommandBarButton)myApplication.CommandBars["Text"].Controls.Add
            (menuItem, missing, missing, 1, true);

        myControl.Style = Office.MsoButtonStyle.msoButtonCaption;
        myControl.Caption = "My Menu Item";
        myControl.Tag = "MyMenuItem";

        myControl.Click +=
            new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler
                (myControl_Click);

        customTemplate.Saved = true;

        GC.Collect();

    }

    void myControl_Click(Microsoft.Office.Core.CommandBarButton Ctrl,
        ref bool CancelDefault)
    {
        System.Windows.Forms.MessageBox.Show("My Menu Item clicked");
    }
    private void ThisAddIn_Shutdown(object sender, System.EventArgs e)
    {
    }
}

Now you can issue a patch to your buddy so that he has only one “My Menu Item” appearing in his shortcut menu. Although .. I am not sure what “My Menu Item” is really suppose to do …