I want basic information about windows installer. I made installer that has version 1.0.0.0. I installs this on your pc. Now I add new features to app and build setup(in debug from date I know its updated) and give it to you(its still 1.0.0.0). you uninstall old one and install this one. I have question here, what would be the impact ?
Actually case is that, I gave build 1.0.0 to my friend, he install this. I make UI and some logical changes in Form1(c#), build the setup(its new but still 1.0.0) and give it to him. he uninstall old one and installs this one. when program executed it shows new UI changes but my friend is asking that UI changed but not logic changed. I cant understand as its not logical argument that if UI updated of setup but not logic.
Can someone give valid argument ?
Well, you're going to be hard pressed convincing your friend that he has a new version, given that the product version has not changed. How can you confirm that he actually uninstalled the old version, or even installed the new version (and not have just run the old installer by mistake).
I think you have two options:
Update the product version of the installer, so that you can prove that a new version has been installed. This could just be a minor or revision version change (e.g. 1.0.0.1)
Set the version of the .NET assemblies. If you change these with each build, even if your installer version remains the same, you can verify that he has the new assemblies.
Related
While upgrading my solution from version 1 to 2 using the new MSI, I noticed one of my custom actions which configure the application was using values which belong to version 1 (on the OnCommit action)
I added messageboxes and logs that print out the assembly version and confirmed that during an upgrade, the windows installer is using the dll from the previous MSI. However, if I manually install the newer MSI the correct custom action is used.
Is there a way to get around this? Have not found much information on why it uses the previous custom action?
I set the RemovePreviousVersions = true and UpgradeCodes are equal while ProductCodes are different.
I believe that this is an old bug:
https://support.microsoft.com/en-us/kb/555184
and there is another support article about it that I can't find. It may have been deleted because it applies to older versions of setup projects. I think the detours are things like renaming the assembly, and changing its assembly version.
The issue (as you might guess) is that the uninstall loads the assembly to do the uninstall, and the assembly from the upgrade install is identical as far as the load rules determine in this situation (reflection loading), so it does not load your new assembly but uses the older one that is already loaded. This all implies that you are using a very old version of Visual Studio setup projects that first uninstall the old product then install the new one. That hasn't been the default behavior since (and including) Visual Studio 2008, so I don't think you'd get the issue with a newer version.
I have created a successful deployment project using Windows Fourms that work as intended but there are two things that need to be solved:-
First: I have to click the setup.exe file in order for the installation to check for the perquisites, and if click the setup.msi it proceeds to install the software directly without checking anything.
Second: When i click on the setup file while the software is already installed on my PC, i get an error message "Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel" while i should get a Repair and Remove options.
Can anybody help me solve this problems ?
As said by Morten, that's how it works. You want to make sure that the prerequisites are (get) installed before your product is installed.
This probably is caused by a rebuild of the deployment package after you installed it. Windows installer notices that you use a different MSI (with a different package code), that contains the same product version. This situation, apparently, is inconclusive enough to leave it up to you what to do with it. The logic of this, I think, is to prevent a "Repair" that in fact installs a different product. Inconvenient for testing, but very much desirable in production environments. If you try to install the same MSI you should get the repair/remove options.
BTW, after building a release, you can right-click the setup project in VS and choose "install". This executes a setup that kindly removes a previous installation with the same version.
I have created VS installer in VS2010. it works fine. when the program is already installed and you re-run the installer it would prompt for repair and uninstall. this is good. the problem is when I re-build the same exact installer and try to install it on a machine that already has one installed it would not give me the prompt repair and uninstall. Instead it gives me pop up error "Windows Installer: Another version of this product is already installed. Installation of this version cannot continue...." then it asks me to do manual uninstall using Add/Remove program from Control panel.
So there is gotta be something changed/auto generated during the re-build. kind a like key or something that is different from the older version which makes the newer one fails to recognize the older version. anybody knows how to handle this?
increment your setup project version and set
- DetectNewerInstalledVersion = true
- RemovePrevousVersions = true
more info : http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/717cfce0-3061-400f-9ea3-069f73f3a473
If you increase the version it will automatically detect the previous version and handle it as per your configuration on RemovePrevousVersions and DetectNewerInstalledVersion.
On the properties on the VS Setup project set the RemovePreviousVersions to True. I believe by default it is set to false. I beleive that would save some time instead of doing it manually.
Also, there is an ProductCode, UpgradeCode, and Version in these properties. These control installation behavior, more information is here:
http://msdn.microsoft.com/en-us/library/aa372845(v=VS.85).aspx
Here are more details:
http://msdn.microsoft.com/en-us/library/aa370579(v=vs.85).aspx
I have a Windows service written in C# using VS2005.
The installation is via a wizard that calls msiexec to install the msi file also created using VS2005.
I am having trouble generating an msi file that will upgrade from one version of the service to another. The wizard program handles detection of the currently installed version, stopping the service, coming up with an appropriate command-line for msiexec and then re-starting the service.
The existing msi has a version property of 1.1.02, the new one is 1.1.03. The product and upgrade codes are identical.
Uninstalling 1.1.02 manually via add/remove programs works fine, as does installing 1.1.03 onto a "clean" system.
Upgrading 1.1.02 to 1.1.03 goes through the motions but the end result is 1.1.02 installed.
The command line that the wizard uses for upgrading is:
msiexec /qb /i "MyProduct.msi" REINSTALL="ALL" REINSTALLMODE="vos"
Where am I going wrong? I'm assuming I must have missed something fairly fundamental...
The fall-back position is to inform customers that they need to manually uninstall 1.1.02 before running the wizard to install 1.1.03 but I'd rather not have to do that.
Edited to add:
Changing the product code (as VS2005 also prompts you to) actually removes the ability to upgrade at all, as it the installer won't let you do a reinstall if that product code hasn't previously been installed.
All it will then let you do is install (and then you get the usual "service already exists" -type message).
There are several things that need to be done to get "upgrades" to work with MSI's if you want to automatically remove the previous version.
First some background information about the mysterious "codes". There are 3 codes (GUID's) associated with an MSI:
Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code.
Upgrade Code - This identifies the application and should not change through it's lifetime
The Upgrade Code should never change. For you upgrade scenerio, the Product Code must be changed for each version. Additionally, as you mentioned, you must bump the version number. The Product Code and Upgrade Code can be found by selecting your setup project and going to the Properties Window. The Package Code is hidden in Studio and will always be updated.
The item you are probably missing, is that you also need to set the RemovePreviousVersions setting in the Properties Window to true.
One more thing in addition to mohlsen's answer (For Visual Studio 2008):
In order for your Primary Output (your EXE!) to upgrade properly, you must increment the FILE VERSION
This setting can be found in the Project Properties: Application Tab -> Assembly Information
An easier way to manage this is to REMOVE the AssemblyFileVersion from all assemblies, including the main executable and all the managed DLLs.
In each of your AssemblyInfo.cs files, I recommend doing something like this if you don't care about the version numbers, but want to have some traceability.
[assembly: AssemblyVersion("1.1.*")]
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")]
Everything still compiles fine, and if you don't have the AssemblyFileVersion defined, then the installer assumes that everything is different every time (which is probably fine if you are installing all of the DLLs next to the main EXE).
I spent a long time figuring this out, especially if I don't want to have to increment anything manually!
I have created a custom installer dll & everything is working fine. I just want to call another installer's Uninstall method from my current installation. When I do this, I get error code 1618 (signifies another installer is already running). However when I call the uninstall of the same product from a test project, it is working fine.
Could anyone suggest a solution to this?
Can I uninstall another application from the current installer?
AFAIK calling an installer (either to install or uninstall) from another installer is not supported. It was supported in earlier versions of Windows Installer, but is now deprecated, and even then I'm not sure uninstallation of an other product was supported.
The recommended way now is to use a bootstrapper to check for and install any prerequisites. Theoretically you should also be able to uninstall a product using a custom bootsrapper, however writing one is not a trivial exercise.
Also silently uninstalling something from a users machine is not necessarily a nice thin. Using the Visual Studio 2005 Generic Bootstrapper you should be able to generate a bootstrapper that checks if the other product is installed and asks the user to uninstall it.
If this other product is your own (and hence you have access to what the installer should be doing), or you want to do something dirty, you could try removing the files/registry entries/etc yourself then unregistering the program in the registry (HKEY_LOCAL(MACHINE|USER)\Software\Microsoft\Windows\CurrentVersion\Uninstall\{PROGRAM}). Not really the greatest idea ever, but if you have access to what the installer should be doing, then it'll work for you.