I'm testing the compatibility of two products (A) and (B) within a TestAutomation project. The test verifies that product (B), which is actually the product under test, can be installed eventhough (A) is already installed --> to do so, the installer of (B) looks up if the UpgradeCode of (A) is present.
NOTE: I already know the UpgradeCode of (A). What I'm trying to do is to write it into the table that will be looked-up upon installing (B), WITHOUT actually installing the MSI of (A) - this is kind of like a "mock" in integration-testing.
The test is running on a VM where (A) is not already installed by default. My goal would be to write a script which would allow me to skip the "real" installation of (A).
QUESTIONS:
I'm not sure of where it looks the UpgradeCode up. It is NOT looking it up in the registries (I aready tried that hack). I have found the UpgradeCode within the Win32_Property table... is that the right place to look into?
My guess is that I have to emulate the API-call, with which the original MSI from (A) sets its UpgradeCode... any idea of how that works? Possibly with a Powershell script. I have seen online people modifying the WMI properties tables can with calls to gwmi (then using put) or swmi, but all my attempts so far failed.
NOTES:
I do not really know my way around with the Windows Installer nor with PowerShell... this is not at all what I usually do. An answer in Layman terms would be much appreciated.
I know that there are other ways around this (e.g. a dedicated VM or performing a "real" installation of (A)), but I'd like to know how to achieve this programmatically.
Why I need to do that? It's an automated test that only concerns the installer of (B). I do not want the success of my test to be depending from (A)'s successfull download or installation.
The easiest way to do a test without installing the actual A would be to produce a small MSI with the same UpgradeCode and ProductCode and install it. I can't see why you want to "fake" it when you can just do the real thing.
If you want to prevent the install of B when A is already installed you could add A's UpgradeCode to B with OnlyDetect=yes, that will set a property that can be used to prevent B from being installed. It's not clear what the context is for not installing B, whether you have external launchers, a bootstrapper, or which tool is being used to generate the MSI (because some tools will give you help if you want to skip B if A is installed with their built-in detection features).
You can get the UpgradeCode via WMI (Win32_Property WMI table) or via MSI API (Windows Installer Database - registry).
I would not hack the upgrade code in the Windows Installer Database for any reason. Why do you need to fake the UpgradeCode? Is the install of product A very large?
WMI / PowerShell / VBScript:
How can I find the Upgrade Code for an installed MSI file?
WMI is very slow to use, and can cause side effects such as self-repairs and in certain cases spam the event log with error messages. See the Disclaimer section here.
MSI API:
You can use MSI API COM calls (VBScript, Javascript, etc...) or MSI API Win32 calls (C++).
Here is a hacky way of getting the Upgradecode via
a session object using VBScript. I am not sure what side-effects - if any - result from spinning up many session objects: Is MsiOpenProduct the correct way to read properties from an installed product?
Related
I am working on a project where we need to repeat certain steps with powershell to deploy stuff. i would like to create a process/install guidance (steps supported with UI) with WIX but after the msi has finished i have an entry in programs and features. I just need it to execute the powershell and the end without registering in windows. i might be using the wrong tooling or whatever, any suggestions are welcome.
Definitely not recommended unless you want to track the deployment of these scripts on different systems by checking the entries in ARP (Add/Remove Programs), and even then it clogs up the Add/Remove view of your computers. Most system administrators hate this approach, it is better to just write to your own registry key and read it back from every machine.
What are the scripts doing? Are you actually installing files.
Okay, I am trying to write an installer that installs multiple programs. The installer needs to be able to either get the files from a web server, or be able to package the files into a single installer file.
The end result I am looking for is a user hits a webpage, they can click a link to download a single installer file and the installer goes ahead and installs each of the programs. Quiet installations would be preferable but not absolutely necessary. I am trying to make this as user friendly and idiot proof as possible.
Grabbing the installers for each program from a web server would be preferable so it always grabs the latest version and I will not have to tweak the installer script each time the programs are updated.
I have looked into NSIS and MSI, and neither seem to be able to do what I need. I have entertained the idea of using Java Web Start to run a Java program that can install everything, but I am not sure the plausibility of that. If that is possible, then the user would not even need to run a file the Java Web Start would just take care of everything.
Perhaps Ninite will help.
If not, there are two possible solutions:
You can try using a MSI wrapper which installs the applications as prerequisites or through custom actions. It's dirty and complicated, but MSI is a standard.
You can write your own application which handles the installers. This is most likely the best approach.
Essentially, the question I'd like to ask is related to the automation of software package deployments on Solaris 10.
Specifically, I have a set of software components in tar files that run as daemon processes after being extracted and configured in the host environment. Pretty much like any server side software package out there, I need to ensure that a list of prerequisites are met before extracting and running the software. For example:
Checking that certain users exists, and they are associated with one or many user groups. If not, then create them and their group associations.
Checking that target application folders exist and if not, then create them with pre-configured path values defined when the package was assembled.
Checking that such folders have the appropriate access control level and ownership for a certain user. If not, then set them.
Checking that a set of environment variables are defined in /etc/profile, pointed to predefined path locations, added to the general $PATH environment variable, and finally exported into the user's environment. Other files include /etc/services and /etc/system.
Obviously, doing this for many boxes (the goal in question) by hand will certainly be slow and error prone.
I believe a better alternative is to somehow automate this process. So far I have thought about the following options, and discarded them for one reason or another.
Traditional shell scripts. I've only troubleshooted these before, and I don't really have much experience with them. These would be my last resort.
Python scripts using the pexpect library for analyzing system command output. This was my initial choice since the target Solaris environments have it installed. However, I want to make sure that I'm not reinveting the wheel again :P.
Ant or Gradle scripts. They may be an option since the boxes also have Java 1.5 enabled, and the fileset abstractions can be very useful. However, they may fall short when dealing with user and folder permissions checking/setting.
It seems obvious to me that I'm not the first person in this situation, but I don't seem to find a utility framework geared towards this purpose. Please let me know if there's a better way to accomplish this.
I thank you for your time and help.
Most of those steps sound like things handled by use of a packaging system to install your package. On Solaris 10, that would be the SVR4 packaging system included with the OS.
I have been tasked with looking into our deployments, and seeing where they can be streamlined. Right now we have 4 different configurations (Debug/Dev, Test, Staging, Release) and 4 *.config files. We have a task that will overwrite app/web.config with the appropriate *.config pre-build time based on the active configuration. An MSI is created, and we do a full deployment of the component on release night.
This is not entirely ideal because if we change something in a config file, or fix the spelling in a specific view we have to re-deploy the entire thing. Not to metion that the MSI will occasionally require a reboot. One other option that has been brought up is instead of creating MSIs we could create custom deployment/rollback scripts and have the ability to do incremental release.
Has anyone here tried deployments both ways? What are some of the pros/cons you have found? Is there a third way we haven't thought of?
edit: Just to clarify a few things...We don't deploy to customers. All software is deployed to our servers. (a few sites, and a lot of windows services). We never change things in production. We actually use the built in system within VS to create the MSI, so that part isn't the terrible part. To me it just doesn't make sense to redeploy an entire website if you had to change 1 view. We also have to deploy to multiple servers. Right now that is done by running the MSI on each one.
MSI pros:
Application/service/site gets installed and registered like most other Windows apps, and shows up in Add/Remove programs
Some built-in support for re-installing, upgrading
Has some built-in support for installing Windows services/IIS sites/lower-level Windows features
MSI cons:
Seems really cryptic once you get "under the hood"
Seems more difficult to customize than using a custom script
Script pros:
Easier to customize, although certain steps might require lots of/cryptic scripting (working with IIS, lower-level computer administration)
Don't have to deal with low-level weirdness of MSI
Script cons:
.bat scripting is not the most readable or writable language. (Powershell is better, but then you have to worry about whether Powershell is installed on the target machine).
Low-level operations require a lot of administrative scripting for commit/rollback behavior
No built in support for installing or rolling-back (MSI has some support built-in)
One thing I've come across that helps with MSIs is WiX (http://wix.sourceforge.net/), but even WiX seems pretty cryptic in a lot of ways. We use a combination of MSBuild and WiX to do automated builds and deployment/installs, and it works okay for us.
Overall, I'd probably lean more towards doing MSI/WiX (or other installer toolkit) deployments over scripts. MSIs are the standard way of doing installs on Windows, and once you get it working, you usually don't have to change too much. MSBuild or some other build framework (NAnt, etc.), can be useful for setting up the deployment (renaming files, doing string replacements, etc.), before putting together the final MSI package.
Running a dev company that build web apps for five years we struggled with this and tried a bunch of solutions. Here are a couple tips:
Always replace the entire web directory with your code (except if you have content generated by the web site, like a CMS). It's pretty fast to do this and incremental deployments can introduce phantom bugs if files are left around.
Have your build process (Nant, MSBuild, whatever) mod the .config files for each environment and build for what you push for. Alternately you can use registry settings so that the .config files are the same but that means a dedicated machine for each environment. May or may not be an issue.
Don't make changes in production. If you need to make changes (spelling errors on site) make those top priority to get changed in dev so that you don't overwrite them with the next push.
If you aren't using MSI's then make sure you have a rollback process. Keeping a copy of the site just before you changed it really helps when something unexplained goes sideways during a roll-out.
I don't know that these tips point to MSI or script. I think it's a matter of which you are most comfortable with. MSI's can be hard to customize, but easy to run and manage. Microsoft has lots of tools for managing roll-outs of MSI's across an organization or farm. Scripts may require custom tools and custom tooling or lots of manual work on the production end.
We ran scripts with Nant and a custom deployment harness. These days (VS2008) building deployment packages is much easier.
Your best option is to get a decent MSI builder to do the job with - i'm talking about InstallShield etc (there are a couple, so do look around). While these invariably cost, they can save you a huge amount of time/money/pain further down the track. Having said that, the pain is not totally eliminated, just reduced :)
Anything tricky you need to do can be done as a custom task within the msi - and you can even do this with the setup builder that comes with Visual Studio (if you are using VS).
I have a suggestion for your config files - include all four in the msi, and then have a public property which can be set from the command line. You can then modify that public property to install the appropriate config file (and have the default value of that property set so that the release config gets installed). That way, your customers just use the msi and get the correct config file, but your test team can get their config file by changing the value of the public property; the command line they would use to do the install is this:
msiexec /i "MyInstaller.msi" CONFIG=test
You can do install scripts quite easily, but as already mentioned you also need to script the uninstall. Using install scripts precludes you from getting Windows certification for your product should you look at getting that done. But that doesn't mean you shouldn't use install scripts, they may be the perfect fit for your needs. Alternatively you may look at using a combined script/msi approach by having your scripts run as custom actions from within the msi.
In your opinion, are MSDeploy packages a good option for giving to an end user to install a webapplication on their system. How does it compare with, say, the experience of using an MSI file to install a web app?
Has anybody tried wrapping up an MSDeploy package inside an MSI package? Would it work?
MSDeploy was described to me as a tool that helps synchronize web sites between machines, much in the way that AppCenter used to replicate a well configured master to many machines. The Windows Installer (MSI + WiX CustomActions for IIS and SQL config) is about applying packages to a machine that modify state in a transaction. It follows the more traditional packaged software model.
Those are two different approaches to the problem of configuring machines. Each is optimized around a different set of requirements. MSDeploy = replicating machine state. MSI = apply changes in transaction.
Could you throw MSDeploy into an MSI? Probably. Would it work well? Maybe, if you ignore the part about transaction. That in my mind is the key difference. In environments where you want to declare the configuration you want distributed and have it either apply fully or not apply at all (i.e. don't end up in an intermediate/busted state) then package based installation seems appropriate.
If you have a machine that you configured just right and want to make a bunch of machines look like it (and are willing to take a failed machine out of rotation and repeat the process until it is beaten into submission) then MSDeploy seems appropriate.
There isn't enough information in your question to suggest which works better... but I don't think they go together. <smile/>