cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
LaserVision
Level 4

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.
Labels (1)
0 Kudos
(6) Replies
RobertDickau
Flexera Alumni

Would COM extraction or the like be appropriate? The help section Creating Installations > Organizing Files ... > Registering COM Servers describes your options.
0 Kudos
LaserVision
Level 4

Thank you for your quick response.

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?
0 Kudos
RobertDickau
Flexera Alumni

Perhaps see if KB article Q108890 helps?
0 Kudos
LaserVision
Level 4

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=
0 Kudos
MEinstaller
Level 7

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?
0 Kudos
shawntp
Level 3

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.
0 Kudos