I am developing an installer for our companies application using WiX.
One of the things I've noticed when testing is that running the same installer twice (after a successful install) causes the install to be aborted because the same version of the software already exists. I need behaviour that allows the same installer to run multiple times, and install the same application multiple times.
This is because when we deploy to our clients (which has been manual) we always deploy in both a Test Environment and a Production Environment. The code bases for the two environments are identical. Additionally some clients wish to have multiple production / test environments on the same machine.
Is there a way to suppress the version information for the installer, so that it will ignore any previous installations and install again? I've tried so far suppressing PublishProduct, but it does not give this behaviour. It appears that the version attribute is also required (I cannot remove it).
In order to run both installation on the same machine you will need to:
Change the product code to "*".
Remove upgrade code or change it for each installer.
Change the path of the installation for each install.
The easiest thing to do is to have a MajorUpgrade element in your install, sequence it afterInstallInitialize (so it uninstalls the older version then installs the new) and also set AllowSameVersionUpgrades to true. You will need to have the ProductCode and PackageCode values to * so each build creates new guids. Basically it's the ProductCode that says a product is installed and you can't install the same product twice - it needs an upgrade.
Related
I have application on C# created in Visual Studio 2015. I added installer project and created installer of my application. My installer saves path to install directory of my app in registry.
Is it posible when run installer to check if app is currently istalled - run it, if not - run installation progress?
My purpose is: I need to create a CD disk with my app. When user inserts this cd disk at first time the installer is run. When user inserts this cd disk another time the installed app must run without install process.
Autoplay of inserted CDs is something that is frequently turned off (the security risk) so I wouldn't count on anything automatic happening.
The normal behavior of inserting a CD and "running" it for an installed product is that a maintenance/repair operation occurs. It's probably not a good idea to change this behavior. Also, if your installed product is broken in some way and goes into repair mode then the user will be asked to insert the CD to get the install repaired (such as installing deleted files) and again it wouldn't be a good idea if inserting the CD broke this behavior and decided to run your app instead (or at the same time).
So this isn't really an install question because it's about the design of the program you put on the CD that deals with all this when the user runs the CD. It will need to see if the product is already installed, and if it is then run the installed app, except that the user may have put the CD in because Windows asked them to for a repair, and I don't know how the program can detect that it was inserted for a repair. If the product isn't installed then you run your setup. This all code you'd need to write, dealing with the issues that people have raised.
There are many issues here, and also I've never seen a product that behaves like this, so that's something else that users don't expect. It's not a good idea, as everyone is saying, and you almost need to decide which features of Windows Installer you want to break, such as repair and maintenance.
I made an application with version 1.0.0 and it installed in my computer (because I made a setup for it), but I already changed some code in it (and this version is 1.0.2). So, how do I make the application on my computer that has version 1.0.0 up to date to 1.0.2? What do I need to do in order to have my application in my computer or other computer that has version 1.0.0 to version 1.0.2?
I used MSI.
Check this post: How to upgrade via msi.
Additionality I recommend that you also check the WiX Toolset for creating Windows installers - it alows making almost everything
There are two type of upgrade you can do,
Upgrading the whole application
When I say upgrading the whole application, existing application will be uninstalled and new msi will be installed with new changes, You can easily handle this with MSI.
Change the version number of the new MSI (default version is 1.0.0)
When you change the version VS will prompt a message whether to change the product code. select yes
Make sure RemovePreviousVersion property is set to true.
Also make sure UpgradeCode of old msi and new msi are same.
When you install new msi with above settings it will first remove any older application installed and then installed itself.
Upgrading part of application
When i say upgrading part of the application it could be a dll change or any other resource change. These kind of upgradings can not be handled through MSI(Unless you write your own upgrade manager module). But luckily Microsoft has an elegent technology to handle these type of upgrades it's called ClickOnce.
ClickOnce applications can be self-updating; they can check for newer
versions as they become available and automatically replace any
updated files. The developer can specify the update behavior; a
network administrator can also control update strategies, for example,
marking an update as mandatory. Updates can also be rolled back to an
earlier version by the end user or by an administrator
I have created custom action dll file with embedded resource as SQL Server Compact Edition msi...this dll is assigned as a custom action in setup project ..but when i run setup msi it will throws error saying that another installation is in progress... I tried process.waitforExit(3000) options in code but still couldnt find solution?
Kindly reply
There are basically two ways of including dependancies to your installation. Either through a bootstrapper that runs before your msi-file or as a merge module. As this is a Microsoft product i doubt that it is available as a merge module.
In other words you should probably use a bootstrapper to your application. Try dotNetInstaller
Another option is MSI chaining, although it was not introduced until MSI 4.5, and will require the target system to have MSI 4.5 or later installed. Right now, only Windows 7 has native support, but there are 4.5 redistributables for the older versions of Windows. Finally, be aware that updating MSI with the 4.5 redistributable usually requires a reboot.
MSI enforces two mutexes. 1) One Execute Sequence per Machine and 2) One UI Sequence per process. While it is technically possible to disregard best practice and call your second MSI from the UI of the first, you will lose the ability to have silent installs and some poor customer out there is going to be disappointed one day.
Either invest in a bootstrapper / chainer or another possibility is SQL Server Compact edition is so small that they also support a private deployment model where you just deploy the assemblies in your application directory. The problem with this approach is if Microsoft ever has security updates for those assemblies they won't be able to service them. You will have to rebuild and deploy your product.
Do you need to support silent install? My recollection is that your install won't acquire the lock on the Installer service until it enters the execute sequence. That means you could kick off the SQL Server install somewhere in your UI sequence.
I have a small .NET WinForms application, and couple of linux servers, DEV and CL1,CL2..CLN (DEV is development server and CL* are servers which belons to our clients, they are in private networks and it's a kind of production servers)
I want an update mechanism so that
(1) i develop a new version and publish it to a DEV
(2) users of DEV-server install latest version from DEV
(3) users of CL2 (employees of client2) install stable version from CL-2 directly
(4) application checks for updates using server it was installed from (so, if it was installed from CL-2, it should check CL-2 for updates)
(5) i should be able to propogate the update to a selected CL-server (using just file copy & maybe sed; not republishing), if i want that (and if i don't, that CL-server will have an old version until manually i update it)
I tried to use clickonce, but looks like it meets only first two requirements.
What should i do?
ClickOnce should handle 1-4 to be honest. All that would be needed is that for each site you want to deploy/update from, you'll need it to have its own publish, which after looking at your specifications is not incorrect to do.
What you could then do in order to make 5. applicable, is create an automated process to re-publish the file. This could perform a publish and then upload to the correct server.
Remember that ClickOnce needs a new manifest per version, and a new version requires a publish, so I'm not sure that you'll get around 5. with a simple file replacement.
Kyle is right. But for the 5th note, you just need to copy the deployment, and then use mage to modify the installation URL and point it to the new server, and then re-sign the manifests.
I support an app that we deploy to a DEV, QA, PROD servers. The way I handled this is that
I created created a cmd file that has command line calls to MSBUILD. It builds the app once for each server with the appropriate URLs and switches. I give my DEV and QA builds a different AssemblyName that way I can run all 3 environments side by side. This way my build process is automated and I don't have to publish at all.
Here's an article that describes the parameters you can use.
http://msdn2.microsoft.com/en-us/library/ms165431(VS.80).aspx
#Kyle,
For the above solution can the different versions run side by side or do you get errors indicating the app is already installed.
I have a big MDI Suite application that I've written for our company. It is installed on two Citrix servers, and is then accessed by hundreds of Windows terminals across the plant.
Before installing updates, I (the sole developer) test my new routines until I am satisfied that it is going to perform how I expect it to. This generally works, but it has the group manager worried.
He wants me to install a BETA version that can be tested on in our workplace environment by others.
To do this, I would need to install my application twice on the Citrix servers machines so our employees can test it (right?); however, when I try to install the application again on the same PC (i.e. the Citrix server), Windows says it is already installed.
The VS2008 Setup and Deployment Installer has a Product Code. Should I just change this? What problems do I need to be aware of? Do I need to keep track of two Product Codes (one for testing, and one for release)?
How do I install 2 working versions of the same application on 1 PC?
The safest way is to create new ProductCode, new UpgradeCode, new TARGETDIR and make sure there are NO shared directories (besides the system dirs). Make Windows Installer think it's a completely different product.
Changing the ProductCode, but NOT the UpgradeCode may cause existing components to upgrade. When the install runs the FindRelatedProducts action, it will locate anything with the matching upgrade code and attempt to upgrade matching components.
I strongly agree with cutrisk - stage the whole thing somewhere else first (install released version, upgrade to BETA, open it for internal testing, etc.) Then carefully roll it out to customers.
Trust me, you do NOT want your installer to bring down someone elses production service(s) because your BETA "upgrades" some component and the whole system falls over.
Since you want to allow dual installs that should work. I'd make a new "beta" installer that may target a different install directory to keep bleed over to a minimum.
Here's the MSDN write up on changing Product Code for some more info.
Another possible angle, that may be a lot simpler.....is there a test/staging Citrix server you can host it on? That's how we roll out changes here. But that ultimately depends on your Citrix environment/servers in farm...
Oh, and in relation to tracking the product code, in my experience(right or wrong), that isn't as important as making sure you keep your UpgradeCode is sync.
I'd give the beta .exe a different name: app_beta.exe. You can use the same setup to deploy it. You can also keep changing your upgradeCode with each version of the beta or prod release- it's ok for them to overlap.
prod: 2.0
beta: 2.1
beta: 2.2
prod update: 2.3
next beta: 2.4
InstallShield 2009 and later support "multiple instances":
e.g.:
http://blog.deploymentengineering.com/2008/03/installshield-2009-beta-part-i.html