I get the following exception when I double click my MSI package
CustomActionException: System.UnauthorizedAccessException: Filename: redirection.config
Error: Cannot read configuration file due to insufficient permissions
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_SitesSection()
at Microsoft.Web.Administration.ServerManager.get_Sites()
...
It does this because it's trying to access the path C:\Windows\System32\inetsrv\config from inside a Custom Action
Now if I ran the MSI from PowerShell, where you're running as Administrator, it seems to work fine but the default double-click invocation does not work
Other than adding myself to the UAC of that folder, is there anyway for my CustomActions to run with elevated privileges?
I tried the Package-level attribute of InstallPrivileges="elevated" but to no effect
You need to use Bootstrapper to run the msi in admin mode by default. You can use Wix Bootstrapper to do that. Or you can use any third party tool like WinZip Self extractor or Inno Setup to run the msi file. It will run the msi as administrator always.
Related
I used the Wix tool in Visual Studio 2015 to generate an msi in a custom directory - not in Program Files. The software got installed alright (only for current user) but I am unable to uninstall it.
The error shown is: The specified path 'H:\Config.Msi\' is unavailable.
However, a folder with name exists at the specified path. Also, the uninstallation succeeds when I delete the contents of the folder created by the installer.
Any ideas on how I can get the software to uninstall cleanly?
The problem was that the referenced path H: was a virtual drive that caused the error. Mapping TARGETDIR to reference the correct path was a work-around. For my use case, this was sufficient.
When Burn runs an MSI installer, using MsiPackage, I'd like the MSI's log file to have a custom name, like MyProductName.log. I'd also like to append to an existing log file (with same name).
In InstallShield's Basic MSI Project's Release view there is an entry "MSI Command-Line Arguments" where you can enter a custom log file name:
/l+* "%TEMP%\MyProductName.log"
The "+" will append the log to an existing file.
Burn can pass public properties to the MSI, but I don't see a way to do what I want.
It looks like I'll need to write code (custom Burn bootstrapper) to run after the MsiPackage is installed (or uninstalled) to copy the contents of the log file (in the Burn variable defined in LogPathVariable) to the file with the custom name.
You can use the LogPathVariable attribute of the MsiPackage element to provide a custom log file name ...
See: http://wixtoolset.org/documentation/manual/v3/xsd/wix/msipackage.html
Also: https://support.firegiant.com/hc/en-us/articles/230912207-Pass-Properties-to-MsiPackage-from-Bundle-
To do what I needed, I wrote a simple bootstrapper, which became more complicated as I addressed things like passing installer properties to the bootstrapper, giving warnings if installing an x86 installer on an x64 OS (we encourage customers to use and x64 installer), etc.
It works on Win7 when I run msi file from local disk and from network share.
But when I run msi file on Win8-10 I get an error:
This application requires administrative rights
I set for Product:
InstallScope="perMachine"
InstallPrivileges="elevated"
Also, I have 10 custom actions (.NET).
How I can fix it?
Have you tried running it from elevated command prompt?
Open Start, type "cmd", right click on "cmd.exe", click "Run as administrator". Then navigate to your MSI file and use msiexec /i "yourmsi.msi"
If you want your installer to start elevated itself, you can create a bootstrapper application (executable file) to run it.
We are using WiX to sign and create MSI files and then bundle them into a signed EXE file. The MSIs are generated fine.
Each MSI file contains a command to run at the end to kill the application. In the standard WiX manner, we use CAQuietExec to run a quiet command (we've no Form, so we can't use CloseApplication).
This works just fine for the signed MSI files and also works fine if the MSI file is bundled into an unsigned EXE file.
However, if we sign the EXE, then the signature appears OK, but the kill command causes a 1603 Error Code.
We eventually (by literally commenting out each line in the MSI WXS file, building and running the EXE) isolated the issue to the CAQuietExec line that executes a 'taskkill' command.
Is there a way we can get more information on this? It doesn't make much sense and ensures we can't deploy a bundled EXE file.
I managed to find the problem. We found :
1) .Net 45 rather than .Net4 wouldn't have the issue (i.e. changign the pre-req and out app requirement)
2) The signing should be carried out in Wix
3) Sign all contents AND the MSIs too
So I have a Wix 3.0 project that installs an IIS7 Native Code Module. When uninstalling I would like to be able to shut down the IIS7 application pools before deleting the file so that a reboot is not necessary.
I am using the appcmd utility to shut down the app pools in a CustomAction element, but when I attempt to do an uninstall I get this error before the customaction is ever invoked:
The setup must update files or
services that cannot be updated while
the system is running. If you choose
to continue, a reboot will be required
to complete the setup.
I have the "After='InstallInitialize'" property set on the CustomAction, because the documentation says that any deferred/not-impersonated custom action must come between InstallInitialize and InstallFinalize.
So is there some way to have a custom action execute before this check for files in use is made? Or disable this check for a given file, or make the check happen later in the sequence?
Yes, you can specify the order for actions to occur by modifying the Sequence column in the InstallExecuteSequence table within the MSI file.
Get the ORCA tool to examine the MSI file to see what I mean, and use a Javascript script to modify the MSI as appropriate.