Recently I was involved in a problem where we had a WCF service referencing a 32 bit dll. The service was set to to “Start WCF Service Host when debugging another project in the same solution”. Unfortunately that ended up with an exception.

Could not load file or assembly ‘My32BitLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

When a CLR process starts, the exe file determines if it will be loaded as a 32 or 64-bit process. In this case the WcfSvcHost.exe is started as a 64-bit process, loads the service dll (compiled as “Any CPU”) and then fails when trying to load the My32BitLib assembly which is compiled as “x86”.

The solution is to create a special 32bit version of WcfSvcHost and setup the debugging environment to use that instead of the standard WcfSvcHost

Changing the Service Library itself to X86

A first attempt to solve the problem was to change the service library itself to x86. I thought that it would be natural for Visual Studio to check the platform target of the service class library and use a corresponding WcfSvcHost.

Unfortunately I was wrong. WcfSvcHost pops up an error message.

System.BadImageFormatException: Could not load file or assembly ‘file:///C:\Users\andabe\Documents\SVN\BlogCode\trunk\TestService\bin\Debug\TestService.dll’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

StackOverflow to the Rescue

When having this kind of problems google is often the one and only thing that helps. I found a StackOverflow Question which hinted with a link about using the corflags tool.

Setting up 32-bit Debugging

To set up a robust, reusable 32-bit debugging environment for WCF services I want to create a separate version of WcfSvcHost.

As a command line geek I launch a Visual Studio Command Prompt in administrator mode.

c:\
>cd "c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE"

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
>copy WcfSvcHost.exe WcfSvcHost32.exe
        1 file(s) copied.

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
>corflags /32BIT+ /Force WcfSvcHost32.exe
Microsoft (R) .NET Framework CorFlags Conversion Tool.  
Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

corflags : warning CF011 : The specified file is strong name signed.  
Using /Force will invalidate the signature of this image and will 
require the assembly to be resigned.

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
>

With a WcfSvcHost32 created the next step is to make Visual Studio use it. The option to “Start WCF Service Host when debugging another project in the same solution” won’t work any more, so first uncheck that option in the service project’s properties on the “WCF Options” tab. Then switch over to the “Debug” tab and manually configure the class library to be debugged with WcfSvcHost32.exe.

Startup Projects

To debug the WCF service together with the client program, the option to use multiple startup projects can be used to launch both of them together. Bring up the context menu of the solution itself in solution explorer and choose “Set StartUp Projects…”.

Unit Tests Against the Service

When writing the code for this blog, I use a test project to be able to easily run different snippets of test code. To run my test case that calls the WCF service I first have to launch the service project. From the context menu of the project, choose debug. That should bring up a small popup from the task bar. Once the Wcf service is hosted, the test cases can be run as usual.