locked
Registering 32 bit dll on Windows 7 64 bit during installation of package created using InstallShield RRS feed

  • Question

  • I have a COM Server / DLL written and "compiled" using Visual Foxpro 9. I then package this with the runtime(s) using InstallShield 5 Express Limited Edition that was bundled with Foxpro. This used to all work fine however now that I try to install the package on a Windows 7 64 bit machine the dll fails to register during installation with the message

    Error 1904.Module C:\Program Files (x86)\App Folder\filename.dll failed to register. HRESULT -2147220473. Contact your support personnel.

    I can manually register the dll afterwards using

    %systemroot%\syswow64\regsvr32 pathtodll.dll

    and it registers no problem but I would obviously like to improve the experience for the user.

    I have tried changing the dll properties from "self-registering" to "extract COM information" but whilst the installer does not error, the COM/DLL file does not fully register all of the classes etc. As I see it my options are:

    a) Include a batch file which the user can run after installation to register the dll.

    b) Upgrade to a newer version of InstallShield which is 64 bit aware and should handle this properly.

    c) Switch to an alternative installer such as InnoSetup or NSIS.

    My questions are thus:

    1. Have any other Visual Foxpro developers encountered this situation and how are you handling it?
    2. If I upgrade to a newer (non-VFP bundled) version of InstallShield such as 2013 Express will I still be able to distribute the VFP Runtime modules?
    3. If I switch to an alternative installer will I still be able to use group policy to deploy the application on a network and can I keep the same Upgrade GUID so that old versions are automatically upgraded?


    Regards
    Darren Woodford - MCP, MCSA, MCSE, MCTS


    Monday, September 16, 2013 12:57 PM

Answers

  • >In other words the InstallShield bundled with VFP is not capable of registering DLLs on 64 bit Windows?

    totally wrong conclusion.

    1. Installshield is not making the registration, msi packages are handled by Windows Installer, the MS system component for software installations.

    2. It's the association of msi to a dll in system32, where 64bit components reside, which triggers every msi to be treated as 64bit package, that's also not the fault of Installshield. 

    If there is no meta data in the msi package telling windows it's a 32bit COM dll to register, Windows Installer (not Installshield) is handling anything inside the msi as 64bit components.

    If you make a setup.exe on the other side, this will be a 32bit exe, running as 32bit process and thus use 32bit components of windows and register fine, so are my assumptions for now. I haven't tested that ,yet.

    What is important anyway, is the runtime of the setup, is it running as 32bit or 64bit setup process. That will determine where files really go and what system components are used and which part of the registry is seen by the setup process.

    Bye, Olaf.


    Olaf Doschke (Setmics)

    Thursday, September 19, 2013 9:54 AM

All replies

  • 1. I am not using installers for my VFP applications. A copy to the destination folder is sufficient obviously. If some component requires registration then the application itself will do it. The application is also self updateable. (It can execute a batch or any external EXE with elevated rights if necessary.)

    2. VFP Run-time DLLs are nothing special and each installer should handle them without problems. It is sufficient to have these DLLs in the application folder.

    3. My updater does not need any GUID so I cannot answer.

    Monday, September 16, 2013 7:42 PM
  • Are you sure you are using the installshield coming with VFP?

    It itself is 32bit, isn't 64bit aware (most recent destination os mentioned is win2003) and creates 32 bit setup exe.

    The only reason I can imagine the install itself works like a 64bit installer is, you create setup.MSI packages instead of setup.EXE. If using msi the destination system may treat it as 64bit. I'm not sure about this, but it may be worth a try.

    So

    1. No, but if I were, I would try EXE instead of msi

    2. yes, msm files can be copied over, you own them

    3. alternative installers using the same windows native installer system would also handle product codes as GUIDs. I don't know if inno does so, but the GUID part is part of the OS, not of Installshield.

    Especially for msi packages, see reference for msiexec.exe parameters, eg uninstall needs a product code GUID, so product codes are at least an MSI thing, if not for any installer, they are not an Installshield specific.

    Bye, Olaf.


    Olaf Doschke (Setmics)

    • Edited by Olaf Doschke Tuesday, September 17, 2013 8:34 AM
    Tuesday, September 17, 2013 8:33 AM
  • >C:\Program Files (x86)\

    Makes me wonder, because it means the install is aware it's installing a 32bit software.

    Then it should also use 32bit tools of the SysWOW64 folder and/or write to the 32bit registry.

    I may try a bit with installshield at the weekend and see, how it goes. As far as you say, a manual registering afterwards helps, so it doesn't fail on any missing components. Maybe it's the order of registration of the VFP runtime and the COM DLL, you obviously depend on vfp9t.dll being present before your COM DLL can be registered, otherwise registering may fail at setup time and work afterwards, because the vfp9t.dll then is known.

    Bye, Olaf.


    Olaf Doschke (Setmics)

    Tuesday, September 17, 2013 8:47 AM
  • Thanks Guys. Yes I am 100% definitely using the InstallShield that comes with VFP. It just seems to be using the wrong version of regsvr32.exe - or whatever mechanism it uses to register dlls. I am building as MSI as I distribute via group policy. I will try EXE though just in case it makes a difference. I don't think it is order of DLL registration vs installation of VFP runtime either as I have tried on my machine with VFP9 already installed and I get the same result.

    Regards
    Darren Woodford - MCP, MCSA, MCSE, MCTS

    Tuesday, September 17, 2013 8:57 AM
  • OK,

    lookin into registry, .msi is associated as Msi.Package, which in turn is associated with @%SystemRoot%\System32\msimsg.dll,-34

    That speaks for msi packages being installed in 64bit mode, so to say.

    Bye, Olaf.


    Olaf Doschke (Setmics)

    Tuesday, September 17, 2013 8:01 PM
  • OK,

    lookin into registry, .msi is associated as Msi.Package, which in turn is associated with @%SystemRoot%\System32\msimsg.dll,-34

    That speaks for msi packages being installed in 64bit mode, so to say.

    Bye, Olaf.


    Olaf Doschke (Setmics)


    In other words the InstallShield bundled with VFP is not capable of registering DLLs on 64 bit Windows?

    Regards
    Darren Woodford - MCP, MCSA, MCSE, MCTS

    Wednesday, September 18, 2013 8:51 AM
  • >In other words the InstallShield bundled with VFP is not capable of registering DLLs on 64 bit Windows?

    totally wrong conclusion.

    1. Installshield is not making the registration, msi packages are handled by Windows Installer, the MS system component for software installations.

    2. It's the association of msi to a dll in system32, where 64bit components reside, which triggers every msi to be treated as 64bit package, that's also not the fault of Installshield. 

    If there is no meta data in the msi package telling windows it's a 32bit COM dll to register, Windows Installer (not Installshield) is handling anything inside the msi as 64bit components.

    If you make a setup.exe on the other side, this will be a 32bit exe, running as 32bit process and thus use 32bit components of windows and register fine, so are my assumptions for now. I haven't tested that ,yet.

    What is important anyway, is the runtime of the setup, is it running as 32bit or 64bit setup process. That will determine where files really go and what system components are used and which part of the registry is seen by the setup process.

    Bye, Olaf.


    Olaf Doschke (Setmics)

    Thursday, September 19, 2013 9:54 AM
  • Hi Olaf et al

    Thanks for your responses so far. I've quite accidentally discovered that with UAC disabled the installation works trouble-free. No errors occur and the dll appears to be registered correctly. Obviously my assumption that this was an issue with 64 bit was incorrect and I have now proved the error also occurs on a 32 bit Windows 7 machine unless UAC is disabled. So apologies for sending everyone down a dead-end there. It would thus appear that the issue is actually a problem with the installer registering dlls when UAC is enabled and is therefore likely a problem with any version of Windows from Vista onwards.

    Obviously temporarily disabling UAC is a workaround however this does require a reboot and can be a bit of a pain especially when working remotely. Can anybody suggest a neater way around this please?

    Regards

    Darren


    Regards
    Darren Woodford - MCP, MCSA, MCSE, MCTS

    Monday, April 7, 2014 2:20 PM