Help With TeamCity Build Problem

First off a little background information:

We are migrating to a new development build server.

  • Old server is running TeamCity 4.x on Windows Server 2003 (x32) using HSQLDB database. Oracle 10.2 client. No Problems encountered.
  • New servier is running TeamCity 5.x on Windows Server 2008 (x64) using HSQLDB database (planning on migrating to Oracle after current issue is resolved). Oracle 11.1 x64 client.


Here is an overview of the specifc build configuration that I am having problems with:

  • Version Control System: SVN
  • Build Runner: MSBuild, .NET Framework 3.5
  • Outline of MSBuild Tasks
    • Perform Compile
    • Execute NUnit Tests
      • Tests execute application code that accesses an Oracle database via Ibatis Data Mapper.


We are having an extremely odd problem on the new server that only manifests when running the NUnit tests in an MSBuild project within TeamCity. Running the tests within Visual Studio or directly in MSBuild from a command prompt are successful.

In a nutshell, the runtime is not able to load in the Oracle.DataAccess.dll, but only within TeamCity. Snippit of error generated from IBatis is below

"...Could not load file or assembly 'Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. An attempt was made to load a program with an incorrect format..."

We have tried many different types of troubleshooting activites from trying different versions of the Oracle client (32 vs 64 bit), tweaks within the project references, etc. to no avail. The really odd thing is that this only occurs when running from within TeamCity.

The question would be why do the NUnit tests fail (i.e. underlying Oracle load problem) in TeamCity initiated MSBuild but succeed when MSBuild is executed from a command window?

Any guidance or assistance regarding how to troubleshoot this problem from a TeamCity perspective is greatly appreciated.

5 comments
Comment actions Permalink

That Oracle dll has a dependency on an unmanaged dll that is compiled for a 32 bit OS.  My guess is you are running the unit tests on a 32 bit OS but your build agent(s) is/are running a 64 bit OS.  I am not entirely sure if there is a way around this in TeamCity, but if there is not and you don't need your app to run as a 64 bit app on 64 bit OSes you can force it to build as a 32 bit only app which will force it to run as a 32 bit app whether it is on an 64 bit OS or a 32 bit OS.  Does that make sense?

[Edit]
Sorry, its a bit late for me and I just realized that yes, indeed your new server is 64 bit.  So yeah, if worst came to worst you and you don't care if your app runs in 64 bit on 64 bit OSes then you can just force your app to build for 32 bit instead of 'Any' which essentially tells it to run as 32 bit on a 32 bit OS and 64 bit on a 64 bit OS.

0
Comment actions Permalink

Thanks,

I will investigate your suggestion.

...Steve

0
Comment actions Permalink

Actually, I just found there is a better solution than what I previously suggested.  It seems TeamCity does have a build in feature for this kind of thing.  In the "Build Runner" settings, set the Run platform to x86 and your unit tests will run as x86 regardless of the OS bitness.  I have tested it on a project of mine that would normally exhibit the same symptoms on a 64 bit build agent.

0
Comment actions Permalink

Seth, that is a great thought. Unfortunately, I think that I can already rule that out as the default TC MSBuild run platform is set to x86 which means that the problem is occuring with TC running the build in x86 mode. I also experimented with the x64 setting to which there were other problems, which I cant recollect, that caused the build not to run at all.

0
Comment actions Permalink

Got this figured out and wanted to share the solution. The problem was indeed a reference to the wrong architecture specific Oracle assembly in a 64 bit environment. The server initially had the 64 bit Oracle client installed and we found the solution was to also install the 32 bit client.

The output below shows what is now in the Windows Global Assembly Cache. Item #1 was installed by the 64 bit Oracle client and #2&3 installed by the 32 bit client. We were running the build with the MSBuild runner in x86(32 bit) mode within TeamCity and it failed when only the 64 bit version was available but works when the 32 bit version is available and can be loaded.

1) Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64

2) Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86

3) Oracle.DataAccess, Version=1.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342

On an additional note I figured out why I could not run the build in x64 mode from with TeamCity as Seth suggested. The MSBuildCommunityTasks library that we also use was not loading as it probably has 32bit assembly references. See error below from that run

error MSB4019: The imported project "C:\Program Files\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" was not found.

0

Please sign in to leave a comment.