D
David Thielen
Hi;
Ok, here is what I think happens. Please let me know if I am wrong
(also 6 questions interspersed). TIA.
1) Add-ins are listed in [HKLM |
HKCU]/Software/Microsoft/Office/Word/Addins. The critical things here
is the name of the key - such as AutoTag.Connect and the LoadBehavior
DWORD.
2) To load that add-in, it then goes to HKCR/name -
HKCR/AutoTag.Connect in my case and gets the CLSID subkey value.
Q1: For my shim there is a HKCR/AutoTagAddInShim.Connect key with a
CLSID and a CurVer subkey. The CurVer subkey has a value of
AutoTagAddInShim.Connect.1. Then there is an
AutoTagAddInShim.Connect.1 key with a CLSID subkey. Both CLSID subkeys
have the same GUID. WHat is all of this about?
3a) Managed code: From the CLSID, you then go to HKCR/CLSID\{GUID}
where {GUID} is the CLSID from step 2. In this key you go to
InprocServer32/3.0.10.0 where it has a bunch of values including
CodeBase which is the location of the AutoTag.dll file. This gives
Word the file to load.
Q2: When there are multiple versions under InprocServer32, how does it
know which to load? Does it always load the latest version?
3b) Shim code: From the CLSID, , you then go to HKCR/CLSID\{GUID}
where {GUID} is the CLSID from step 2. In this key you go to
InprocServer32 - no version subkey. And the default value is the
location of the DLL.
Q3: Are these differences due to managed vs unmanaged code? And does
this mean Word understands they are managed vs unmanaged?
4) When VisualStudio is building the add-in, if the properties for the
add-in in Build/Register for COM Interop is set to true, then when it
finishes the build it sets the two HKCR nodes in the registry for the
latest version. It does not touch the HKLM | HKCU setting. By doing
this, if the HKLM | HKCU setting is already there, the just built
version is what will be run as it specifies the location of the dll
file.
Q4: Is there any reason to not have both the managed dll and the shim
register for COM upon completion of the build? This means each can be
accessed by Word or other applications - but this registering by
itself does not do anything.
Q5: In Visual Studio for the shim properties if I set
Linker/General/Register Output to true which sets the CLSID stuff, as
long as only 1 of my classes (the managed code or the shim) is in the
add-ins part of the registry - then only one instance gets loaded.
Q6: When my add-in is installed it says the shim will self-register.
It has the information to do so in it's rgs file and it is successful
doing so. But when/how is that done?
5) If you want to debug the shim, you need to turn debug unmanaged
code on in the debugger properties for the managed (not shim) code. It
then breaks in the shim too. But do not turn this on unless you need
it - it's about 5 times slower running.
I think this explains the whole registry/load scenario. Please sing
out if I have anything wrong or missed anything.
thanks - dave
Ok, here is what I think happens. Please let me know if I am wrong
(also 6 questions interspersed). TIA.
1) Add-ins are listed in [HKLM |
HKCU]/Software/Microsoft/Office/Word/Addins. The critical things here
is the name of the key - such as AutoTag.Connect and the LoadBehavior
DWORD.
2) To load that add-in, it then goes to HKCR/name -
HKCR/AutoTag.Connect in my case and gets the CLSID subkey value.
Q1: For my shim there is a HKCR/AutoTagAddInShim.Connect key with a
CLSID and a CurVer subkey. The CurVer subkey has a value of
AutoTagAddInShim.Connect.1. Then there is an
AutoTagAddInShim.Connect.1 key with a CLSID subkey. Both CLSID subkeys
have the same GUID. WHat is all of this about?
3a) Managed code: From the CLSID, you then go to HKCR/CLSID\{GUID}
where {GUID} is the CLSID from step 2. In this key you go to
InprocServer32/3.0.10.0 where it has a bunch of values including
CodeBase which is the location of the AutoTag.dll file. This gives
Word the file to load.
Q2: When there are multiple versions under InprocServer32, how does it
know which to load? Does it always load the latest version?
3b) Shim code: From the CLSID, , you then go to HKCR/CLSID\{GUID}
where {GUID} is the CLSID from step 2. In this key you go to
InprocServer32 - no version subkey. And the default value is the
location of the DLL.
Q3: Are these differences due to managed vs unmanaged code? And does
this mean Word understands they are managed vs unmanaged?
4) When VisualStudio is building the add-in, if the properties for the
add-in in Build/Register for COM Interop is set to true, then when it
finishes the build it sets the two HKCR nodes in the registry for the
latest version. It does not touch the HKLM | HKCU setting. By doing
this, if the HKLM | HKCU setting is already there, the just built
version is what will be run as it specifies the location of the dll
file.
Q4: Is there any reason to not have both the managed dll and the shim
register for COM upon completion of the build? This means each can be
accessed by Word or other applications - but this registering by
itself does not do anything.
Q5: In Visual Studio for the shim properties if I set
Linker/General/Register Output to true which sets the CLSID stuff, as
long as only 1 of my classes (the managed code or the shim) is in the
add-ins part of the registry - then only one instance gets loaded.
Q6: When my add-in is installed it says the shim will self-register.
It has the information to do so in it's rgs file and it is successful
doing so. But when/how is that done?
5) If you want to debug the shim, you need to turn debug unmanaged
code on in the debugger properties for the managed (not shim) code. It
then breaks in the shim too. But do not turn this on unless you need
it - it's about 5 times slower running.
I think this explains the whole registry/load scenario. Please sing
out if I have anything wrong or missed anything.
thanks - dave