I'm trying to put an application on my website so potential customers can down load it and run it. I'm using WIX to create the MSI and I've got a GoDaddy code signing certificate. The name of the MSI file is 'License Manager.msi', but when the screen blanks out during the install to ask permission, I get a dialog that states:
Do you want to allow this App to make changes to your device.
19e7696e.msi
The name of the MSI seems to change on every attempt to install. Is this a Windows 10 thing or a WIX thing? Where does this name come from and how can I replace it with the name of my application or something more informative?
OK. Found it. It's part of SignTool. The /d switch allows you to override the temporary MSI file created from the starting MSI file.
Related
I have a application that uses Wix for its installer.
I'd like to understand where the UAC window takes its app name from, I am having an old name where the UAC window appears does not correspond with current productname defined in Wix.
Digital Signature: It looks like your MSI is signed with a code-signing certificate?
"If you Authenticode-sign your .msi package, Windows will show that as the name. Otherwise, you get MSI's temporary copy of it, which has a random name." - source.
Signtool.exe: You need to modify your signtool.exe parameters:
Odd 'Program name' when installing signed msi installer
Some old answers with comments discussing signtool.exe parameters:
What is causing to show Publisher to unknown on UAC despite signing exe using signtool
Windows Installer Unknown Publisher
Links on Digital Signing:
Installshield Custom Dialogue Installer
How to add publisher in Installshield 2018
I'm working on an MSI installer written in Wix. The installer works in both per-user, and per-machine contexts.
In a per-machine installation, everything goes smoothly; the product is installed and configured for the initial user. Upon switching to a test user, the application appears in the start menu correctly. Running it for the first time, a msiexec process starts with the message that the app is being configured. However, if the original .msi has been deleted, this process fails.
The failing setup action gives the following message in its log:
Error 1706. An installation package for the product myProduct cannot be found. Try the installation again using a valid copy of the installation package 'myInstaller.msi'.
=== Logging stopped: 3/16/2017 11:15:52 ===
I understand from reading a blog post by Rob Mensching (Lead of Wix) that it probably isn't possible to just edit the source list to point towards the windows cached .msi, a point backed up by another article I've found. Is that correct?
Is there a way to stop this entire action of calling the msi on first run by users from happening? Caching the msi or keeping the original is not ideal, I'd like to use the .msi in a custom bootstrapper that involves deleting the msi once installation is complete.
Microsoft recommends you keep the original MSI available, Rule 31:
https://blogs.msdn.microsoft.com/windows_installer_team/2006/05/24/tao-of-the-windows-installer-part-3/
and I won't repeat what it says about repair/resiliency, but you cannot guarantee the source MSI won't be needed sometime.
You're probably getting this "repair" because there is some resource (a file most likely) that is being installed to a user-profile location. When another user logs on and uses the application that file is missing, so potentially the application is broken. For example a file installed to User's Application Data needs to be available for all users of the system, not just the user that installed it.
So keeping the MSI might not be ideal but is strongly recommended, and in your case of product use by multiple users it's even more likely to required. There should be an Application Event log entry under MsiInstaller that says something about the missing resource.
Suppose that you have an installer (not a wix installer) that you downloaded from somewhere. How can you know UpgradeCode of that installer so that you can fill it in in the UpgradeCode section in the new installer that you prepare?
Can I learn it from registry somehow? So the question is basically, how to know the UpgradeCode of a program that is installed in the computer.
Actually my problem is that my product has been installed with another installer and I am now trying to move it to wix installer. However, I can't find upgrade code in previous installer and I want to find it from installed software.
Thanks.
As I posted to WiX users:
I've seen this done by having the upgrade get the uninstall string from the registry, where there should be a command you can use since it's not MSI-based. Whether you should call it in the UI sequence or the execute sequence or both depends on your requirements for silent installs, meaning that you'd need to do it silently in the execute sequence, and perhaps need to alter the uninstall command to make it silent.
The same general idea should work if that install has a standard uninstall shortcut you could get the command from. Either way, you're just using a CA to run an external program, or maybe a Util
CAQuietExec kind of thing.
Assuming it's a Windows Installer based installer ( WiX, InstallShield, et al ) you can edit it with ORCA and look at the Property table to see it's UpgradeCode. You may have to first extract it if it was packaged as a self extracting installer.
You can also query the MSI API or look in the registry (HKCR\Installer) for this information. If you go the registry route it's probably easiest to look at the Products/GUID/Sourcelist key and trace it back to a cached MSI and look at it in ORCA. Otherwise you have to learn how to join different datasets and convert Darwin transformed GUIDS back to their original GUID format.
Fire up PowerShell (run as admin) and run this command to get a list of installed products with product code:
Get-WmiObject Win32_Product | Format-Table Name, LocalPackage
You will get a list of all installed MSI products, and a weird looking path to the local cached MSI database. It normally looks something like this:
C:\Windows\Installer\235bbf8.msi
The 235bbf8.msi file name is random, and will be different for each installed product. It is a cached copy of the MSI file that you originally installed. It does not contain cab files (or at least it didn't in older versions of Windows).
You can open that file with the random name from Orca by chosing File -> Open and then pasting in the full path to the file open dialog, and then pressing open. Don't make any changes but check the upgrade code in the Property table. You can also use other MSI tools such as Installshield.
Note that the path C:\Windows\Installer is "super protected" and is not even visible in Windows Explorer before you enable the show hidden folders AND you disable the protect operating system files option. I still believe you can open the file directly if you paste the whole path into Orca - no need to go via Windows Explorer.
I coded my MSI installer using WiX. The MSI is also signed with my code signing certificate. When I begin its installation I get the following security warning on Windows 7:
But for some reason the Program Name is nothing but the name of my MSI or anything I added to it.
Is there a way to give it some user-friendly name to display in that warning?
With SignTool.exe it is enough to set a description text from what I remember, this being used as application name in the UAC prompt. Have you tried that? (don't know if this is supported from WiX)
I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:
The feature you are trying to use is on a network resource that is unavailable
with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)
I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.
Is this the case?
What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)
The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:
msiexec /fv path\to\your.msi /l*v i.txt
That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.
One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)
That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.
Now there are several ways out of this pickle:
Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\Installer. CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.
or
Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.
or
Reimage your workstation
If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.
For example:
Locate the MSI file in %WINDIR%\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
Open the msi file with Orca.
Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
Save the msi and close Orca to release the lock on the msi file.
1 - Have you experimented with "run from source" during installation?
This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: "The feature you are trying to use is on a network resource that is unavailable" if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.
2 - Are you running script custom actions? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?
3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.
4 - Are any of your userprofile folders redirected to a network share?
5 - Are you installing anything directly to a folder on the network?
There are plenty of other possibilities.