Problem referencing 32bit library in 64 bit WCF service

Question

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...
Thanks.

Posted 25-Jul-12 5:14am

Sander Rossel

Add a Solution

Comments

Kenneth Haugland 25-Jul-12 11:32am

Does not sound fun at all, but there might be a way out?
http://www.techsupportalert.com/content/how-windows7-vista64-support-32bit-applications.htm

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Dave Kreskowiak · Accepted Answer · 2012-07-25T06:08:00

Solution 1

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.

Posted 25-Jul-12 6:08am

Dave Kreskowiak

Updated 25-Jul-12 6:11am

v2

Comments

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.