EXE file is not working

Question

I have a .msi (windows installer package) file into my project . I generated .exe file from .msi file successfully but whenever I try to open that .exe file or run as administrator it does nothing . How to solve this? Anything will help regarding this . Please help

UPDATE Here is my code for .msi file

components.wxs

    <?xml version="1.0" encoding="UTF-8"?>
    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

    <?include Defines.wxi?>

    <Fragment>

    <ComponentGroup Id="MenuComponents" Directory="ProductMenuFolder">
    <Component Id="ProductMenuComponents" Guid="*">

    <!--<Shortcut Id="UninstallPackage" Directory="ProductMenuFolder" Name="Uninstall package"
          Target="[System64Folder]msiexec.exe" Arguments="/x {[ProductCode]}" Description="Uninstalls $(var.YourApplicationReference.TargetName)"/>-->
<RemoveFolder Id='ProductMenuFolder' On='uninstall' />
<RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' 
Type='string' Value='' KeyPath='yes' />

   </Component>
   </ComponentGroup>

   <ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
   <Component Id="FileWatcher">
   <File Source="$(var.FileWatcher.TargetPath)" />

   <!--Register this file as a Windows service-->
   <ServiceInstall Id="ServiceInstaller"
                Type="ownProcess"
                Description="Sends Incoming mainframe files to the  Webservice"
                DisplayName="FileWatcher"
                Vital="yes"
                Start="auto"
                ErrorControl="ignore"
                Interactive="no"
                Name="FileWatcher"
                Account="[ACCOUNT]"
                Password="[PASSWORD]">

      <ServiceConfig Id="svcConfig" DelayedAutoStart="yes" OnInstall="yes" OnReinstall="yes" OnUninstall="no" />
</ServiceInstall>

     <!--Set the user to be used by the service-->
     <util:User Id="ServiceUser" Name="[ACCOUNT]" Password="[PASSWORD]" CreateUser="no" LogonAsService="yes" UpdateIfExists="yes" />

     <!--Added example of how to stop service automatically-->
     <ServiceControl Id="ServiceControl" Stop="both" Remove="uninstall" Name="FileWatcher" Wait="yes" />
     </Component>
     <Component Id="FileWatcher.Files" Guid="*">
     <!--<Component Id="MAIDFileWatcher.Files" Guid="*">-->
     <File Id="filB93E7D71690869B9CD2D0A479DB69C6C" Source="$(var.FileWatcher.TargetDir)\ExceptionHandling.dll"  />
    <File Id="fil487232F7A833919419AF9537A4390083" Source="$(var.FileWatcher.TargetDir)\ExceptionHandling.xml" />
    <File Id="filDE3649B71309470D2D7C086E0FAABAE8" Source="$(var.FileWatcher.TargetDir)\itextsharp.dll"  />
    <File Id="filF73350F1AEF9ECF2621D4E63B9823029" Source="$(var.FileWatcher.TargetDir)\FileWatcher.exe.config"  KeyPath='yes'/>
    </Component>
    </ComponentGroup>

product.wxs

   <?xml version="1.0" encoding="UTF-8"?>
   <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

   <?include Version.wxi?>
   <?include Defines.wxi?>

   <Product Id="$(var.PRODUCTCODE)" Name="$(var.PRODUCTNAME)" Language="1033" Version="$(var.REVISION)" Manufacturer="$(var.MANUFACTURER)" UpgradeCode="$(var.UPGRADECODE)">

   <Package InstallerVersion="400" Compressed="yes" InstallScope="perMachine" Comments="$(var.COMMENTS)" Description="$(var.DESCRIPTION)" />

   <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
   <MediaTemplate EmbedCab="yes" />

   <Feature Id="ProductFeature" Title="$(var.PRODUCTNAME)" Level="1">
    <ComponentGroupRef Id="ProductComponents" />
    <ComponentGroupRef Id="MenuComponents"/>
   </Feature>

   <UIRef Id="USERUI" />

   <?include Actions.wxi?> 

   </Product>

   </Wix>

hi thanks for reply @mjwills :) . I updated my question with code — , Feb 06 '18 at 20:42
Did you uninstall something? and if so, have you rebooted? It appears you are installing services. If windows installer is expecting a service to get uninstalled then you can't reinstall a new version until you reboot to complete the uninstallation of the old one (depending on how you did it.) — Wyck, Feb 07 '18 at 05:18

score 0 · Answer 1 · answered Feb 06 '18 at 20:32

0

You can debug an msi installation with a command line like this:

msiexec /i someapplication.msi /L*vx log.txt

This will run the installer and output log info to a file called log.txt.

See also: Windows Installer Command Line Options

answered Feb 06 '18 at 20:32

Wyck

10,311
6
39
60

hi @Wyck thanks for reply :) . I'm new to this . I need to generate log.txt file to get the errors at the time of installation of my .msi file? am I right? – Feb 06 '18 at 20:46
That's right. It's for seeing what went wrong during installation. For example you claimed that "it does nothing". This command line will try to do the installation and then the log will reveal what happened or where it stopped. – Wyck Feb 06 '18 at 21:09
It's not clear to me that the install log will help. The install will either work or completely roll back. If the installed exe is there but won't run, then the install log won't tell you why. The description seems to indicate that starting the exe causes an immediate crash, and that might be due to missing dependencies or fragile coding. – PhilDW Feb 06 '18 at 22:34
the exe causes an immediate crash you are right @PhilDW – Feb 07 '18 at 03:59

score 0 · Answer 2 · answered Feb 06 '18 at 21:13

Another pro tip is to debug your installer in a virtual machine. Take a snapshot before installing so you can roll back, or repeat the installation after making code changes and start from a reproducible state. I can't imagine debugging installers without Hyper-V - it's essential to me.

Stein Åsmul · Answer 3 · 2018-02-07T08:00:39.273

This is basically just shooting from the hip, please ignore whatever is not relevant (maybe check the very last three bullet points first):

Best practice: first of all, you are installing multiple binaries with a single component. This is a violation of component creation best practice.

For something this small I would suggest you use one component per file. This solves all kinds of future problems with patching, upgrades and other things.
What happens if the component rules are broken? Please skim this, or take our word for it and just use one file per component. At least make a separate component for all binaries (required).
A little blurb about the nature and philosophy of component GUIDs: Change my component GUID in wix? Some find it helpful to understand the mysterious and always troublesome component GUIDs.
If you insist on using multiple files per component, make sure that the key file for the component is a versioned file. I would think WiX would auto-magic this.
- If you don't have a versioned key file, you could risk the component not installing at all if there are files already in the target location.
- If you do have a versioned key file, make sure that your install has a higher version binary than the one it may encounter on disk at the target location (if any). Please read about the MSI file versioning rules for an explanation.

Logging: Does your application have a log feature (by default, or one that you can enable) which you can use for debugging? Maybe to the system's event log? Wouldn't services write there?

Dependencies: Also, did you check the pointers I provided earlier with regards to dependency checking? C# Debug folder when copied to another location does not run the exe.

Checking first the modules view in Visual Studio, and then using Dependencies.exe to check for missing dependencies?
Using procmon.exe is a little involved, but almost always reveals surprises and problems that can be hard to detect in other ways: Registering a CPP dll into COM after installation using Wix Msi installer
Does Fuslogvw.exe tell you anything? (.NET assembly binding failures).

Service Credentials: are you sure that those login credentials are getting applied during installation?

Did you try to set them manually to see if the service will run then? Did you add these properties to the SecureCustomProperties list of properties allowed to pass to deferred installation mode?
I think WiX has "auto-magic" here and does this for you, I forget. Check SecureCustomProperties in the property table of your final, compiled MSI using an appropriate tool, for example Orca.
With that delayed service start setting, is the service even running? (got to mention it at least). Or did you say it crashes on launch?

Hard-coded references: pointers to missing resources.

Did you check all the manifest files and config files (FileWatcher.exe.config) for anything funky that points to resources on your developer box (erroneous, hard-coded references)?
Could there be lacking resource files? (images, dlls, etc...).

Architecture & runtime requirements: is the target computer the same architecture as your developer machine? Just to chalk it up, surely you would see a warning about this?

What is the CPU targeted by your code? Any CPU? Did you try to manually register the files on another machine (a clean virtual machine maybe).
Is there anything special about the problem, target computer? Does it have weird policies? Does it have security software blocking things? Does it lack a common runtime component that is installed on your development computer? (.NET, VC++ runtime, VC runtime, java, etc...). These are the things a procmon.exe session should reveal, or a check with Dependencies.exe should show.
Are you using the notorious FileSystemWatcher .NET class? I have used it only once many years ago, but it caused me a lot of grief and I had to stop using it. It did crash my service file regularly.
- I will dig up some links here if you are using this class.
- Found a couple for now: FileSystemWatcher events raising twice despite taking measures against it and FileSystemWatcher vs polling to watch for file changes.

score 0 · Answer 4 · answered Nov 20 '20 at 07:21

0

When I have installed my EXE under %PROGRAMDATA% I had the same issue
When I have installed my EXE under %PROGRAMFILES% I solved the problem

answered Nov 20 '20 at 07:21

Patrick

621
2
7
21

That would indicate a simple ACL permission issue. In other words the application does not have write access to the folder and it typically needs it to write to some settings file. I would guess that the OP had an issue with service credentials - maybe. – Stein Åsmul Nov 21 '20 at 01:13

EXE file is not working

4 Answers4

Linked