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
- :
- Set environment path before registering dll
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
‎Feb 12, 2009
07:41 AM
Set environment path before registering dll
I have a simple Basic MSI Project with a dll that has to be registered. I can set the property to "Self Register" but this only works for the dll if it has been installed in the system32 folder. To install it at a different location I have to set a environment path variable and I also managed to add information to the installshield project.
But it is still telling me that the registration failed at the end of the installation process though it has updated the environment path.
Does anyone have a clue to this problem? I saw some older postings containing the same problem without being answered.
The only workaround I can think of is to remove the "Self Register" flag and create a batch file that registers/unregisters the dlls with a CA after the installation process (don't know if that works).
Thanks in advance.
But it is still telling me that the registration failed at the end of the installation process though it has updated the environment path.
Does anyone have a clue to this problem? I saw some older postings containing the same problem without being answered.
The only workaround I can think of is to remove the "Self Register" flag and create a batch file that registers/unregisters the dlls with a CA after the installation process (don't know if that works).
Thanks in advance.
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2009
09:04 AM
Would COM extraction or the like be appropriate? The help section Creating Installations > Organizing Files ... > Registering COM Servers describes your options.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2009
02:38 AM
Thank you for your quick response.
Unfortunately I have tried that already and I get the -4354 warning:
This is why I chose the self register option. Tried it anyway (getting the warning, turning off self registering) and I can definitely say that my DLL is not registered. Do you have another idea?
Unfortunately I have tried that already and I get the -4354 warning:
ISDEV : warning -4354: The build was unable to extract COM information from the file MyDll.dll in component MyDll.dll. Please ensure that the file is self-registering and verify that the self-registration process.
This is why I chose the self register option. Tried it anyway (getting the warning, turning off self registering) and I can definitely say that my DLL is not registered. Do you have another idea?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 17, 2009
07:34 PM
Perhaps see if KB article Q108890 helps?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 19, 2009
09:18 AM
mmhh, that does not help. I did already all steps described in Resolution A. Then I checked on a VM for missing dependencies but found nothing....
I still wonder if the environment path is set before (and therefore being available) before the Dll is registered...
KBQ108890:
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q108890&sliceId=
I still wonder if the environment path is set before (and therefore being available) before the Dll is registered...
KBQ108890:
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q108890&sliceId=
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2009
07:10 AM
I am running into the same problem right now. I used to put some dlls in the system32 which allowed me to register some other dlls in my project. In trying to clean up the install without placing the dlls in the system32 directory I have put them someplace else and now use an environment variable to point to those dlls. As you said the variable does not seem to be in place at time for the registration of the dlls. I even tried setting the sequence # of the WriteEnvironmentStrings sequence to happen earlier in the install. One thing I have noticed is that if you open a command window and look at your path it does not have your env. variable added to it until after rebooting the machine even though if you look at the variables by right-clicking on My Computer the variable is listed.
Any other thoughts?
Any other thoughts?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 02, 2010
09:37 AM
I also have dealt with this issue recently. When you set the PATH variable it does get updated right away but your MSIEXEC sessions does not see it yet - it only knows of the PATH definition as it existed when the process started.
So in essence you update the System's PATH ok but it is not available to you because your process is already running/using the pre-existing path.
You can mimic this behavior in a cmd window also.
I am looking for a cleaner solution but you can always make direct registration calls and set a temporary path in the cmd window.
"C:\Windows\System32\cmd.exe" /c PATH = %PATH%; C:\SomeNewPath&& "C:\Windows\System32\regsvr32.exe" /s "C:\SomeOtherPath\SomeFile.dll"
This writes a new temporary/immediate instance of PATH for the cmd processes duration which will be available to regserver. I set this up in a VBScript action with directory variables - I does pop up a cmd window which isnt the prettiest solution.
I am looking to relocate things back to System32 though so I do not have to deal with this every time a new dll pops up that has this issue.
So in essence you update the System's PATH ok but it is not available to you because your process is already running/using the pre-existing path.
You can mimic this behavior in a cmd window also.
I am looking for a cleaner solution but you can always make direct registration calls and set a temporary path in the cmd window.
"C:\Windows\System32\cmd.exe" /c PATH = %PATH%; C:\SomeNewPath&& "C:\Windows\System32\regsvr32.exe" /s "C:\SomeOtherPath\SomeFile.dll"
This writes a new temporary/immediate instance of PATH for the cmd processes duration which will be available to regserver. I set this up in a VBScript action with directory variables - I does pop up a cmd window which isnt the prettiest solution.
I am looking to relocate things back to System32 though so I do not have to deal with this every time a new dll pops up that has this issue.