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.
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?
How to create msi installer which can install file located near by it or fetch this file over http?
We want to create an msi installer with wix toolkit 3.9 that should distribute our virtual machine (size is bigger than allowed in cab files), hypervisor, register(unregister) powershell scripts and something else.
We cannot create MSI with big file.
I see two approaches:
We can put virtual machine image located near by msi installed and programming this installer to install image if it exists near by it.
d:> dir
myapp.msi
vm.vdi
We can agree with client that he must put vm image located near the msi installer manually, before run it.
Download this vm image with http. What are the options for this?
How I can do this ?
I do this like this:
<!-- This is a list of directories that are used by this product as installation locations or custom -->
<!-- action file search locations. -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder" Name="AppData">
<Directory Id="AppRootDirectory" Name="Lookd"/>
</Directory>
</Directory>
<DirectoryRef Id="AppRootDirectory">
<Component Id="SupplementalScripts" Guid="31693357-578d-4dde-aefc-92f413942810" KeyPath="yes" DiskId="1">
<CreateFolder/>
<RemoveFolder Id="RemoveAppRootDirectory" On="uninstall" />
<File Id="SupplementalScripts_Register" DiskId="1" Vital="yes" Source="dst\Scripts\Register.ps1" Checksum="no"/>
<File Id="SupplementalScripts_UnRegister" DiskId="1" Vital="yes" Source="dst\Scripts\UnRegister.ps1" Checksum="no"/>
<File Id="SupplementalScripts_Throw" DiskId="1" Vital="yes" Source="dst\Scripts\Throw.ps1" Checksum="no"/>
<RegistryKey Root="HKCU" Key="Software\CVisionLab\Lookd" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">
<RegistryValue Name="Version" Value="[ProductVersion]" Type="string"/>
</RegistryKey>
</Component>
<Component Id="VirtualMachineDiskImage" Guid="daa7375f-7bd8-4e97-846a-db5f6e6b025a">
<CopyFile Id="VDIFile" SourceName="lookd.vdi" SourceDirectory="SOURCEDIR" DestinationDirectory="TARGETDIR" />
</Component>
</DirectoryRef>
But I recive and error when build:
error LGHT0094 : Unresolved reference to symbol 'Directory:SOURCEDIR' in section 'Product:{7BBA165B-9A8A-40D1-97FA-233F93426F83}'.
If 1 will work for you, then a WiX CopyFile should work. The source location of the copy would be the [SourceDir] property, and the destination some directory defined in your WiX.
If it's really that big, download may be tedious, but if you use it then do it from an app you install rather than run it from the MSI install.
Clarifying in response to comment: there are just two recommendations here that are separate and not related:
Use WiX CopyFile if you choose to copy the file from next to the MSI file to the client system.
If you choose the download option, doing that from the MSI will be tedious and very error prone. It may not even work given that VS custom actions have very limited (or no) access to the network. So do a download from the app you're installing and not the MSI, if you do in fact decide to download.
My application installs the DesKey Dk2 dongle drivers if they are not installed or are lower than a perticular version. One of the user is complaining that whenever he runs the application from start menu shortcut, DK2 installation starts and then application is launched. Nobody else is facing this issue.
I am indtalling Dk2 as custom action in Wix script as below. lets say DK2 is represented as ABC:
<DirectoryRef Id="TARGETDIR">
<Directory Id="ABCRedistDirectory" Name="ABCDrivers">
<Component Id="ABCRedist" Guid="*">
<File Id="ABC_EXE" Source="$(var.TargetDir)ABC.exe" KeyPath="yes" Checksum="yes"/>
</Component>
</Directory>
</DirectoryRef>
<Property Id="DK2_VERSION">
<RegistrySearch Id="Dk2_Version"
Root="HKLM"
Key="SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\DESkey DK2 Uninstall"
Name="DisplayVersion"
Type="raw" />
</Property>
<Feature Id="ABCRedist" Title="ABC drivers" AllowAdvertise="no" Display="hidden" Level="1">
<ComponentRef Id="ABCRedist"/>
</Feature>
<CustomAction Id="InstallDK2Drivers" FileKey="ABC_EXE" ExeCommand="" Execute="deferred" Impersonate="no" Return="check"/>
<InstallExecuteSequence>
<Custom Action="InstallDK2Drivers" Before="InstallFinalize">
<![CDATA[NOT DK2_VERSION OR DK2_VERSION < "7.34.0.57"]]>
</Custom>
</InstallExecuteSequence>
The warning in Windows Event viewer points to main executable, which is below:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="FolderName">
<Directory Id ="MyFolder" Name="MyApp">
<Component Id ="MyApp.exe" Guid="*">
<File Id="MyApp.exe" Source ="$(var.TargetDir)MyApp.exe" KeyPath="yes" Checksum ="yes" />
<Shortcut Id="MyAppStartMenuShortcut" Name="My App" Directory="ProgramMenuDir" Icon="MyAppIcon.exe" WorkingDirectory="MyFolder" Advertise="yes"></Shortcut>
<Shortcut Id="MyAppDesktopShortcut" Name="My App" Directory="DesktopFolder" Icon="MyAppIcon.exe" WorkingDirectory="MyFolder" Advertise="yes"></Shortcut>
</Component>
...
Now it is not happening on other machines so I am not able to diagnose. Can anybody point out any obvious mistake? What can I do to diagnose this on customer's machine i.e. how to get logs when installing .exe, .dll, some third party installers like VC100 CRT and VC100 MFC and .Net 4.0 bootstrapper?
Thanks in advance.
I can't tell from your post if the 3rd party ABC product that you're using is the same one that is repairing, or maybe the client doesn't know and you're assuming that it is your ABC thing. There's no indication in that WiX fragment exactly how you're installing the ABC thing, all you show is that it's copied to disk, there's no clue how you are running it to get it installed, and no shortcuts either.
What's happening in general seems to be that the other product is going into repair mode. There should be MsiInstaller entries in the Application Event Log that say something about whatever is wrong, referencing component ids, products, and maybe file names or registry entries.
Your setup may have a conflict with that other install. It's unlikely to be anything to do with your shortcut except that your shortcut is advertised, so it goes off into a component feature check, and is apparently finding that you are sharing something with that other app, and now it needs repairing. If the 3rd party app that repairs is not your ABC thing then you won't be able to reproduce the issue unless you also install that 3rd party thing and find out what you're sharing with it, perhaps in the wrong way.
Is this some sort of bit-torrent component? I see an abc project on sourceforge.net with Python dll's, some visual C++ runtimes included as well as other stuff. This is by no means a properly constructed package, and it could trigger the self-repair problems seen on that particular computer.
To debug this would require to see what entries exist in the Windows Event log - it will specify what MSI component triggered the repair. The error could still be in other packages since a COM call from the embedded components in this abc package, could trigger a repair in any MSI package installed on the system. As could taking over a file association associated with torrent files.
Right click My Computer
Select Manage
Event Log -> Windows Logs -> Programs
In this log you will find entries starting with "Description: Detection of product..." with id 1001 or 1004. Here is a sample:
Event ID: 1001
Description: Detection of product "{4ED0C75A-8BC5-4520-B9C7-76968FD5677F}", feature "Test" failed during request for component "{A7B09747-E527-4E1B-AE51-323CD636210F}"
This information is enough to determine what package triggered the self-repair. Please provide this information and we can take it from there.
I extracted the above sample information from Stefan Krüger's MSI FAG at installsite.org.
You are using advertised shortcuts. In your Shortcut elements, set Advertise="no" or remove the Advertise attribute completely.
For more information, see this SO answer and msdn.
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.
Following directory setting works perfectly for me.
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id="ProgramFilesFolder">
<Directory Id='INSTALLDIR' Name='MyApp'/>
</Directory>
</Directory>
However, when I tried changing "ProgramFilesFolder" to "LocalAppDataFolder", I got lots of error when using light to link and generate my msi:
D:\runGroup.wxs(53) : error LGHT0204: ICE38: Component cmpA5561BE36D80EB58252E69DDA0C2FF8C installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
D:\main.wxs(38) : error LGHT0204 : ICE64: The directory INSTALLDIR is in the user profile but is not listed in the Remove File table.
Looks like "LocalAppDataFolder" is not acceptable for WiX, while I believe it is one of the system folder properties which defined in here.
What am I supposed to use for LocalAppData folder?
I converted an application from being a perMachine install to be a perUser install. In order to properly convert the install I had to add a registry key for each of the components I have.
Originally I had the following:
<Component Id="C.MyExe">
<File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)" Source="$(var.MyExe.TargetPath)" DiskId="1">
<Shortcut Id="SC.StartMenu"
Directory="D.ApplicationMenuDir"
Name="$(var.AppName)"
WorkingDirectory="INSTALLDIR"
Icon="MY_ICON.ico"
IconIndex="0"
Advertise="yes"
/>
...
When I moved the exe component to the user install I had to do something like this:
<Directory Id="LocalAppDataFolder" Name="AppData">
<Directory Id="MyAppDirectory" Name="$(var.AppName)">
<Component Id="C.MyExe" Guid="{MY_GUID}">
<CreateFolder />
<RemoveFolder Id="RemoveMyAppDirectory" On="uninstall" />
<RegistryKey Root="HKCU" Key="Software\MyCompany\MyApp">
<RegistryValue Name="MainExe" Value="1" KeyPath="yes" Type="integer" />
</RegistryKey>
<File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)"
Source="$(var.MyExe.TargetPath)" DiskId="1" Checksum="yes">
</File>
</Component>
...
The most important part is that you will have to add a registry key which points to HKEY_CURRENT_USER. I added a registry value for each component which indicates that the component is installed.
I also had to remove the following: Advertise="yes".
I had this problem recently. I wanted to convert my installer from per-machine to a per-user but was getting ICE38. I asked on wix-users and one opinion was that you can ignore ICE38 because that was meant as a check for per-machine installs.
See the discussion at wix-users.
Since that is the case, ICE38 is (in my opinion) incorrect and you will want to ignore it. ICE38 implies you are installing per-user resources in the context of a per-machine installation but never verifies that this is so.
Actually authoring a per-user install requires that you ignore ICE38
because it won't ever be accurate for that world.
[Edit]
Looks like you got help here.
From Peter Shirtcliffe:
This is my own, admittedly inexpert, understanding of per-user installations:
Installing to subdirectory of LocalAppDataFolder is perfectly OK in a
per-user MSI. Because of certain scenarios relating to roaming users, you
need to add components containing elements for any
directories you create under LocalAppDataFolder. That's why ICE64 is
appearing.
The ICE38 error is slightly misleading: since you have a per-user
installation, it's safe to ignore as long as the user cannot pick an
alternative installation location that is common to all users. ICE38 is
checking for the situation where multiple users all install the same
component to the same path.
Just posting to help other people (like me).
Ok, just found that we can do it by overwriting "ProgramFilesFolder":
<SetProperty Id="ProgramFilesFolder" Value="[LocalAppDataFolder]" Before="CostFinalize"><![CDATA[NOT Privileged]]></SetProperty>
Another thing to do is, in <Package> we need to set InstallPrivileges to limited.
Well, I can see no reason why "ProgramFilesFolder" can be used directly while "LocalAppDataFolder" can't.
Are you installing per-user or per-machine? Also, what OS versions are you targetting? You might want to read:
Authoring a single package for Per-User or Per-Machine Installation context in Windows 7