I'm using Visual Studio 2017 with the Installer Projects extension to make an MSI for my app.
However, when I run the, say 0.2.7 MSI on a system with 0.2.5 already installed, it adds another item to the appwiz.cpl, and leaves the version the same, so that after the 0.2.7 install, it just runs the 0.2.5 exe.
I make sure that the UpgradeCode is the same, the PackageCode and ProductCode are changing with each version and I have RemovePreviousVersions set to true.
My source code is available here. You'll find the installer project in ChromebookGUI/Installer/.
What am I doing wrong?
You can get a list of upgrade codes for installed packages like this: How can I find the Upgrade Code for an installed MSI file?
I have another one that is a bit simpler, but I couldn't dig it up right now. I will have a look later.
Adding this answer to "evolve" it if you provide more follow-up information (to avoid too many comments).
UPDATE: the other answer is here, but I wouldn't recommend that script if you have automatic logging enabled since it will create log files in the temp folder when run.
Related
I am sorry if this is a repeat but I cannot find what I am looking for by way of the Google (mostly because I don't know what to ask).
tl;dr - Is there a way to make my C# VS Installer project ignore any versioning errors or missing files of previous installs during updated version installs?
Long Version: I have created a C# application that includes 6 files (3 programs, 2 services, and a DLL). I am using a MSI deployment project in VS to create and distribute these files, register the DLL, and install the services. The problem starts when an anti-virus or malware app removes my files (and/or reg keys, services, etc.) from the system. In order to get a new version of my app installed, the MSI must be able to uninstall the old. At this point the install fails because the files or services have been altered and the original MSI package is required. Finding the original can be tricky as my clients typically do not keep them. There were also instances, when I did not know better, when a client needed a custom change to an executable. I would simply change the file and copy it to the users install folder. This further angers the MSI Gods because the file versions are now different than the ones that were put there by the installer. What can I do to easily remove old versions of my application and install the new? I am planning a Major revision and am expecting many headaches over a hundred or so installs otherwise. What else could/should I consider in the future to avoid these issues? What have I failed to comprehend?
Scope: Now that was a lot of questions at once. Firstly, how large is your distribution? How many machines are we talking about?
FixIt: You can try this FixIt tool from Microsoft as a "quick fix", but running that on many computers manually is cumbersome to say the least. Not sure if it can be automated. Never tried.
MSI Uninstall: An MSI does not normally need the original source to uninstall, unless it erroneously calls the ResolveSource standard action or a custom action does something strange. This old answer explains in more detail: Why does MSI require the original .msi file to proceed with an uninstall?
Major Upgrade Uninstall: It could be that during a major upgrade there is some source resolution going on - frankly I am not sure. Did you try to invoke uninstall by its own, manually? In other words run an uninstall command only, and not install the new version on top of the old one and do a major upgrade uninstall? I will run a test when I get a chance.
Section 3 here: Uninstalling an MSI file from the command line without using msiexec
How can I find the product GUID of an installed MSI setup?
Fresh Installation Location: As a workaround you could install your new version in a different place than your old version and de-couple it from the past versions. There could be conflicts in terms of COM servers and other global registrations, but if there isn't you can just leave the old version in place (potentially removing its shortcuts) and leave it there. Emergency "solution".
Self-Repair / Resiliency: MSI "knows" what you installed. It tries to actively maintain that installation state as explained here: Why does the MSI installer reconfigure if I delete a file?. Don't fight MSI - it fights back. Try to follow the paradigm - or you get a ride with the windmill :-).
Virustotal.com: One measure against malware inclusions or false-positive detection and file quarantine is to use an online service which scans your binaries with many malware scanners. Virustotal.com is such a service. Upload your finished setup and maybe also binaries there to see what different tools do to your binaries. Sorry if this is obvious, adding as a tip for whoever else reads this.
Bogdan Mitrache: https://www.advancedinstaller.com/antivirus-whitelisting.html
Section 7 in this answer: How do I avoid triggering MSI self-repair with my WiX / MSI package?
Links:
How to build MSI package on a linux server?
How do I avoid distributing sensitive information in my MSI by accident?
https://devblogs.microsoft.com/setup/resolving-prompts-for-source/
https://devblogs.microsoft.com/setup/resolvesource-requires-source/
I use the Installer Projects extension for visual studio 2015 to distribute my sw written in WPF.
I would like the installer, before the installation, remove all the files in the program folder.
I tried putting true RemovePreviousVersion properties but does not work.
Does anyone know how to fix?
You have to make sure that ALL your project versions inside AssemblyInfo is altered to a new one (greater than the previous one) and also, check that the Installer version it self is altered and a new id is generated (be carefull not to alter the installer id but the upgrade id). It should prompt you when changing the version of the installer that new id will be generated.
Also, because the installer projects are no longer supported directly (see wix), a lot of issues may be raised by the vs extension.
Ypu may also try the Inno setup. It very powerfull and easy to migrate from clasic installer projects.
Good luck.
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 a .NET 3.5 Setup Package Project which installs my application successfully.
The setup package deploys a number (around 70) custom files for use from within the application.
From time to time I have the requirement of deleting some of these files, however upon restarting the executable, it automatically runs a portion of the Setup MSI again, and re-installs these files.
The only way I can achieve my desired result at the moment is to delete the files after starting the executable.
I have looked through the attributes on the files in the setup package such as Vital and PackageAs, however cannot seem to identify the required setting to achieve this.
Does anybody have any idea what is needed to acheive this ?
Much thanks
From http://msdn.microsoft.com/en-us/library/kz0ke5xt%28v=VS.100%29.aspx
"
How do I turn off repair for a file that users are expected to modify or delete?
Visual Studio creates advertised shortcuts so that when the program is started it verifies that all its files exist. To change this behavior and cause it not to repair the file, select the files in the setup project and change the Condition property to NOT REINSTALL so that the file will not get reinstalled on a repair and its Transitive property to TRUE so that the condition is re-evaluated. This will cause the Installer to flash on the screen the first time after the file is deleted, as it verifies that the file should not be reinstalled, but you will not see the installer after that.
"
This has annoyed me too, and I don't know the specific setting you have to change to prevent this, but I can tell you a work-around that I've used. I found that it only happens when I run the application from the shortcut that was installed as part of the installation. So, if you create a new shortcut to the application and run it via that shortcut, then the files you've deleted won't be automatically restored.
Windows Installer supports three types of product upgrades: major upgrades, minor upgrades, and small updates. A synopsis of which upgrade to use under what circumstances can be found here: http://helpnet.flexerasoftware.com/robo/projects/installshield12helplib/MajorMinorSmall.htm
What you want to do is set you installer up in such a way that the new version of your software sees the file deletions as upgrades to a prior version. If you fail to do this and then you delete files, the program installation thinks it is damaged, and tries to restore the files you deleted when the program is executed again.
In InstallShield (the installer product with which I am familiar), there is a Product GUID and an Upgrade GUID. The Upgrade GUID always stays the same within your product family of different versions. The Product GUID changes with each new MAJOR or MINOR release. In general, if you follow this pattern, and then specify file deletions in your new version, the installer should interpret the file deletions as upgrades, and you should not get any errors on subsequent execution of the newly-installed version.
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!