I have a WIX project that is creating an MSI to install an Excel VSTO application, including desktop shortcuts to launch the application. The installation and shortcut creation is working fine. But I need to be able to launch the application by executing the shortcut after the installation has completed. I've seen guides on how to launch an executable, but nothing for a shortcut. Is there some way of doing this that I'm missing?
Thanks!
How is launching shortcut different from launching the executable? I mean the shortcut points to an executable plus maybe some command line arguments. The result is a running application anyway, then why bothering?
Related
I'm looking to create a Windows Installer package that will run an exe that runs another Windows Installer.
I'm putting a package together that has to install three files, an EXE, a CONFIG and an empty TXT. In addition, we also need to run the Access Database Engine 2007 as part of this process. However, when setting custom actions to just run it (with the flag /quiet) it fails because it's attempting to run an MSI inside of an MSI.
Is there any way I could somehow have it launch right after/right before or something? I've looked into WIX but honestly I'm clueless on how it would solve the problem.
Thanks.
You should look at the WiX Burn functionality and prerequisites. Some examples are:
WiX - Install Prerequisites and 3rd party applications
http://www.c-sharpcorner.com/UploadFile/cb88b2/installing-prerequisites-using-wix-bootstrapper-project-and/
You could probably just run the setup from the Burn bootstrapper - it will do its own detection if it's already installed.
I created a VB.net application that, among other things, uses two DLLs to update the firmware on a microprocessor. It works perfectly during debugging.
To distribute it, I used InstallShield LE to create an installer. If I install the program and run from the Start Menu or Desktop icon, the program works - except for that part that uses the DLLs... that fails part of the way through.
The kicker is that if I go to C:\Program Files (x86)\programName\ and run the .exe from there everything works perfectly.
When I run from the shortcuts or from the actual directory and go to Task Manager and view the process properties, it lists the same directory. So I am under the assumption that the shortcuts are properly referencing the correct location.
So, how can running from a shortcut affect the running of the .exe?!
Thank you for your help.
-Mschmidtbauer
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.
I'm trying to certify a desktop application for Windows 8.1 using Windows App Certification Kit 3.1.
Everything is fine with the exception of the uninstall. I created the MSI file using Wix Toolkit 3.6. When the application installs it creates an entry in Programs and Features as well as a shortcut for uninstalling.
When I trigger the uninstall from either of these locations it works properly and all the files and registry entries get removed.
However, when the WACK launches the uninstall process, the MSI starts the installation process instead.
Is there a specific command from msiexec I need to test that WACK might be using to cause this?
I really do not understand why the Kit will launch the installer again.
Thank you,
Fernando
I found the problem and my solution.
The WACK calls the uninstall process using the Change option instead of Uninstall. You can test this by going to *Programs and Feature*s and clicking Change.
Since my application does not support changing or repairing, I simply set ARPNOREPAIR and ARPNOMODIFY to "Yes" and now WACK only calls uninstall.
The other option is to offer the Change/Repair dialog on your setup project and have the Remove check-mark available.
Hope this helps.
Cheers,
Fernando
I'm launching a custom action console application that can return 0 or -1.
On Windows 8 when it returns 0, the install continues.
On Windows 7 when it returns 0, the install ends prematurely.
<Property Id="QtExecCmdLine" Value=""$(var.SourceFiles)\MyProgram.exe""/>
<CustomAction Id="CheckForOld" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
<InstallExecuteSequence>
<Custom Action="CheckForOld" After="AppSearch" />
</InstallExecuteSequence>
Does anyone know what can be done to resolve this?
What are the UAC levels/settings on the Windows 8 and Window 7 machines? If you have UAC disabled on your dev machine but enabled (default setting) on the test Win 7 you could get the EXE failing to run as a custom action.
In this case I also recommend migrating your code to a DLL, you could write a C# DLL, using WixToolset and DTF.
The DLL can then set a property with the result of this search, and you can use that property to define a new launch condition to stop the installation, if required.
From Tao of the Windows Installer, Part 5
Rule 53: Test thoroughly It is crucial that you test your packages thoroughly before deployment. A classic mistake is for
developers and package authors to test only on their own systems where
they have full administrator rights and then discover that normal
users cannot use their applications.
Is that a QT exe file? What is the EXE file doing / checking? What happens if you turn off error checking - does it run and perform its task?
I wouldn't recommend to run a custom action with an exe file if you write the code yourself. Write it as a dll and connect the debugger to the code to step through it using a debug build dll - you will see exactly what happens as you step through the code:
Insert code to show a message box from within the function you want to debug
Compile a debug dll file and insert into the MSI file with the necessary plumbing to hook things up. This isn't entirely trivial, but not that complicated. See link below.
Run the MSI and wait for the message box to show
Attach the debugger to the correct msiexec.exe - either the user context one or the system context one depending on how your custom action is sequenced
Set breakpoints and step through the code to determine what is happening
How to create a basic MSI dll:
http://www.codeproject.com/Articles/1747/MSI-Custom-Action-DLL
What is this EXE supposed to do? There are several code smells. First is that it's scheduled in the UI sequence only. It won't get run during a silent install. The second is it's an EXE scheduled as immediate. EXE's can't access the MSI handle and set properties or do anything useful so I assume the EXE is changing the configuration of the machine. This is inappropriate outside of the execute sequence transaction. Finally, QtExecCmdLine needs an absolute path to the EXE on the destination machine. I don't see how $(var.SourceFiles) could provide that. That's a preprocessor variable that's only going to tell you where the file exists on the build server.
You aren't testing on your own dev machine? I'm guessing you build this on a Win 8 box and then tested on the same box. It happens to work cause it can find the file. When you run it on another machine (Win 7) it can't find the file and fails because the file can't possibly be there... you haven't installed anything yet.