I need to register some .dll and .ocx for a 32-bit application. I can register these fine using Custom Actions in System32 by using the %SYS% Paquet Builder global variable. But on a 64bit OS, System32 contains the 64bit libraries. I need to register these in SYSWow64, but Paquet Builder 3.0.4 has no global variable to reference SYSWow64.
I do see a %CUR% global variable. What is the difference between %SYS% and %CUR% - the documentation is vague. Mean time, I have to reference an absolute path of C:\Windows\SYSWow64 which I would rather not do. Does anyone have a suggestion for how to address this? I can’t be the only one.
If you create a 32-bit package, all DLL and OCX files will be automatically copied to the SYSWOw64 folder. In fact, 32-bit packages can only deal with the System folder dedicated to 32-bit files.
To copy and register 64-bit files, you have to create a 64-bit package.
%CUR% contains the path to the current working directory in Windows.
In all cases, to copy files to the System folder, use %SYS%.
Okay great, so I was doing it correctly by using %SYS% and where the DLLs are copied is dependent upon the package being created, and the destination OS. For some reason, my DLLs weren’t getting registered on 64bit Windows. The only way I could get them to reliably register was to create two sets of Self-register actions, one where %IS64OS% = 0 where my actions reference %SYS%, and another where %IS64OS% = 1, where I reference hard-coded path to SysWOW64:
Actually I’m using an if/else conditional, but in any case this is the only way I can get it to reliably register the DLLs. Perhaps you could suggest a better method?