|
|
UninstallPublisherUnknown.PNG (40,055 bytes) |
|
|
ExactStepsTaken.mht (2,429,701 bytes)
PublisherUnknown.PNG (41,329 bytes) |
|
|
Resolved with these checkins https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4126 https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4127 The uninstall now looks like an uninstall; it doesn't show the EULA, talk about installation, or prompt for an installation location, ... |
|
|
I tested the uninstaller (on a clean VM) and it is much simpler and things that were unnecessary are removed. Question, however... On install, the publisher correctly shows HRD Software, LLC On uninstall, the publisher says "Unknown". Is this the correct behavior? (Image attached) |
|
|
More information is needed: What did "Show more details" show? What specific executable was running? You can find the executable by using Process Manager, and that will reveal a path to the file. Capturing the file would help; at the very least, finding the version and signature information from that file would be helpful. |
|
|
The uninstall is very fast, almost instantaneous. The HRD folder is still left with a few files in it. Also files left at C:\Users\HRD\AppData\Roaming\HRDLLC. |
|
|
The files remaining in the HRD folder should be removed after a reboot. If not, please take the time to enumerate and describe the files in your report; it would be useful to have the names and sizes. It's by-design to not remove user data. |
|
|
I'm re-testing this. John - install scripts only remove things that the install script created. Many things get created on "first-run". These things in the registry and in certain folders won't be removed by the installer (this includes activation key). |
|
|
On re-test, the same result. That is - the installer removes the program just fine. It's cleaner and it's easier to understand. (These tests ran on a clean Windows 10 VM that had never had anything installed on it except Windows updates.) My finding is related to the uninstall dialog saying "Publisher Unknown" when setupHRD.exe was running the uninstall. In the attached files, you'll find a file that contains all the steps taken with images at each step... with one exception. Problem Steps Recorder doesn't snag the image when the uninstall script goes into UAC. So the additional image (PublisherUnknown) happened at step 10.5. We may not fail this change because of this. But it's worth knowing if there's something we should change so that the publisher of setupHRD.exe is not "Unknown" when the uninstall ran. (The publisher was known when the install occurred.) "Show More Details" is what is shown in the image posted on 2018-06-05 14:07 above. |
|
|
I've tested this twice with the same results. I'm going to pass this. If we seek to solve the "Publisher Unknown" problem with setupHRD.exe later, we can open a new bug report for that. |
|
|
Some comments in this record are in reference to 2114 which was created to tend UI topics in the uninstall. Those topics were successfully resolved. Disregard those comments here. Rather - the topics that are in need of discovery here are related to the signing of the setupHRD.exe during uninstall. |
|
|
To make progress, it would help to have an answer to these questions: What specific executable was running? You can find the executable by using Process Manager, and that will reveal a path to the file. Capturing the file would help; at the very least, finding the version and signature information from that file would be helpful. Maybe SetupHRD.EXE is carried in the installer image (which we rename to Setup.EXE) and it's not signed. Maybe something else is going on. I'd rather not have to make guesses to try to addres the issue, so I hope we can do make some observations to deduce exactly what's happening. |
|
|
If we can confirm that an unsigned, correct version of SetupHRD.EXE is the problem, then it's likely a post build signing step in InstallAware is the solution. https://www.installaware.com/blog/?p=416 |
|
|
The contents of the folder referenced in the last dialog box image are attached in a zipped folder. UninstallFolderContents.zip (4,157,282 bytes) |
|
|
The file in question is "SetupHRD.EXE"; in this ZIP file, it's about 4.5 megs in size and is from version 846. The file isn't signed, so it seems like we've got to find a way to get InstallAware to sign this file during its build process. |
|
|
It's looking like I can add a "post-build" step to do this signing. The challenge is that I want the same seutp project to be able to built un-signed builds for developers who don't have the certificate (or its password). Making the post-build event conditional and strict about setup configuration is beyond the internal capabilities of InstallAware. |
|
|
There are two similarly named executables: setup.exe, which our customers download and run; and SetupHRD.EXE, which is an executable installed onto customers machines. This bug refers to SetupHRD.EXE. SetupHRD.EXE is left around to implement the modify and uninstall features. This Mantis issue refers to an aleart that SetupHRD.EXE itself is not signed. SetupHRD.EXE is produced during the installer build. It's temporarily visible: the install script is compiled, the component files are assembled, and they're all compressed into a self-extracting executable file that becomes Setup.EXE. The only shot we have at signign the file is at a "post build" setp in the InstallAware project. I've added such a step. Unfortunately, the step isn't very simple. We have to install SetupHRD.EXE twice, once each with two different hash algorithms. We also want the paths and passworsd and certificate files to be configurable. Further, we want to support "unsigned" builds so that developesr (who might not have hte certificates and passwords) can make unsigned buidls for testing, if necessary. This flexibility isn't _very_ complicated, but it's more complicated than the InstallAware designers imagined. The evidence of that design is given as a small window, not resizable, that implements the post-build commands. I've implemented the simplest solution that I think is robust enough: in that tiny post-build window, we invoke a batch file. The batch file takes InstallAware compiler symbols and uses them as parameters, so that the paths and parameters required are settable. I've modified the BuildUp python script to pass the required compiler symbols in to the InstallAware command-line compiler. They're in turn passed to the post-build step. The post-build step does the signing, if and only if the BuildType compiler variable indicates that the This is a Goldberg Machine, I guess, but it does the job and maintains the flexibility we need. If this stops working or gets any harrier, we can investgigate an alternative: have the installer build run with no post-build step. When the Setup.EXE is produced, extract SetupHRD.EXE from it; sign it, then re-build the self-extracting executable with the newly signed SetupHRD.EXE bits. But, for now, what I've implemented seems to work. |
|
|
fixed with this checkin; https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4235 |
|
|
Uninstalling v.872. I had Rig Control, Logbook and DM780 when I started the Uninstall process. A message appeared telling me that those apps should be closed before continuing the Install. That should be Uninstall. Also, cannot the Uninstall process ask permission to close all open apps and then close them automatically if the user agrees? |
|
|
I tested this and confirmed that it is fixed. |
- Anonymous
