32-bit app, with 32/64-bit driver, won't install on 32-bit

[v-jocull]

The scenario: 32-bit app, with a multi-architecture WinUSB-based driver to be installed. 32-bit app runs on both architectures. Signed WinUSB driver installs manually on x86 and AMD64 archiectures. Put it in an InstallShield project, however, and I have to have two copies of the same driver, calling one 32-bit and the other 64-bit, and the system requires me to flag the whole package as 64-bit -- meaning the package refuses to install on 32-bit systems.

I'm a bit annoyed that we went to the trouble to buy a pro license, advertised to support driver installation, only to have the idea of a 32-bit app with a driver which supports multiple architectures be so completely alien to the system that I have to write a custom installation step and fake it. Or, worse, that now I have to have a 32-bit install and a 64-bit install, as separate items. Am I missing something? "Device Driver machine architecture" should have checkboxes, not radio buttons, and it shouldn't impact the Summary Information Stream | Template Summary field at all. If I have to write custom installation steps just to be able to have a single distribution MSI that I can use to provide support for 32-bit and 64-bit OSes via a driver (how long have INF files supported all three architectures published together? Since the inception of 64-bit?), I might as well have cobbled together the MSI with Orca myself. Please tell me I'm a n00b and what the easy solution I'm missing is.

Thanks,

=-John-=

[v-jocull]

I'm guessing I'll just install the files as part of the main component and then manually invoke SetupDIXXX calls to get around this. Anyone? Bueller?

[Reureu]

Correct me if I'm wrong, but I think it is a limitation of MSI.
Your scenario might be supported if you integrate your driver in an InstallScript project.

I faced the same issue a while ago, and I managed to find a workaround. Here is a brief description in a few words:

• When you set a component to install a driver, InstallShield creates and schedule some custom actions for you.
  
• These custom actions call methods in the Difxapp.dll and the Difxappa.dll.
  These 2 DLL's are either 32 or 64 bit DLL's.
  
• So, the idea is to pack both versions of these DLL's in the Binary table and determine which one to use at runtime.
  

I ended up duplicating some actions at runtime, and it took me a while to make this work, but it did the job, and it saved us releasing 2 different MSI packages.

It would be much easier to simply call an executable to install your driver from your MSI.

[np_install_user]

We faced a similar issue. The route we ended up taking was to split driver installation out into a separate installer. It has worked out well.

We build separate x32 and x64 driver installer projects.

Then we created prerequisites for our driver installer which are used by the main app installers. Our x32 app installers carry both the x32 and x64 driver installers, while the x64 one just carries the x64 driver installer.

Since multiple different apps then share a common driver installer, the prerequisite detection allows that stage to be skipped if the driver is already present on the system.

This arrangement also allows us to easily provide standalone driver installers to system integrators of our products if they need them.

[lasiewicz]

The previous reply in the correct approach. You can however use one project and use release flags for your 32 BIT or 64 Bit apps and specify the template summary on the build.

If you don't want .exes for your customer, you can use chained MSI or installshield .prq to wrap both msi files in one set up launcher.