We have found that there is a bug in Visual Studio when it comes to building a 64-bit application on a 64-bit system. Visual Studio will use the 32-bit version of license compiler (LC.exe) when the build configuration is set to x64.

Please note, this article refers to Visual Studio 2008/2010 and .NET framework 2.0 ... for correct information regarding VS2010 and .NET framework 4.0, please refer to Q10341 - INFO: Workaround for a license compiler exception on 64-bit systems with VS2010

To workaround this issue you will need to modify your application project file in a text editor. Add the highlighted line shown below to all of your 64-bit build configurations:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' "> <DebugSymbols>true</DebugSymbols>   <OutputPath>bin\x64\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <DebugType>full</DebugType> <PlatformTarget>x64</PlatformTarget> <CodeAnalysisUseTypeNameInSuppression>true</CodeAnalysisUseTypeNameInSuppression> <CodeAnalysisModuleSuppressionsFile>GlobalSuppressions.cs</CodeAnalysisModuleSuppressionsFile> <ErrorReport>prompt</ErrorReport> <LCToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64</LCToolPath></PropertyGroup><PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' "> <OutputPath>bin\x64\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <Optimize>true</Optimize> <DebugType>pdbonly</DebugType> <PlatformTarget>x64</Pl

When compiling a project in .NET 2.0, you may receive an error message similar to the folowing:

Warning 2 Assembly generation -- Referenced assembly 'Atalasoft.dotImage.dll' targets a different processor

The reason for this error is the Atalasoft DLLs are compiled either to the processor 'x86', which is for 32 bit only, OR to the processor 'x64' which is 64 bit only. To put it another way, our components "have bitness", so in order to run properly, your project needs to have a platform target of either x86 or x64, and the Atalasoft dlls being referenced need to match. You can not target 'AnyCPU'.

To resolve this problem, please change your project's target platform to 'x86' and use our x86 dlls (or, if you are explicitly targeting x64, set your platform target to 'x64' and ensure that ALL Atalasoft dlls referenced are x64 versions).

For more information, please see:

Q10165 - FAQ: Cause of System.BadImageFormatException

Q10149 - INFO: Compiling with DotImage on a 64-bit system

Q10406 - 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

When an application that references DotImage, DotTwain, DotAnnotate or any of our add-ons is compiled on a 64-bit system you may run into a couple issues.

Our assemblies are available in 32 bit ('x86') and 64 bit ('x64); When compiling on a 32 bit system, if you happen to leave the platform target set to 'AnyCPU' (The default for some versions of Visual Studio) things work fine for you, but cause problems the minute you run the retulting application on a 64 bit machine. Therefore any applications using DotImage components must specify a platform target of either 'x86' or 'x64' and must use the corresponding Atalasoft dlls.

Note that you do not NEED to compile to x64 in order for your applications to wok on x64 systems. Unless you have a specific need to build x64-only applications, target x86 and your applications will run on both 32 and 64 bit Windows.

In summary, changing the "Platform Target" setting on the Build tab of your project settings to x86 or x64 and make sure the Atalasoft references used all match that "bitness". Without this setting you will receive a BadImageFormatException when running your application.

When building x64 applications, there are some issues related to the fact that Visual Studio itself is actually a 32 bit process, and there There is a bug in some Visual Studio versions that will try to run the License Compiler in the wrong (x64 / x86) mode. To work around this you may need to to add pre-build and post-build events to your project. Here are the settings for those events:

For problems building x86 targeted apps:

Pre-Build:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow

Post-Build:
C:\WINDOWS\Microsoft.NET\Framework64\

In newer versions of Visual Studio (VS2012 and VS2013 at the time of writing), When you drag/drop one of Atalasoft's Winforms viewers onto your forms designer, it can sometimes fail to show up.

There are several possible causes for this...

The first thing to do is to check that you're not targeting x64. We have x64 dlls and absolutely support building x64 apps with DotImage, but the VS forms designer is running in 32 bit and can't understand our x64 dlls. (this actually can happen in ALL versions of VS, not just 2012 and 2013)

To address this situation set your platform target to x86 or AnyCPU while working in the designer and use our x86 DLLs.

The next case (if you're ensured you've got the "bitness" sorted) is to ensure you add references to ALL of the following DLLs:

Atalasoft.dotImage.dll
Atalasoft.dotImage.Lib.dll
Atalasoft.dotImage.WinControls.dll
Atalasoft.Shared.dll

You may need to restart Visual Studio after adding those references if the drag/drop still doesn't work.

Finally, if you've done all that and when you drag/drop the designer still refuses to work and/or if you see an error saying it can't add the reference to Atalasoft.dotImage.WinControls.dll because it's already there, Go ahead and remove the reference to Atalasoft.dotImage.WinControls.dll, restart VS and try again.

If you're still having issues after following these guidelines, create s support case (please make sure you reference this KB article, indicating you've already tried following it.

For more information, please see:

Q10165 - FAQ: Cause of System.BadImageFormatException

Q10149 - INFO: Compiling with DotImage on a 64-bit system

We have found that there is a bug in Visual Studio when it comes to building a 64-bit application on a 64-bit system. Visual Studio will use the 32-bit version of license compiler (LC.exe) when the build configuration is set to x64.

Please note, this article refers to the .NET Framework 4.0 ... for correct information regarding the .NET framework 2.0, please refer to Q10288 - INFO: Workaround for a license compiler exception on 64-bit systems with VS2008/VS2010 .Net 2.0

To workaround this issue you will need to modify your application project file in a text editor. Add the highlighted line shown below to all of your 64-bit build configurations:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' "> <DebugSymbols>true</DebugSymbols>   <OutputPath>bin\x64\Debug\</OutputPath> <DefineConstants>DEBUG;TRACE</DefineConstants> <DebugType>full</DebugType> <PlatformTarget>x64</PlatformTarget> <CodeAnalysisUseTypeNameInSuppression>true</CodeAnalysisUseTypeNameInSuppression> <CodeAnalysisModuleSuppressionsFile>GlobalSuppressions.cs</CodeAnalysisModuleSuppressionsFile> <ErrorReport>prompt</ErrorReport> <LCToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64</LCToolPath></PropertyGroup><PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' "> <OutputPath>bin\x64\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <Optimize>true</Optimize> <DebugType>pdbonly</DebugType> <PlatformTarget>x64</PlatformTarget> <CodeAnalysisUseTypeName

Symptoms

At compile time you receive an error message that the “license signature is invalid”

Cause

This is caused by using an older license file with a new version of the software.

Resolution

You will need to generate a new license file by using the DotImage Activation Wizard. When you use this utility it will generate a new license file for you with the proper license signature for the current version of the software you have installed. Please be sure to overwrite any of the existing license files that you during this process. Once you have done this you will need to do a “Rebuild” of your project so that it pulls in the updated license file.

Workaround

If the above does not work it is likely due to the cause that you have license files in none standard locations on your system. With the 5.0b release of the software we made an addition to the activation wizard that will search your system for Atalasoft license files and remove them. Please run this utility remove all the files that it finds and then follow the above instructions.

When you purchase DotImage, DotPdf, WingScan, or JoltImage, you will receive an email with serial numbers. These serial numbers will be used to 'unlock' the evaluation version. Please see this topic for more information on serial numbers and license files. Use the following steps to register your developer license:

1. Find all *.lic files: If you have moved any of the .lic files (in a web project, for example) please make sure to delete them, then replace them with the newly created .lic file. Just to be sure, we suggest searching your entire hard drive for "Atalasoft.*.lic" before registering your developer license; a stray evaluation license can be quite frustrating to find.
2. Register your license: Use the Atalasoft Activation Utility to create the license file on your machine. See here for more information. If you do not have a valid internet connection, or your firewall blocks access to the licensing service, log into our website and upload your activation file here.
3. Compile with the license: After activating your license, you still might get the evaluation splash screen. If you're using DotImage or DotPdf, you may need to restart Visual Studio, and rebuild the solution (a full rebuild, not build or F5). This will recreate the resource file with the new license. Sometimes Visual Studio will cache the licenses and you will actually need to log off, and log back in for the new licenses to take effect.

If, after following these steps, you still see an evaluation splash screen please try the following:

• Look inside the license file(s).

To accommodate our customers that are supporting older applications we have made available a license that will make a COM callable wrapper possible. While Atalasoft does not support this function we will make available the license that makes this possible. To get the license you need for this please contact our sales team at Atalasoft they can be reached via email at sales@atalasoft.com or via phone at 1-866-568-0129.

Following is a link that explains how to create a COM callable wrapper. We hope that this can clarify any questions that you may have on this matter. Again Atalasoft will not support any issues with this we will only make the license available that make this an option.

http://blogs.msdn.com/bwaldron/archive/2004/12/01/273476.aspx

For additional information, please see:

Q10143 - INFO: Using DotImage through COM Interop

Atalasoft dotImage has streaming capabilities that can be used jointly with ADO.NET to read and write images directly to a database without saving to a temporary file. The following code snippets demonstrates this in C# and VB.NET.

private void SaveToOleDatabase(AtalaImage image)
{
    OleDbConnection myConnection = null;
    try
    {
        //Save image to byte array
        byte[] imagedata = image.ToByteArray(new Atalasoft.Imaging.Codec.JpegEncoder(75));


        //create the SQL statement to add the image data
        myConnection = new OleDbConnection(CONNECTION_STRING);
        OleDbCommand myCommand = new OleDbCommand
                ("INSERT INTO Atalasoft_Image_Database (Caption, ImageData) VALUES ('" + txtCaption.Text + "', ?)", myConnection);
        OleDbParameter myParameter = new OleDbParameter("@Image", OleDbType.LongVarBinary, size);
        myParameter.Value = imagedata;
        myCommand.Parameters.Add(myParameter);

        //open the connection and execture the statement
        myConnection.Open();
        myCommand.ExecuteNonQuery();
    }
    finally
    {
        myConnection.Close();
    }
}

Private Sub SaveToOleDatabase(ByVal image As AtalaImage)
    Dim myConnection As OleDbConnection = Nothing
    Try
        'save image to byte array
        Dim imagedata As Byte = image.ToByteArray(New Atalasoft.Imaging.Codec.JpegEncoder(75))









        'create the SQL statement to add the image data
        myConnection = New OleDbConnection(CONNECTION_STRING)
        Dim myCommand As OleDbCommand = New OleDbCommand
                ("INSERT INTO Atalasoft_Image_Database (Caption, ImageData) VALUES ('" + txtCaption.Text + "', ?)", myConnection)

Starting in 10.4, DotImage's PdfDocument components have a new Examiner tool. It allows a very fast, low-overhead means to probe a PDF to ascertain useful information such as whether the file is a valid PDF, if it contains certain structures or types that we do not support, if it has forms data, etc.

Making use of Examiner

First, you will need to make sure to add a reference to Atalasoft.PdfDoc.dll to your project.

You will need a license for DotImage Document Imaging or DotPdf to use this component (you do NOT need a license for PdfReader to use Examiner)

add the required using/Imports statement

C#:
using Atalasoft.PdfDoc.Examiner;

VB.NET:
Imports Atalasoft.PdfDoc.Examiner

Now, you're ready to use the Examiner to analyze the PDF - you'll need a stream to pass to it. Support strongly suggests that you wrap your stream in a using statement as this will guarantee you don't leave a file handle open on your PDF file accidentally.

C#:

The Atalasoft BarcodeReader can sometimes get "confused" by multiple barcodes which are a bit too close to each other... this can result in missed barcodes on a page even though the barcode images are completely valid and should have read.

Here are two sample methods (meant to be used together) to perform an iterative read:

When you are building ASP.NET web applications using Atalasoft controls, you may sometimes run into situations where you get random JavaScript errors and/or image viewers are not displaying as expected when viewing in IE, but the same solution runs fine in FireFox, Chrome, Safari, and/or other browsers.

There are several common causes of this behavior:

1. IE9 is not supported in DotImage versions previous to 9.0
   IE9 is only supported in DotImage v9.0 and newer. Also, we've made many bug fixes and improvements in IE9 support since the initial release of v9.0.0. For best results, consider downloading the latest version of DotImage (currently v10.0.0). If you need to stay with v9, please visit our legacy downloads page and download the latest official v9.0 release (currently 9.0.4d)


2. IE Document Mode settings (IE 8,9, and 10)
   DotImage ASP.NET controls require that the Document Mode be set to Standards mode. For IE9, this would be "Document Mode: IE9 Standards"; for IE8, this would be "Document Mode: IE8 Standards" and so-on.
   
   To test if this is your issue, simply hit F12 while viewing your app in IE and ensure the Browser Mode and Document Mode are properly set.
   
   
   
   If you find that this resolves your problem, but that every time you view the page from a new session, you're winding up in Quirks Mode, then you may wish to explicitly set the mode in your HTML.
   
   The easiest way to ensure Standards Mode is set is to add !doctype to your tag:
   
   <!doctype html>
   ... your page here ...
   </html>
   
   If this isn't possible, you can set Document Mode using a meta tag in the section:
   
   

Our GlyphReader engine needs to be loaded by Reflection if being used in a Web App / Web Service / WCF service

Use this simple method to handle the loading (make sure you set your paths)

/// <summary>

/// The GlyphReader Engine needs to be loaded by reflection in a web application...

/// </summary>

/// <returns></returns>

private OcrEngine CreateGlyphreaderEngine()

{

try

{

string ocrPath = Page.MapPath("OcrResources");

GlyphReaderLoader loader = new GlyphReaderLoader(ocrPath);

string dllPath = ocrPath + "/Atalaso

GlyphReader Engine

The glyph reader engine is a highly accurate OCR engine built for DotImage. The engine has been tested with the ISRI OCR Performance Toolkit and has been found to be more accurate, with a 99.5% accuracy rate, than other expensive industry leading OCR engines.

GlyphReader is a lexicon OCR engine requiring no dictionary. It supports European characters only. The following ASCII characters are supported.

The GlyphReader engine does not support font name or family determination. This engine does support font size, baseline, glyph bounds, and confidence.

The DefaultFontName property determines what the font name used by the OcrGlyph class.

Features

Output Formats

Note: This information is specific to DotImage at the time it was written and may change slightly in future versions.

Every OcrEngine has different requirements in terms of how it is deployed. Atalasoft has tried to formalize this process as much as possible as well as to provide guidelines on the mechanism for deployment. Licensing is covered in another topic. This topic covers how to ensure that an OcrEngine will be able to start and will be able to find its own resources.

In your SDK installation, you will find a folder named "OcrResources". This folder is the general folder for all supported OCR engines. Within it you will see a structure like this:

EngineManufacturer1

<Files>

EngineManufacturer2

<Files>

...

EngineManufacturerN

...

In general, most of the handling of loading and locating resources is managed by Atalasoft or by the engine itself and does not require work by the client, but in custom situations, there may be work to be done by the client to handle this.

To sort this out, let's start with a few definitions:

engine resources folder - this is the folder which contains the OCR Engine's resource files
OCR resources folder - the top level folder of all OCR Engine resources, called "OcrResources"
application folder - the folder where your application is installed
assembly folder - the folder which contains the dotImage assembly files (ie, Atalasoft.dotImage.Ocr.dll), this ma

DotImage's ImageSource classes are incredibly useful tools for dealing with multipage files in a memory-conscious way.

One of the most important uses of ImageSource classes is to completely replace/eliminate any instances of ImageCollection objects in your solution.

However, as one digs in to our offerings a bit, one may realize that our PdfImageSource takes a stream, but FileSystemImageSource needs physical files on disk... There are times when a FileSystemImageSource would be the correct choice if only it could take a Stream instead of needing files on disk.

There is no general use ImageSource that takes a stream or byte[] in DotImage.

Fear not: we can easily create a StreamImageSource by deriving from the RandomAccessImageSource abstract class

In order to use the example presented at the end of this article, you'll need to grab the StreamImageSource.cs file attached to this case and add it to your project using Add Existing...

Example of Simple StreamImageSource

Some customers have reported that their Managed browser hosting controls (.NET 2.0 winforms controls embedded in a user control for IE) suddenly stopped working.

Further investigation found that this occurred after applying certain security patches related to .NET 4.5 (such as those in MS KB 2858725)

In their page on Application Compatibility in .NET 4.5, Microsoft explicitly states the following under "Web Applications":

Change: Hosting these controls is blocked in Internet Explorer.

Impact: Internet Explorer will fail to launch an application that uses managed browser hosting controls.

The previous behavior can be restored by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/MICROSOFT/.NETFramework to 1 for x86 systems and for 32-bit processes on x64 systems, and by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/Wow6432Node/.NETFramework to 1 for 64-bit processes on x64 systems.

So to sum this up: MS is explicitly blocking embedded Managed Browser Hosting Controls. this is being done for security purposes. There is every possibility that a future update could remove even the ability to override this block.

Atalasoft support strongly recommends that if you're still maintaining a user control that uses our .NET 2.0 winforms components, that you immediately begin the process of replacing that functionality using our classic ASP.NET controls (WebImageViewer, WebAnnotationViewer / WebThumbnailViewer) or our new ASP.NET controls (WebDocumentViewer /WebDocumentThumbnailer).

If you were using DotTwain user control, please look into our WingScan components for web bas

At times, you may run into an image which has a "non-square" resolution - an image where the resolution of the X (width) axis of the image differs from the resolution of the Y (height) axis

The most common cause for such an image is that many older fax systems used to use a resolution of 204 DPI for the width but 98 DPI for the height.

Such images appear normal when viewed in the original orientation, but if rotated or opened in one of our viewers, these types of images often cause unwanted effects - distortion of an image when rotated or annotations that completely fail to line up / appear as intended.

NOTE: if you would like a means of detecting and fixing all such images in a multipage TIFF File please see
Q10153 - HOWTO: Using TiffFile to resample FAX images with unequal resolutions in a multi-page TIFF

Example Code: