Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: WCF VB10.0 VB.NET service
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
Comments
Kenneth Haugland at 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

Rate this: bad
good
Please Sign up or sign in to vote.

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.
  Permalink  
v2
Comments
Naerling at 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 at 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.
Naerling at 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 at 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.
Naerling at 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)

  Print Answers RSS
0 OriginalGriff 620
1 Maciej Los 610
2 CPallini 255
3 RyanDev 161
4 Peter Leow 125
0 OriginalGriff 5,784
1 Sergey Alexandrovich Kryukov 4,838
2 Peter Leow 3,009
3 Maciej Los 2,894
4 DamithSL 2,465


Advertise | Privacy | Mobile
Web03 | 2.8.140721.1 | Last Updated 25 Jul 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100