D
David Thielen
Hi;
Ok, here is what I think happens. Please let me know if I am wrong:
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.
Q: 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.
Q: 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.
Q: 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.
Q: 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.
Q: 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.
Q: 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:
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.
Q: 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.
Q: 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.
Q: 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.
Q: 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.
Q: 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.
Q: 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