This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- File Registration Information and Install Compiles...
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2009
08:41 AM
File Registration Information and Install Compiles...
Hi all,
Ok, this quetion(s) stems from the biggest problem I have had working with developing installs and that would be file registration and inclusion of such information in the install itself.
Its been several years since I worked with InstallShield, but here is what I remember. I think we had all our install source files copied locally to the build machine. Then, whenever a file was added, IS would scan and add the appropriate registration information to the template.
Do I recall that correctly or is that how InstallShield functions now? Is this the same for files that have RegAsm information?
Actually, I don't remember having too many problems in this area with IS, but do with a product(s) of one of its major competitors.
What sometimes ends up happening is Custom Actions are created to register the file at the end of the install process. I'm hoping this isn't necessary with InstallShield, but can live with it if that is the case.
I guess it would be nice to know the best practices as they pertain to InstallShield for getting file registration information into the installations. Is it best to have source files local to the install build machine? I don't think I ever had to do this before, but should the source files be registered on the install build machine?
Any ideas, information or points to such would be GREATLY APPRECIATED!
If I haven't mentioned before in earlier recent posts, we're looking to make a switch from one of IS's major competitor's products because it doesn't seem they are putting much development effort towards the software we use.
We are also evaluating one other product (InstallAware) and whichever is more user friendly will probably get the nod. Since I've worked with InstallShield before, it has the slight advantage at this point.
I'm also fairly comfortable working directly with the .msi tables so the Direct Editor in IS is OK for me as I don't need a flashy interface to cover all of the nuts and bolts.
Anyway, I digress, sorry. 😮 Any information on best practices for file registration would be appreciated.
THANKS!!
Ok, this quetion(s) stems from the biggest problem I have had working with developing installs and that would be file registration and inclusion of such information in the install itself.
Its been several years since I worked with InstallShield, but here is what I remember. I think we had all our install source files copied locally to the build machine. Then, whenever a file was added, IS would scan and add the appropriate registration information to the template.
Do I recall that correctly or is that how InstallShield functions now? Is this the same for files that have RegAsm information?
Actually, I don't remember having too many problems in this area with IS, but do with a product(s) of one of its major competitors.
What sometimes ends up happening is Custom Actions are created to register the file at the end of the install process. I'm hoping this isn't necessary with InstallShield, but can live with it if that is the case.
I guess it would be nice to know the best practices as they pertain to InstallShield for getting file registration information into the installations. Is it best to have source files local to the install build machine? I don't think I ever had to do this before, but should the source files be registered on the install build machine?
Any ideas, information or points to such would be GREATLY APPRECIATED!
If I haven't mentioned before in earlier recent posts, we're looking to make a switch from one of IS's major competitor's products because it doesn't seem they are putting much development effort towards the software we use.
We are also evaluating one other product (InstallAware) and whichever is more user friendly will probably get the nod. Since I've worked with InstallShield before, it has the slight advantage at this point.
I'm also fairly comfortable working directly with the .msi tables so the Direct Editor in IS is OK for me as I don't need a flashy interface to cover all of the nuts and bolts.
Anyway, I digress, sorry. 😮 Any information on best practices for file registration would be appreciated.
THANKS!!
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2009
06:16 PM
If you can, you'll probably want to use "COM extraction" instead of self-registration. This populates the COM-related MSI tables, and sidesteps problems with the order of registration, rollback, and other issues. Looking up "COM" in the help index will turn up some resources, as will the TOC section Organizing Files for Your Installation > Registering COM Servers...
If you can't use COM extraction for some reason, you can mark files as self-registering, using InstallShield's default method, or Windows Installer's method. You should never need to create custom actions to register COM servers.
If you can't use COM extraction for some reason, you can mark files as self-registering, using InstallShield's default method, or Windows Installer's method. You should never need to create custom actions to register COM servers.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2009
07:33 AM
Hi Robert,
Thanks for the reply.
Does the fact I should never have to use custom actions to register COM servers apply to both files needing RegSvr and those needing RegAsm for registration.
So, if I have a file not registered properly post install where COM Extraction was used, I should then try Self Register. Again, will this be an ample attempt for both files needing RegSvr and RegAsm?
Boy, if I could get this ironed out, I would be one Happy Camper!
Oh, and am I to take it that the location of the files that are added to the install is irrelevant. I seem to recall that there were problems with the current product we are using where pulling files across the next missed registration information if the proper version of .NET wasn't installed.
Thanks for the reply.
Does the fact I should never have to use custom actions to register COM servers apply to both files needing RegSvr and those needing RegAsm for registration.
So, if I have a file not registered properly post install where COM Extraction was used, I should then try Self Register. Again, will this be an ample attempt for both files needing RegSvr and RegAsm?
Boy, if I could get this ironed out, I would be one Happy Camper!
Oh, and am I to take it that the location of the files that are added to the install is irrelevant. I seem to recall that there were problems with the current product we are using where pulling files across the next missed registration information if the proper version of .NET wasn't installed.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2009
09:05 AM
Oh, I'm going several years back now but I thought Self Registration was advised against. ??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2009
09:15 AM
For .NET COM servers, you can use the .NET COM Interop component setting (and possibly other of the component .NET settings; the help has more information). My understanding is that it doesn't matter if the source files are local or pulled down over the network, but others can share their experience with that.
Exactly right, you should avoid self-registration if you can, in favor of using MSI database tables (as COM extraction does, for example).
Exactly right, you should avoid self-registration if you can, in favor of using MSI database tables (as COM extraction does, for example).
