views:

217

answers:

4

Hi,

I know this a is a common issue, but everything I can find in the forums seems to relate to 64bit framework incompatability (which is not an issue in my case).

I have a set of simple WIX 3.5 installers developed using Votive that I can compile happily in VS2010, but when I try to compile them via NAnt (and MSBuild) on TeamCity (i.e. TeamCity -> Nant -> MSBuild -> WIX) I get the following error:

 [exec] Project file contains ToolsVersion="4.0", which is not supported by this 
            version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
 [exec] Compile:
 [exec]   Microsoft (R) Windows Installer Xml Compiler version 3.5.2006.0
 [exec]   Copyright (C) Microsoft Corporation. All rights reserved.
 [exec]
 [exec]   Product.wxs
 [exec]   Product.Generated.wxs
 [exec] Link:
 [exec]   Microsoft (R) Windows Installer Xml Linker version 3.5.2006.0
 [exec]   Copyright (C) Microsoft Corporation. All rights reserved.
 [exec]
 [exec] light.exe : error LGHT0001: Unable to load DLL 'winterop.dll': The specified module 
           could not be found. (Exception from HRESULT: 0x8007007E)
 [exec]
 [exec]   Exception Type: System.DllNotFoundException
 [exec]
 [exec]   Stack Trace:
 [exec]      at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.ExtractCabBegin()
 [exec]      at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile)
 [exec]      at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file)
 [exec]      at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args)
 [exec] Done Building Project "c:\dev2\ad3\utilities\Installers\Database\Database.wixproj" (default targets) -- FAILED.
 [exec] Done Building Project "c:\dev2\ad3\AgentDesktop3.1.sln" (default targets) -- FAILED.
 [exec]
 [exec] Build FAILED.
 [exec]
 [exec] "c:\dev2\ad3\AgentDesktop3.1.sln" (default target) (1) ->
 [exec] "c:\dev2\ad3\utilities\InstallerService\InstallerService.csproj" (default target) (5) ->
 [exec] (ResolveAssemblyReferences target) ->
 [exec]   C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
            : warning MSB3088: Could not read state file
            "obj\Release\ResolveAssemblyReference.cache". Unable to find assembly
            'Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral,
            PublicKeyToken=b03f5f7f11d50a3a'.
 [exec]
 [exec]
 [exec] "c:\dev2\ad3\AgentDesktop3.1.sln" (default target) (1) ->
 [exec] "c:\dev2\ad3\utilities\Installers\Database\Database.wixproj" (default target) (6) ->
 [exec] (Link target) ->
 [exec]   light.exe : error LGHT0001: Unable to load DLL 'winterop.dll': The specified 
              module could not be found. (Exception from HRESULT: 0x8007007E)
 [exec]
 [exec]     1 Warning(s)
 [exec]     1 Error(s)
 [exec]
 [exec] Time Elapsed 00:00:05.92

 BUILD FAILED

Any ideas?

A: 

Is there any chance you're not setting the working directory right? I assume you've verified the DLL is there?

I'd also install .NET 4.0 to remove the warning - might as well eliminate this as a potential cause (can't personally think of any reason why something straightforward would cause it to break). Perhaps as a half way house you could change the ToolsVersion back to 3.5 ?

Ruben Bartelink
I may be able to install framework 4 at some future stage, but (desiring not to go through a Kafkaesque nightmare of change requests) I decided to stick with framework 3.5 for now. Your answer does make me wonder whether the WIX env var would be picked up by TC without a restart of the server?
Andrew Matthews
+1  A: 

We had a similar issue when building using Team Build (2010). We ended up doing a filemon (its called processmonitor these days) for winterop.dll on one of our build agents to see where it was expected.

We ended up adding the bin folder of the wix installation in our path and suddenly winterop.dll was found.

fredrikt
It moved on to another issue with the build env, but I'm pretty sure the path approach worked. It's yours!
Andrew Matthews
A: 

This sounds like a known issue: http://sourceforge.net/tracker/?func=detail&aid=3037918&group_id=105970&atid=642714

Rob Mensching
I saw that thread (which is mostly 'me too!'s), but I didn't see a workaround on the issue - can you suggest any way I could tackle it? Have you seen this kind of issue with TC/CCNET? Is this issue rectified in the nightly builds? I'm willing to switch to more bleeding edge versions if it gets me closer to a solution.
Andrew Matthews
The 'me too!'s are helping us prioritize getting a fix for this issue as quickly as possible. Watch the bug for when the issue is really fixed.
Rob Mensching
+1  A: 

Depending on how you do your team build you can also add a target file that re-maps the wix targets, tools and paths and then sets up the 'RunWixToolsOutOfProc' item to run it out of band. Here's a chunk of my target file that maps the three paths. Just change the initial property to wherever you usually put your wix files.

<CreateProperty Value="$(ProductDirRoot)\buildfiles\tasks\wix\">
  <Output TaskParameter="Value" PropertyName="WixToolPath"/>
  <Output TaskParameter="Value" PropertyName="WixExtDir"/>
</CreateProperty>

<CreateProperty Value="$(WixToolPath)wix.targets">
  <Output TaskParameter="Value" PropertyName="WixTargetsPath"/>
</CreateProperty>

<CreateProperty Value="$(WixToolPath)wixtasks.dll">
  <Output TaskParameter="Value" PropertyName="WixTasksPath"/>
</CreateProperty>

<!-- If we didn't find the registry path, assume we're in a 64bit process. -->
<!-- WiX tools are 32bit EXEs, so run them out-of-proc when MSBuild is 64bit. -->
<CreateProperty Value="true" Condition=" '$(MSBuildExtensionsPath64)' != '' ">
  <Output TaskParameter="Value" PropertyName="RunWixToolsOutOfProc" />
</CreateProperty>
Dan Piessens