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>

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

• 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