By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,315 Members | 2,150 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,315 IT Pros & Developers. It's quick & easy.

About SelfReg table for registering dlls

P: n/a
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!
Nov 17 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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]
- mv*@spam.guard.caspershouse.com

"Shiraz" <Sh****@discussions.microsoft.com> wrote in message
news:97**********************************@microsof t.com...
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!

Nov 17 '05 #2

P: n/a
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 [.NET/C# MVP]" wrote:
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]
- mv*@spam.guard.caspershouse.com

"Shiraz" <Sh****@discussions.microsoft.com> wrote in message
news:97**********************************@microsof t.com...
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!


Nov 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.