Managed/Unmanaged code and "bitness"
How AnyCPU Works
Web Applications and Services vs Executables (WinForms, WPF, console,
etc...)
Under What Circumstances Can I Target AnyCPU
with DotImage?
Quick Summary:
This article will attempt to cover targeting AnyCPU with DotImage components
which is a
You must target either x86 or x64 as our components "Have bitness".
VisualStudio / .NET does not allow you to mix "bitness" in the same project, and
as soon as you need to reference a non-AnyCPU dl (which most of the key
functionality of DotImage lives in), you are committed to that "bitness" for the
project.
If you reference our x86 or x64 dlls in a project that targets "AnyCPU" you
will find that it fails under many/most situations. We ran into issues with
older versions of Visual Studio defaulting to AnyCPU... since Visual Studio
itself is 32 bit, projects targeting AnyCPU but using our x86 components
appeared to work when run in Visual studio host process and/or when run on 32
bit machines, but would immediately crash when attempting to run in a 64 bit
context.
So, target x86 or x64. Since x86 apps run on both x64 and x86 systems, the
most compatible choice is to build x86. If you MUST build a 64 bit solution,
you'll need to target x64 and use our x64 dlls.
Helpful Links for x64 -related issues:
Compiling with
DotImage on a 64-bit system
Warning:Referenced
assembly targets a different processor
Detailed Explanation:
Visual Studio provides several
"platform target" options:
AnyCPU
x86
x64
Itanium (not available past VS 2010)
Since DotImage 6.0, Atalasoft has supplied DLLS for x86 and x64, and since
DotImage 9.0, we've supplied two sets - one labeled 2.0 (for .NET framework 2.0,
3.0, and 3.5) and 4.0 (for .NET framework 4.0 and 4.5)
We have never had any support for Itanium.
DotImage 10.0 introduece AnyCPU support for an extremely limited subset of
dlls that are specific to certain SharePoint use cases, but the AnyCPU dlls
found in
C:\Program Files (x86)\Atalasoft\DotImage 10.X\bin\4.0\AnyCPU\
Should not be taken to mean that you are free to target AnyCPU with your
applications.
This is because we simply do not have AnyCPU versions of any of our dlls
except
Atalasoft.dotImage.dll
Atalasoft.dotImage.WebControls.dll
Atalasoft.Shared.dll
and
those are for specific SharePoint WebPart use... they contain dependencies that
will clash with non-SharePoint solutions.
As soon as you
need components that exist in any of the others: Atalasoft.dotImage.Lib.dll or
Atalasoft.dotImage.WinControls.dll, or any other of our components, there is no
AnyCPU version ... they "have bitness"
"Ok then,
why don't you have full AnyCPU support in DotImage?"
Part of it has to
do with memory management... a 64 bit address space versus a 32 bit address
space... when you have image processing, you need to put images in to contiguous
blocks of memory (a requirement from Windows) and when you do many image
processing operations, you're doing pointer arithmetic... this is done in
unmanaged code and "has bitness"
Yes, in theory, we
could write an abstraction layer to adjust dynamically between 32 bit addressing
and 64 bit addressing but it would be at the cost of orders of magnitude of
slowdown for processing unless it was written from the ground up... and there
are hundreds of thousands of lines of code in DotImage...
Simply put, it is
a not likely that we will be able to provide full AnyCPU support in
DotImage.
This is not a
matter that we can put in a feature or bug request for... this is not a case of
us simply choosing to do or not do something because one way was easy or
hard.... the practical upshot is how AnyCPU actually works.
When an AnyCPU
application is run, it needs to determine whether it's going to run 32 bit or 64
bit based on execution context.
Managed code (C#,
VB.NET, etc...) can live in that world, but the basic building blocks that power
DotImage are in unmanaged code (C/C++) and have been years in the making, so
converting them to Managed code without sacrificing performance and without
potentially breaking thousands of things is a long term (years) project.
The closest you
can come would be to build both an x86 and an x64 version of your application,
and then have some controller/wrapper application determine on the fly which one
to run. If you target AnyCPU with Atalasoft components, what will happen is that
depending on whether you're using our x86 or x64 dlls, it will only work when
the AnyCPU app runs under the matching context:
Run on a 32 bit
machine, and it will only work if the Atalasoft dlls are the x86 ones
Run on a 64 bit
machine, and it will only work if the Atalasoft dlls are the x64 ones
The process of
properly embedding licensing is just about impossible due to the fact that
visual studio itself is a 32 bit app (x86 only) and the license compiler
(lc.exe) "has bitness" if you're running the lc.exe in x86, it won't be able to
"see" the x64 dlls for DotImage and vice versa (if you force it to x64, it won't
"see" the x86 dlls)
Wrapping
Up:
We'd very much
like to be able to provide full AnyCPU support, but for the foreseeable future,
you will need to pick x86 or x64 for your project(s) that use DotImage, and
match that "bitness" with the correct version of the Atalasoft dlls.
For more information, please see:
INFO: Bitness Roundup Whitepaper: x86, x64, AnyCPU
Q10165 - FAQ: Cause of
System.BadImageFormatException
Q10149 - INFO:
Compiling with DotImage on a 64-bit system
FIX: Drag-Drop of Some Atalasoft Viewers Not Adding Control to Designer
Q10341 - INFO:
Workaround for a license compiler exception on 64-bit systems with VS2010 .Net
4.0
Q10288 - INFO:
Workaround for a license compiler exception on 64-bit systems with VS2008/VS2010
.Net 2.0
Q10158 - INFO:
Warning:Referenced assembly targets a different
processor
Original Article:
Q10401 - INFO: x86 vs x64 vs AnyCPU