About SelfReg table for registering dlls

G

Guest

Hi

I just made an installer for an application that uses two external COM dlls.
On the surface, everything seems to be running smoothly and the the
application runs without any errors. However, I am not completely satisfied
by my implementation.

I basically used a software that generates an msi file quite easily and
included the two dlls in my package. I then edited the msi file using orca,
and forced the dlls to self register by stating their FileName key in the
column of the SelfReg table. Nothing wrong there...
Now here is my concern:

The SelfReg table makes a unique registry entry in the HKCR logical section,
by overwriting the already existing key. That's still acceptable but the
problem is that on uninstalling the application, the installer also
unregisters these two dlls, which is undesirable as they might be needed by
other applications which now must register the dlls again.

Ideally, shouldn't the installer make a new key in the HKCU section, which
does not effect the previously existing registry entry? I don't know how it
could be done but if somehow the installer could generate a separate key for
the copy of dlls being used by my application, then on unregistering them,
the other applications wouldn't get affected (or so I'm guessing).

I would appreciate if anybody could suggest a better way to do this.

Thanks!
 
N

Nicholas Paldino [.NET/C# MVP]

Shiraz,

If this DLL is shared, then your installer should be able to pick up
that the component is installed and not install in the first place. This
should keep the installer from not uninstalling the original component.

Also, you shouldn't have to modify the install tables yourself. I
remember that Visual Installer 1.1 allowed you to specify the
install/uninstall properties of a COM dll. I can't imagine that's been
removed. You should be able to set a flag indicating that the component
should not be uninstalled.

Also, it should be installed in the Common Files directory, assuming it
is shared.

Hope this helps.
 
G

Guest

Nicholas

I think I somewhat understand the problem now. Firts of all, I used the
software Installer2Go for making my msi file instead of the Visual Installer
1.1, so I don't have the same kind of options as in VSI.

Secondly, I did put my dlls in the Common Files folder as you suggested and
found out that whoever had made the previous installer had done so likewise,
but the main problem I believe is with using the SelfReg table. The other
installer has a bunch of dlls all listed under this table. What SelfReg seems
to be doing is overwriting any exisiting registry entries in the Global cache
with these new ones and when the application is unregistered, it deletes the
GUIDs for the dlls. This I think causes a lot of problem; for instance, if
application1 is installed and then application2, or the other way around,
things will definitely keep running. But the moment either one of these
application are uninstalled, no application using the shared dlls of these
two applications will work, making it necessary to re-install the application
being used currently, which of course is just a very bad fix...

So what I need to do is to not make the same mistake again of using SelfReg
and somehow register my dlls and on uninstallation, keep them in the registry
if they're being shared. And I can do this only using Orca, so I have to
figure out a way to use the tables for this : |

Any suggestions?

Anyhow, if there's anyone who might know a better way to proceed or if what
I said wasn't totally correct, I'd be glad to hear your ideas.

Thanks a lot

Shiraz



Nicholas Paldino said:
Shiraz,

If this DLL is shared, then your installer should be able to pick up
that the component is installed and not install in the first place. This
should keep the installer from not uninstalling the original component.

Also, you shouldn't have to modify the install tables yourself. I
remember that Visual Installer 1.1 allowed you to specify the
install/uninstall properties of a COM dll. I can't imagine that's been
removed. You should be able to set a flag indicating that the component
should not be uninstalled.

Also, it should be installed in the Common Files directory, assuming it
is shared.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Shiraz said:
Hi

I just made an installer for an application that uses two external COM
dlls.
On the surface, everything seems to be running smoothly and the the
application runs without any errors. However, I am not completely
satisfied
by my implementation.

I basically used a software that generates an msi file quite easily and
included the two dlls in my package. I then edited the msi file using
orca,
and forced the dlls to self register by stating their FileName key in the
column of the SelfReg table. Nothing wrong there...
Now here is my concern:

The SelfReg table makes a unique registry entry in the HKCR logical
section,
by overwriting the already existing key. That's still acceptable but the
problem is that on uninstalling the application, the installer also
unregisters these two dlls, which is undesirable as they might be needed
by
other applications which now must register the dlls again.

Ideally, shouldn't the installer make a new key in the HKCU section, which
does not effect the previously existing registry entry? I don't know how
it
could be done but if somehow the installer could generate a separate key
for
the copy of dlls being used by my application, then on unregistering them,
the other applications wouldn't get affected (or so I'm guessing).

I would appreciate if anybody could suggest a better way to do this.

Thanks!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top