Reputation: 197
I prepare a MSI setup project with WiX when I install this MSI package to %ProgramFiles%
and make a shortcut to desktop folder it is work only run as administrator. When double click it doesn't work. When I install folder in desktop it is work with double click. I want to install to %ProgramFiles%
and work with double click. Please help me I spend 2 week for this installation.
my code is here.
<Product Id="*" Name="FlowNet Master" Language="1033" Version="1.0.0.2"
Manufacturer="Melina-Aero" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Platform='x64' />
<Icon Id="icon.ico" SourceFile="Images\Splash Screen.jpg" />
<Property Id="ARPPRODUCTICON" Value="icon.ico" />
<!-- <Property Id="MSIUSEREALADMINDETECTION" Value="1" />-->
<WixVariable Id="WixUIBannerBmp" Value="Images\Banner.bmp" />
<WixVariable Id="WixUIDialogBmp" Value="Images\Background.bmp" />
<WixVariable Id="WixUILicenseRtf" Value="Licences\EULA.rtf" />
<Property Id="AllUSERS" Value="1"/>
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER2"/>
<UIRef Id="WixUI_InstallDir"/>
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
Upvotes: 1
Views: 880
Reputation: 42236
Elevated Rights: Files installed under %ProgramFiles%
will be read-only for standard users (and administrators as well, unless you elevate the rights via the UAC prompt). You must determine what your application is doing that requires write access to files installed under this folder - or whether you try to write to HKLM in the registry - which will cause the same problem (access denied exception). It is also possible that your application tries to do something that requires certain NT Privileges available only to admin users - causing elevation to be required (privileges differ from access rights - ACL - in being pervasive on the whole system, and not "attached" to objects - for example "change system time" - for lack of a better example).
Move Files: There are several ways to fix this access problem (or work around it), but few that are recommended. I would suggest you move the settings file that causes the exception to the user profile and store settings there with full write access. You can also apply custom ACL permissions to the installed files (see section 6 in link above), but this is not a good idea for many reasons (safety, preservation of settings, etc...). See the link above for further descriptions of alternatives (store settings in database and access on launch and other approaches).
Check List: Here is a generic check list for application launch problems.
Attach Debugger: One technique I sometimes use is to install debug-binaries to %ProgramFiles%
and then show a message box immediately from the launch sequence (if the launch gets that far at all). Then I attach the Visual Studio debugger to the message box and start interactive debugging from the installed product to check for errors and exceptions. Procedure summarized here.
Disclaimer: Though obvious, it has to be mentioned: never use debug binaries for actual release.
1)
Not at all legal,2)
not a good idea due to the transparency and reverse-engineering possibilities of debug binaries, and3)
debug runtime binaries will not exist on non-developer boxes (and don't be tempted to statically link - if that is possible in debug mode). And finally: it could be easy to forget to rebuild with release binaries when you mess around with debugging like this. It sure happens.
Dependency Scan: There are a number of tools you can use to scan for dependency problems that can cause launch problems. Here is a dependency scanning tools list. Maybe also check the section "Visual Studio Modules View". I am not sure if that view would show you what settings files are in use (or just what binaries are loaded).
Some Links:
Upvotes: 1