I get while running my installshield setup. The official installshield guide doesn't say what this error is. My output logs for the build states:
ISDEV : warning -7205: Skipping file crdb_ado.dll.AEDB3316_9515_4FC0_AB37_ED59C4AFBEA8 due to unmerged or missing component crdb_ado.dll.AEDB3316_9515_4FC0_AB37_ED59C4AFBEA8 in merge module
But this doesn't help me resolve the problem.
could anyone kindly explain?
I had the same warnings. In my case, it was due to the fact that, by default, InstallShield limits the number of files in an install to 32,767.
This is the resolution from the article...
The maximum number of files that can be included in an MSI-based project is dependent upon the number of bits available in the Media table. The number of bits in the Media table is 15. By default, a maximum of 32,767 files can be added directly to a project. However, larger packages can be authored.
To author a larger package, follow these steps:
Backup the following file: <EditorProductPath>\Support\0409\IsMsiPkg.itp.
Note: By default, <EditorProduct Path> is the installed location of the MSI Editor (DevStudio, IS X, etc)
Overwrite this file by renaming the file: <Product Path>Support\0409\IsMsiPkgLarge.itp to IsMsiPkg.itp
Rebuild the project.
This uses the larger InstallShield template that allows more than 32,767 files to be included in the project.
Here is link to documentation where described how to change path to MergeModule files location.
Don't 100% sure, but could you please check the path where your project builds, perhaps it has very long name (>255 chars with MergeModules file names). It also might be a problem.
Related
Here is what I am dealing with. I have a WIX project, that outputs a MSI file. This works like a charm.
I got a new requirement, that I need to analyse in order to figure out how to approach it. As the new requirement is, I need to get as output, a ZIP file, that contains the files and folders as described in the WIX project...
I searched for the "ZIP" keyword on the official documentation, but did not have any luck in finding something helpful...Maybe some of you guys have an idea?
Obviously, I could use other tools to perform this, like maven and the maven assembly plugin, but that would cause maintenance issues, as there would be 2 different projects, 2 different technologies, and since the files and directories structure is quite big, this could cause issues like one developer modifying a project, and forgetting about the other..
So yeah...difficult question...any input would be welcomed :)
Thx
Administrative Installation: Windows Installer / MSI features a built-in capability to extract all files and make a "network installation point" (a network location where installation can be kicked off from to install on all workstations on the network - ensures all source files are available for repair operations and patching). This is called an administrative installation - in plain terms a glorified file extraction mechanism.
Given the availability of the administrative installation, is a ZIP file really necessary? I suppose you could zip up the extracted admin image? Note that any files that need to go to system, shared or userprofile folders may cause issues and prevent successful launching of your application from the extraction folder (obvious, just mentioning).
Command Line: Try it, from a cmd.exe command prompt (see above link for more details):
msiexec.exe /a MySetup.msi
You could set the Compressed="no" attribute of the Package element to create an uncompressed layout. The result could be easily zipped (excluding the *.msi file) by running any of the freely available command-line zippers (e. g. 7za.exe of 7-zip).
Note:
File elements can override the Compressed attribute of the package.
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
Is it possible to make a WiX installation bundle with size of total .msi's and exe's inside bundle more than 2GB? Currently in my .wxs template I have a <chain> inside of a <bundle> that contains multiple <MsiPackage>'es. I haven't created that WiX template on my own, I'm just improving/fixing bugs in a legacy project, so I am not very proficient with the WiX toolset. Anyway, then I create a .wixobj out of that .wxs template with candle.exe and this .wixobj I feed to light.exe. It seems that if total size of content to link is more than 2GB light.exe fails with error:
error LGHT0306 : An error (E_FAIL) was returned while finalizing a CAB
file. This most commonly happens when creating a CAB file with more
than 65535 files in it. Either reduce the number of files in your
installation package or split your installation package's files into
more than one CAB file using the Media element.
I looked for solution and one suggestion was to use <MediaElement> but that one is only available in a <product> tag which I guess I cannot use in my situation, because the bundle that I am cooking has a custom bootstrapper embedded, and as far as I understood wix product template is not about bootstrapper applications. Another opinion that I found was that you can't create WiX bundle with size of single package more than 2GBs, but that is not exactly my case, because each package I am bundling is no more than 700MBs.
I have already tried separating <MsiPackage>s into <PackageGroup>'s in separate <Fragment>'s which was referenced in <Bundle>'s <chain> in <PackageGroupRef>, but it didn't help, light.exe throws the same error. I have also found a suggestion to try to put packages into separate <Container>s in <bundle>, but I didn't manage to try it because I didn't understand how to do it, WiX bundle documentation just mentions that the are some containers but never actually gave an advice on how to use them.
I am using WiX 3.11
UPD: I just wanted to add some clarifications.
My goal is to make a bundle what would be a single .exe file with all related .cab's and other stuff embedded into the final bundle, so delivering bundle that consist of .exe bootstrapper and multiple external .cab file isn't really a preferred option even though it might be x times faster unless this is the only solution in my case.
UPD 2:
It seems that yet you can assemble a bundle with 2 GBs + size, it won't start. Maybe because the output executable is x86, and windows can't launch x86 executables over 2gbs size. I didn't manage to make an x64 bundle, maybe that would work, but I never found how to do it. Guess the only option is to let users download missing content and make bundle only contain essential parts. Thanks everyone for help.
Compressed bundles cannot be bigger than 2GB. Burn supports containers up to 2GB each and only one container can be attached to the bundle .exe itself.
Bob's answer is still correct for v3.
Support for multiple attached containers was recently added in v4 (#6144). That allows a single file bundle to be larger than 2GB. v4 also added support for x64 (and ARM64) bundles, which allows the bundle to be larger than the x86 maximum.
A related open feature request is #6521 where WiX would automatically split payloads across containers so that the user doesn't have to manually create new containers to avoid the cabinet limitations for size or number of files.
I would like to create a script that will update files in the (default) install location with files from the source location where needed, based on the .wxs files that I have. I need to get this info from the wxs files, because the installation dir structure differs from the source location dir structure.
This would speed up my development cycle by not requiring a complete MSI uninstall/install when I have only recompiled one DLL for instance.
Is there functionality available in the Wix toolset that can give me a list of corresponding source and destination paths or would I have to implement everything including parsing of the Wix XML files myself?
I did not see anything relevant in the List of Tools section of the Wix documentation.
Alternative Approach: I would suggest using the commercial file and directory syncing and comparison tool Beyond Compare to copy files to the destination directory with ease if this is just for QA. I guess you can use post build steps too, but Beyond Compare is very nice and reliable. It has the features you need for just about anything related to comparison of files and folders (not affiliated). You can let the application just sit there and you can do a full comparison on the fly whenever needed. Essential software for deployment people. Alternatives exist of course (list).
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.