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...
Related
I have a question about the rules organizing resources into components.
What I want to do is the following; There are two files (both 64bit) with the same filename but in different source locations and with different component GUID's;
C:\data\win7\driver.sys
C:\data\win10\driver.sys
I want both included in the installer and when the installer runs decide depending on the OS which of these two files will be installed in the same location:
C:\Program Files\MyProgram\driver.sys
Is this a violation of the rules regarding the components? (the main one applying would be the first one I would say:)
"Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies."
https://learn.microsoft.com/en-us/windows/desktop/Msi/organizing-applications-into-components
Actual Answer: Yes, installing different files to the same absolute path is indeed a violation of the MSI component rules - in
theory. As you have discovered reading the documentation. However,
seeing as only one file will make it onto the box, it is all semantics
really, there will never be two files installed. Still, the MSI will
probably not validate - you will see validation errors.
I am not sure of the technical implications, but could you make the
file name different based on OS? Then you simply put the files in
separate components and use different component GUIDs and condition
the component for installation or not. Full compliance instantly.
With all that said, it seems driver files are to be installed using
INF-files in standalone packages in the future. Please read below.
Component Rules, Pragmatically: This is a well-known problem indeed. I have this old answer that might be helpful: Change my component GUID in wix? It describes how the component rules work in practice, and how the idea is that you reference count an absolute path, and not a file per-se. Please read it to make it clearer. More links in this answer.
Driver Installation: We are supposed to know how to do this, but the rules keep changing (and another answer). Essentially drivers are to be distributed via Windows Update, or at least via a standalone package without the need for an installer in the future (until Microsoft change their mind again?). Windows Hardware Dev Center dashboard. As far as I understand the installation is INF-based (as before).
Question: Are you sure about that installation location? What does the documentation say? I thought sys files should go primarily to the Windows folder? Or the WinSxS folders (side-by-side win32 assemblies). As you understand driver installations confuse us all.
Windows 10 Detection: It appears to be a challenge to detect Windows 10 due to the new "evergreen versionlessness" of Microsoft. I have this old answer written up to summarize my current understanding of it: Windows 10 not detecting on installshield. Deployment tools such as Advanced Installer does the job for you and detects Windows 10 with simple measures. Not sure what Installshield does. The linked answer lists a few approaches to detect the version yourself - not sure which is the saner approach. Please read (and also please report any interesting findings when you have a successful package).
The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
How do I avoid triggering self-repair from my WiX generated MSI package?
This is a Q/A-style question with an answer that just list a few things not to do in your MSI file to avoid the most common causes of repeating self-repair.
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
General WiX / MSI Advice: This self-repair piece was
split from the original answer on general MSI problems:
How do I avoid common design flaws in my WiX / MSI deployment solution?
Short Summary
I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file. Other deployment specialists, please extend the "pitfall list" below.
The earlier answers I wrote turned out to be developer relevant, but not developer friendly:
How can I determine what causes repeated Windows Installer self-repair? - Focuses on understanding the self-repair problem in general. Setup developer / application packager focus.
What do I do when launching an application triggers repeating, endless Windows Installer self-repair? - Provides a checklist for solving self-repair scenarios. "How to fix focus" - rather than just understanding. For developers, sysadmins, application packagers and end users. How to handle bad MSI packages in general - from any vendor or source, not just your own.
I think there is time for yet another perspective on self-repair. Now I can finally write what I intended all along: the developer's view of self-repair - some of the pitfalls to avoid for developers who do their own setup development work - often using the WiX framework. Just a short, concrete list of things not to do in your MSI package.
MSI / WiX design pitfalls causing self-repair issues
This is a rough first-draft. These bullet points will be fleshed out when time allows.
You mess up the installation of shared runtimes. You don't use merge modules to deploy globally registered, and/or shared runtime files. Rather you install your own copies of the files and register them system-wide. This is particularly bad for COM files, but applies also to other types of files. Conflicting applications will try to put their state back, and "self-repair fighting" results on every alternate application launch.
You run into the empty folder self-repair peculiarity. You create an empty component with a directory key path without adding a CreateFolder entry. This causes an endless loop where MSI removes the folder and then triggers self-repair to put it back. There might be protection in WiX against this at this point.
Incorrect component reference counting. You create a suite of packages yourself that install a file with the same name to the same location on disk from different MSI setups using different component GUIDs. This will most likely trigger self-repair as the packages "fight" to put its version of the file in place. There are several "fixes" for this such as designing a merge module, using a WiX include file, installing the file without reference counting (blank component guid) - (more details will be added soon).
Erroneous per-user file installation. You install files to the user-profile and set a file key path instead of a registry key path in HKCU (required by MSI design guidelines). This frequently cause regular users to experience repeating self-repair that never succeeds due to missing disk permissions. The key files are not "seen" by the regular user because there is no read permission where the key file resides (another user's user-profile). Here is a color illustration. And in addition to a link, in image form as well:
Erroneous disk / registry custom permissioning. This problem is different, but similar to the previous issue. You apply custom file, folder and registry permissions during installation that removes read access to installation locations for regular users. Regular users will see repeating self-repair that never succeeds. This can happen to "per machine" file locations as well, not just user-profile paths (like the previous issue). I hear rumors that some have seen this in particular for write protected ini files as well.
You leave ref-counting enabled for temp files. For some crazy reason you decide to install a file to the tmp folder or another folder that might be cleaned up at any point. Perhaps you intend to run the file from a custom action or something. In either case you install it via a component with a component guid and a key path set, and when the file is "cleaned" from disk, your MSI file will try to put it back. This repeats every time the file is "cleaned". Since the install location is likely a per-user location, other users might not "see" the file from their login, and they experience immediate, repeating self-repair whereas you only see it when the file is "cleaned".
Malware - real and false positives. You install an unusual binary without running it through a basic virus / malware screening. It is as important to check for actual malware as it is to check for false positives (one malware scanning service to use is http://www.virustotal.com - almost 70 different scanners - pay special attention to the major vendors - obviously). So you ignore the malware check, and after deployment your product suffers false positives from several anti-virus vendors and self-repair will run in vain trying to put back the file only to have it "quarantined" again. Your customers blame you (funny how a false positive can be harder to get rid of than real malware?). The result is of course equally bad if you actually install a real virus or malware instead. The result is exactly the same - self-repair keeps running in vain. On the other hand, if the binary was infected after installation, then self-repair should serve its purpose and run once to put the clean file back in place. The major problem is that fixing a false positive is actually harder than dealing with malware (malware is of course worse for the customer if it causes data loss, but it is understood that this is out of your hands as software provider). With malware you simply tell your client to rebuild their PCs and reinstall your software, but with a false-positive you need to do something to whitelist your binary - often with several security software vendors. How do you deal with this process? As malware seems to become worse and worse and security is attempted tightened in any way possible, false positives are likely to become a major deployment problem - even more so than now. A lot of time can be wasted trying to get your binary whitelisted. And the obvious, but let's just say it out loud: don't brave this task on your own as a deployment person - this whitelisting is a huge task that requires management involvement. The problem affects everything for a software vendor: sales, development, marketing and support. As security software become more advanced and "smart" - they may start to quarantine the whole cached MSI on the system that is found in %SystemRoot%\Installer (used for maintenance installs, repair and uninstall). When this happens no self-repair will be possible - and also no uninstall (!) - unless you have access to the exact, original MSI that was used to install with. In these cases I suppose you could try some of the options listed here to get your MSI with malware or false-positives uninstalled: Why does MSI require the original .msi file to proceed with an uninstall? or section 12 here: Uninstalling an MSI file from the command line without using msiexec.
You install desktop files likely to be deleted by the user. This is a "fringe case" requiring that you have also erroneously set the key path for the installing component to a disk key path (rather than the correct HKCU path). Most of the time you put shortcuts on the desktop, and this is fine. However, if you install a data file of some sort that the user then deletes, you could see it put back by self repair when your application is launched via an advertised shortcut, or even if a advertised COM object is instantiated or a particular file type is launched.
You install advertised shortcuts to the "Startup" folder. Don't install advertised shortcuts to the "Startup" folder. It can trigger self-repair to run on every system startup without any user interaction taking place at all. Deleting the shortcut has been reported to also trigger self-repair. This is something I have never actually seen, but it makes sense.
You use a HKCU key path (or HKLM for that matter) that your application changes. Any setting you write from your MSI to the registry should generally not be modified, or worse, deleted by your application's operation. Self-repair will likely result. Only write data that the application just reads. Your application itself should always populate all default settings to HKCU, and your setup should never interfere with them. The same goes for userprofile files. They should be copied for each user from a per-machine template location. The overall moral of the story: deploy only per-machine files and settings (HKLM). Everything else should be initialized by the application: Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?.
Your setup writes to registry keys that are periodically overwritten by group policy. I believe I first saw this problem in relation to some IE proxy settings keys in HKCU being set using an MSI. Using an MSI to just set a few registry keys is always a bad idea for a lot of reasons. Please see this serverfault.com answer for a list of several problems: MSI package for reg deployment (recommended quick read, though it is most relevant for system administrators, but important to know about for developers). I am having trouble reproducing this problem since self-repair is triggered when key paths are missing (generally not just changed or modified). Perhaps group policy actually removed the HKCU values that were added by the MSI? We did see the problem, so this is probably what happened. The overall message: never use an MSI to just set a few registry keys, particularly if they are in HKCU. Use group policy, logon scripts, VB Scripts, PowerShell or other, more reliable measures such as having applications do it on launch (once per user).
You register a particular file / MIME association or command verb in your MSI file. Most self-repair seems to be triggered by COM registry interference between products that triggers self-repair on COM object instantiation, or the invocation of an advertised shortcut. However, you can also trigger self-repair via file / MIME associations and command verbs. In particular file associations could be registered by other applications / MSI files on the system, and this could trigger very persistent self-repair as each application tries to "steal back" the file association. Use these features sparingly in your MSI - and make sure the file associations you register really are unique. Never set a "common" file association in your MSI setup (for example jpg).
The same MSI is installed twice (or more) by mistake. This sounds strange, but it is possible in several ways actually. Self-repair might not be your biggest problem if this happens, you will see other problems too:
You forget to generate a new package GUID for your rebuilt MSI. Windows Installer then treats the two different MSI files as the same file "by definition". I believe I have seen self-repair in these cases, but you will be facing a plethora of other problems as well, all equally weird. Always auto-generate the package GUID. There is no reason for any two MSI files to have the same package GUID (unless you are testing something incredibly obscure in the Windows Installer Engine). While fully aware of the problem of duplicate GUIDs, it still happened to me many years ago using Installshield during some very hectic development. I still wonder how it actually happened - but it did. Perhaps it was an unknown bug in the tool?
A failed major upgrade can leave two versions of your setup installed at the same time. You see two entries in add/remove programs. Self-repair problems are possible in these cases, but so are a plethora of other problems. In my experience this problem is serious, but not as bad as using the same package GUID for two MSI files (previous bullet point).
I am sure there are several other ways the same product can end up being installed multiple times. Perhaps failed multi-instance transforms can cause the problem as well? I dislike that particular concept so I haven't really tried.
Some general "runner-up" self-repair related issues:
Run validation on your MSI and several of the above issues will be flagged and easily eliminated.
Never run MsiZap.exe on your developer box or any machine that you can't easily revert. In fact don't use this "tool" at all. You will often see self-repair problems when deploying on top of the "dirty state" created by the MsiZap.exe's nuking of the MSI database.
If you need to install COM shell extensions, make sure to test thoroughly when using Windows Explorer and switch between different view modes to check if self-repair kicks in. A COM object like this is essentially in continuous use, and self-repair is hence very likely (certain) if any settings are interfered with.
If you put an advertised shortcut in a feature by itself it should almost never trigger a self-repair. Key path checking is done for the feature the shortcut is in and for all its parent features (last time I checked ;-) - which was years ago).
Self-repair related answers (links for safekeeping):
What could be causing MsiInstaller to continuously reconfigure applications (EventID 1035)?
How can I determine what causes repeated Windows Installer self-repair?
Serverfault.com: How can I determine what causes repeated Windows Installer self-repair?
MSI self-repair triggered for the non-admin user when Tabctl32 was installed via merge module
Diagnosing self-healing MSI
why does windows installer start up everytime i start up visual basic 6
We have the scenario with an application with one .Net- and one VB6-client that should be deployed as a single bundle. The VB6 part on its hand contains its binaries as well as an ComPlus proxy. The proxy's installer is generated using COMAdminCatalog.ExportApplication. The three parts is bundled together with WiX Burn and uses the standard bootstrapper application. The creation of the bundle is part of an automatic build and deploy chain.
The problem is how to handle the proxy's installer in the bootstrapper.
There is no way of controlling the product- and upgrade code or version in COMAdminCatalog.ExportApplication. Thus a previous version can't be upgraded by a new. (At least I have not found a way, is there any?)
The msi generated from COMAdminCatalog.ExportApplication does not handle repair or reinstall. Will result in error and rollback of whole bundle.
Two versions of the proxy cannot be installed at the same time. Second one will result in error and rollback.
I have had some progress wrapping the complusproxy.msi in a bat script and use ExePackage instead of MsiPackage. The script begins with removing any previous version of the complusproxy. The problem with this is to get all different install/upgrade/uninstall-scenarios to work correctly.
I'm considering the option to edit the generated complusproxy.msi to get control of the upgrade code and version and add that to the build process.
It feels like I'm trying complex work arounds and it should be a correct, better way of doing it. What would be a better or good enough approach to solve it?
How can I create an automated Installer for a program that has a regular Installer with questions like:
Install Directory,
Accepting License,
Creating Icon on Desktop
etc...
Assuming that I am OK with building an Automated Installer for every program I want to separately, Or i want to put files in a Self Extracting Archive and run the Installer after unpacking.
Do I need a third party program for it? Should I use Command Prompt? Do I need to learn Lua? (I'm learning C#)
EDIT:
To clarify I'll use an example:
Let's say i wrote a program but that program has a requirement, like
DirectX, or Adobe Air, or Maxthon Browser.
I wrote my program in such a way that I have to be sure that that is
installed in a very specific Drive/Folder on the PC or with some
specific preferences/parameters.
I include an installer for this program, but I want to specify where
it gets installed on the PC and with what parameters.
Preferably Installing this requirement right after or during the
Installation/Extraction of my own program.
I'm looking for a way to be able to run the Installer of any given program and navigate through the install wizard of it with out the user having to/being able to change the settings I need (with the foreknowledge and permission of the user of course).
It doesn't need to be silent install or anything.
I have rewritten my answer.
Your mentioned setups requirements seem very common to me for the class of installation programs (setups) and not at all unusual.
Generally you have two options:
You write everything on your own, you create the install dialogs, the way the settings are saved, and so on. Then you are fine with C# (or any other language).
It is quite uncommon to do so, because it is time consuming, and you are reinventing things which have been solved in standard ways several times. Moreover you will fall in common setup error traps which are maybe already captured (or at minimum documented) if using tools.
If you want to use a tool, it is your first decision, if you want a tool based on MSI (Windows Installer) or not. MSI is the most powerful and most industrial-accepted setup technology in Windows, but it is a quite complicated matter, and no tool can shield this 100% from you. Google for WiX (Open Source) or InstallShield as starting points for MSI tools but there are of course more.
Some tools are already integrated or integrateable in Visual Studio for example.
Selfextracting tools are a starting point, but the following tools offer far more and are a good intermediate way between the extreme points SFX and MSI:
InnoSetup
(has also a home here on SO).
Nullsoft Scriptable Install System (NSIS) on SourceForge
One self extracting program in Windows I want to mention, because it is not widely known, that "IEXPRESS.exe" is already included in the OS.
Concerning your special question of navigating through the install wizard:
Every mentioned tool has ways to save install settings and of course is deciding which settings are changeable by the user part of the 1*1 of setup creation. With the tools you can design the install dialogs like you want consisting of the parts you want.
I hope I got your point.
P.S. While most tools have kind of a scripting language or something similar included, you are normally free to extend the installation process with your own actions written in nearly every programming language you like.