EXE档案无法运作 [英] EXE file is not working

问题描述

我的项目中有一个.msi（Windows安装程序包）文件。我成功地从.msi文件生成了.exe文件，但是每当我尝试打开该.exe文件或以管理员身份运行时，它都不会执行任何操作。如何解决呢？对此会有任何帮助。请帮助

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

更新
这是我的.msi文件代码

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>

推荐答案

这基本上只是从臀部射击，请忽略无关紧要的内容（也许先检查最后三个要点）：

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

最佳实践 ：首先总而言之，您将使用单个组件安装多个二进制文件。这违反了组件创建最佳做法。

• 对于这么小的东西，我建议您每个文件使用一个组件。这样可以解决补丁，升级和其他方面的各种将来的问题。

• 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).

关于组件GUID的性质和原理的一些模糊描述：在wix中更改我的组件GUID吗？有些人发现了解神秘且总是麻烦的组件很有帮助GUID。

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.

如果您坚持每个组件使用多个文件，请确保该组件的密钥文件是版本文件。我认为WiX会自动解决这个问题。

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.

如果确实有版本密钥文件，请确保安装的二进制版本比磁盘上可能遇到的版本高。在目标位置（如果有）。请阅读有关 MSI文件的信息版本控制规则进行解释。

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?

依赖项 ：此外，您是否检查了我之前提供的关于问候的指针依赖检查？ 复制到其他位置的C＃调试文件夹无法运行exe 。

• 首先检查模块在Visual Studio中查看，然后使用Dependencies.exe检查缺少的依赖项？

• Checking first the modules view in Visual Studio, and then using Dependencies.exe to check for missing dependencies?

使用 procmon.exe 有点牵连，但几乎总是会发现其他地方很难发现的意外和问题。方式：注册使用Wix Msi安装程序将CPP dll导入COM

是否 Fuslogvw.exe 告诉您什么吗？ （.NET程序集绑定失败）。

Does Fuslogvw.exe tell you anything? (.NET assembly binding failures).

服务凭据 ：您确定在安装过程中已应用了这些登录凭据吗？

• 您是否尝试过手动设置它们以查看服务是否可以运行？您是否将这些属性添加到 SecureCustomProperties 允许传递到延迟安装模式的属性列表吗？


• 我认为WiX在这里具有自动魔术性，我忘了。在最终的已编译MSI的属性表中检查SecureCustomProperties，使用适当的工具，例如Orca 。


• 使用该延迟的服务启动设置，该服务是否还在运行？ （至少要提一下）。还是您说它在启动时崩溃？

• 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.

• 您是否已检查所有清单文件和配置文件（ FileWatcher.exe.config ）是否包含指向您开发人员资源上的任何时髦内容（错误的硬编码引用）？


• 会缺少资源文件吗？ （图像，dll等）。

• 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?

• 您的代码所针对的CPU是什么？有CPU吗？您是否尝试过在另一台机器（也许是干净的虚拟机）上手动注册文件。


• 目标计算机是否有关于此问题的特殊信息？它有奇怪的政策吗？它具有安全软件来阻止事物吗？它是否缺少开发计算机上安装的公共运行时组件？ （.NET，VC ++运行时，VC运行时，java等）。这些是 procmon.exe 会话应显示的内容，或者应该对Dependencies.exe进行检查显示。



• 您是否正在使用臭名昭著的 FileSystemWatcher .NET类？我几年前只使用过一次，但是它给我带来了很多痛苦，我不得不停止使用它。它确实使我的服务文件崩溃了。

• 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.

立即找到了一对：尽管已采取措施，但FileSystemWatcher事件引发了两次和 FileSystemWatcher与轮询以监视文件更改。

这篇关于EXE档案无法运作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！