Office COM add-in / setup project / deployment

[Gary McGill]

I've read all the posts, I've searched the web, I've even looked at MSDN
but I've yet to find a decent description of how to use Visual Studio to
create a Setup package for an Office COM add-in that actually works. Is that
because it can't actually be made to work? That's the impression I get about
a lot of this stuff - Microsoft don't want to offer a description of how to
do it because they don't want to admit that, actually, it can't be done.
Instead, it seems to be better to let hundreds of poor schmucks like myself
waste hours and hours banging their heads off their desk...

Leaving aside the nightmare of the "shim" work-around which I haven't even
attempted yet, I've got pretty close to a working installer - after several
days (so much for the "wizard"!). If I run my setup program, nothing
actually works (my toolbar fails to appear in Word), BUT if I run "regasm"
on my DLL then hey presto - I get my toolbar at last.

My question is: why the heck do I have to manually run "regasm" myself???
What kind of cruddy Setup program is it that won't do that for me? And why
isn't this information available??? Sorry, I'm just so ANGRY!

 

[Mike Walker [MVP]]

Hi Gary

A couple of things to clarify, I appreciate your pains and as such is
annoying but there are a couple of things that will eliviate your problem
and as such is a must to make your installation a) work and b) be safe on
your client computers. - I think there is a high level discussion on using
the SHIM wizard and this is very important to be used but will then improve
the installation process as the SHIM wizard will register a COM Dll that
will load the CLR and load the managed code solution which then doesn't need
REGASM to be ran .

FYI - Shim wizard has undergone several versions and would advise to check
you have the latest version that being from
http://msdn.microsoft.com/library/en-us/dno2k3ta/html/ODC_Office_COM_Shim_Wizards.asp

Another important often missed DLL is the interop for Extensibility this is
important as this is the Interface to Office

I would work on the shim solution as this DLL Created can also be signed and
registered using normal installation REGSVR32 functionality.

Regards

Mike Walker MVP
Visual Developer VSTO
Please Reply via NG

 

[Gary McGill]

Mike,

Thanks very much for your post. I tried using the shim wizard following the
steps in this article, and that put me on the path to success.

For the benefit of the group, let me describe what else I had to do to
achieve my goal of having a setup program that will actually install the
darn thing, since installation isn't covered by this article. (I do so wish
there was a comprehensive, end-to-end article!).

After downloading the shim wizard and then finding that it didn't appear in
the VS project types list, I first of all had to install C++ which I hadn't
installed before because, after all, I'm developing C# apps!

Having then used the Wizard to create a shim project, I was left thinking
"well, what now? how do I install it?". I figured I must have to create a
new Setup project for the shimmed version of the add-in.

So, I created a new setup project, and added the primary output of the shim
project. The only output of this project was (by default) the shim DLL.
Since I knew that this DLL needed registered, I set the Register property to
vsdrpCOMSelfReg (this wasn't the default).

I guessed that the setup project wouldn't be much use if it didn't include
all the other DLL files from my main project, so I added the primary output
of my un-shimmed DLL project to the setup project. This automatically added
all the dependencies for me - although it actually added far more files than
were necessary. I manually excluded every DLL that wasn't one of mine
(getting rid of office.dll, stdole.dll, etc.) *except* extensibility.dll,
which I'd read is needed.

I then tried to remember what else was required in my Setup project, and
consulted my old (non-shimmed) Setup project to see what else I should do. I
found a whole bunch of registry keys in the Registry section of the Setup
project that appear under HKLM/Microsoft/Office/Word/Add-ins etc. I thought
I'd have to add those, but on further investigation I realised that the shim
project has a registry script that creates these during registration. So,
they don't need to appear in the Setup project.

Having done all that, I built the setup project and tried it out on another
machine. Hey presto, it worked! And what's more it worked without any manual
registering or suchlike! (Note that I haven't yet got around to signing the
shim DLL, so it wouldn't work with "high" macro security).

Note that when I started Word on my development machine and activated my
add-in, it promptly crashed. Subsequent attempts have been OK, so I'm not
sure what happened there. I am somewhat worried about the fact that I
already had a non-shimmed version installed and working, so I'm not sure if
there's any conflict there. (It's not entirely clear to me how I'm meant to
handle the setup on my development machine).

I have one remaining question. When I used the shim wizard, I had to select
a DLL file. I selected the DLL from the "bin\debug" directory of my
un-shimmed project, since that's what I've been building. What happens if I
want to build a non-debug version? Do I need to build a new setup project?

Thanks again,
Gary

 

[Mike Walker [MVP]]

Hi Gary - including typo fix

The main thing on the release version is the Strong name should be the same
so if you adjust your setup project to include the release files from the
Managed Code solution this should be fine. Additionally you can setup your
development environment to use the SHIMMED version and is advised as a
precaution the Managed Code addin will be using REGASM on rebuild/build of
the solution which will knock out the shim on the dev machine only, you can
goto properties of the ManagedCode project and untick regasm for this
project to alieviate that.

Can you post back your finding's online as this help's others appreciate the
work we do as MVP's as well as acknowledge the solutions help.

LOL on the install C++ though

Regards

Mike Walker MVP
Visual Developer VSTO
Reply via NG -

 

[Gary McGill]

Mike / Group,

I changed the "Register for COM interop" setting for my un-shimmed (managed)
DLL to False, as you suggested below to avoid the "knock-out".

I also changed the post-build step for the shim project so that instead of
registering the shim DLL in the project output directory, it copies it to
the project output directory of the un-shimmed (managed) DLL and registers
it there. (As the article you referred to explains, they have to be in the
same directory). The reason I decided to move the shim DLL rather than the
un-shimmed (managed) DLL is that my un-shimmed (managed) DLL uses lots of
other managed DLLs and so it's easier to copy the shim DLL than to copy all
those managed DLLs.

While this all works (hurrah!), there's a strange supplementary problem

My add-in uses a configuration file whose location is assumed to be
alongside the (managed) DLL itself. I get the location of the (managed) DLL
using:

System.Reflection.Assembly.GetExecutingAssembly().Location

This has always worked OK, and indeed it still works if I use the Setup to
install the add-in on another machine. HOWEVER, on my development machine,
it's looking for the config file in a *very* bizarre place, namely:

c:\documents and settings\gary\local settings\application
data\assembly\dl2\OIAoiOIJDOIJWAO.... (lots of gibberish)...
\mydll.dll.config

Any idea why this is the case?

Gary

 

[Mike Walker [MVP]]

Hi Gary

This is because in process the application base directory is the Excel.exe
or Winword.exe location, I think we use
Assembly.GetExecutingAssembly().CodeBase or Location property will help

Regards

Mike Walker MVP
Visual Developer VSTO
Reply via NG

 

[- B@rney]

I might be missing the point here, but I'll take a shot...

When I make a new Office Add-In, I create a new project in VS.NET 2003,
select Other Projects | Extensibility Projects and Shared Add-in.

Then I get all PIA's, Setup Project that works, basically all you need to
wire up a Office Add-In...

HTH