All,

In the various builds we all have the ExcelRTD project which has always seemed to work magically when it comes to installing via COM itself for debug purposes. Some not so good news, this is likely to break when you start moving to the next version with Bonds.

Monitoring a Debug Run

Following a lengthy session with FileMon I discovered that the IExcelRTD server seemed to not be getting its dll’s from the GAC or the local directory but from C:\Documents and Settings\…\Local Settings\Application Data\assembly\dl2\…\…\…\… [actually GWVO70ZL.PCT\NK9B96Q2.MNJ\0da889d1\4c31828b_0a62c501]. So like any careful developer, I deleted the whole tree of files below dl2. Rebuilding the project installs the dll and dependencies into various directories within this tree (the first two parts of the path stayed static).

How “Register for Com” seems to work

I will therefore make the several leaps of intuition to come up with the following scenario. When a project is compiled with Register for Com checked then it builds the Dlls as normal and copies it and its dependencies to the output directory (usually bin/Debug). The TLB is also generated and placed in the output directory. Now for the fun bit, each dll is copied into the C:\Documents and Settings\…\Local Settings\Application Data\assembly\dl2\[xxx\xxx]\[yyy\yyy] path where [xxx\xxx] is common to all dlls, but [yyy\yyy] is specific to each. Along with each dll Visual Studio also places the .pdb  and an __AssemblyInfo__.ini file.

e.g.

[AssemblyInfo]

Signature=….

MVID=….

URL=file:///C:/vss/xxx V2.1/xxx.Bank/ExcelRTDOffice11/bin/Debug/xxx.xxx.Data.DLL

DisplayName=xxx.xxx.Data, Version=2.0.0.1, Culture=neutral, PublicKeyToken=e64fdb2f….d84

In another [yyy\yyy] a copy of Microsoft.VSDesigner.DLL 7.10.3077.0 is placed, and the whole lot of dlls in \[xxx\xxx]\[yyy\yyy] are registered. Finally the TLB is used to specify the COM part.