T
teddyJam
Hello,
I have written an add-in for word & excel. For quite some time now I've
been reading about COM Shims and have been aware of what I need to do
once the add-in is finished. I've read the article on MSDN regarding
deployment of com add-ins with the shim solution and have downloaded
the odc_comshim package. I have followed the instructions word for word
and for the life of me I can't get the add-in to work. I couldn't even
get the demo (HelloCOMAddInVB) to work so although I have done it a
million times and know the procedure back to front so I'm obviously
missing something.
These are the steps that I've taken:
1. Add the COM Shim project
2. Set the COM Shim project properties (rename the output dll etc)
3. Set the name of my assembly and public key token in ShimConfig.cpp
4. Generate 2 sets of GUIDs and replace the ones in COMAddInShim.idl
5. Replace the CLSIDs in ConnectProxy.rgs with the 2nd generated GUID
6. Add ProgID registration details to ConnectProxy.rgs
7. Rebuild solutions
8. signcode the Shim dll
9. Create deployment project and add my assembly (set to not register
for COM)
10. Add COM Shim project output (set to self register for COM)
11. Install on a machine.
After doing this several thousand times I've run out of ideas. And from
what I've been able to dig up on blogs regarding that MSDN article,
there doesn't seem to be any mistakes in the instructions provided by
MSDN so I must be doing something wrong.
I ran a registry monitor so I can see what registry keys are being
accessed by winword (for example) to try and see where the missing link
is and I found the following (and I'll use the HelloCOM example because
I tried that last):
when winword initially opens the
HKCU\Software\Microsoft\Addins\HelloCOMAddInVBShim.Connect it then
looks for the HKCR\HelloCOMAddInVB.Connect key which is non existent.
Instead (and again I was strictly following the MSDN instructions)
there is of course the HKCR\HelloCOMAddInVB.ConnectProxy and
ConnectProxy.1 keys so basically that's where winword gives up and
can't find the right keys to load the dll.
I'm no expert when it comes to this but my understanding is that from
that key that resides in HKCU, the host application then looks up its
corresponding key in HKCR, opens the CLSID key and uses its value to
access the HKCR\CLSID\{...}\InprocServer etc and eventually grabs the
path to the dll and loads it (I realise this is probably a gross
generalisation but that's all I've been able to piece together).
I don't know how much of this makes sense but I'm hoping that it does
to at least one person out there because I've hit the end of the road.
If anyone can make a suggestion or at least put me in the right
direction I will be very appreciative (not to mention extremely
excited).
Kind regards,
Ted Zafirov.
I have written an add-in for word & excel. For quite some time now I've
been reading about COM Shims and have been aware of what I need to do
once the add-in is finished. I've read the article on MSDN regarding
deployment of com add-ins with the shim solution and have downloaded
the odc_comshim package. I have followed the instructions word for word
and for the life of me I can't get the add-in to work. I couldn't even
get the demo (HelloCOMAddInVB) to work so although I have done it a
million times and know the procedure back to front so I'm obviously
missing something.
These are the steps that I've taken:
1. Add the COM Shim project
2. Set the COM Shim project properties (rename the output dll etc)
3. Set the name of my assembly and public key token in ShimConfig.cpp
4. Generate 2 sets of GUIDs and replace the ones in COMAddInShim.idl
5. Replace the CLSIDs in ConnectProxy.rgs with the 2nd generated GUID
6. Add ProgID registration details to ConnectProxy.rgs
7. Rebuild solutions
8. signcode the Shim dll
9. Create deployment project and add my assembly (set to not register
for COM)
10. Add COM Shim project output (set to self register for COM)
11. Install on a machine.
After doing this several thousand times I've run out of ideas. And from
what I've been able to dig up on blogs regarding that MSDN article,
there doesn't seem to be any mistakes in the instructions provided by
MSDN so I must be doing something wrong.
I ran a registry monitor so I can see what registry keys are being
accessed by winword (for example) to try and see where the missing link
is and I found the following (and I'll use the HelloCOM example because
I tried that last):
when winword initially opens the
HKCU\Software\Microsoft\Addins\HelloCOMAddInVBShim.Connect it then
looks for the HKCR\HelloCOMAddInVB.Connect key which is non existent.
Instead (and again I was strictly following the MSDN instructions)
there is of course the HKCR\HelloCOMAddInVB.ConnectProxy and
ConnectProxy.1 keys so basically that's where winword gives up and
can't find the right keys to load the dll.
I'm no expert when it comes to this but my understanding is that from
that key that resides in HKCU, the host application then looks up its
corresponding key in HKCR, opens the CLSID key and uses its value to
access the HKCR\CLSID\{...}\InprocServer etc and eventually grabs the
path to the dll and loads it (I realise this is probably a gross
generalisation but that's all I've been able to piece together).
I don't know how much of this makes sense but I'm hoping that it does
to at least one person out there because I've hit the end of the road.
If anyone can make a suggestion or at least put me in the right
direction I will be very appreciative (not to mention extremely
excited).
Kind regards,
Ted Zafirov.