Click here to Skip to main content
15,942,934 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
So I have this problem and it's been bugging me all day. No matter what I do or Google I don't seem to be able to find the answer...
Here's the deal:

My employer asked me to create a WCF service that can print labels using BarTender. BarTender is a tool, not unlike Crystal Reports, in which you can design and print labels.

I can use the BarTender library with no problems when using WinForms, when building in x86 (32 bits) that is. So here is the problem, in WCF I can't build in x86 because my system runs a Windows 7 64 bit edition... I can build in 'Any CPU' or x64, but that causes a BadImageFormatException[^]. BarTender uses/calls 32 bit components using COM and unmanaged code. I suspect that is the problem. An application built in 64 bit can't target 32 bit components (or so I believe).

So I understand that I should build x86 to solve my problem. I don't know why this is not allowed in WCF, but it's something I have to deal with. I have spent an entire day trying to fix this with no result whatsoever.

I am using a WCF Service Library (not WCF Service Application).

I have contacted BarTender about this issue, but I am assuming this is not really a bug in their software, but a problem that has to do with Windows, 32 bit/64 bit and WCF in particular.

So, any idea's? I'm getting kind of desperate...
Kenneth Haugland 25-Jul-12 11:32am    
Does not sound fun at all, but there might be a way out?

1 solution

What are you hosting the service in??

The easiest solution is to leave the thing compiled AnyCPU, then write a custom hosting app to host your service, but compile that x86 only. When the service .DLL is loaded, it'll be forced to run 32-bit only.

Another option, which I haven't tested at all, is to edit the resulting .DLL and change the CPU type using corflags from the .NET Framework SDK:
corflags /32bit myService.dll

You'll have to be careful doing this though as the service MUST be hosted in a 32-bit process, whatever it is your using to host with.

If you're using IIS to host, you may want to check out this[^], especially the option called "enable32BirAppOnWin64", which is False by default.
Share this answer
Sander Rossel 26-Jul-12 3:50am    
I'm hosting in a custom host, so both solutions sound like they should work. Unfortunately they don't. Still the same error...
I'm not using IIS, so that's not an option (yet).
Dave Kreskowiak 26-Jul-12 7:31am    
Compile the host x86 only, then use the corflags trick to force the WCF .DLL to x86.

I got the command line wrong. It should be "corflags /32bit+ myService.dll". Note the + sign at the end of 32bit.

If that doesn't work, trying using the corflags command line on your host .EXE then retest.
Sander Rossel 26-Jul-12 8:18am    
Yeah, I figured out the command line. Still nothing though. Keeps giving me a BadImageFormatException. I even tried running on a 32-bit machine, but without luck.
The only thing I haven't tried yet is developing the whole thing on a 32-bit machine (it's not the developing that's the problem, it's getting a 32-bit machine with both BarTender and VS2010). Right now it looks like it'll be the only option...

If you have any other suggestions I'd be pleased to hear them. Thanks for your help in any case.
Dave Kreskowiak 26-Jul-12 9:59am    
BadImageFormat exception says you're still mixing 32 and 64-bit code in the same process. Granted, using "corflags" is a bit of a hack, but it was worth a try.

The only other solution you have is to convert the WCF Library project to a WCF Service project instead. Those will let you compile x86.

It does not matter what machine you compile the code on. Everything compiles down to processor agnostic MSIL. You can compile this code on an ARM-based machine and it's still going to have the same problem.

It matters what processor type you RUN the code on. When you launch a managed code executable, the MSIL code is compiled down to processor-specific code by the JIT (Just In Time) compiler. That's when the determination is made whether the native code (tagged AnyCPU) is going to get generated as x86 or x64.
Sander Rossel 27-Jul-12 4:51am    
Thanks for your answer. We have decided to go for the IIS solution. I'll be converting my Service Library to a Service Application, so far the first tests seem to work.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900