Hi I am trying to install a web application using WIX. I am not sure if what I have is correct but I am getting this error in my log files:
My wxs file:
<ComponentGroup Id='IISConfig'>
<Component Id='WebAppPool' Guid='5EC0510D-BE49-4FE9-9572-5695DB9BD343' Directory='INSTALLLOCATION'>
<CreateFolder/>
<iis:WebAppPool Id="WebAppPool" Name="DefaultAppPool" />
<iis:WebSite Id='DefaultWebSite' Description='Default Web Site' Directory='INSTALLLOCATION' WebApplication='WebApplication'>
<iis:WebAddress Id='AllUnassigned' Port='80' />
<iis:WebDirProperties Id='WebDirProperties' Execute='yes'/>
</iis:WebSite>
</Component>
<Component Id='WebVirtualDirComponent' Guid='52D0B071-0801-4B93-8C8F-F5FC92DD8D8F' Directory='INSTALLLOCATION'>
<CreateFolder/>
<iis:WebVirtualDir Id='WebVirtualDir' Alias='[PRODUCTNAME]' Directory='INSTALLLOCATION' WebSite='DefaultWebSite'>
<iis:WebDirProperties Id='WebVirtualDirProperties' Execute='yes' WindowsAuthentication='yes'/>
<iis:WebApplication Id='WebApplication' Name='[PRODUCTNAME]' WebAppPool='WebAppPool'>
<iis:WebApplicationExtension Extension='dll' Executable='[#mod_Gsoap.dll]' CheckPath='yes' Script='yes'/>
</iis:WebApplication>
</iis:WebVirtualDir>
</Component>
</ComponentGroup>
Any my log file:
MSI (s) (90:C4) [14:48:38:200]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (90:AC) [14:48:38:216]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIAB38.tmp, Entrypoint: WriteIIS7ConfigChanges
WriteIIS7ConfigChanges: Error 0x80040154: Failed to open AppHostWritableAdminManager to configure IIS7
WriteIIS7ConfigChanges: Error 0x80040154: WriteIIS7ConfigChanges Failed.
CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 14:48:38: InstallFinalize. Return value 3.
I would be grateful if anyone could point me in the right direction..:)
That error message means the IIS7 COM object for writing to the IIS configuration is not properly registered on the machine. Not sure the best way to fix the issue, but you might try repairing (or uninstall/install) IIS.
In my case, IIS was not installed at all. D'oh.
Related
I am using Wix to create MSI installers. My requirement is to pass parameters while installing msi from the command line and update' theappsettings.json` with the values passed.
To achieve this, I have added below property and component.
<Property Id="ApplicationLog.pathFormat" />
<Component Id="config" Guid="*">
<File Id="appconfig" Source="$(var.BasePath)\appsettings.json" KeyPath="yes" Vital="yes"/>
<util:XmlFile
Id="_pathFormat_" File="$(var.BasePath)\appsettings.json"
Action="setValue"
Name="pathFormat" Value="[pathFormat]"
ElementPath="/ApplicationLog/Serilog/WriteTo/Args/"
Sequence='1' />
</Component>
I have passed the values as follow while installing
C:\work\Installer\bin\Debug>MyService-Debug-x86.msi pathFormat="value1"
But I get below error
Failed to open XML file ....\Installer\bin\Debug\netcoreapp2.1\win-x86\publish\appsettings.json. system error -2147024786
Additional Information
There was ICE30 error,
ICE30: The target file 'l-racj8d.jso|appsettings.json' is installed in '[ProgramFilesFolder]\MyService\' by two different components on an LFN system: 'config' and 'cmpF82FCA80BBAF44D285C97F10993DEEE6'.
Which resolved by changing the ICE validation-> Suppress ICE validation
But why installer unable to open the json app settings? I am running the installer in administrator mode.
Update
I have changed $(var.BasePath) to '[INSTALLDIR]'
<Component Id='config' Guid='*'>
<File Id='jsonconfig' Source='[INSTALLDIR]appsettings.json' KeyPath="yes" Vital="yes"/>
<util:XmlFile Id='xpathFormat' File='[INSTALLDIR]appsettings.json'
Action='setValue' Name='pathFormat' Value='[ApplicationLog.pathFormat]'
ElementPath='/ApplicationLog/Serilog/WriteTo/Args/' Sequence='1' />
</Component>
But I am getting
The system cannot find the file '[INSTALLDIR]appsettings.json'.
Is it because appsettings.json is not yet copied to [INSTALLDIR]?? If yes, then how to achieve this?
Even though I hide the WiX property that contains a password and the ExecXmlFile property...
<Property Id="MyApp_MyServer_constr" Hidden="yes" />
<Property Id="ExecXmlFile" Hidden="yes" />
<DirectoryRef Id='MYAPPDIR'>
<Component Id='UpdateMyAppMyServerConnectionString' Guid='MY-GUID' Win64="yes">
<CreateFolder />
<util:XmlFile Id='UpdateMyAppMyServerConnectionString'
Action="setValue"
ElementPath="[MyServer_elementpath]"
File="[MYAPPDIR]MyApp.exe.config"
Value="[MyApp_MyServer_constr]" />
</Component>
</DirectoryRef>
...password details are exposed in the MSI install log file.
MSI (s) (F0:7C) [20:27:56:613]: Executing op: ActionStart(Name=ExecXmlFile,,)
Action 20:27:56: ExecXmlFile.
MSI (s) (F0:7C) [20:27:56:613]: Executing op: CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=20C:\Program Files\MyCompany\MyInstallerName\MyApp\MyApp.exe.config30//configuration/connectionStrings/add[#name='MyServer']/#connectionStringUser ID=sa;Password=wysiwyg;Initial Catalog=MyDatabase;Data Source=MACHINE-NAME;Application Name=MyShortAppName)
I've done a considerable amount of checking online, but there does seem to be a WiX way of hiding this information from an MSI log without doctoring things using Orca after creating an MSI.
I found this WiX bug http://wixtoolset.org/issues/3859/, but it seems that not allowing hiding of ExecXmlFile CustomAction calls was by design.
Alternately, is there another WiX way to accomplish what I need that doesn't expose password details in the log file?
Thanks
I have a project that includes an ATL service. Currently, our installer registers the service with custom actions that run the installed service executable with the command:
MyService.exe /server
and unregisters it with the command
MyService.exe /unregservice
This has caused headaches in some situations where the command has failed and the installation becomes stuck in a state where it can neither be completed or fully rolled back, leaving the application unusable.
We would like to replace these custom actions by using the ServiceInstall tag to do the registration completely within the MSI file, but we can't get it to work. Our initial code looked like this:
<Component Id="c.MyService.exe" Guid="{PUT-GUID-HERE}">
<File Id="f.MyService.exe" Name="MyService.exe" KeyPath="yes"
DiskId="1" Source="$(var.MyService.TargetPath)" Vital="yes" />
<ServiceInstall Id="svci.MyService" Name="MyService" Type="ownProcess"
Start="demand" ErrorControl="normal" DisplayName="MyService"
Description="My Service" Account="LocalSystem" Interactive="no"
Vital="yes">
<ServiceDependency Id="RPCSS"/>
</ServiceInstall>
<ServiceControl Id="svcc.MyService" Stop="both" Remove="uninstall"
Name="MyService" Wait="yes" />
</Component>
The install would complete, but running the program failed with this message:
Retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040152 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
One suggestion found via google was to add in the AppId tag inside the Component tag as follows:
<Component ... />
...
<AppId Id="$(var.MyServiceGUID)" LocalService="MyService" Description="MyService" />
...
</Component>
However this didn't have any effect.
Any ideas how to replicate the ATL's self-registration in the MSI itself?
For reference, I believe I am having the same problem as in this ancient, unanswered post: http://social.msdn.microsoft.com/Forums/vstudio/en-US/eb33cf47-628a-4fbf-a740-f81afe2f2b43/atl-service-install-and-registration-issue-com-server-vs-windows-service?forum=vcgeneral
Thanks very much
WiX has a program called Heat that can be used to harvest the COM metadata for your ATL server. Run this program to generate a wxs fragement, migrate the COM elements to your wxs fragement then rebuild and test on a clean snapshotted VM. Rinse and repeat if needed as COM/ATL is a little tricky at times.
Harvest Tool (Heat)
I am struggling to install a com based isapi dll globally into iis 7.5 using wix 3.6.3303.1/4.0.12.0.
I have the following wix config (full config here):
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="IsapiDll" Guid="ADD-GUID-HERE">
<File Id="isapidll" Name="isapi.dll" Source="isapi.dll" />
</Component>
<Component Id="IisFilter" Guid="ADD-GUID-HERE">
<CreateFolder />
<iis:WebFilter Id="IisFilter" Name="MyIsapi" Path="[INSTALLFOLDER]isapi.dll" LoadOrder="last" Description="MyIsapi" />
</Component>
</ComponentGroup>
</Fragment>
I receive the following error in my msi log when running on Windows 7 32bit with IIS7.5:
WriteIIS7ConfigChanges: Error 0x8007000e: Failed while finding IAppHostElement filter/#name=(null)
WriteIIS7ConfigChanges: Error 0x8007000e: Failed to delete filter
WriteIIS7ConfigChanges: Error 0x8000ffff: Unexpected IIS Config action specified for global filter
WriteIIS7ConfigChanges: Error 0x8000ffff: Failed to configure IIS filter global.
WriteIIS7ConfigChanges: Error 0x8000ffff: WriteIIS7ConfigChanges Failed.
I fear the problem is a bug in wix itself.
CreateGlobalFilter() passes pwzFilterName to DeleteCollectionElement() before it has been assigned a value. This later causes Iis7FindAppHostElementString() to be called with a null wzAttributeValue value which appears to be the cause of the error.
I could of course be on a wild goose chase and be happy to be pointed in the right direction...
Update:
I've now played with website level installs and have that working with the addition of the WebSite attribute and element. Config here
Edit: Changed path attribute to correct format.
0x8007000e means out of memory and the (null) in the message makes me bet this is a bug in the custom action. If you can debug it that's ideal. In any case, entering a bug at http://wixtoolset.org/bugs would probably be a good idea.
You forgot to add WebSite attribute, this code works well for me in WIX3.7:
<Component Id="IsapiFilterComponent" Guid="AE102719-D7DE-450A-A44C-29E7D9A36C0D" KeyPath="yes">
<iis:WebFilter Id="MyWebDavFilter" Name="MyWebDavFilter" Path="[INSTALLFOLDER]MyWebDavFilter.dll" LoadOrder="last" Description="My Web Dav Filter" WebSite="DefaultWebSite" />
</Component>
but this
<Component Id="IsapiFilterComponent" Guid="AE102719-D7DE-450A-A44C-29E7D9A36C0D" KeyPath="yes">
<iis:WebFilter Id="MyWebDavFilter" Name="MyWebDavFilter" Path="INSTALLFOLDER]MyWebDavFilter.dll" LoadOrder="last" Description="My Web Dav Filter"/>
</Component>
gives the same error you have.
Of course, you have to add <iis:WebSite> element to your wxs file.
Having a major problem. I read that Rob M said to use Guid="*" whenever possible so I changed all of my Guid's to this. Uninstalling my product is messing up now though. The files are successfully removed but the shortcuts, services and registry are not. Please Help
This is my service:
<Component Id="service" Guid="*">
<File Id="service.exe" Name="service.exe" KeyPath="yes" Source="$(var.Bin)\service.exe"/>
<ServiceInstall Id="service.exe" Name="[PRODUCTNAME]" Description="[ProductName]" Account="[SERVICEACCOUNT]" Password="[SERVICEPASSWORD]" Arguments=" /start [ProductName]" Start="auto" Interactive="yes" Type="ownProcess" Vital="yes" ErrorControl="critical" />
<ServiceControl Id="service.exe" Name="[PRODUCTNAME]" Stop="both" Start="install" Remove="uninstall" Wait="no"/>
</Component>
This is the uninstall log:
Service '' () could not be stopped. Verify that you have sufficient privileges to stop system services.
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ActionStart(Name=DeleteServices,Description=
Deleting services
,Template=
Service: [1]
)
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=1300000)
MSI (s) (DC:D0) [14:25:02:018]: Executing op: ServiceControl(,,Action=8,Wait=0,)
MSI (s) (DC:D0) [14:25:32:064]: Executing op: ServiceControl(,Name=OPC,Action=8,Wait=0,)
Info 1922.
Service '' () could not be deleted. Verify that you have sufficient privileges to remove system services.
Its not picking up the name, anyone know why it would do this?
First questions first:
Have you already released a version of this product? If so, changing component GUIDs is likely a huge violation of component rules, so you should not change these once released. If it's only been on your test machine, that's not important.
Are you resetting your test machine such that the violation of component rules is not affecting the uninstall, or are you attempting to perform some sort of upgrade before this failing uninstallation?
What does the verbose MSI log from uninstallation indicate?
How is your property "PRODUCTNAME" defined? If it's not a constant, please verify that it's initialization is performed during uninstall sequence
MSIZAP, will be the ultimate way to eliminate everything installed on the machine by the installer. I do recommend that you test it on a Proof of concept of what you are trying to do, and use a VM for all installing tests.