This was working in WiX 3.0.
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="inetpubDir" Name="inetpub">
<Directory Id="wwwrootDir" Name="wwwroot">
<Directory Id="INSTALLDIR" Name="DS3000Services" FileSource="\Server\Implementation\DS3000Services\Web">
<Component Id="DS3000ServicesVirtualDir" Guid="{4EFD7047-09F4-42e7-ACB5-A209D26B0338}">
<CreateFolder />
<iis:WebAppPool Id="AppPool" Name="[AppPoolName]" Identity="other" User="PortalUser" IdleTimeout="0" RecycleMinutes="0">
<iis:RecycleTime Value="1:00" />
</iis:WebAppPool>
<iis:WebVirtualDir Id="DS3000ServicesVirtualDir" Alias="[VIRTUALDIR]" Directory="INSTALLDIR" WebSite="DefaultWebSite">
<iis:WebApplication Id="DS3000ServicesApp" Name="DS3000 Services" Isolation="medium" WebAppPool="AppPool" />
</iis:WebVirtualDir>
</Component>
Install Log:
MSI (s) (10:E8) [09:57:58:553]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI14A0.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x800700b7: Failed to add appPool element
WriteIIS7ConfigChanges: Error 0x800700b7: Failed to configure IIS appPool.
WriteIIS7ConfigChanges: Error 0x800700b7: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (10:4C) [09:57:58:585]: User policy value 'DisableRollback' is 0
MSI (s) (10:4C) [09:57:58:585]: Machine policy value 'DisableRollback' is 0
Action ended 9:57:58: InstallFinalize. Return value 3.
Installing on Win Server 2008 R2. The AppPool already exists. If I remove the AppPool, the installer succeeds. Any thoughts? Thanks...
I would recommend you to create a customAction for creating virtual directory along with Application Pool.
I have used custom action in my project for that purpose. In the custom action you can check whether the application pool with the given name exists or not.
Added inbuilt commands
<Component Id="VDWeb" Guid="493E3487-AA4C-4476-8CC0-4B1C763AF6F7" Permanent="no">
<iis:WebVirtualDir Id="VDir" Alias="[VDNAME]" Directory="dir_Application_0" WebSite="WebSelectedWebSite">
<iis:WebApplication Id="WebApp" Name="[VDNAME]" WebAppPool="ABCAppPool" />
</iis:WebVirtualDir>
<RegistryKey Root="HKLM" Action="createAndRemoveOnUninstall" Key="SOFTWARE\ABC\[ProductCode]\VirtualDirectory">
<RegistryValue Name="VDName" Type="string" Value="[VDNAME]"/>
</RegistryKey>
</Component>
<Component Id="AppPool_1" Guid="414a377f-e044-49d5-b905-66bf3da6489f" Permanent="no">
<util:User Id="PoolAccount" Domain="[DOMAINNAME]" Name="[LogonUser]" Password="[NT_PASSWORD]" CreateUser="no">
<util:GroupRef Id="IISUsersGroup"/>
</util:User>
<iis:WebAppPool Id="ABCAppPool_NT" Name="[APPPOOLNAME_NT]" ManagedRuntimeVersion="v4.0" ManagedPipelineMode="integrated" Identity="other" User="PoolAccount">
<iis:RecycleTime Value="05:00" />
</iis:WebAppPool>
</Component>
<util:Group Id="IISUsersGroup" Name="IIS_IUSRS"/>
<iis:WebSite Id="WebSelectedWebSite" Description="[WEB_WEBSITE_DESCRIPTION]">
<iis:WebAddress Id="AllUnassigned1" Port="[WEB_WEBSITE_PORT]" IP="[WEB_WEBSITE_IP]" Header="[WEB_WEBSITE_HEADER]" />
</iis:WebSite>
Am using this and it works perfectly fine.
Related
I built a simple MSI installer with Wix 3.11. It includes an EXE and a shortcut, but the shortcut never appears on the desktop. I build the MSI without errors, it otherwise installs just fine, and there are no errors in the MSI log file. I viewed the MSI with Orca and I see the shortcut and desktop directory in their tables. Thoughts? I've tried setting ALLUSERS to 1 as well to no avail. Here is my wxs file:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Name="Imaginary Product" Language="1033"
Version="1.2.3.4" Manufacturer="Company" UpgradeCode="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
<Package Id="*" InstallerVersion='300' Compressed='yes'/>
<Media Id="1" Cabinet="ImaginaryProduct.cab" EmbedCab="yes"/>
<?if $(sys.BUILDARCH)="x64" ?>
<?define Win64 = "yes" ?>
<?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
<?else ?>
<?define Win64 = "no" ?>
<?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
<?endif ?>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DesktopFolder" SourceName="Desktop">
<Component Id="MainExecutableShortcut" Guid="{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}">
<Shortcut Id="ImaginaryUIEXEShortcut" Name="Imaginary UI" Description="Runs Imaginary UI" Target="ImaginaryUI.exe" WorkingDirectory="ProductProgramFilesFolder"/>
<RemoveFolder Id="RemoveDesktopFolder" Directory="DesktopFolder" On="uninstall"/>
<RegistryValue Root="HKCU" Key="Software\Microsoft\ImaginaryUI" Name="installed" Type="integer" Value="1" KeyPath="yes"/>
</Component>
</Directory>
<Directory Id="$(var.PlatformProgramFilesFolder)">
<Directory Id="ManufacturerProgramFilesFolder" Name="Company">
<Directory Id="ProductProgramFilesFolder" Name="Imaginary Product">
<Component Id="MainExecutable" Guid="{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}">
<File Id="ImaginaryUIEXE" Name="ImaginaryUI.exe" Vital="yes" Source=".\bin\$(var.Configuration)\ImaginaryUI.exe" KeyPath="yes"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id='MainApplication' Level='1'>
<ComponentRef Id="MainExecutable" Primary="yes"/>
<ComponentRef Id="MainExecutableShortcut" Primary="yes"/>
</Feature>
</Product>
</Wix>
Update: when the shortcut doesn't specify and icon, I see this in the installer log:
Action start 16:27:50: CreateShortcuts.
MSI (s) (08:34) [16:27:50:522]: Note: 1: 2205 2: 3: Icon
MSI (s) (08:34) [16:27:50:522]: Note: 1: 2228 2: 3: Icon 4: SELECT `Name`, `Data` FROM `Icon`
MSI (s) (08:34) [16:27:50:522]: Note: 1: 2205 2: 3: MsiShortcutProperty
MSI (s) (08:34) [16:27:50:523]: Note: 1: 2205 2: 3: MsiShortcutProperty
Action ended 16:27:50: CreateShortcuts. Return value 1.
When I do specify one, I see even less:
MSI (s) (14:D0) [16:34:59:527]: Doing action: CreateShortcuts
MSI (s) (14:D0) [16:34:59:527]: Note: 1: 2205 2: 3: ActionText
Action start 16:34:59: CreateShortcuts.
MSI (s) (14:D0) [16:34:59:528]: Note: 1: 2205 2: 3: MsiShortcutProperty
MSI (s) (14:D0) [16:34:59:528]: Note: 1: 2205 2: 3: MsiShortcutProperty
Action ended 16:34:59: CreateShortcuts. Return value 1.
So, no indication of failure. The icon just goes into the ether.
I'm not sure if this is your issue but to use the desktop folder you just define it as
<Directory Id="DesktopFolder"/>
I think you are actually putting the shortcut in "C:\Desktop\" (assuming the TARGETDIR is C:). All System Folder Properties should be defined the same way.
Also, remove this from your component definitions
<RemoveFolder Id="RemoveDesktopFolder" Directory="DesktopFolder" On="uninstall"/>
You don't want to remove the Desktop folder, it's not something you created in your install and neither is it something you own. Also, RemoveFolder will not do anything if anything else is present in that folder and basically everyone has at least a Recycle Bin in their desktop folder so it will never do anything.
I'm not sure why the RemoveFolder is used in other Shortcut definitions like the startmenu. It may be due to how windows installer works where it only implicitly removes a folder if components containing Files were present.
I'm pretty sure that Target must be an ID, not the name of the file. So change
Target="ImaginaryUI.exe"
to
Target="[#ImaginaryUIEXE]"
We are using WIX 3.10 to create web applications under default website, this implementation works fine but the issue is with uninstall of the product that it does not remove the web application under the default website.
The Website port and name are entered by user as part of custom dialog which are stored in respective properties.further during uninstall these properties are restored using wix toolset remember property http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ which sets the web application property during uninstall, but still the application is not removed on uninstall.
Uninstall log that sets the website properties after Appsearch:
Action start 15:17:04: AppSearch.
MSI (s) (24:64) [15:17:04:657]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (24:64) [15:17:04:657]: PROPERTY CHANGE: Modifying WEBSITEPORTPROPERTY property. Its current value is 'WEBSITEPORT'. Its new value: '80'.
MSI (s) (24:64) [15:17:04:657]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (24:64) [15:17:04:657]: PROPERTY CHANGE: Modifying WEBSITEPROPERTY property. Its current value is 'WEBSITE'. Its new value: 'Default Web Site'.
<Fragment>
<iis:WebSite Id="SITE" Description="[WEBSITE]">
<iis:WebAddress Id="AllUnassigned" Port="[WEBSITEPORT]"/>
</iis:WebSite>
<DirectoryRef Id="INSTALLFOLDER">
<Component Id="TestAppPool" Guid="GUID" KeyPath="yes" Permanent="yes">
<iis:WebAppPool Id="TestAppPool"
Name="Test Net 4.0"
Identity="applicationPoolIdentity"
ManagedPipelineMode="Integrated"
ManagedRuntimeVersion="v4.0" />
</Component>
<Component Id="IIS.Component" Guid="GUID" KeyPath="yes" Permanent="no" Win64="yes">
<iis:WebVirtualDir Id="VirtualDir" Alias="[APPLICATION_NAME]" Directory="Dir" WebSite="SITE" >
<iis:WebApplication Id="Application" Name="[APPLICATION_NAME]" WebAppPool="TestAppPool"/>
</iis:WebVirtualDir>
<RegistryValue Root='HKLM' Key='SOFTWARE\Test\Prod' Name='Website' Value='[WEBSITE]' Type='string' Action='write' />
<RegistryValue Root='HKLM' Key='SOFTWARE\Test\Prod' Name='WebsitePort' Value='[WEBSITEPORT]' Type='string' Action='write' />
<RegistryValue Root='HKLM' Key='SOFTWARE\Test\Prod' Name='Application' Value='[APPLICATION_NAME]' Type='string' Action='write' />
</Component>
</DirectoryRef>
</Fragment>
There is another issue related, repair operation through Add Remove Programs throws a Fatal error with the following error:
WriteIIS7ConfigChanges: Entering WriteIIS7ConfigChanges in C:\Windows\Installer\MSICDDF.tmp, version 3.10.3007.0
WriteIIS7ConfigChanges: Custom action data hash: 41034C345A4E6B9B4DDB8490C1BC5266637BC0E8
WriteIIS7ConfigChanges: CustomActionData WriteIIS7ConfigChanges length: 225
WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application
WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application.
WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed.
Any other alternative solution that would solve the issue?
I am doing WIX MSI slient installation,and also there is some custom actions checking in between if the customaction fails how to roll back or end the slient installation process of the msi??I am copying files and also starting windows service using Wix installation.When ever customaction fails how i can stop the creation of directory and starting of the windows service??
[CustomAction]
public static ActionResult PrerequisiteCheck(Session session)
{
if (Status.IsServiceAvailable && Status.IsPrinter)
{
return ActionResult.Success;
}
else
{
//Stop Installer
return ActionResult.Failure;
}
}
<CustomAction Id="CheckPrerequiste" BinaryKey="BIN_CustomAction" DllEntry="CheckPrerequiste" Return="ignore" Execute="immediate" />
<InstallExecuteSequence> <Custom Action="CA_PrerequisiteCheck" After="InstallExecute" > </Custom>
</InstallExecuteSequence>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="Service">
<Component Id="WindowsService" Guid="AA34D3C1-26F1-4A7E-A226-1AB01501C67C">
<File Id="00690A65EA1A3EFEB7607285DBA0C8C5" KeyPath="yes" Source="WindowsService.Svc.exe" />
<ServiceInstall Id="Service" Name="Service" DisplayName="Windows Service" Description="Windows Service" Start="auto" ErrorControl="normal" Type="ownProcess" />
<ServiceControl Id="sc_Service" Name="Service" Stop="both" Remove="uninstall" Wait="yes" />
<Component Id="WindowsSvcexe" Guid="06ABF18B-DEDE-4D98-AF9F-8384539A6BC3"> <File Id="49215CE1A25380930C771772AD14519B" KeyPath="yes" Source="WindowsService.Svc.exe.config" /> </Component> </Component>
</Directory>
</Directory>
</Directory>
The installation sequence is divided into two main stages; immediate and deferred. The main reason of dividing an installation into two phases (UI and Execution) is supplying roll-back if an error occurs. All actions in the execution phase, between InstallInitialize and InstallFinalize are included in the roll-back, which is called the deferred stage. The initial phase, where the roll-back script is being prepared but the roll-back protection has not started yet is called immediate stage.
The UI sequence does not have any roll-back feature, therefore actions that alter the system should never take place there.
Custom actions that make system changes should be marked as deferred and should be scheduled to run between InstallInitialize and InstallFinalize in the execution phase. Roll-back actions should be supplied by the developer for custom actions:
…
<CustomAction Id=”myaction” Execute=”deferred” Return=”check” />
…
<InstallUISequence>
<Custom Action=”myaction” After=”CostFinalize” />
<Custom Action=”myaction2” After=”myaction” />
</InstallUISequence>
<InstallExecuteSequence>
<Custom Action=”myaction3” After=”InstallInitialize” />
<Custom Action=”myaction4” After=”myaction3” />
</InstallExecuteSequence>
Custom actions that are deferred execute during the Execute sequence’s rollback-protected phase. To give those actions rollback capabilities, separate custom actions that undo the work should be authored.
Rollback actions are scheduled before the action they are meant to revert in case of an error:
<CustomAction Id="systemChangingCA" Execute="deferred" Script="vbscript">
msgbox "Your system has been changed"
</CustomAction>
<CustomAction Id="rollbackSystemChangingCA" Execute="rollback" Script="vbscript">
msgbox "System changes are undone"
</CustomAction>
<CustomAction Id="causeError" Execute="deferred" Script="vbscript">
Err.Raise 507
</CustomAction>
These are scheduled as:
<InstallExecuteSequence>
<Custom Action="rollbackSystemChangingCA" Before="systemChangingCA" />
<Custom Action="systemChangingCA" After="InstallInitialize" />
<Custom Action="causeError" After="systemChangingCA" />
</InstallExecuteSequence>
In this example, systemChangingCA will run during deferred phase of InstallExecuteSequence. When causeError runs afterwards, it causes an exception to be thrown, which triggers a rollback. Then rollbackSystemChangingCA runs.
Wix toolset also provides its own custom action for stimulating a rollback called WixFailWhenDeferred. It is a part of WixUtilExtension and you could use it to test your rollback methods.
The folders created by WiX itself should be removed automatically during a rollback.
You can learn more about the overall concept of Microsoft Installer and WiX from the book of Nick Ramirez: "A Developer's Guide to Windows Installer XML". It has many examples and cases including the ones above.
I have this component in my .wxs file:
<Component Id="Component.IisConfiguration" Guid="[COMPONENT_GUID_IISSITE]">
<iis:WebAppPool Id="IIS.AppPool" Name="[WEB_APP_POOL_NAME]" Identity="networkService" ManagedRuntimeVersion="v4.0" />
<iis:WebSite Id="IIS.WebSite" Description="[WEB_APP_NAME]" SiteId="[WEB_APP_SITEID]" Directory="TARGETDIR" >
<iis:WebApplication Id="IIS.WebSite.Application" Name="[WEB_APP_POOL_NAME]" WebAppPool="IIS.AppPool" />
<iis:WebAddress Id="IIS.WebSite.WebAddress.Port" Port="[WEB_APP_ADDRESS_PORT]" />
<iis:WebDirProperties Id="IIS.WebSite.Authentication" WindowsAuthentication="yes" />
</iis:WebSite>
</Component>
Is it possible to set "ASP.NET Impersonation" anywhere ?
It seems there's no out-of-the-box switch for this. You can have a custom action which calls:
appcmd set config /commit:WEBROOT/section:identity /impersonate:true
See this article for more information.
On the other hand, you can always set this setting on the application level, and use the standard XmlConfig element to modify the web.config file for this.
I have following .wxs-file:
<?xml version="1.0" encoding="UTF-8"?>
<?define ProductVersion="x.x.x.x" ?>
<?define UpgradeCode="{**MYGUID**}" ?>
<?define Manufacturer="My Company" ?>
<?define ProductName="My Product" ?>
<?define SkuName="MyProduct" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*"
Name="$(var.ProductName)"
Language="1033"
Version="$(var.ProductVersion)"
Manufacturer="$(var.Manufacturer)"
UpgradeCode="$(var.UpgradeCode)">
<Package InstallerVersion="301"
Compressed="yes"
InstallPrivileges="elevated"
InstallScope="perMachine"
Platform="x86" />
<Media Id="1"
Cabinet="$(var.SkuName).cab"
EmbedCab="yes" />
<Directory Id="TARGETDIR"
Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="ManufacturereDirectory"
Name="$(var.Manufacturer)">
<Directory Id="ProductDirectory"
Name="$(var.ProductName)" />
</Directory>
</Directory>
</Directory>
<ComponentGroup Id="MainComponentGroup">
<Component Directory="ProductDirectory">
<File Name="$(var.MyProject.TargetFileName)"
Source="$(var.MyProject.TargetPath)"
KeyPath="yes"
Vital="yes" />
<ServiceInstall Id="SeviceInstall"
Name="$(var.ProductName)"
DisplayName="$(var.ProductName)"
Type="ownProcess"
Interactive="no"
Start="auto"
Vital="yes"
ErrorControl="normal"
Account="LOCALSYSTEM">
</ServiceInstall>
<ServiceControl Id="ServiceControl_Start"
Name="$(var.ProductName)"
Start="install"
Wait="no" />
<ServiceControl Id="ServiceControl_Stop"
Name="$(var.ProductName)"
Stop="both"
Remove="uninstall"
Wait="yes" />
</Component>
</ComponentGroup>
<Feature Id="MainFeature"
Level="1">
<ComponentGroupRef Id="MainComponentGroup" />
</Feature>
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Property="UPGRADEFOUND"
Minimum="0.0.0.1" IncludeMinimum="yes"
Maximum="$(var.ProductVersion)" IncludeMaximum="yes"
OnlyDetect="no"
IgnoreRemoveFailure="yes"
MigrateFeatures="yes"/>
</Upgrade>
<CustomAction Id="ServiceRestarter"
Directory="ProductDirectory"
ExeCommand=""[SystemFolder]sc.exe" failure "$(var.ProductName)" reset= 60 actions= restart/0"
Impersonate="no" />
<InstallExecuteSequence>
<InstallExecute Before="RemoveExistingProducts" />
<RemoveExistingProducts Before="InstallFinalize" />
<Custom Action="ServiceRestarter" After="InstallFinalize"><![CDATA[NOT Installed]]></Custom>
</InstallExecuteSequence>
</Product>
</Wix>
Before that, I've tried:
<CustomAction Id="ServiceRestarter"
Property="QtExecCmdLine"
Value='"[SystemFolder]sc.exe" failure "$(var.ProductName)" reset= 60 actions= restart/0' />
which apparently called sc.exe - but changed nothing ...
Before that I've tried:
<ServiceInstall Id="SeviceInstall"
Name="$(var.ProductName)"
DisplayName="$(var.ProductName)"
Type="ownProcess"
Interactive="no"
Start="auto"
Vital="yes"
ErrorControl="normal"
Account="LOCALSYSTEM">
<ServiceConfig Id="ServiceConfig"
DelayedAutoStart="yes"
OnInstall="yes"
OnReinstall="yes"
OnUninstall="no"
FailureActionsWhen="failedToStopOrReturnedError" />
<ServiceConfigFailureActions Id="ServiceRestarter"
OnInstall="yes"
OnReinstall="yes"
OnUninstall="no"
ResetPeriod="0">
<Failure Action="restartService" Delay="0" />
<Failure Action="restartService" Delay="0" />
<Failure Action="restartService" Delay="0" />
</ServiceConfigFailureActions>
</ServiceInstall>
which did not work, as the MsiServiceConfigFailureActions table does not work if using an installer < 5.0, and even if using InstallerVersion="500" the only thing I get is an error:
Serivce 'My Product' (My Product) could not be configured. This could
be a problem with the package or your permissions. Verify that you
have sufficient privileges to configure system services.
(and yes, ... I've tried InstallPrivilges="elevated" also - but ... the real issue is Action="restartService" according to this)
So ... using a CustomAction is the way to go (or not?).
I have following output of the log
MSI (s) (34:28) [13:56:46:914]: Note: 1: 1722 2: ServiceRestarter 3: C:\Program Files (x86)\My Company\My Product\ 4: "C:\Windows\SysWOW64\sc.exe" failure "My Product" reset= 60 actions= restart/0
MSI (s) (34:28) [13:56:46:914]: Note: 1: 2205 2: 3: Error
MSI (s) (34:28) [13:56:46:914]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1722
MSI (c) (2C:0C) [13:56:46:914]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action ServiceRestarter, location: C:\Program Files (x86)\My Company\My Product\, command: "C:\Windows\SysWOW64\sc.exe" failure "My Product" reset= 60 actions= restart/0
MSI (s) (34:28) [13:56:48:849]: Note: 1: 2205 2: 3: Error
MSI (s) (34:28) [13:56:48:849]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1709
MSI (s) (34:28) [13:56:48:849]: Product: My Product -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action ServiceRestarter, location: C:\Program Files (x86)\My Company\My Product\, command: "C:\Windows\SysWOW64\sc.exe" failure "My Product" reset= 60 actions= restart/0
Action ended 13:56:48: ServiceRestarter. Return value 3.
Action ended 13:56:48: INSTALL. Return value 3.
Can anybody help me out?
edit
I've used the old ServiceConfig-extension:
<util:ServiceConfig xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
FirstFailureActionType="restart"
SecondFailureActionType="restart"
ThirdFailureActionType="restart"
ResetPeriodInDays="1"
RestartServiceDelayInSeconds="20" />
which gives me a following build-error:
error CNDL0200: The ServiceInstall element contains an unhandled
extension element 'util:ServiceConfig'. Please ensure that the
extension for elements in the
'http://schemas.microsoft.com/wix/UtilExtension' namespace has been
provided.
I know that I can resolve this error by using -ext WixUtilExtension via commandline - but I want to use Visual Studio for building ... So how can I adapt the build-command?
Only chance is to add a reference to WixUtilExtension.dll to my project.
I can see that you've only tried the ServiceConfig element, which came with MSI 5.0. However, there's another ServiceConfig element in UtilExtension, which has been there for a long time and it seems that the thread you mention in your question confirms that it works.
The util:ServiceConfig element contains 3 parameters you'd like to use: FirstFailureActionType, SecondFailureActionType and ThirdFailureActionType, all accepting the same enumeration of values - none, reboot, restart and runCommand.
Try it out and if it works, it is far better choice than a custom action.
For WIX V 4.0, building with VS2015, the following works:
1: Ensure that WixUtilExtension.dll assembly is referenced by WIX project.
2: Add http://wixtoolset.org/schemas/v4/wxs/util ns to root Wix element. Note that this is the correct NS for WIX 4.0 (NOT http://schemas.microsoft.com/wix/UtilExtension as for previous versions).
<Wix
xmlns="http://wixtoolset.org/schemas/v4/wxs"
xmlns:util="http://wixtoolset.org/schemas/v4/wxs/util"
>
3: Ensure that ServiceConfig element is prefixed with correct namespace reference.
<ServiceInstall
Id="MyService"
Type="ownProcess"
Name="MyService"
DisplayName="MyService"
Description="My Service"
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="normal"
>
<util:ServiceConfig
FirstFailureActionType='restart'
SecondFailureActionType='restart'
ThirdFailureActionType='restart'
RestartServiceDelayInSeconds='30'
ResetPeriodInDays='1'/>
</ServiceInstall>
In Visual Studio, to avoid using -ext in CLI you may do the following:
Of course, you add a resource: <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
then, in Solution Explorer -> References -> Add..
WixUtilExtension.dll
After that everything works like a charm.
(wix 3.10)
Of course, if you do use the second ServiceConfig from utils. Like <util:ServiceConfig blablabla