When using a batch to do exactly the same thing manually, this works !
In order to get the error within the Batch file, just use the command line
light.exe [add_your_options_here] > myLogFile.txt
light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance."
"In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build". However, this generates a problem when called from within the Team Build, and this problems often often occurs and we have to perform some workarounds :
- e.g. disable the validation so that VBScript is not called any longer,
- or change the computer's account's security,
- or Try to use Votive, and disable the checking option, ...
SOLVED : Simply just add the command line option when calling Light to disable the VBScript validation (that generated a security problem when called by TeamBuild). Then , the magic happened and your MSI could apprear, for each Build, on your Drop Folder.
Here are the Blogs that helped me investigate on this problem :
==============================================
http://biztalkdeployment.codeplex.com/Thread/View.aspx?ThreadId=218533
Date: 2010-08-25 15:27:04 UTC
Read the Thread. I found the Build Service account in the IIS_IUSR. Removed
Build Service Account from IIS_USR and added to Local Administrator.
Recycled the Visual Studio Team Build Service. (update the primary windows
token)
It worked. Like the thread author I am puzzled as to why?
==============================================
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/11/14/wix-projects-vs-tfs-2010-team-build.aspx
After a night's sleep, I played around some more and stumbled into a work around. In order for the .WiXProj files to compile, the account running the build controller/agent must be in the local machine's administrator group. I found that any domain or computer account works fine for the builds. You can also use NT AUTHORITY\NETWORK SERVICE, but you have to add it to local machine administrator group. Since you can't do that through the computer manager, he's the command line way to make the addition:
net localgroup "Administrators" "NT Authority\Network Service" /add
==============================================
http://biztalkdeployment.codeplex.com/Thread/View.aspx?ThreadId=218533
Jul 7 2010 at 11:06 PM Edited Jul 7 2010 at 11:08 PM
I found your exact problem in a two-year-old mail thread: http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg18888.html. They don't seem to have found much of a resolution other than messing with group membership and permissions on the account used by Team Build. Are you saying that the MSI build works without error on the build machine when you log in and run it yourself?
You can always disable light.exe's MSI validation since the MSI is most likely being generated correctly. Unfortunately that will require changing BizTalkDeploymentFramework.WiXSetup.targets in \Program Files\MSBuild\DeploymentFrameworkForBizTalk\5.0. I believe (but am not 100% sure) that the additional command line switch that you would need is -sval.
Thanks a lot, you saved me a lot of time and I could build my Wix projects as part of TFS 2010 build.
ReplyDeleteMohammad