I am looking at what the best options for creating patches for our clients. They don't want a full blown installer when doing minor patches (from 1.0 to 1.1) since they will need to do a full regression on the system.
I wanted to know whether there is a tool (paid or not) that will take 2 msi builds do a diff/compare and out put a useable patch installer.
Most of the time it will be updates to assemblies (modified or new) but may require some custom script (in c# if possible)
They don't want a full blown installer when doing minor patches... since they will need to do a full regression on the system.
This statement is based on some faulty logic and whoever uttered it is blowing smoke out the proverbial. There is every bit as much risk from a patch install as what there is from a full installer - if the testers have no faith in your build/release process then both need to be tested fully. The msi is just the packaging, a full install or a patch install can both change the whole system. If the testers want to come up with the argument that "with the patch, the file abc.dll has not changed so we don't have to test the functionality in it", then you can argue that that thinking is incorrect - if the code using abc.dll has changed then abc.dll may exhibit different behaviour.
IOW, my argument is that a patch install or full install both carry the same level of risk, and both should be tested to the same level. To minimize the amount of retesting required you need to build trust and certainty with your release process - an automated build/release process and an auditable source control system should do that for you.
In any case, i agree withthe answer from #Christopher - tools such as InstallShield can be used to create a single msi that is either a full install if you haven't already got the product on your machine, or it will switch to upgrade mode if it detects an item with the same product code and a lesser version number already installed. Having said that, it can be incredibly difficult to get that upgrade to work correctly.
InstallShield can do this provided:
You follow strict compliance with the component rules and have a working minor upgrade servicing story.
You are incrementally building your assemblies as to not make the system think all of your files changed.
There are other ways to accomplish this but it takes quite a bit of plumbing to be honest.
To be honest, I've heard your "we have to test it all" story many times and I've never bought the argument. Usually they want to piece-meal their baseline and then stick their head in the sand on what the true test surface is. Usually their real problem is one of SCM / Build / Release discipline and not whether the installer is a Major Upgrade, Minor Upgrade or Patch. ( IMO )
Related
I am using WiX to install a executable and I have used ManagedBootstrapperApplicationHost for CustomUI.
Is it possible to get the name of the feature being installed at the time of installation ?
If possible then how can we get the name of the feature ?
Any help would be appreciated.
Thanks.
Features aren't installed one after another. For example if 3 features are being installed, each with 10 files then the InstallFiles action will install all 30 files at the same time. Same thing with registry entries. So you can't display a UI that says "Installing Feature1" and then later on "Installing Feature2" because that doesn't happen. All you can know is that some list of features are being installed.
Your comment asks about finding out whether a feature installed successfully or not. This issue never comes up - there are never some features that install and others that fail. An MSI install is a transaction and it either all works or fails and rolls back and deletes changes it made so that the system is restored to its previous state.
It's not clear why the list of features is so important to display. If you use the MSI's internal UI there is a feature selection dialog where the user selects which features are to be installed; if you use the Burn UI the same thing is available, so the user can see what features have been chosen.
Inside the MSI the list of features being installed (after they've been selected) is in the ADDLOCAL property, but that's the internal name. It could be used to display a list of the features that were installed at the end, but again by definition what was chosen is installed otherwise the install would have rolled back entirely. I don't believe I've ever seen an install where the list of MSI features installed is displayed at the end - it's redundant info. It would be useful to know the scenario you have, or what problem you're trying to solve, and if you believe that you need to display a list because some might install and others might fail then there is no point, as I have said.
I have finished writing a shake-based build system and have reached the deployment stage.
Is there any resource on best practices for deploying Shake-based build systems in intranet scenarios? I'm concerned about things like reproducing a build 5 years from now, whether plain cabal or stack would be a better fit to build the build system itself, how to track the build system dependencies given there's no internet access...
In order to reproduce a build, I'm considering something like generating a Makefile (easy with my approach) prior to tagging a release, and resort to make for building at points that fail to build using the latest shake version. That would avoid storing copies somewhere of all the dependencies used by shake itself over time, but I was wondering if there're better approaches.
For reproducing builds and the build system, the best way to go is a virtual machine image in which you have the OS, along with all things you might otherwise fetch from the web - e.g. Haskell libraries off Hackage. That should give you 100% reproducibility, and is project/language agnostic.
If you want to avoid a complete VM for a Haskell project, the next-best thing is a stack.yaml file, which specifies a given package set, and thus fully ties down every package version, so will stick to an old version of Shake.
Since Shake is much newer than Make, and has a much larger API, it is inevitably going to change more than Make, and will have breaks that mean your old code will not work anymore indefinitely (hopefully rare, hopefully easily fixable). In contrast, Make has been very stable for decades, so a Makefile backup is probably useful to have if it's cheap to create.
Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.
I have an InstallShield InstallScript MSI project that contains the FLEXnet Connect without Software Manager merge module. The version of this product is 6.0.32. I created a second installer for version 6.1 that also contains the FLEXnet Connect without Software Manager merge module. When I perform a major upgrade on a system that contains the 6.0.32 version I get a message in the MSI log stating:
Disallowing installation of component: {FF970098-B748-427B-B946-AA8E1A1F82AD} since the same component with higher versioned keyfile exists
The component is referencing the isusweb.dll file located in the FLEXnet Connect folder.
It looks like this check occurs prior to the 6.0.32 product being removed. The install proceeds to remove the 6.0.32 product, which removes isusweb.dll. During the 6.1 install the isusweb.dll is not put back because of the component version check.
The upgrade succeeds. When I attempt to run the application from a shortcut it verifies the components. Since the isusweb.dll is missing the MSI attempts a repair, then cannot find the MSI and does not allow the application to open.
Is there some way to get the merge module to always overwrite?
This sounds suspiciously like this bug:
http://support.microsoft.com/kb/905238/en-us
and I've come across this bug and you do see that log message, and RemoveExistingProducts is early in the install. It decides to not install the file based on the higher version being there, but doesn't re-evaluate that decision after the REP removes it. Then a repair restores it when you use a shortcut. The bug should apply only to files in the GAC or SxS, so that's a bit puzzling.
If you can schedule REP at the end of the transaction sequence (InstallExecute, REP, InstallFinalize) that should fix it - might be worth a try, all other effects of the move being ok.
Merge modules don't get installed, they get merged. Product MSI's get installed. One of the problems with using third party merge modules is if they have a bug, there isn't much you can do about it.
I'd consider creating an MSI solely for the purpose of encapsulating this MSM. Then I'd create a setup prereq or suite installer to install this MSI apart from your product MSI.
You have got two really good answers already, but to try and synthesize:
It really sounds like a buggy merge module. Phil suggests to fix your REP placement in the InstallExecuteSequence to work around the bug. Chris suggests to put the faulty merge module in its own setup. I agree with both and think you should follow both suggestions:
Remove the merge module from your main setup.
Create a new setup and add the faulty merge module and ensure the right REP sequencing.
For the REP fix to work your component referencing must be 100% correct - now and in the future. To eliminate this as a problem creating a separate setup allows you to contain the buggy module inside its own MSI. This will help you avoid re-activating the bug by mistake or by changed design in the future - and the latter is never unlikely.
As Chris says: a merge module isn't delivered, it is merged. An updated merge module may be available for all I know, but even then it is wise to contain it. Especially when you are dealing with the GAC (Global Assembly Cache).
Another solution that I applied when encountered this bug was to set to update the "Version" column from File table, in the merge module, using Orca. Set that to the maximum 65535.65535.65535.65535, this will force the upgrade to always install the DLL from the merge module.
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.