1

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?

ShaneLS
  • 356
  • 5
  • 14

1 Answers1

1

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.

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.

Links:

Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
  • It is a small (100 or so) distribution built specifically for our clients. . It does communicate to a over the internet and is without (soon to get with this major update) a code signing certificate. I always presumed with a small distribution, unsigned code, and internet comms, I would most likely see antivirus/malware false positives for years, if not always. A fresh install would be great but, the services would be left in place and cause a headache with connection logs on my server. Anyway, you have given me a lot to read through... much appreciated. – ShaneLS Mar 05 '19 at 21:01
  • Communicate over the Internet? Is there a custom action doing that in the setup? Custom actions can cause source media resolution issues. Existing services can be shut down from your newer setup even if it goes to a different location. Will do some testing when I get a chance. – Stein Åsmul Mar 06 '19 at 03:21
  • There are several techniques you can use to disable a custom action that causes uninstall problems, some manual and some automatic. A manual approach is the Microsoft FixIt tool I mentioned above. The best is to patch the existing installation with a minor upgrade to disable problematic custom actions. Let us know what custom actions you have in your package? – Stein Åsmul Mar 06 '19 at 04:41
  • My apologies... No, the installer does not comm to a server. A few of the executables contained within do, currently contain unsigned code, and is not widely distributed. This was meant to explain why AV and Malware will presumably always consider the individual executables and installer a threat. – ShaneLS Mar 06 '19 at 15:09