Register remote dll:s
Hi, I have a vendor package for a program, but for it to work in an locked down environment (usera have only user-righte on the computer) I have to manually register Dll files that are on the server. How do I do this in an package?
Thanks in Advance
//Alstersjo
Thanks in Advance
//Alstersjo
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
aogilmor
18 years ago
Posted by:
WiseUser
18 years ago
Although possible, registering files which are located on another machine is not a recommended practice. Copying them locally first would be preferable.
It is possible to register files for the user rather than the machine, although it is unlikely that you will be able to do that with "Regsvr32.exe". The users would have permissions to do this themselves.
Which packaging software do you use (if any)?
It is possible to register files for the user rather than the machine, although it is unlikely that you will be able to do that with "Regsvr32.exe". The users would have permissions to do this themselves.
Which packaging software do you use (if any)?
Posted by:
Mayur
18 years ago
Posted by:
linstead
18 years ago
Posted by:
ZhuBaJie
18 years ago
ORIGINAL: alstersjo
Hi, I have a vendor package for a program, but for it to work in an locked down environment (usera have only user-righte on the computer) I have to manually register Dll files that are on the server. How do I do this in an package?
Thanks in Advance
//Alstersjo
I did this yesterday in a Kluwer package (Dutch).
When I tried to make it work I found I had the same problem you have.
Here's my solution.
I compiled the package as it was.
Then I made a .cmd script with the necessary regsvr32 commands addressing the dll's on the server.
I tested it first and unregistered the files after that.
Next I did a start snapshot and told it to add to the .wsi I made before.
Now I ran the script and did the end snapshot.
Voilla the .dll's on the server were registered!
I first tried to add the script as a custom action but, while it worked from the command prompt, that didn't work.
Above solution is the most elegant in my opinion.
Ofcourse, if you start from scratch you don't have to do the second snapshot.
Marcel
Posted by:
alstersjo
18 years ago
Posted by:
WiseUser
18 years ago
Yes.
Registering an active-X component involves writing registry information.
Because "HKCR" is a combined representation of "HKLM\Software\Classes\" & "HKCU\Software\Classes", the registration can be in either location.
Unfortunately, "non-admin" users do not have "write" permissions to "HKLM\Software\Classes\" (only "HKCU\Software\Classes\"), but writing to HKCR writes the information to "HKLM\Software\Classes\".
It should be possible to create an MSI that would allow a "non-admin" user to install (and register) these files under his own user account. The files would not be registered for subsequent users of the machine. Personally, I avoid per-user installs whenever possible.
Registering an active-X component involves writing registry information.
Because "HKCR" is a combined representation of "HKLM\Software\Classes\" & "HKCU\Software\Classes", the registration can be in either location.
Unfortunately, "non-admin" users do not have "write" permissions to "HKLM\Software\Classes\" (only "HKCU\Software\Classes\"), but writing to HKCR writes the information to "HKLM\Software\Classes\".
It should be possible to create an MSI that would allow a "non-admin" user to install (and register) these files under his own user account. The files would not be registered for subsequent users of the machine. Personally, I avoid per-user installs whenever possible.
Posted by:
alstersjo
18 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.