I have written a plugin for an application which has an installer as an executable. My plugin is installed using an msi, written in wix. We've now been given permission to distribute the two together. Ideally, this would be in a single file with two installations. Both parts would need to be updated seperately, particularly the main program, I have read that this restricts the methods of installation.
I'm having trouble installing the main program first, then the plugin. I have tried including this main exe in the wix as a custom action, but I'm worried that this will mess things up when either program needs updating. I have seen something called an MsiEmbeddedChainer but can't seem to find anywhere that describes how to implement it.
Any advice, or pointers of useful articles would be greatly appreciated.
Most of what you need to know is linked from the Not supported in Windows Installer 4.0 document, but it will likely still take a lot of trial and error. This blog post has a lot of interesting points to help with rough patches along the way. However let me warn you that my experience with InstallShield has shown that MsiEmbeddedChainer chaining is not as reliable as bootstrap chaining, at least in environments with Terminal Services.
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).
I'm developing a windows application (using vb.net) that can install various versions of runtimes like vc++, Direct X, .net frameworks etc on a PC. My program must be able to to run the runtime installers (msi & exe) one at a time in the background and do the following:
1.Check weather the runtime is already (previously) installed or not.
2.Show the installation progress in a progress bar in the main form of my program.
3.And at last get the return code (exit code) from the installer to indicate weather the installation was successful or not.
What are the codes required to perform the above tasks?
Also I want to know what are all the possible return codes(values) an installer can return.
All of those redistributables might have different command line options, so it's not likely to be one answer for everything.
It's not clear how you can get the installation progress. It's almost certainly impossible or very difficult. You're asking how you can run a program that will "steal" the output of some other program, and in many cases that will be Windows Installer. If I had a program that fired off a Windows Form program, then you're asking "how can I get the content of that program and steal the output messages". That's not an install question, it's a Windows messaging/windows message loop question.
The detection methods used by those setups are coded internally (or configured as internal data), so you're also asking how the code in all those programs detects that the dependency isn't installed (on multiple OS versions and 32-bit and 64-bit), and some of that might be available on the web but it's unlikely that it is readily available for every redistributable.
You might also have an issue with EULAs. Some redistributables need a EULA to be accepted and might not install unless it's accepted, or some may have a command line option that includes something like (just an example) ACCEPTEULA=1.
Basically you should:
Find the command line options available for all those redistributables to see if they have an option that displays only progress, then let them show that.
Similarly, see if they have documentation that tells you if the exit code means success or not.
Don't bother trying to find all the detection methods for everything - just run the redist, and if the target is already installed it won't do anything.
Finally, you are re-inventing the wheel. WiX, the Bootstrap Manifest Generator, InstallShield, Advanced Installer (and so on) all provide bootstrapper programs that already do this as prerequisites for installing software. Nobody writes code to do this any more because there are existing solutions.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
1638 for already installed. 0 for successful installation. Yet mind 3010 which stands for success but pending reboot.
About showing progress in parent window .. this may be not a trivial task. Hopefully someone else can give you a hand with that.
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...
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.
I found that Wix v3 uses a tool (heat.exe) to "harvest" information into WiX fragments. Either I am looking in the wrong location, or this is thinly documented.
What is the best way to auto-generate a WiX fragment (likely using heat.exe) for a complex folder structure that contains media files:
Of varying types (ico/png/xaml/etc)
That may change regularly (names/locations/adds/removes)
That are classified as "Content" and included in a .csproj
such that they can be built into an installer via WiX and would withstand upgrades and patches with decorum?
Background Information
I found heat.exe, which seems to solve the autogenerate WiX fragment requirement
In getting the "dir" harvester working, I noticed the "project" harvester (commandline help)
Media is already in C# project file, and so noted that "-pog:Content" might do very well
Cursory search found out of date documentation that didn't mention "project" harvester
Realized entire project installer could probably done with "project" harvester, but was unsure how well this was supported, and what the pitfalls were.
Saw the generation of "PUT-GUID-HERE" and realized that autogeneration of guids would likely have upgrade/patch implications.
Realized that there must be people who use these tools for similar purposes and could probably point me in the right direction.
It was (fairly) pointed out that v3 is not yet "done" (thus the scarceness of documentation and tutorials). The sense that I get now is that it is non-trivial to automate this in my build scripts, and the tools are growing right now to ease this.
In my experience John Robbins' Paraffin solves alot of the issues with tallow.exe (heat.exe in v3). I'm not sure if Paraffin plays nicely with v3, but it might be worth checking out.
FYI, I've used Paraffin in a build process and it allowed me to remove the previous 2-3 step cleanup process that involved a powershell script.
For the upgrade implications of auto-generated setups, read this. The take-home message:
Windows Installer doesn’t let you
remove components in a minor upgrade
It is hard to guarantee that components continue to exist if you generate your setup automatically. Therefore you have to chose between auto-generation of components and the ability to do minor upgrades.
If you have some auto-generated components, then just stick to major upgrades. You can use this sample by Rob as an example.
Thanks for the background, I wasn't aware that they were working on a new version of Wix. According to the project page, it isn't RTM yet, so that may explain the problems you're having. I hope to hear from the WIX developers in one of the replies.
I can't help you use the under-development heat.exe features. However, I have been in your situation and my solution was to create a tool that took directory and file information as input and generated valid wix project files as output. A .vsproj file is just an XML file, and you can use XSL, C#'s LINQ, PowerShell, or a number of other tools to do the work. I personally have used (pre-LINQ) C#/XMLDOM to parse VS project files for this purpose.
Good Luck,
Dave
For documentation, check out the help file that is installed with WiX - WiX.chm provides the most up to date information (along with the command line -help option).