I made an MSI installer using WIX. installing on windows 7 is no problem bud on windows 7 embedded something funny is going on. when the software is installed it does run, bud not properly. I found out it had something to do with administrator permissions. the executable doesn't start as administrator, which it should since only then it runs properly. I could set it manualy bud i prefer to do it automatically via the installer. Can this simple be done as described in this thread and put in a VB.NET script? or is there another better way?
note: the executable always needs to run as administrator, so the setting needs to be permanent.
thanks in advance.
F.Jansen
Is this an executable that you have control over and also is this a VC++ executable ? If yes, I would suggest to re-compile this executable by making it UAC compliant. This would involve re-compiling the executable with the appropriate flags as stated at:
https://msdn.microsoft.com/en-us/library/bb384691.aspx
/MANIFESTUAC:level=_level
Set the value of _level variable to :requireAdministrator
Doing so would make the executable UAC compliant and then launch it always with Administrative privileges. This is the recommended way for all UAC compliant executables starting with Windows Vista or higher.
You can read more about UAC at: https://technet.microsoft.com/en-us/library/cc709628(v=ws.10).aspx
What you are trying to do as highlighted How to set "Run this program as an administrator" programmatically , exists just for the purpose of back ward compatibility. If the .exe that you are trying to launch is a legacy exe, then this might be the way to go. Make sure that if you follow this approach, it exists in the latest version of Windows.
Hope this helps.
Related
Inside our .NET Framework 4.6.2 solution; we have a WiX project responsible for generating the .msi installer package for our WPF application.
The generated .msi installs fine on my machine, but not on colleague's computer.
After investigating for a couple of hours, we concluded that it was because of the nature of the D:\ drive on my colleague's computer.
The .msi was being run from an alias hard drive. He created the alias by following instructions here. So an alias drive is just a regular folder on C:\ but you turn that into an alias hard drive.
When the .msi is run from outside the aliased drive, the program installs without any problems, otherwise he gets these errors:
Clicking Retry doesn't do anything, but clicking cancel gives the following:
On my machine, I don't have any alias hard drives set up, and things just work, in other words, the program installs without any issues.
How do we get the installer to work with alias drives too?
This isn't supported by Windows Installer. The alias created by Subst only exists in the user profile that created it. MSI runs as SYSTEM and can't see it.
Subst Considered Harmlessly Useless: Yes, as Chris states we have both seen this before. MSI is an old girl, and newer Windows features or old ones that are weird cause such problems.
Workaround: In the realm of workarounds, maybe check features and / or transforms:
Optional Features: what is this D:\ drive? Is it his personal data storage? Are you installing files into "My Documents" or something like that? It you make a separate feature for the components going into the D:\ drive and then unselect that feature from installation, does it then install? (albeit with a few missing files). Screen shot of feature selection.
Transforms: There are also other ways to achieve the suppression of features and files from installing. You can use transforms - little database fragments - to apply runtime changes to a running MSI installer. More on transforms here. Shorter version here. And just one more.
Administrative Installation: You can (also) get hold of the missing files from another computer, or maybe by running an administrative installation of the MSI: What is the purpose of administrative installation initiated using msiexec /a? (glorified file extraction).
I created a program in vb.net in vb language. After that I created an installer (.msi) for the same in Advanced Installer program. I installed it on the computer and everything seems professional.
I copied the folder that contains the program and all its dependees and sent to to a different computer. I was surprised that the application (.exe) file works without installation!!
How can I make my application works only with installation?
Appreciate the help.
Advanced Installer has a licensing module that works for VB.NET apps too, which you can easily integrate into your installer.
However, this is in the Enterprise edition, and I assume you are using the free edition, as this sounds like quite a simple application/installer.
In this case you can try looking for an alternative OSS solution for a licensing/trial library.
Basically with this library every user that needs to use the software will need a key to activate it, so even if they copy the folder with the application files from Programs Folder, they will still not be able to run your app.
My Wix installer worked installing my program, but it's broken for uninstallation. A file is removed too early, and it's needed further down the line. The uninstaller fails and reverts its changes.
This means I can't remove the package from my machine, and hence can't install any further builds of my installer (a considerable inconvenience). How can I force removal of the package?
Update, Stein Åsmul: Injecting this newer list of cleanup approaches.
Find your package in C:\Windows\Installer, where Windows keeps copies of installed MSI packages. The names are generated randomly, so you'll have to look at the creation dates of the files.
Open the MSI file with Orca. (Unfortunately there is no simple download for the orca installer. You can get it by installing the "MSI Tools" of the Windows 10 SDK, and then searching for orca.msi in C:\Program Files (x86)\Windows Kits.)
Delete the offending custom action from the CustomAction table
Now you should be able to uninstall the package.
UPDATE: You can find the actual cache MSI file using Powershell. That was for one package, you can also get for all packages (scroll down to first screenshot).
This command usually works for me:
msiexec /fv installer.msi
It somewhat recaches the installer, so you can try again with a corrected one.
One time this command didn't work and I had to use Microsoft FixIt. It solved the problem (quite a shock for me).
Depending on the exact reason of the behavior you described, you might have at least a couple of options.
If the reason of the failure is a custom action which runs on uninstall, and this custom action is conditioned with some properties you can influence upon, you can try to pass the desired value via the command line:
msiexec /x {YOUR-PRODUCTCODE-HERE} RUNMYACTION=false
In this sample RUNMYACTION is a Windows Installer property which participates in a custom action condition, and if you pass false as its value, the action won't run.
Otherwise, you can fix the logic (or just disable the custom action explicitly) and build the new MSI package. Then upload it to that target machine, and run like this:
msiexec /i YourPackage.msi REINSTALL=ALL REINSTALLMODE=vomus
Here YourPackage.msi is a new fixed package, REINSTALL=ALL instructs the msiexec to re-install the product using this new package, and REINSTALLMODE=vomus (the v part of it) will re-cache the MSI package and you'll be able to remove it the normal way afterwards.
A side note: you should test your installation on a virtual machine in order not to risk your real one.
FYI: In Windows 8.1 the installers have been moved here: C:\ProgramData\Package Cache\
If you are really desperate and all solutions above don't work try
msizap.exe
This will erase all that your installer put on a machine
LITTLE WARNING
Don't run msizap without knowing what options you want to run it with (for a list of options run msizap /? first).
I used this little tool also from Microsoft
https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Basically this tool can be used to "repair issues including corrupted registry keys that block you from installing or removing programs"
What it fixes:
Corrupted registry keys on 64-bit operating systems
Corrupted registry keys that control the update data
Problems that prevent new programs from being installed
Problems that prevent existing programs from being completely uninstalled or updated
Problems that block you from uninstalling a program through Add or Remove Programs (or Programs and Features) in Control Panel
It can be used for:
Windows 7
Windows 8
Windows 8.1
Windows 10
I usually just look for <Your Installer's Name>.msi or <Your Installer's Company Name> in the registry and delete some of the uninstall keys from some of the Products under the Windows installer trees and everything usually works fine and dandy afterwards, although this WOULD leave some stuff lying around like cached installers and possibly tons of other registry keys for each file installed, etc. but its ALWAYS worked for me when developing installers because honestly, who cares if one MSI is left over and cached somewhere? You're using the machine for development anyways, right?
A while ago I found a packaging tool for visual studio that allowed quite heavy control by means of a build script and was a freebie , problem is I can't remember the name of it. Anyone know of a package/tool that fits those criteria? Failing that I just wanted it as I know I could do completely silent install packages with it. Which is exactly what I want for a central deploy. Oh this is in VB
Anything which produces an MSI file, such as WiX, can be installed silently using the /qn flag and thus matches your criteria.
Another major installer script is NSIS (Nullsoft Install System) - you can write a silent installer using this as well.
Can you remember any of the syntax or anything? WiX is XML-based, and NSIS is it's own stack-based language, although there is a plugin to make it imperative.
I've created a WiX setup project based on the article WiX 3 Tutorial: Understanding main WXS and WXI file mainly because it gives the WiX needed to do an application shutdown.
However, I'm puzzled by the outcome. Here's the situation:
We have an executable which uses a dll and create a setup which installs the executable and the dll. We execute the setup.
CASE 1: Next, we change the executable and NOT the dll and create the setup again. Then we start the installed application and make sure also the dll is loaded. If we now execute the second setup, a dialog is shown asking the user to shutdown the executable just as we expected.
CASE 2: But if we do not change the application but only the dll and then execute the setup while the application is running and the dll is loaded, no dialog is shown. At the end of the setup a dialog appears asking if we want to restart the computer.
Is this expected behaviour and how can I force the application shutdown dialog of CASE 1 also when only a dll is changed as in CASE 2? I do not want the user having to restart the computer because the application is running on a server which cannot be restarted.
This is all determined by Windows Installer during the costing process. The installer decides which files need to be installed / updated and calculates how much disk space is needed and if there are any file locks. If there are file locks, it attempts to resolve the lock to a process with a window handle. If it can do this, you'll get the dialog. If it can't, you won't. This doesn't mean a reboot won't be needed, it just can't give you useful information on how to avoid it.
A few additional points:
Make sure you are versioning your EXE and DLL. If the old DLL is 1.0.0.0 and the new DLL is 1.0.0.0 costing will say "Nothing to do here".
How does the EXE use the DLL at runtime? It might simply not have a lock on it during the entire life of the process.
Understand that MSI's reboot behavior can be altered through the use of properties such as REBOOT=ReallySuppress
Here's some good articles to read:
InstallValidate
FileInUseDialog
System Reboots
I haven't checked the code but I think what is happening is the CloseApplication action is not running because it sees that the exe hasn't changed. As far as I am aware you cannot target a DLL with CloseApplication. If you run your install with logging you should be able to see if the action is triggered. I am assuming you have RemoveExistingProducts schedule late in the install, if you were to move it after InstallValidate it would remove the exe every time and therefore trigger the action.