Unit Testing x86 .NET Assembly with x64 Build Agent

Hi!

I'm using TeamCity 3.0 to run unit tests (of the NUnit flavor) in my .NET assemblies. Some of these assemblies are referencing the XNA runtime, which only works in x86 (32-bit) processes.

Now the JIT compiler in .NET has the habit of compiling assemblies to the native platform, which for Windows Vista x64 happens to be 64-bit machine code.

As a result, when my Build Agent on Windows Vista x64 tries to run a unit test, JetBrains.BuildServer.NUnitLauncher2.0.exe will get executed as a 64-bit process, loads my assembly in 64-bits mode and then fails each and every unit test because the XNA runtime (x86-only) cannot be loaded.

I'm discussing this in the forums because I can't think of an elegant solution, either on the TeamCity side or in my build scripts.

-Markus-

4 comments

Some further infos:

.NET assemblies can be tagged as 32-bit only by setting the '32BIT' flag in their CLR header. Upon seeing this flag for the entry assembly, the JIT compiler will produce x86 code and the process runs in WoW6432 mode. Aforementioned flag is automatically set when a .NET project is built for the 'x86' platform instead of 'Any CPU', which is what Visual Studio selects by default for a new project.

So that's how my XNA-referencing applications are supposed to work for people with Windows Vista x64. When my application (let's call it Xy.exe) is the entry point, the JIT compiler will see the '32BIT' flag, compile it as x86 code and the XNA runtime loads.

But when JetBrains.BuildServer.NUnitLauncher2.0.exe, which doesn't have the '32BIT' flag set, becomes the entry point, the process is a 64-bit process and runs my unit tests as 64-bit code, rendering the XNA runtime unworkable.

I can mitigate the problem by using CorFlags.exe from the .NET Framework SDK to set the '32BIT' flag on JetBrains.BuildServer.NUnitLauncher2.0.exe, but modifying the internals of a TeamCity Build Agent is of course not the nicest thing to do.

-Markus-

0

By the way, NUnit's answer to this problem are nunit-x86.exe and nunit-console-x86.exe. These two executables have the '32BIT' flag set and execute your unit tests as x86 code, on x64 platforms such as Windows Vista x64.

See: http://nunit.com/index.php?p=nunit-gui&r=2.4.2 (the lastmost paragraph)

So can anyone think of a good solution for TeamCity?

Maybe provide a JetBrains.BuildServer.NUnitLauncher2.0-x86.exe and a flag to the sln2005 and sln2008 runners of TeamCity (plus, of course, for the nant runner, a 'teamcity.dotnet.nunitlauncher2.0-x86' property in addition to the already existing 'teamcity.dotnet.nunitlauncher2.0')?

-Markus-

0

Hello,
Could you please submit that issue to our Jira.

As a workaround, could you please patch JetBrains.BuildServer.NUnitLauncher2.0.exe
to work only under x86.
You will have to do it only once and all build-agents will be autoupgraded.

open ]]>/WEBAPPS/ROOT/update/plugins/dotNetPlugin.zip

under dotnetplugin/bin find and patch JetBrains.BuildServer.NUnitLauncher2.0.exe.
Than save it back to
the server folder. After that all you build agents will autoupgrade.

Thanks!
--
Eugene Petrenko
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Some further infos:

NET assemblies can be tagged as 32-bit only by setting the '32BIT'
flag in their CLR header. Upon seeing this flag for the entry
assembly, the JIT compiler will produce x86 code and the process runs
in WoW6432 mode. Aforementioned flag is automatically set when a .NET
project is built for the 'x86' platform instead of 'Any CPU', which is
what Visual Studio selects by default for a new project.

So that's how my XNA-referencing applications are supposed to work for
people with Windows Vista x64. When my application (let's call it
Xy.exe) is the entry point, the JIT compiler will see the '32BIT'
flag, compile it as x86 code and the XNA runtime loads.

But when JetBrains.BuildServer.NUnitLauncher2.0.exe, which doesn't
have the '32BIT' flag set, becomes the entry point, the process is a
64-bit process and runs my unit tests as 64-bit code, rendering the
XNA runtime unworkable.

I can mitigate the problem by using CorFlags.exe from the .NET
Framework SDK to set the '32BIT' flag on
JetBrains.BuildServer.NUnitLauncher2.0.exe, but modifying the
internals of a TeamCity Build Agent is of course not the nicest thing
to do.

-Markus-



0

Please sign in to leave a comment.