View Full Version : .NET COM Interop scan scrambles registry table

04-09-2002, 08:55 AM
We found what we believe is a bug in ISD7.0, ISD7.01, ISD7.02 and ISD7.03beta:

Setting .NET COM Interop "yes" and scan at build time to "Dependencies and Properties" for a .net DLL (single file and marked keyfile) causes ISD7 a lot of entries in the "Registry" MSI table to be overwritten with the resulting registry entries from the build-time-scan!
However, the registry table in the ISD project is NOT scrambled.

As a workaround we identified that it helps to rename all the registry entries in the "Registry" table (via Advanced->Direct Editor) from "RegistryXXX" to a different name.

I our case a lot of registry entries from the scan-at-build-time were written across the previously defined registry entries Registry1 to Registry102. These were no longer present in the resulting msi file.

How to repeat:

* create a standard project
* populate registry table
* create a component holding a single .net DLL
(I can provide ours)
* check ".NET COM Interop" yes
* set ".NET scan at build time" to "Dependencies and Properties"
* build a release

* install the release, compare with the defined registry entries


* open .msi file in Direct Editor and compare the registry table
with the one inside the ISD7 project

How to workaround:

* rename all entries in the registry table to NOT use the "RegistryXXX" name

-> Drawback:
1) a lot of work (~200 in our case!)
2) creating registry entries via components advanced settings like
File Extensions or AppPaths create "RegistryXXX" entries.
These have to be renamed again after creation.

Does anybody know of a more comfortable workaround?
Could somebody explain the difference between ".NET<->COM Interop" and "Extract COM information at build time". Can I use this as an alternative? Our DLL provides a .NET<->COM bridge. Since interfaces are still changing and we do nightly automatic builds, we cannot afford dropping the scan-at-build.


04-26-2002, 04:21 PM
I will be researching this issue. Could you please send me your .net DLL to chandimar@installshield.com so that I can try and reproduce this over here? Thanks!

Lon Wergin
04-30-2002, 11:10 AM
We've just got hit by the same bug: Only the registry entries from the one component with the ".NET COM Interop" setting set to "Yes" are included in the Registry Table in the resulting .MSM file; The other component's registry values (which were entered via the Registry editor of those components) were not!

As a test, if I set the ".NET COM Interop" setting of the offending component to "No" and then re-built the merge module. The result was that the other component's registry values were correctly included in the .MSM file.


04-30-2002, 02:28 PM
I had the same problem. It seems to be fixed, though, in the Release version of 7.03. Be wary, though, and check out the other threads on 7.03.... ;)