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
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