How an add-in starts - I think I have it

[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

 

[Peter Huang]

Hi,

Comments in line.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: How an add-in starts - I think I have it
thread-index: AcS6HZ05oro9bsjmTamUaRFU+/WYIQ==
X-WBNR-Posting-Host: 199.45.247.98
From: "=?Utf-8?B?RGF2aWQgVGhpZWxlbg==?=" <[email protected]>
Subject: How an add-in starts - I think I have it
Date: Sun, 24 Oct 2004 16:03:02 -0700
Lines: 62
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.office.developer.com.add_ins
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.office.developer.com.add_ins:6928
X-Tomcat-NG: microsoft.public.office.developer.com.add_ins

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.

Yes, you are correct.

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?

The progid.x(the x means the version) is for version control purpose. In
this scenario, the addin will load the version that is specified in the
CurVer subkey.
If you look into the IDL file of certain ATL Object in ATL project, you
will see the attribute.

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?

I think for one clsid, there will only one InprocServer32, or the com
service will do not know how to load the binary image.
For the managed Addin code, the com service will load the mscoree.dll and
then the mscoree.dll will load the managed code instead.
You may look into the reg file below.
[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32]
@="C:\\WINDOWS\\system32\\mscoree.DLL"
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"

And the other regstry key will tell the mscoree what assembly to load.

is the only one which tell the com service about how to load the com dll,
for all the managed code, the com service will load the mscoree first, and
then the mscoree to load the managed dll.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}]
@="WordAddin.Connect"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\Implemented
Categories]

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\Implemented
Categories\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32]
@="C:\\WINDOWS\\system32\\mscoree.DLL"
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"
"Class"="WordAddin.Connect"
"CodeBase"="C:\\Program Files\\Microsoft\\WordAddinSetup\\WordAddin.dll"
"InprocServer32"=hex(7):7c,00,72,00,31,00,2a,00,77,00,59,00,69,00,61,00,7e,0
0,\

64,00,41,00,44,00,61,00,6c,00,44,00,42,00,48,00,38,00,64,00,24,00,25,00,3e,\

00,2c,00,50,00,49,00,70,00,3d,00,43,00,65,00,77,00,52,00,5d,00,5b,00,5f,00,\
5a,00,24,00,24,00,75,00,43,00,2c,00,2e,00,6b,00,00,00,00,00
"RuntimeVersion"="v1.1.4322"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32\1.0.1761.26077]
"Class"="WordAddin.Connect"
"Assembly"="WordAddin, Version=1.0.1761.26077, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v1.1.4322"
"CodeBase"="file:///C:/Documents and
Settings/v-phuang/??/WordAddin/bin/Debug/WordAddin.DLL"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32\1.0.1761.29176]
"Class"="WordAddin.Connect"
"Assembly"="WordAddin, Version=1.0.1761.29176, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v1.1.4322"
"CodeBase"="file:///C:/Documents and
Settings/v-phuang/??/WordAddin/bin/Debug/WordAddin.DLL"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32\1.0.1762.25665]
"Class"="WordAddin.Connect"
"Assembly"="WordAddin, Version=1.0.1762.25665, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v1.1.4322"
"CodeBase"="file:///C:/Documents and
Settings/v-phuang/??/WordAddin/bin/Debug/WordAddin.DLL"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32\1.0.1762.27081]
"Class"="WordAddin.Connect"
"Assembly"="WordAddin, Version=1.0.1762.27081, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v1.1.4322"
"CodeBase"="file:///C:/Documents and
Settings/v-phuang/??/WordAddin/bin/Debug/WordAddin.DLL"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32\1.0.1762.27149]
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"
"Class"="WordAddin.Connect"
"CodeBase"="C:\\Program Files\\Microsoft\\WordAddinSetup\\WordAddin.dll"
"RuntimeVersion"="v1.1.4322"

[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\ProgID]
@="WordAddin.Connect"

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?

See above, word have no idea about if they are managed or not.

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.

Word load the addin based on the [HKLM |

HKCU]/Software/Microsoft/Office/Word/Addins, and the key will finally

point to one progid, and that progid will be mscoree.dll ( for managed one)
or the com shim (unmanaged one) or even a classical unmanaged com dll. We
can not specifed two both. because one clsid will be pointed to just one
libray(mscoree.dll , comshim.dll or else...)

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.

I think a word instance will only load one addin instance.

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?

When you build the shim dll, the ide will register the information into
registry based on that file.
.rgs file means registrar script file.
Regrgs.exe: Adds Entries to the Registry Using RGS File
http://support.microsoft.com/?id=220836

 

[David Thielen]

Hi;

Thank you - you answered a lot of this. A couple of follow on questions:

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?

I think for one clsid, there will only one InprocServer32, or the com
service will do not know how to load the binary image.
For the managed Addin code, the com service will load the mscoree.dll and
then the mscoree.dll will load the managed code instead.
You may look into the reg file below.
[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32]
@="C:\\WINDOWS\\system32\\mscoree.DLL"
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"

There is no HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}
in my registry.
And under
HKEY_CLASSES_ROOT\CLSID\{F076B0EA-FEE3-40E0-A576-4E68D13FAC75}\InprocServer32
(the CLSID for my add-in) there are four subkeys; 3.0.1.12733, 3.0.1.14548,
3..0.1.14886, and 3.0.12.0

See above, word have no idea about if they are managed or not.

But for the shim (unmanaged code) all the registry has in
HKEY_CLASSES_ROOT\CLSID\{c2f1fb6c-86e0-49a7-a423-1ab93deee94e}\InprocServer32
is the dll location as the default and the ThreadingModel.
For the managed code, it has mscoree.dll as the default for InprocServer32.
Is it possible (please don't guess - only tell me yes if you are sure) that
all Word uses in the InprocServer32 value and in the case if mscoree.dll it
then goes back to the registry to get the other registry settings?
And if so, does it use the sub keys that are by version number and if so,
how does it choose which one?

When you build the shim dll, the ide will register the information into
registry based on that file.
.rgs file means registrar script file.
Regrgs.exe: Adds Entries to the Registry Using RGS File
http://support.microsoft.com/?id=220836

Actually I meant when the installer is running to install my add-in on
another computer. In that case how does the infor in the .rgs file get placed
in the registry?

thanks - dave

 

[Peter Huang]

Hi

Thank you for your input, comments in line.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

Thread-Topic: How an add-in starts - I think I have it
thread-index: AcTAObCfx8mcGaQNRUC0BsbrWNG5lw==
X-WBNR-Posting-Host: 199.45.247.98
From: "=?Utf-8?B?RGF2aWQgVGhpZWxlbg==?=" <[email protected]>
References: <[email protected]>

Subject: RE: How an add-in starts - I think I have it
Date: Mon, 1 Nov 2004 09:39:08 -0800
Lines: 69
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.office.developer.com.add_ins
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.office.developer.com.add_ins:7043
X-Tomcat-NG: microsoft.public.office.developer.com.add_ins

Hi;

Thank you - you answered a lot of this. A couple of follow on questions:

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?

I think for one clsid, there will only one InprocServer32, or the com
service will do not know how to load the binary image.
For the managed Addin code, the com service will load the mscoree.dll and
then the mscoree.dll will load the managed code instead.
You may look into the reg file below.
[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32]
@="C:\\WINDOWS\\system32\\mscoree.DLL"
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"

There is no HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}
in my registry.
And under
HKEY_CLASSES_ROOT\CLSID\{F076B0EA-FEE3-40E0-A576-4E68D13FAC75}\InprocServer 32
(the CLSID for my add-in) there are four subkeys; 3.0.1.12733, 3.0.1.14548,
3..0.1.14886, and 3.0.12.0

The registry is the addin on my machine so the clsid is different, I paste
it just for demostrate the scenario.

But for the shim (unmanaged code) all the registry has in
HKEY_CLASSES_ROOT\CLSID\{c2f1fb6c-86e0-49a7-a423-1ab93deee94e}\InprocServer 32
is the dll location as the default and the ThreadingModel.
For the managed code, it has mscoree.dll as the default for InprocServer32.
Is it possible (please don't guess - only tell me yes if you are sure) that
all Word uses in the InprocServer32 value and in the case if mscoree.dll it
then goes back to the registry to get the other registry settings?
And if so, does it use the sub keys that are by version number and if so,
how does it choose which one?

I have confirmed with our senior engineer, you are correct, word just try
to load the mscoree.dll, the the clr will help to generate a wrap to
support the call between word and managed addin. As for the version, as the
registry key I post in my last post,
[HKEY_CLASSES_ROOT\CLSID\{E661AF83-1B16-4983-A64C-5E5FEDC0C4FC}\InprocServer
32]
@="C:\\WINDOWS\\system32\\mscoree.DLL"
"Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null"
"Class"="WordAddin.Connect"
"CodeBase"="C:\\Program Files\\Microsoft\\WordAddinSetup\\WordAddin.dll"
"InprocServer32"=hex(7):7c,00,72,00,31,00,2a,00,77,00,59,00,69,00,61,00,7e,0
0,\

64,00,41,00,44,00,61,00,6c,00,44,00,42,00,48,00,38,00,64,00,24,00,25,00,3e,\

00,2c,00,50,00,49,00,70,00,3d,00,43,00,65,00,77,00,52,00,5d,00,5b,00,5f,00,\
5a,00,24,00,24,00,75,00,43,00,2c,00,2e,00,6b,00,00,00,00,00
"RuntimeVersion"="v1.1.4322"
"ThreadingModel"="Both"

In the InprocServer32 key, there are many values
1. @="C:\\WINDOWS\\system32\\mscoree.DLL" //the loaded dll
2. "Assembly"="WordAddin, Version=1.0.1762.27149, Culture=neutral,
PublicKeyToken=null" //loaded assembly, the mscoree.dll will load the
version

Actually I meant when the installer is running to install my add-in on
another computer. In that case how does the infor in the .rgs file get placed
in the registry?

One method is that you write code in the DllRegisterServer function in the
ATL com object what the rgs do, so that the necessary information will be
written into the registry when you call regsvr32 to registry the com dll.
Or
We need to use the tool above to run the rgs file to do the job.

 

[David Thielen]

Hi;

One final follow-on (I think). In the below I don't understand what you are
saying. I don't call regsvr32 to register the dll and in the install program
I set the shim to selfRegister. So how does that then cause it to register?

thanks - dave

Actually I meant when the installer is running to install my add-in on
another computer. In that case how does the infor in the .rgs file get placed
in the registry?

One method is that you write code in the DllRegisterServer function in the
ATL com object what the rgs do, so that the necessary information will be
written into the registry when you call regsvr32 to registry the com dll.
Or
We need to use the tool above to run the rgs file to do the job.

 

[Peter Huang]

Hi Dave,

We can simplily consider the problem as below.
As we discussed before, to make an addin running we need to add some
registry key in the registrys.

And the Shim dll is also an unmanaged COM DLL which is also need to be
registered.

Now the problem is how to write the registry key information into registry.

We have two approaches,
1. the shim dll is an VC++ com dll, which has a dllregisterserver function,
which will be called when we use the regsvr32.exe to register the shim dll.
So if we write the registry information in the function, the information
will be written into registry when we call the regsvr32.exe shim.dll.

2. use the .rgs file, which is a script file which is commonly called by
IDE but we also can use that tool to execute the .rgs to add information
into registry.

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[David Thielen]

I understand everything you said below.

What I don't understand is how/when/where is either regsvr32 or the .rgs
file called to register the shim? I never call it. In the installer is says
selfRegister for the shim.

So how is regsvr32 or the .rgs file called?

thanks - dave

 

[Felix Wang]

Hi Dave,

If you set the shim with "selfRegister", the component will be put into the
"SelfReg" table of the MSI file. Windows Installer will call
"DllRegisterServer" against the file for you during the installation. You
may refer to the following link for more dicussion on "SelfReg":

SelfReg Table
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/s
elfreg_table.asp

The "SelfReg" table is one of the two common options to register COM
components with Windows Installer.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[David Thielen]

Hi;

THank you - ok now I understand. I had thought selfRegister meant something
else (that it would register itself when first run).

thanks - dave

 

[Felix Wang]

Hi Dave,

Please feel free to post here if you have any further concerns regarding
this issue.

Have a nice day!

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.