I am receiving an ICE30 when I am trying to compile my WiX installer project. The complete error is below:
ICE30: The target file 'DPFPSH~1.DLL|DPFPShrNET.dll' is installed in
'[TARGETDIR]\Windows\DPDrv\' by two different components on an SFN system:
'DPFPShrNET.DA2BFC77_FAFE_41D1_8BB6_134232B2EADC' and
'DPFPShrXTypeLibNET.51D3E534_F1F9_4BC6_BFC5_B27F733081C7'. This breaks component reference
counting.
Now the peculiar thing is that these two components belong to two different merge modules, DPOTDotNet.msm and DPOTShrDotNet.msm. When viewed in Orca, the two components in question, DPFPShrNet (which is part of DPOTShrDotNet.msm) has a dll of the same name associated with it (DPFPShrNet.dll as seen in the file table), while DPFPShrXTypeLibNet also has a one dll of the same name associated with it (DPFPShrXTypeNet.dll). I do not see two DPFPShrNet.dll's being installed as the error says.
We are migrating away from InstallShield and into WiX, and the InstallShield ism file references these two merge modules and they both install correctly using that method. Is there some reason why WiX thinks two files of the same name are being installed? As soon as I remove DpOTShrDotNet.msm from my project, it compiles correctly, but I am missing the DPFPShrNet.dll in the GAC after I install.
ICE's are validation (unit tests) not compilation. Some of the ICEs are known to have bugs / design shortfalls. You should be able to ignore this one. Third party merge modules can be problematic though so you might want to look for an exe/msi redist installer for these components instead. Another possibility is to wrap these MSM's into their own MSI's and use WiX burn chainer to link it all together. This provides some separation / firewall / mitigation to the risks.
Related
I am creating a new version of an existing setup with WiX.
In the process, the version of an included third party product has been updated. It consists of several files (DLLs, Configs, exes), each of which is in its own component.
Do I need to change the GUIDs of all these components?
The new version of the third party product requires a newer VC redist package than the old version, so it is not backward compatible.
The names and destinations of the affected files are the same.
I have read
https://learn.microsoft.com/en-us/windows/win32/msi/changing-the-component-code?redirectedfrom=MSDN
Change my component GUID in wix?
but I am honestly even more confused now.
If it wasn't for the redist dependency change thing, I would have just put the new files in the places of the old ones and left the GUIDs the same.
But now?
The names and destinations of the affected files are the same.
Overall: This basically means that you should keep the same component GUIDs as before. The component GUID essentially identifies a target destination. If the target destination (the absolute path) changes you need a new component GUID.
File Name Change: Keep in mind that renaming a file changes the absolute path even if the path stays the same - hence you need a new component GUID for such file name changes.
Runtime: The incompatibility of the runtime should be irrelevant for the component GUID issue. What third party product is this? Perhaps it has its own installer? If it does it can potentially interfere with your installation in other ways (COM registration etc...).
Setup.exe Launcher: The standard procedure is to bundle runtimes in a setup.exe wrapping your MSI and all runtimes it requires. WiX offers the Burn framework to make such setup.exe launchers. Perhaps try my deployment info search grid for info on Burn. Also: Make yourself a single page PDF explaining your application's runtime requirements for corporate use and include it in your setup.exe so your setup is easy to deploy large scale.
The MSI File Itself: You can also add launch conditions to the MSI to identify that a required runtime is missing (so you can abort) - or you can use a custom action to inspect the system (I find this more flexible, but custom actions in general are complex. Use them read-only - for inspection only, and they are safer).
Links:
Will change in ComponentID for component in Windows Installer effect during upgrade scenerio.?
I have 1 dll file which I try to load during the installation with UseDLL() in one of my installscripts.
this dll has 2 dlls it depends on. they both located on the same directory of the main dll.
When in build the installation with an older installshield - it find it's dependencies and works fine.
When I try to build it with IS2016, it fails because it doesn't find it's dependencies. (If I put these 2 dlls in SysWOW64 - it finds them and works fine).
What is the problem?
Thanks,
Dudi
It looks like InstallShield 2018 makes this easier through a new Enable/Disable flag called DLL_DIRECTORY_SUPPORTDIR. But in InstallShield 2016 there's a good chance you can add the following InstallScript code to find dependencies in SUPPORTDIR. If your DLLs are in a different directory, substitute that instead.
// Add prototype for SetDllDirectory(); this typically goes near the top of your script
prototype number kernel32.SetDllDirectoryW(wstring);
// Call it; this goes in a function called before your UseDLL call
SetDllDirectoryW(SUPPORTDIR);
Note that doing this removes some protection against DLL planting, so it is safest to do this only if you ensure the DLLs in question are either proactively resistant to such things, or if you vet and secure the directory in question. (I'm uncertain whether InstallShield does this for you.)
I'm using WIX to generate a .msi via TFS/MSBuild. The error that is breaking the build (not just a warning) is:
ICE30: The target file 'eiycriw9.exe|MyApp.exe' is installed in '[ProgramFilesFolder]\Folder\MyAppFolder' by two different components on an LFN system: MyApp.exe and cmp497A0C7040B1E426AA3569D995A62AF2. This breaks component reference counting.
This error appears twice in the build log.
I am only installing one version of the software and there is not duplicate files. It's a single windows application with a single .exe.
I verified unique GUIDS and have played with a few settings a number of times, still with no luck. I even rolled back a bunch of things (wix files, build process template) and I still get the same error no matter what.
There is only one <Directory Id=> section in my WinApp.wxs file.
I am having a hard time finding info on this as most people who experience problems have multiple versions of same app in their wix files. We do not.
Any help you can provide would be very awesome.
Component1 and Component2 both have a file named 'READEME.1st'.
When using short file names, the installer installs both Dir1 and Dir2 to the same directory, TARGETDIR\PRODUCT.
ICE30 generate two errors, one for each file. In an authoring environment that displays error locations, the first error is at one file's entry in the File Table, and the second at the location of the other file.
----- comes from https://msdn.microsoft.com/en-us/library/windows/desktop/aa368954%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
I have the same problem before then I found that I use the wrong value in Source under Component.
In my wix installer I need to install some kind of addon dlls to a directory. There could be many addons, all are installed to the same directory. Each addon is a feature which could be chosen or not. Each addon is installed together with referenced dlls. The referenced dlls can be the same (both: name and contents) for two or more components. So it could be something like this:
Addon1:
Addon1.dll
Reference1.dll
Reference2.dll
Addon2:
Addon2.dll
Reference2.dll
Reference3.dll
If both features are selected, the installation result is:
Addon1.dll
Addon2.dll
Reference1.dll
Reference2.dll
Reference3.dll
I would like to make a separate fragment for each addon so that I can manage features properly. I can harvest files for each addon but the problem here are the same file names. A wix project containing such fragments doesn't compile.
I would like to avoid placing shared reference dlls to another common fragment because there could be many addons with very different dependencies between references.
Is there any way to dial with it differently?
This is something I would do manually without automatic harvesting. Unless you have hundreds of AddOns this really isn't going to be much extra work and if you harvest them using heat and then embed the resulting wxs files into your project with some modification, it won't be too difficult at all. I suppose this will add more overhead if the AddOns change frequently but I would imagine that this won't happen all that often.
I'm using latest votive (Wix v3.5) and created a simple Wix VS 2010 setup project. I added my website reference and set the Harvest option as true.
Now since my INSTALLDIR points to a folder under IISROOT, I get this light.exe error:
[filepath]: error LGHT0231: The component
'cmp93982C4086FF8C75F07339DD7CEA8152' has a key file with path
'TARGETDIR\webdir...[filename].xml'. Since this path is not rooted
in one of the standard directories (like ProgramFilesFolder), this
component does not fit the criteria for having an automatically
generated guid. (This error may also occur if a path contains a
likely standard directory such as nesting a directory with name
"Common Files" under ProgramFilesFolder.)
While I understand the reason behind this error, I don't necessarily agree to its rational (maybe I don't understand the innate workings of Wix MSI generation).
How can I resolve this error?
To provide some context:
I'm trying to set this up in conjunction with Team Build. I can use the legacy format and run Heat/Harvest task against a folder to bypass this issue but do not want to go the legacy route.
I have not played enough with the new workflow based build definition, so not sure how I can incorporate this custom task.
I need to run harvest every time the Setup project is built because I do not want to keep track of hundreds of files manually.
The problem is because the component is rooted in TARGETDIR, which WiX cannot use for automatically generating a guid. You can add Directory/#ComponentGuidGenerationSeed to a directory above this component to avoid the problem. By adding this attribute, you must now take responsibility for ensuring the component doesn't get installed to two different directories across upgrades.
In Windows Installer, components need to have a guid that doesn't change between patches, minor upgrades, and major upgrades. As a convenience, WiX can generate a version 5 UUID for you using the component's directory hierarchy as the seed. But, TARGETDIR is ineligible for this.
I believe the reason is that TARGETDIR changes across installations (it's set to the drive that has the most free space). One of the component rules is "each component must be stored in a single folder". If TARGETDIR changed between major upgrades, then you could end up trying to install the same component to a second folder.