views:

538

answers:

3

This is the error that is thrown by our automated build suite at Windows 2008, while running ICEs (after migrating from WiX 2.0 to Wix 3.0):

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 light.exe(0, 0)

Additionally these are the errors that show up in the event log:

MSIInstaller: Failed to connect to server. Error: 0x80070005 Product: [ProductName] -- Error 1719. 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.

Intuitively:

  • vbscript and jscript were registered under admin.
  • integration service has permissions for the desktop interaction and all the files
  • builds succeed, when executed manually on the same machine by another user or even user logged in as integration account (via RDP)

I'm out of ideas so far.

Does anybody else happened to encounter and solve this problem while keeping ICE validation?

A: 

Well, since it's been so long with no answer, I haven't had this problem, but I have some suggestions.

  • Have you tried updating the Microsoft Installer version on the build server?
  • What version of WiX 3.0 are you running? Try grabbing the newest release, since it's 3.0 release stable now.
  • If all else fails, try running the build service under a specific build user who you can fiddle with permissions for...

Good luck!

Christopher Karper
1. Yes; 2. Latest; 3. I can change permissions of integration account.
Rinat Abdullin
Try adding the build user to the DCOM local users group.
Christopher Karper
Didn't work that time. I ended up disabling ICE validation in the integration build.
Rinat Abdullin
+1  A: 

End of the story:

after fiddling with the permissions of the integration account, DCOM, service activation etc without any luck I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.

Rinat Abdullin
This was the best answer I could come up with, too. It appears that the account which the build process runs under needs to elevate in order to connect to the Windows Installer Service to run ICEs. I thought about giving the build process admin permissions in order to solve the problem, but figured just disabling it on the CI build is just as much of a problem for now.
codekaizen
A: 

From http://wix.sourceforge.net/faq.html#Error217:

In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.

gregmac
Did anything in that link actually help you fix this problem?
bwerks