I’m creating an installer for a software application that interfaces with a hardware device. The hardware device uses an FTDI USB serial interface. I need to install the FTDI USB drivers (if the user doesn’t already have them) along with the software, and I’m using WiX and the DIFxApp extension to accomplish this.
So far, so good. That all works fine. I have separate MSI packages for my software and the 32-bit and 64-bit flavors of the drivers, and I’m using Burn to bundle them all up into a single installer. The driver MSI packages deploy the driver files to a subdirectory of my application installation folder, and then DIFxApp installs the drivers to the appropriate system locations from there. (Which seems silly – they’re only used during install; why keep them hanging around after that? A copy is kept in the system driver store, after all. It would be preferable to extract them to a temporary folder, install the drivers, and then clean them up. But evidently, that’s the way DIFxApp works.)
But the FTDI chipset is used by a lot of different devices, and it is likely that a user will own other devices that also require the FTDI drivers. In testing, I have found that DIFxApp uninstalls the drivers when the software is uninstalled. This is undesirable, because it will break any other FTDI-based devices the user owns, requiring the user to reinstall the drivers to get those devices working again.
I would like DIFxApp to leave the drivers installed on the user’s system when my software is uninstalled so that removal of my software does not affect the user's other devices.
I could do this by setting the Permanent attribute on the MsiPackage or Component that installs the drivers, but that will prevent the driver files that were deployed to a subdirectory of my application installation folder from being cleaned up. I want those removed along with my application; I just don’t want the driver removed from the system driver store, etc.
It also looks like I could accomplish what I want by installing the drivers with a DPInst custom action. And it looks like the DPInst approach would support installing the drivers from a temporary folder and not require the driver files to hang around in my application folder for eternity. This would seem to be the pragmatic solution, but evidently DPInst is discouraged in favor of DIFxApp in MSI-based installers.
What is the “right” way to handle this?
I have dealt a little different with the same issue.
I consider the drivers and the application as separate pieces of software so they should not share any directories or files.
I install the drivers with difxapp and also copy them to program files/common files as they could be shared/common.
The application is installed to it's own directory in program files.
Then you can mark the driver msi as permanent in the bundle and keep the drivers when the application is uninstalled.
Related
I need to distribute a webapp in an offline version on an USB. Electron seems like a great way to make the webapp feel native and work well on all platforms. There is (potentially) just one problem: The offline version requires several huge media files and therefore there is not enough space for each package to have its own folder with the media files. This can be solved by letting the packages share a common directory on the USB. Can you tell me if this is possible with Electron. And if so, how?
(Note that each package must be available on the USB.)
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
Our C++/QT desktop application for Mac, Windows and Linux needs an installer. I'd rather we have a single installer for all three platforms. I do know it's a bit tricky, I guess what I wanted ask is if a framework already exists for that (Java maybe?).
I'd really like to avoid having to write three different installers.
The link that Kyle mentions is pretty comprehensive, but I wanted to provide a bit more of information about InstallBuilder for Qt (Disclaimer, I am one of the developers) since most of the cross platform installation programs referenced there are Java-based. This requires bundling a JRE, etc. and adds a significant overhead that is not required with a Qt-based installer, like ours. It is able to generate wizard-like executable installers for all platforms from a single project file as well as native packages such as DEB and RPM. If you ship your software in DVDs, you can create a single multi-platform DVD that shares data across platforms but still have native launchers.
Having said this, since your application is Desktop-oriented, for the particular case of OS X if it does not require complex installation you may be better off creating a .app file and package it inside a DMG. Users can then drag the file directly to the Applications folder.
Finally, I wanted to mention that InstallBuilder is commercial, but we offer free licenses for open source projects and discounts for small development firms.
IzPack rocks: http://izpack.org. It is truly crossplatform, very lightweight, easy to master, and produces excellent results.
After fully integrating both Izpack and InstallBuilder into our builds (using Windows, OSX, and Ubuntu 14 build servers for testing purposes), I will say I believe InstallBuilder is well worth the money (and free for open source projects according to wojciechka).
Izpack is a bit slow, a bit large if you need to package a JVM, and has an amateurish user interface. Version 5 (release candidate 3) was also not generating uninstallers properly. That said, as long as you use a 4.x version and require a JVM anyway, it may be enough for your needs. The extension interface is not terribly easy to deal with, but is almost infinitely flexible. The Windows installers do not register with the Control Panel uninstaller list.
InstallBuilder has a great, fast UI in the produced installers and has a serviceable UI for creating installers. The XML is pretty easy to deal with, too. Downloads are about as small as possible. It also includes nice hooks for doing all sorts of custom stuff easily. The only slightly annoying thing I ran into was that the Windows server required that I manually add some configuration to set executable bits on the other systems' packages (other systems didn't require this configuration).
Note: I was using the three-platform version of standard InstallBuilder (not InstallBuilder for QT).
I need to know how to make a software in Visual Studio(VC++ or VB) that can be run from a USB pendrive?
Is there anyway i can create this standalone software that doesnt need any installation in the PC in which the USB is plugged into?
Just save the executable on the drive. All referenced dlls also need to be stored there. If you have code access active you also need to make sure that the drive is allowed to provide executable code.
One more thought: If the system is linux ore mac then you should consder to switch to Java to be platform independend.
Yes, any native code application can run from a pen drive (so long as any dll's or associated files are also stored with it). .NET apps can also run... if the machine has the necessary run times installed.
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).