I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.
Related
I used WiX to build an installer (MSI) for an application, which works fine, except for this unreasonable amount of "applications that are using files that need to be updated by this setup":
This happens for some users some times, and I don't quite understand why this happens, and how to fix it.
I don't see a reason that the installation process of my application would conflict with all of these applications, and I'm not sure how to investigate it further.
My application is a standalone desktop application - not any add-on or something that interacts or depends on any of the applications listed.
The steps my installation process does:
Check that .Net framework 4.0 CP is available (exit if not).
Install the application under Program Files[Company][Product] (including my exe, my DLL, 2 third party DLL's that I bundle)
Install MS Visual C++ Runtime Redist 14.0 if needed
Add Start menu items for the application (launch & uninstall shortcuts)
Custom action for creating a scheduled task that starts my application on user logon as admin (the application runs in the tray as admin).
Custom action for starting the application after setup finishes (if checkbox is checked in last dialog).
Any advice on how to fix this, or at least investigate what causes this, will be appreciated :-)
Does it happen only when you run the installer and your desktop application is already running?
To investigate this further, best place to look at is your log file. The log file will have the details about the file which is being held by the other process, something like:
Info 1603. The file C:\...\abc.exe is being held in use by the following process: Name: xyz, Id: 19010, Window Title: 'xyz'. Close that application and retry.
Info 1603. The file C:\...\abc.dll is being held in use by the following process: Name: xyz123, Id: 9243, Window Title: 'xyz123'. Close that application and retry.
Once you determine the actual file being used by those other process, then it will help you figure out what the root cause is. Basically the INSTALLVALIDATE windows installer action determines if one or more files to be overwritten or removed are currently in use by an active process. An entry is added to an internal FilesInUse table if any file is overwritten or removed while it is open for execution or modification by any process during File costing. The FilesInUse table contains columns for the name and full path of the file. When the InstallValidate action executes, the installer queries the FilesInUse table for entries and determines the name of the process using the file. The InstallValidate action adds one record to the ListBox user interface table for each unique process identified by this query.
I'm using freepascal. So after I run my code compiler creates an exe file that should create few text files. However after it creates an exe file it says "Program c:\fpc\2.6.4\bin\i386-win32\maxmin.exe exited with exitcode = 2". No text files are created. If I later run maxmin.exe manually - it works fine.
UAC - disabled and EnableLUA = 0. But I still pretty sure - it is windows 8.1 rights issue problem.
Some possibilities, in descending order of likeliness:
Note that exitcode 2 usually indicates a file not found error.
Working directory. While manually executing you set the working directory by CDing with the shell, and when indirectly executing the program's assumptions about a working directory are not satisfied.
Sometimes locks linger on Windows for a short while. Usually not noticeable in the manual execution time frames, but when programmatically executing programs in quick succession it might happen.
If you have the feeling that the EXE doesn't run at all, it might be an security software issue. After the binary is generated, the antivirus kicks in and wants to scan, locking the binary for a few seconds.
I download visual studio code for mac today. I tried to create a simple asp.net 5 web application following these instructions https://code.visualstudio.com/Docs/ASPnet5
When I open my web application folder in visual studio, it says I need to run a restore command.
I ran the dnu restore command just like the instructions tell me but it seems to always fail.
I receive different errors every time I run it. But most of them are like this one:
CACHE https://www.nuget.org/api/v2/package/System.Threading/4.0.10-beta-22816
SharpCompress.Common.ArchiveException: Could not find Zip file Directory at the end of the file. File may be corrupted.
Restore failed
There is a stack trace as well, but for brevity sake I'll omit it for now
Has anyone experienced this?
Try dnu restore --no-cache.
You may also need to remove previously downloaded files - check ~/.dnx/packages. I removed all files from that folder some time before trying the above. Also, see the comments below, if ~/.dnx/runtimes contains unexpected versions removing them may also work. Note that the current runtime version can be controlled using dnvm.
I never saw the NullReference exception, but I was getting the SharpCompress.Common.ArchiveException. I suspect there was a mismatch from what dnu thought was the cache state with the actual cache state (maybe something timed out the first time or something).
Strange event is happening in a Mule project. I have the application xml which is JPC.xml. This normally appears in the mule-deploy.properties as follows
redeployment.enabled=true
encoding=UTF-8
config.resources=JPC.xml
domain=default
When I choose Run As, Mule Application Which kicks off the build in the background prior to the deploy and run. During that time the mule-deploy.properties becomes:
redeployment.enabled=true
encoding=UTF-8
config.resources=
domain=default
And when the application runs it says it is missing the mule-config.xml
What is erasing it?
I think I may have found the root of this issue.
It seems to be a bug related to jdk_1.7.0_45 having to do with xml parsing. see: What's causing these ParseError exceptions when reading off an AWS SQS queue in my Storm cluster
I noticed several errors logged in eclipse/anypoint as:
!ENTRY org.mule.tooling.core 4 0 2014-11-19 14:16:41.081
!MESSAGE Error opening resource measurement_scheduler.xml
!STACK 0
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.
I also noticed that after restarting Anypoint, I would be able to build with maven successfully and my mule-deploy.properties file would again have content. Until...at some point after several edits to things in Anypoint, I would again get mvn build that wiped out the contents of mule-deploy.properties.
I further noticed that once this problem started to happen in one project in Anypoint, it would ALSO start happening in ANY project I built in Anypoint...until restart of Anypoint.
It seems this bug in jdk 1.7.0_45 mistakenly applies this limit in the xml parser to all opened files cumulatively, instead of per file. I suspect this causes Anypoint to not finish parsing all of the xml docs that make up my app and therefore couldnt re-create the mule-deploy.properties...leaving it blank.
Upgrading to newer jdk would fix this.
Another way to work around it is to override this limit for xml parser by adding the following to ${JAVA_HOME}/jre/lib/jaxp.properties:
jdk.xml.entityExpansionLimit=0
jdk.xml.maxGeneralEntitySizeLimit=0
I am not certain that both limits need set to work-around this. Possibly only entityExpansionLimit is needed.
After making this change I am now happily able to use Anypoint again. Beware that using this work-around possibly opens you up to a denial-of-service attack through the xml parser if your same jre is used for other not-so-trusted processes.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.