As part of our nightly build on windows, an installer package is created using NSIS. I would like to automatically test the "correctness" of the installer.
This might be things like:
Checking the platform of dll files.
Checking the install folder.
Testing the uninstall function doesn't leave any files behind.
Checking registry keys are created in the right location.
Are there any tools or techniques that could help me achieve this?
I don't think VM's or automated processes to push the package to the VM is an answer in itself. The real problem here is 'How do you know the integrated / deployed product will work?' I think the only answer to that question at this point would be to then have automated processes to test the application itself in the deployed state.
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
Some background to my problem...
We are currently using ClickOnce to deploy part of our solution which was working a treat until we encountered a scenario where we are now required to have multiple instances of our application installed on the same PC. We are able to achieve this internally and have this working perfectly as we know what instances we have so our build process will update AssemblyName to include the instance name before publishing the installer, this means we are able to have multiple instances on our PCs internally (ie, test, live and demo etc).
Our external deployment process is slightly different, we take one of the ClickOnce installers created in our build (along with all our other components that make up our application) and as the ClickOnce installer is deployed on a server we update the app.config along with the manifest files and resign so they now have client specific details. If a client chooses to have multiple instances of our product installed the ClickOnce will now fail when a second instance is installed on a desktop PC as all instances share the same assemble name.
So finally to the question, does anyone know of a way to update the manifest etc after the clickonce package has been created to allow multiple instances to be installed? We could go down the route of building many clickOnce installers but I dont think this will really work for us, is there perhaps an alternative to ClickOnce which provides a similar upgrade experience for non-admin users?
Hopefully someone will be able to share their experiences and help me resolve this.
Thanks in advance
Doug
I don't know of another technology that allows such a simple auto update process. So sticking with ClickOnce... I think this link might be useful. It explains what you need to do to have the same app installed twice. Essentially changing the assembly name and product name should do it.
Hope that helps.
Greg
Our company release a new version every month, with the latest data. We currently supply a CD with the installation program to our customer. We had the request to create a MSI file.
I am looking for a MSI tool that simply create/copy a folder on the C:\.
In the best scenario the solution would be an application that we only have to install. We do not want to program it all.
You can try WiX toolset with the help of WiX Tutorial. It should be quite easy to make a simple installation.
And don't forget to think about Upgrade policy: whether the installed package should be automatically updated with a newer one.
Better approach will be to use ClickOne for automatic application updates or something similar.
I am managing a build lab and have several products/branches to provide service to and I would like my build machines not to be specialized to any one product/branch.
The scenario I would like to have is that souce and all tools needed to build it are checked into source control and just sync and build with some prep/env setup before hand via script.
This is very doable with Visual Studio and many other tools. Is it possible with Xcode? Has anyone gotten a scenario like this to work?
Some system components may need to be shared. Since this is such an atypical scenario, documentation will not be readily available. I would suggest asking on the Xcode-users mailing list that Apple maintains, as you may get a more certain answer.
I doubt if this possible. There are 2 possible ways I know of.
First, which we also follow in our project:
Source code for all projects in checked in the common repository.
A remote server is configured to point to this repository.
Remote server has XCode pre-installed. A pre-written scripts with steps including workspace cleanup, checkout fresh code, build the code, package the output is already feed into the remote server. Of these XCode related commands are using xcodebuild.
Remote server can be configured in 3 ways: a) Build the source code on every checkin, b) Build the source code triggered by user, c) Scheduled building of the source code.
Build results are emailed to the configured email addresses.
Second way is the continuous integration with MAC OS X server.
Just in case you found out the exact system config you are looking for, please post an answer here to enlighten us as well.
I am starting to do some installer work using WiX (yay, not Installshield) and I was hoping to do some TDD of the installer. Does anybody know of an easy way to do this?
It sounds to me more like an integration test than TDD.
As far as i can tell there are no MSI testing suits per se.
Nevertheless you could try something like this ( assuming you have a contiunous integration server):
after successful build, install MSI on a clean virtual machine - if installation fails do something (mail, ticket, whatever)
run whatever integration tests you have on your project
After that you can be sure that installed application does what it should.
Does it make sence, if you create some script file that checks that files are on the right places. I expect make it as perl or python script
test_installer_wix.pl
msiexec /x product.msi # remove
msiexec /i product.msi /silent # install
ASSERT_EXIST_FILE(PFILE, 'productname/application.exe')
ASSERT_REGKEY_EXISTS()
and etc.
I want to add link to post about how to create unit test for WIX installer database: http://miroslawmiodonski.blogspot.com/2012/10/how-to-create-unit-test-for-wix.html
It might not be a bad idea to run a few standard tests on a generated MSI. MSI files support a lot of different deployment scenarios: admin install to extract files, advertised install for active directory, silent install, maintenance install, uninstall etc... Maybe it is indeed an idea to create a small test suite for this - perhaps it's even being considered for the WIX toolset for all I know.
However, I think the first, best step towards delivering a quality setup would be to run the MSI through the MSI validation suite. These are referred to as ICE (Internal Consistency Evaluators) and they are delivered as *.cub file with the Windows Installer SDK. Running these scripts tend to reveal lots of bad design constructs in the MSI. The WIX tool for this is called smoke.exe.