.NET Framework - targets a different processor than the application

Asked By Anders Eriksson on 12-Jul-11 03:33 AM
I get this error when compiling

Warning	2	Referenced assembly '...\Interop.laserengineLib.dll' targets a
different processor than the application.	DCMarkerWpf1

How do I fix this?

// Anders




Peter Duniho replied to Anders Eriksson on 12-Jul-11 11:43 AM
Compile the application with the same target CPU as is used for the
referenced assembly, or get a different version of the assembly that
uses the same target CPU that the application does.

.NET supports a variety of target CPUs.  The most common you are likely
to run into are "x86", "x64", and "Any CPU".  That third one marks the
assembly to be JIT-compiled to match the hardware present at run-time,
e.g. as "x86" when running on 32-bit hardware, and "x64" when running on
64-bit hardware.

The warning means that your program is compiled to target a different
CPU than that targeted by the referenced assembly.

You can get away with a mix of "Any CPU" in one assembly and some other
hard-coded target for the other assembly as long as at run-time the
actual CPU target determined at run-time matches the other assembly's
hard-coded target.  Otherwise, the warning really is a serious problem,
as you will not be able to load the referenced assembly at run-time.

Pete
Anders Eriksson replied to Peter Duniho on 12-Jul-11 12:32 PM
OK, as usual I have left some info out. Sorry about that!
My application has Any CPU as Platform target.
The application uses a assembly (dll) that also has Any CPU as Platform
target.

This assembly uses an ActiveX, laserengineLib.dll, that is created using
VC++ Unmanaged.

As you can see from the Warning it is Interop.laserengineLib.dll

I cannot find anywhere where I can set the Platform target for an Interop?

// Anders
Peter Duniho replied to Anders Eriksson on 12-Jul-11 12:46 PM
Well, it depends on where the interop DLL came from.  They can be built
by hand, or generated automatically, or something in between (start with
one built automatically and edit the code to match specific requirements).

If you wind up compiling code at some point to generate the interop
assembly, you can adjust the target CPU at that time.  Otherwise, you are
stuck with whatever the target CPU was set to.

In any case, even if you can get the target CPU to match on the
assemblies, there is still the issue of the native library being
referenced through the interop assembly.  The target CPU for _that_
library will also have to match the run-time JIT-compiled code for the
managed assemblies in use, and you will not get a compile-time warning
about that if it is wrong.  it will just cause the process to exit when the
mismatched assembly tries to load.

Pete
Anders Eriksson replied to Peter Duniho on 12-Jul-11 02:12 PM
Thanks for your answer Pete, but unfortunately I do not understand...

I add an REFERENCE, which is an COM application (laserengine.exe). Then
when I compile my application then the Interop.laserengine.dll is created.

laserengine.exe is a 3:rd party software, which I have been told is
programmed using VC++ unmanaged.

Is there anyway that I can influence how the Interop.laserengine.dll is
created or find out the platform target of Interop.laserengine.dll or
laserengine.exe?

My software works and it loads the ActiveX and everything is OK, except
for that annoying warning...

// Anders
Peter Duniho replied to Anders Eriksson on 12-Jul-11 02:41 PM
Okay, so you are using an "automatic" variety of assembly generation.


Well, you can determine the target of the interop DLL just by looking at
the assembly metadata.  But really, it is not the interop DLL that you
should be adjusting.  The interop assembly is generated to match the COM
server you are using, and the COM server's target CPU is unlikely to be
changeable.

Even if you can cause the interop assembly to be compiled as "Any CPU",
that is not really helpful, because it is not really what you want for the
given COM server.  It would make the warning go away, but then your
entire project's assemblies could wind up getting JIT-compiled
incorrectly if and when they are deployed on a platform that does not
match the requirements of the ActiveX library.

So instead, what you should be doing is setting the target CPU for your
other projects to match what the interop assembly requires.  This will
ensure that your own code always gets JIT-compiled to the correct CPU
platform needed in order to work with the COM server.

Pete