RegAsm with the /codebase argument

[eladef]

Hi

I have several dll's which I need to register using regasm with /codebase argument (.net 2.0) and do it at setup build time
I tried this but it's not identical to RegAsm /codebase
COM Extract as Build : No
.NET scan as build : Properties Only
.NET COM Interop : Yes

Any idea ?

[schmoli]

eladef wrote:
Hi

I have several dll's which I need to register using regasm with /codebase argument (.net 2.0) and do it at setup build time
I tried this but it's not identical to RegAsm /codebase
COM Extract as Build : No
.NET scan as build : Properties Only
.NET COM Interop : Yes

Any idea ?

Did you find a solution to this problem? I have recently had it start happening to me and for the life of me I can't figure out why. even creating the most basic .Net com accessible dll is impossible for me to figure out how to register.

[arsirantala]

We tried as well the "COM extract at build"=Yes. The results were not complete, it was partially done but there were missing bits of the interface of the component.

So, I solved this problem by doing the registry file of our components using regasm tool with /regfile /codebase parameters. As a result I got a registry key file which content I'll have imported when I built the project.

This is done so that I've defined in component's "REG File to Merge at build" path to my reg file.

Not perfect solution, but was only way I could think of doing the registration of the component. In our case, when the build of the whole product is performed, the component's version is increment. As the version of the component changes - I had to make build script changes to this registry file prior building of the installshield project. I have had tagged the sections in the registry file which I need to change in every build prior building the installshield project.

This is awkward solution - if the interface of the COM component changes I will have to modify the registry file. In our case the interface has not been changed.

In our case the registry file contains tags as follows:
[HKEY_CLASSES_ROOT\CLSID\{xxxxxxxx-yyyy-zzzz-xxxx-yyyyyyyyyyyy}\InprocServer32\[VERSION_NUMBER]]

I replace the tag [VERSION_NUMBER] with version numbers of the component I'm about to register in my build script. After that I'll build the installshield project.

Hope that helps.

[schmoli]

Well another question if this is really the road I have to go down, if I generate the registry file with regasm on the build machine, the Codebase property now has the location of the file on the build server, do you then take your [INSTALLDIR property (or other such prop), switch out "\" for "/", and overwrite that Codebase with the new location? And if so I suppose I'll have to do that in custom actions, but I'm really confused as when I first created my installers (with IS12), I had plenty of .Net COM Interop DLLs that registered just fine, but for some reason this week everything has gone south on me, I can't even fetch my old ISM file and have it build a MSI that registers the DLLs. I haven't found a lot of answers here on the forum so I think I'm going to burn a support call before I decide to do the registry file import method, as it seems really hacky and breaks my ability to have all my .Net COM assemblies self-contained in my merge module.

[arsirantala]

schmoli wrote:
Well another question if this is really the road I have to go down, if I generate the registry file with regasm on the build machine, the Codebase property now has the location of the file on the build server, do you then take your [INSTALLDIR property (or other such prop), switch out "\" for "/", and overwrite that Codebase with the new location? And if so I suppose I'll have to do that in custom actions, but I'm really confused as when I first created my installers (with IS12), I had plenty of .Net COM Interop DLLs that registered just fine, but for some reason this week everything has gone south on me, I can't even fetch my old ISM file and have it build a MSI that registers the DLLs. I haven't found a lot of answers here on the forum so I think I'm going to burn a support call before I decide to do the registry fiel import method, as it seems really hacky and breaks my ability to have all my .Net COM assemblies self-contained in my merge module.

No you don't need to worry about the paths.

The dll component which we are registering in our package contains .reg (which is imported prior build) file which has line:
[CODE]"CodeBase"="file:///[#sync.dll]"[/CODE]

This #sync.dll is defined in installshield project's File table, and also the associated Component (among other things).

So once you install the product, it'll end up to registry as:

CodeBase=file:///C:\Program Files\xxx\Sync.dll

In installation phase it will determine to which path it was copied, and then that path is inserted to the CodeBase registry entry above.

Hope this helps.

[schmoli]

arsirantala wrote:
No you don't need to worry about the paths.

The dll component which we are registering in our package contains .reg (which is imported prior build) file which has line:
[CODE]"CodeBase"="file:///[#sync.dll]"[/CODE]

This #sync.dll is defined in installshield project's File table, and also the associated Component (among other things).

So once you install the product, it'll end up to registry as:

CodeBase=file:///C:\Program Files\xxx\Sync.dll

In installation phase it will determine to which path it was copied, and then that path is inserted to the CodeBase registry entry above.

Hope this helps.

Ok to clarify, if you manually run regasm /codebase /regfile, the created .REG file has the actual path as the codebase, so are you then taking that file and manually editing it and placing the #sync.dll style tag in there?

I have narrowed my problem down by creating a very stripped down .NET 2.0 Com-accessible DLL, importing it into an empty MSI (and MSM) project, and marking the component as ".NET COM Interop". Building the installer will correctly create the .REG file as you described, and populate the Registry table of the MSM/MSI with the correct info to register the COM object. Unfortunately, on the exact same build machine (using the UI), it will sometimes STOP doing both of these (no reg file, no registry table entries) and I am unable to figure out why. I have noticed this has never happened to any MSI/MSM I have built with the standalone builder, only through the UI. I will be calling Installshield today to describe this problem, as it's more than a little annoying. I have also found that once my project has stopped registering my .Net COM dll's, simply adding a new component that is one, then deleting that component, will cause all my existing components that are .NET COM dlls to begin registering again.

I'm sure my rant is a little long winded but trying to narrow this down has eaten several days of my schedule and has been more than a little frustrating.

[arsirantala]

schmoli wrote:
Ok to clarify, if you manually run regasm /codebase /regfile, the created .REG file has the actual path as the codebase, so are you then taking that file and manually editing it and placing the #sync.dll style tag in there?

I have narrowed my problem down by creating a very stripped down .NET 2.0 Com-accessible DLL, importing it into an empty MSI (and MSM) project, and marking the component as ".NET COM Interop". Building the installer will correctly create the .REG file as you described, and populate the Registry table of the MSM/MSI with the correct info to register the COM object. Unfortunately, on the exact same build machine (using the UI), it will sometimes STOP doing both of these (no reg file, no registry table entries) and I am unable to figure out why. I have noticed this has never happened to any MSI/MSM I have built with the standalone builder, only through the UI. I will be calling Installshield today to describe this problem, as it's more than a little annoying. I have also found that once my project has stopped registering my .Net COM dll's, simply adding a new component that is one, then deleting that component, will cause all my existing components that are .NET COM dlls to begin registering again.

I'm sure my rant is a little long winded but trying to narrow this down has eaten several days of my schedule and has been more than a little frustrating.

That is true, if you use the regasm to generate the .reg file, codebase property will have the the absolute path for the dll. You'll need to change that path value in the .reg file to the component's name instead (with # character as prefix). Sorry I forgot to mention this.

I am sorry I cannot help with the build issues - we use stand alone builder in our build machine, I haven't noticed similar problems (which you described) when running it (we create daily builds - the scheduled build scripts are run every night, hence we require software which can be used from scripts/batch files (without UI), thats why we use the stand alone builder).

[eladef]

Our solution ( if we can call it so ) after also discussing this with the support was to register them with regasm.exe by code.

[arsirantala]

eladef wrote:
Our solution ( if we can call it so ) was to register them with regasm.exe by code.

What about uninstallation? Did you guys have CA to uninstall the registeration of the component(s)? How have you resolved the scenario that user uninstalls the software from the computer. If I understood correctly that in first run of your software the component is first registered before the actual program is started?