HOWTO: AddIn Deployment with Shim for Framework1.1 & Framework2.0

R

Rob Lorimer

HOWTO: AddIn Deployment with Shim

In case it matters, my target was a shared AddIn for Excel in Office 2003.

I used the articles describing the COM shim wizard

Creating the shim project:
http://msdn.microsoft.com/office/de...dno2k3ta/html/ODC_Office_COM_Shim_Wizards.asp

Deploying the shim and managed assembly:
http://msdn.microsoft.com/office/default.aspx?pull=/library/en-us/dnoxpta/html/odc_comshim.asp

NOTES:

1) 'Strong Naming'

Didn't know what this was but found a good tutorial at:
http://www.ondotnet.com/pub/a/dotnet/2003/04/28/strongnaming.html

The crux of this is to create your own key file at the Visual Studio command
prompt:

sn -k MyKeyFile.snk

then you modify your AssemblyInfo.cs file:

[assembly: AssemblyKeyFile("..\\..\\MyKeyFile.snk")]

Note that this is the full relative path from the compiled assembly to the
keyfile. (for VS2005, do it on the properties page under signing)


2) Referenced assemblies that aren't strong named.

If you reference an assembly that's not strong named, you'll get the
following error:

"Referenced assembly 'assemblyName' does not have a strong name"

If you have the source, you can recompile with a strong name as per note 1.
If you don't ie its third-party, and you can't convince the developer to
strong name it, all is not lost. You need to disassemble and then reassemble
it with a strong name. See:

http://andrewconnell.com/blog/archive/2004/12/15/772.aspx

Use the Visual Studio command prompt.
First disassemble the assembly:

ildasm thirdparty.dll /out:thirdparty.il

then reassemble it with a strong name:

ilasm thirdparty.il /dll /key=MyKeyFile.snk

(note: your original assembly will be overwritten, so if you want to keep
the 'weak' version, make sure you copy it to another directly)


3) Compiling Shim

You have to make sure that the shim dll is built to the same directory as
your managed assembly ie both projects have the same output directory.

Part of the Shim build process is to actually register the shim (on your
development machine). You can actually register/unregister the shim as a
normal COM dll at the command prompt:

regsvr32 shim.dll (and regsvr32 /u shim.dll)

Your managed assembly should not be set to build for COM interop. If it is,
building it (the managed assembly) without the shim overwrites any previous
shim registration... and ... building the shim overwrites the managed
assembly registration. You can use this to your advantage during debugging.


4) What to deploy

The deployment link (above), stated to include the primary output of the
shim project and add the managed assembly as an Assembly ie

1. In the Solution Explorer, right-click on the newly created
HelloCOMAddInVBwShimSetup project.
2. Point to Add. Click Assembly. This displays the Component Selector
dialog box.
3. Click Browse and locate C:\COMAddInShimTutorial\HelloCOMAddInVB\bin.
4. Select HelloCOMAddInVB.dll. Click Open.

I found in some instances (particularly my Framework 2.0 version) that the
msi would error when the shim attempted to self register.

Although this method appears to work for VS2003, I found it better to
include the primary output from my managed assembly and reference the
shim.dll using the method described above. Note this means I swapped how you
add the managed assembly and the shim. I tried this after finding a
discussion about a VS bug that can cause the 'primary output' reference to
fail. (I hope this isn't too confusing)

Back to what to add ... the general rule of thumb is NOT to include any
assemblies that reside in the GAC or "C:\WINDOWS\Microsoft.NET\..." eg

Microsoft.Office.Interop.Excel.dll (GAC)
Microsoft.Vbe.Interop.dll (GAC)
office.dll (GAC)
stdole (GAC)
System.Window.Forms (C:\WINDOWS\Microsoft.NET\...)
etc...

Unfortunately, the deployment project adds these automatically. You need to
right click each and choose to exclude.

Note that if any of your projects reference office2003 interop assemblies
that aren't pointing to the GAC, you're likely to encounter deployment
problems. Use the following link to fix this:

http://msdn.microsoft.com/office/de...ta/html/officeprimaryinteropassembliesfaq.asp


Extensibility, Extensibility, Extensibility, Extensibility!

The only .Net dll required is extensibility. Note that this was added to my
deployment project automatically in VS2003 but not in VS2005 Beta 1!

If any third-party or owner-built assemblies are referenced by your managed
assembly, they should automatically appear in the deployment project.


I hope this is helpful to someone else ... I had quite a job sorting things
myself (No one article describes all this) But the result is that I know how
to deploy a shimmed addin for office in both framework 1.1 and framework 2.0
 
R

Rob Lorimer

Did some more testing.

It appears that the COM Interop setting in the managed project has no affect
on the deployed project ... I've decided to leave selected to make debugging
easier.

Rob Lorimer
 
P

Peter Huang [MSFT]

Hi Rob,

Thanks for your great and detailed knowledge sharing in the community, I
believe many will benefit from your experience.
Also the managed project's register for com interop option is used to
register the current dll into local machine's registry, So it have no
influent on the deployed machine.
It should be the deployment project's job to register the information into
registry.

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top