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/