1
votes

I need to launch .cmd script during installation, and this script modify some files in the installation directory. I have the following WiX code:

<Fragment>
    <Property Id="WINCMD">cmd.exe</Property>
    <CustomAction Id="ResignManifest" 
                  Property="WINCMD" ExeCommand="/C [ToolDir]manifest_resign.cmd"
                  Execute="deferred" Impersonate="no" Return="check"/>

    <InstallExecuteSequence>
        <Custom Action="ResignManifest" After="InstallFinalize"/>
    </InstallExecuteSequence>
</Fragment>

The problem is that during installation the script fails to do modification, because of insufficient access rigths. My CA specifies that MSI should not impersonate the user context (I launch installer with Admin rigths), but cmd.exe runs without Admin rights.

PS. I know that this isn't good practice to additionally launch bat/cmd files during installation, but I have to do it to resign application and deployment manifests for some Silverlight application (during installation user modifies application config file, so the hash of such file inside manifest become invalid).

1

1 Answers

1
votes

Somewhere in my answer history I've addressed this one before. The trick is to simplify the problem by refactoring the Silverlight code to read from a settings.xml file that isn't signed. This is what I had my developer do a few years ago for an internal app we wrote. The server side has a settings webservice that reads from a settings.xml file. The Silverlight app that calls the webservice to retrieve it's settings. This eliminates the need for the custom action.

See: How to do Text file changes in a ZIP file in InstallShield Basic MSI project

Creating and Using Silverlight web.config app settings (Web.config Configuration Applicatioin Settings) or app.config application settings configuration file for Silverlight

I agree with what you already know. It's not a good design to call a batch file and resign files laid down by MSI. You are right, you should already be executing in the system context. Are you sure CMD.exe isn't running elevated? I don't know how you could determine that as it's not getting logged by MSI. I'd suggest at a minimum using the QuietExecCA pattern to get the results of the cmd script logged in the MSI log.