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
Related
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.
MSI Installer can be installed PerUser or PerMachine.
I'd like to detect before the new version installation: was previous version installed PerUser or PerMachine?
If PerMachine do nothing because Installer will remove the previous version and install the new one, ok.
If PerUser then check: was it installed user which is the current user?
If current user==user who installed then suggest to user switch installation to PerUser and continue.
Else give message "User 'other_user' need to uninstall manually etc".
The question is: how I can check in c# the user name who installed the current version of product?
Oleg,
Based on other questions you've asked I understand the jam that you are in. It's unfortunate but there isn't much you can do. You could wrap the MSI in a bootstrapper (EXE) to remove any existing Per-User installation for the person logged in ( assuming it wasn't pushed to the machine using the SYSTEM account ) but that wouldn't handle a situation where some other user profile had installed the app.
Here is about the best thing I can think of for your situation. Create your new installer to install to a new directory and new registry keys ( completely different foot print then your old application ). Give this new MSI a fresh UpgradeCode property. Author an active setup registry key to run a cleanup utility the next time a user logs on and then reboot the machine. Put the old UpgradeCode in the Upgrade table just in case you can get lucky for an old per-machine install.
When someone logs in for the first time your EXE will be run. It can then perform MSI API queries to look for old versions of your product and perform an uninstall. In time your old application will be removed.
I recall getting myself into this situations many years ago before I understood the ALLUSERS property. Per-User installations are a pain and only useful for non-privlidged "viral" (as in socially spread) application. It's not a good story for commercial / enterprise applications.
What you want doesn't make sense.
Per-user installations are visible to a single user, you won't be able to retrieve information about the per-user installed apps for user A if you are running as user B. Only per-machine installations are visible for all user.
Take a look here:
http://msdn.microsoft.com/en-us/library/aa369786(v=vs.85).aspx
Note If an application is installed in the per-user installation
context, any major upgrade to the application must also be performed
using the per-user context. If an application is installed in the
per-machine installation context, any major upgrade to the application
must also be performed using the per-machine context. The Windows
Installer will not install major upgrades across installation context.
Now to answer your question... If you are executing an installer per-user and the upgrade installer detects the previous version, that means that the current user installed it.
I am new to windows application.Created a tool in windows application and with the help of setup build a exe and install it.
If i try to install when it is already installed its showing another version is already install so i have to go to control pannel uninstall it then install it again .
How can i do it in that way
When not install - Install it
When installed - Uninstall it then install the new version.
When you made a working software, next step is called distributing. Which mostly means putting all your software files into a distribute package. For this you have to choose distribute system (my favorite is NSIS).
It is the job of installer to detect whenever software is already installed and offer Repair or Uninstall option. And it should be very basic thing supported by distribute system (read - it will be very easy to do).
How to make generic installation for my C# program, that will work on Win XP, Win 7 32bit and Win 7 64bit ?
I need that all the related components (like Framework... Crystal Reports...MDAC....) will be include and will install only the program that the OS is missing
Thanks in advance
What version of Visual Studio are you using? It matters, because if you're using Express, you're going to need a 3rd party tool If you're using Professional or higher, you can just create a Setup project as described here:
http://support.microsoft.com/kb/307353
if you weren't worried about required components, of course, you could just do an XCOPY deployment, but since you specifically need your prerequisites included with the install, you need to use a tool like the setup project 9which creates an MSI file) or using a third party tool like Installshield.
i think
1- Create 3 separate packages for (Win Xp,Win7-32 , Win7-64)
2- Ask user if user is downloading from the website and push require download from the server. Alternatively , you can write a samll silverlight based application to get the details of user machine.
3- If 2 point is not true than while installing on a user machine get the details first and choose manually which pakage to install.
why i am telling to create specific package because of Microsoft issues pathches time to time and you may need to change the package so keep it seperate will definately help you.
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.