COM Shared Add-in Creation (Whole Document - Final)

Creating COM Shared Add-in Whole Document in Jpg Format

COM Shared Add-in Creation (Whole document - Part 2)

Creating Com Shared Add-in Whole document in Jpg format

COM Shared Add-in creation (Whole document - Patr 1)

Creating COM Shared Add-in whole document in Jpg format.

COM Shared Add-in (Final)

Build the MSI and Redistribute it

Now that you are done including all the needed files, excluding the unneeded files, and resetting properties for the setup project, you are ready to build an MSI.

To do this,

1. Right-click the SampleAddin project, and then click Build.

2. Right-click the AddinShim project, and then click Build.

3. Right-click the Setup project, and then click Build.

4. Now your ready to run your application in any machine with office 2000+ installed.[basic version , with no service packs at all ]

5. Now to congratulate yourself on your great success cry aloud “I ve donnnnittt” J

COM Shared Ad-in (Part 8)

Using the Wizard for Managed COM Add-Ins: A Walkthrough Exercise

Download COMShimWizardSetup.msi, which contains the wizard as well as the Sample HelloWorld Application.

The COM Shim Wizard behavior described in this walkthrough exercise is representative of all five of the extension types.

In this exercise, you create an example shim for a managed IDTExtensibility2 COM add-in. This is the most commonly used type of managed Microsoft Office extension, and it requires the most input from the developer to establish the precise registry requirements.

1. After you install the COM Shim Wizard, start Visual Studio 2005. On the File menu, point to New, and then click Project. In the New Project dialog box, expand the Visual C++ Projects node, and select the child node, COM Shims, as shown in Figure 1.

Figure 1. Selecting the Addin Shim project in Visual Studio 2005 (click picture to see larger image)

2. Select Addin Shim, and specify a name and location. For this exercise, you can accept the default name and location. Click OK. The wizard runs the COMShimHarvester component, which displays the Specify the Managed Add-in Assembly page of the COM Shim Wizard.
3. If you know the full path to the managed extension assembly for which you want to create a shim, you can type it into the first text box. Alternatively, click Browse and navigate to the assembly. For this exercise, you can use the sample add-in (TestAddin.dll) provided with the download.
4. Select the assembly, TestAddin.dll, and click Open. The COMShimHarvester opens the assembly (by way of the AppDomainHarvester helper assembly), harvests information, and populates the text boxes in this page of the wizard.
5. The COMShimHarvester component of the wizard harvests the name and public key token of the assembly and the name of the class that implements IDTExtensibility2. By default, it also uses the original GUID and ProgId values, as shown in Figure 2.

Figure 2. Harvested assembly information with the original GUID and ProgId

Note If for some reason you do not want to use the same GUID and ProgId values for your shim as for your add-in, clear the check box for this option. If you clear the check box, the COMShimHarvester generates new values. But, we recommend that you reuse the original GUID and ProgId instead of the wizard-generated ones. If you do not, then both the managed extension assembly and the shim DLL are registered. In this situation, your tests pick up one or the other, depending on the GUID and ProgId you use in your test harnesses. This is usually not desired behavior.

6. Click Next to open the Add-in Details page of the wizard, in which you can specify additional information to enter into the registry (Figure 3). This information includes a suitable description and friendly name, the load behavior of the add-in, and the list of target host applications.
7. By default, the wizard sets the add-in to load when the Microsoft Office application starts. This effectively sets the registry LoadBehavior to 3. You can change this if you want a different setting. Also by default, the wizard uses the fully qualified type name of the class that implements the target interface as the basis for both the description and friendly name. You can change these, as appropriate, for your project. Figure 3 shows the Add-in Details page with user-specified choices completed.

Figure 3. Specifying registry information for the add-in

8. Click Next to display the Summary page of the wizard, which summarizes the choices you made (Figure 4).

Figure 4. Wizard summary page for new add-in assembly

9. Click Finish to generate the new shim project and code. In the Visual Studio Solution Explorer, the shim project should include approximately 15 source files, as shown in Figure 5. The exact number of files varies according to the type of extension for which you are developing a shim.

Figure 5. Source files for the add-in shim project

To validate that the solution is working as expected with the shim in place, you should exercise your full test schedule. Before you can do this, however, there is one manual step that you must take. Important :-

The wizard cannot make any assumptions about where you deploy the add-in solution, but because the shim currently requires the extension assembly to be either in the same folder as the shim or to be deployed to the global assembly cache, you should copy or move the extension assembly to the same folder as the shim before you test the solution.

To do this you need to do the following

1. In the solution explorer right click the Shim Project
2. Click the properties
3. It will open the Property Pages, In general change the OuputDirectory to the Release folder of add-in DLL.
4. Click ok.

· Sign the Shim Project with a Strong Name Key

To do this you need to do the following

2. In the solution explorer right click the Shim Project

3. Click the properties

4. It will open the Property Pages, under Linker click the advanced tab.

5. In the keyfile option give : $(ProjectDir)/YourShimKey.snk[make sure that the keyfile is duly created and placed in the Project Directory]

6. Click ok to exit.

Your next step is to modify the setup project so that you can deploy the product in the target machines.

· Remove the existing Primary Output of the Add-in Project.

· Add assembly to the setup and deployment project

The managed COM add-in DLL is one of the files that needs to be included in the setup and deployment project. To do this:

1. In the Solution Explorer, right-click on the newly created Setup project.
2. Point to Add. Click Assembly. This displays the Component Selector dialog box.
3. Click Browse and locate ..\bin\release\.[of your project]
4. Select sampleAddin.dll. Click Open.

sampleAddin.dll is now added to the Selected Components edit box in the Component Selector dialog box. Click OK.

· Add project output to the setup and deployment project

Make the COM add-in shim the primary output of the setup and deployment project. The shim will be the signed unmanaged component that will be registered.

1. In the Solution Explorer, right-click the Setup project.
2. Point to Add. Click Project Output. This displays the Add Project Output Group dialog box.
3. In the Project drop-down menu, select AddInShim.
4. In the list box, click Primary Output.
5. Click OK.

· Set the primary output registration property

The signed COM add-in shim registration details need to be added to the registry. The keys and values that need to be registered are specified in the ConnectProxy.rgs files. These keys and values are then compiled into the DLL file to enable a process known as self registration to be performed, which is usually handled by the regsvr32 utility. To enable self registration to be performed from within the installation package, the Register property of the smart tag shim must be set to vsdrpCOMSelfReg.

1. In the Solution Explorer, under the Setup project node, right-click Primary Output from AddInShim and then click Properties to view its property details.
2. In the Properties box, in the Register drop-down menu, select vsdrpCOMSelfReg.

· Set the assembly registration property

The managed COM add-in doesn't need to be registered for COM interop since it will be called from within the shim.

1. Under the Setup project node, right-click sampleAddin.dll and then click Properties to view its property details.
2. In the Properties box, under the Register drop down menu, make sure vsdraDoNotRegister is selected.

COM Shared Add-in (Part 7)

COM Shim to Produce Managed COM Add-in

The shim is a Microsoft Visual C++ Active Template Library (ATL) COM DLL. It exposes a COM-creatable class that acts as a proxy to the real managed extension class. The COM Shim Wizard registers the CLSID and ProgId for this class in the registry. In the case of COM add-ins and smart tags, the wizard also registers this class against all target Microsoft Office applications that you choose. When the host Office application starts, it checks the registry to see which add-ins and smart tags to load, and then uses standard COM object creation to instantiate the registered proxy class. This action loads the COM shim DLL that is registered to proxy one of the add-ins or smart tags.

When the COM shim is loaded and the proxy class is created, the proxy class in turn creates an instance of a second class: the CLR loader class. The CLR loader object loads the Microsoft .NET Framework common language runtime (CLR). It then creates an application domain and loads the managed extension assembly into the new application domain. It creates an instance of the managed extension class that implements the target interface (that is, IDTExtensibility2, ISmartTagRecognizer and/or ISmartTagAction, or IRtdServer) and caches the interface pointer. Subsequently, any calls from Office into this interface are handled first by the proxy class. The proxy class passes those calls on through the cached pointer to the actual extension class in the managed extension assembly.

COM Shared Add-in (Part 6)

Shared add-in support update for .Net Framework 2.0

To get the project working you need to do some more steps, i.e. get the shared add-in support update for .Net Framework 2.0 which solves the issue of Add-in not loading in target machines.

This update adds a new Shared Add-in Support Update for the Microsoft .NET Framework 2.0 (KB908002) option to the Visual Studio 2005 prerequisites list. When you create a Setup project of a managed add-in, smart document, or smart tag, you must enable this option in the Setup project that will include the required redistributable updates to Office and to the .NET Framework.

To resolve this problem for Visual Studio 2005 developers, a redistributable version of the update for Visual Studio 2005 is available.

The following file is available for download from the Microsoft Download Center:
Download the VS2005-KB908002-ENU-x86.EXE package now.

After you install this update, whenever you create a shared add-in project in Visual Studio 2005, you must include the Shared Add-in Support Update for the Microsoft .NET Framework 2.0 (KB908002) option among the prerequisites in the solution Setup project. To do this, follow these steps:

1. In Solution Explorer, right-click the solution Setup project, and then click Properties.

2. Click Prerequisites.

3. Click to select the Shared Add-in Support Update for the Microsoft .NET Framework 2.0 (KB908002) check box.

Now test the application in the development machine and verify that all is working fine.

Thus we are ready for deployment , though there are other blogs and forums suggesting different ways of deploying the add-in, using a managed add-in shim is the most feasible solution.