Parallel Installation of Common Vision Blox for 32 and 64 Bit...Parallel Installation of Common Vision Blox for 32 and 64 Bit W W W . C O M M O N V I S I O N B L O X . C O M Page 4

► Common Vision Blox Application Note

WWW.ST EMMER- IMAG ING.COM HEAD OFFICE

STEMMER IMAGING GmbH Phone: +49 89 80902-0

STEMMER IMAGING is Europe‘s largest Gutenbergstraße 9-13 Fax: +49 89 80902-116

independent supplier of vision technology and services 82178 Puchheim, Germany [email protected]

Parallel Installation of Common Vision Blox

for 32 and 64 Bit

Version 1.0.0 from 4/13/2016

Author: Volker Gimple

In some scenarios the parallel installation of Common Vision Blox for 32 and 64 is

desirable. This application note describes how this can be achieved – at least for a runtime

installation of Common Vision Blox, but under some circumstances also for a development

system.

► Copyright

W W W . C O M M O N V I S I O N B L O X . C O M W W W . S T E M M E R - I M A G I N G . C O M

Copyright © 2014 STEMMER IMAGING GmbH, Puchheim.

All rights reserved and subject to change.

STEMMER IMAGING, Common Vision Blox, Windows, Visual Basic, Visual C++, C++Builder, Visual

Studio.net, Visual C#, Delphi are registered trademarks.

All rights to this manual are the property of STEMMER IMAGING GmbH, Puchheim/Germany. It may not be

reproduced or copied in printed, electronic or photographic form or translated into another language, either in

whole or in part, without the written agreement of STEMMER IMAGING GmbH.

► Table of Contents


Table of Contents

1 Introduction ..................................................................................................................................................... 4

2 Setting Up a 32 and 64 Bit Runtime Environment .......................................................................................... 4

2.1 Limitations .......................................................................................................................................... 4

2.2 Step-by-Step Instruction ..................................................................................................................... 5

2.2.1 Obtain Common Vision Blox Win32 Fileset ....................................................................................... 5

2.2.2 Installation of Common Vision Blox x64 ............................................................................................. 6

2.2.3 Add the Win32 File Set ...................................................................................................................... 6

2.2.4 Complete the Global Assembly Cache. ............................................................................................. 6

2.2.5 Install VC Runtimes ............................................................................................................................ 7

2.2.6 Adapt Environment Variables ............................................................................................................. 7

2.2.7 Register ActiveX Controls and Overlay Plugins ................................................................................. 7

2.2.8 Modify Registry................................................................................................................................... 8

2.3 Uninstallation ...................................................................................................................................... 8

3 Extension to Development Systems ............................................................................................................... 9

3.1 Problem ActiveX Control .................................................................................................................... 9

3.2 Workarounds .................................................................................................................................... 10

3.2.1 Common Grounds ............................................................................................................................ 10

3.2.2 Before Step 2.2.6 ............................................................................................................................. 10

3.2.3 Visual C++ / MFC ............................................................................................................................. 11

3.2.4 Delphi ............................................................................................................................................... 12

3.2.5 C#/VB.Net ........................................................................................................................................ 13

4 Contact and Feedback .................................................................................................................................. 16

► Parallel Installation of Common Vision Blox for 32 and 64 Bit

W W W . C O M M O N V I S I O N B L O X . C O M Page 4

1 Introduction

Users who want to develop and maintain their applications for 32 and 64 bit in parallel rightly criticize that a

parallel installation of Common Vision Blox for both architectures is currently not supported by the Common

Vision Blox installers. However, with some additional effort and keeping in mind certain limitations, the setup of

a runtime environment or a development environment that allows for the generation and/or execution of 32- and

64-bit Common Vision Blox applications is possible.

Chapter 2.2 describes how such an environment can be set up. The limitations of such a parallel setup are

described in chapter Fehler! Verweisquelle konnte nicht gefunden werden.. Chapter 3.1 describes the

difficulties that are specific to a development system. It also explains under which conditions a parallel setup of

32 bit and 64 bit is possible anyway for a development system.

2 Setting Up a 32 and 64 Bit Runtime Environment

The following sections describe how to set up a 32- and 64-bit Common Vision Blox runtime environment. The

term “runtime environment” in this context refers to the functionality contained in those Common Vision Blox

setups that have the word “Runtime” in their file name – basically a Common Vision Blox installation without the

folders Lib, Tutorial and Wow6432 which are only relevant for developers. The recipe is applicable to Common

Vision Blox as well as the Common Vision Blox CameraSuite. Most of the steps involved require administrative

privileges on the System.

2.1 Limitations

Once all the steps in chapter 2.2 have been successfully executed it is possible to start applications built for the

32 bit architecture as well as those compiled for 64 bit on this system. There are, however, some limitations

that apply to such a parallel installation of Common Vision Blox for 32 and 64 bit:

When following this recipe, it is currently not possible to use the GenICam.vin in a 32-bit application with

GigE Vision or USB3 Vision cameras. Only the 64-bit driver will work.

The SafeNet dongles that have been used up until Common Vision Blox 10.02.000 are not usable with the

x64 build of Common Vision Blox. Owners of a SafeNet dongle who also want to work with the x64 build of

Common vision Blox are encouraged to contact their distributor to get a quote for an upgrade to a WIBU

dongle.

The tools Color, Manto, ShapeFinder and TextOut are currently1 not available for the x64 platform. A .Net

application using one of these tools that has been built with the “Any CPU” target will raise a

System.BadImageFormat exception when launched on such a 32- and 64-bit installation because it will not

find the x64 builds of those tools’ unmanaged DLLs.

The parallel installation of Common Vision Blox for 32- and 64-bit described in chapter 2.2 has not been

tested with different driver setups. Especially when using Win32 drivers there is a chance that a driver will

1 Common Vision Blox 12.01.000



cooperate with the described setup or refuse installation altogether. Therefore, extensive tests of such a

setup are indispensable before deploying it on a production system.

Updating such a parallel installation is not as simple as updating a regular installation of Common Vision

Blox. The 64-bit part can simply be updated by means of running an up-to-date Common Vision Blox

installer, but the 32-bit part needs to be updated manually.

The start menu entries found on the system after following this recipe all refer to the x64 version of the

programs and tutorials. If you want to have start menu entries for the Win32 versions as well these will need

to be added manually2.

Whether or not such a parallel installation is usable on a productive system despite those limitations should be

verified thoroughly. We cannot currently guarantee a level of stability equivalent to that of the regular

installation. Nevertheless, we would like to encourage you to give feedback to this application note. If you find

obstacles, omissions or if the application note leaves questions unanswered please do not hesitate to point this

out to us. Suitable contact addresses are listed in chapter Fehler! Verweisquelle konnte nicht gefunden

werden..

2.2 Step-by-Step Instruction

To install both versions of Common Vision Blox on one system please follow the recipe below step by step.

While doing so it is important to adhere to the correct sequence as some steps build upon previous steps.

2.2.1 Obtain Common Vision Blox Win32 Fileset

First of all, you’ll need the file set of the Win32 version of Common Vision Blox. For this it is necessary to run

the Win32 Runtime Setup (“CommonVisionBlox Runtime 12.01.000 (Win32).exe”). It does not matter much into

which directory Common Vision Blox gets installed at this stage.

After the installation has finished, the following files need to be copied to a temporary directory:

The complete content of the directory %CVB%, including all sub-directories (keeping the directory structure

intact!)

From C:\Windows\System32 (32-bit Windows) or C:\windows\SysWOW64 (64-bit Windows) the files

borlndmm.dll and vcl60.bpl.

Optionally the following files from the Global Assembly Cache will be needed: iCVCColor.dll, iManto.dll,

iSF.dll and iTextOut.dll. These files will only be needed if you want to be able to execute programs that have

been implemented in C# or VB.Net. If this is not a requirement, this step may be skipped.

As the Global Assembly Cache is not directly accessible in the Windows Explorer, these files will need to be

copied on the command line. They are located in versioned sub-directories of the folder

C:\Windows\assembly\GAC_MSIL\<DLLName>. If applications need to be supported that have been

compiled against older versions of Common Vision Blox, it may make sense to also copy older versions of

2 Alternatively the start menu entries may be copied in step 2.2.1 and re-inserted into the start menu again after

step 2.2.8. To avoid name clashes it is recommendable to rename the LNK-files.



those DLLs. Otherwise, the most recent files should suffice (in this case it is also possible to copy the DLLs

from the %CVB%\Lib\Net directory of a Common Vison Blox installation)3.

Hint: If at this stage the installation has been carried out into the “correct” target folder (i.e. the one that will also

be used as the copy destination in step 2.2.3) then it is recommendable to now export the entire registry key

(including sub keys) HKEY_LOCAL_MACHINE\Software\Wow6432Node\Common Vision Blox into a file. This

file can then be re-imported without any changes in step 2.2.8. (Modify Registry). If you also want to import start

menu entries from the Win32 installation these may also be copied aside at this point.

Once all copies have been gathered, the Win32 version of the Installation will not be needed any longer and

may be uninstalled.

2.2.2 Installation of Common Vision Blox x64

Now the x64 version of the Common Vision Blox setup (“CommonVisionBlox Runtime 12.01.000 (x64).exe”)

can be executed on the target system. In principle the destination directory may be freely chosen, however it

may make sense to choose a directory layout with which it is easier to adapt the environment variable %CVB%

if necessary. If the environment variable %CVB% is not to be used, then an installation into the default folder

(C:\Program Files\STEMMER IMAGING\Common Vision Blox) is ok for the x64 version. However, if you e.g.

install the x64 version to C:\CVB\x64 and the Win32 version to C:\CVB\Win32 it is easier to deduce the correct

folder of the Win32 version from the current value of %CVB% (which has, after all, been set by the x64 setup).

2.2.3 Add the Win32 File Set

Now the file set that has been copied into a temporary folder in step 2.2.1 may be copied into a suitable target

directory, e.g. “C:\CVB\Win32” or “C:\Program Files (x86)\STEMMER IMAGING\Common Vision Blox”. Those

files that have been copied from C:\Windows\System32 or C:\Windows\SysWOW64 (borlndmm.dll and

vcl60.bpl) need to be copied to C:\Windows\SysWOW64. The correct treatment of the files from those that have

been copied from the Global Assembly Cache (if any) will be described in step 2.2.4.

2.2.4 Complete the Global Assembly Cache.

If files from the Global Assembly Cache have been copied in step 2.2.1 they should be added to the Global

Assembly Cache again now. The easiest way to do this is via the command line utility “gacutil.exe”. However,

this program is only available after a .Net Framework SDK has been installed. As an alternative you may use

the following PowerShell script to copy the files into the Global Assembly Cache:

BEGIN {

$ErrorActionPreference = "Stop"

if ( $null -eq ([AppDomain]::CurrentDomain.GetAssemblies() |? { $_.FullName –eq

"System.EnterpriseServices, Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a" }) ) {

[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=2.0.0.0,

Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a") | Out-Null

}

$publish = New-Object System.EnterpriseServices.Internal.Publish

3 In this case of course we’re referring to an installation that includes developer resources and tutorials.



}

PROCESS {

$assembly = $args[0]

if ( -not (Test-Path $assembly -type Leaf) ) {

throw "The assembly '$assembly' does not exist."

}

Write-Output "Installing: $assembly"

$publish.GacInstall( $assembly )

}

Hints:

Save the script into a text file and give it the extension “ps1”, e.g. gacinstall.ps1.

Before executing the script is may be necessary to use the PowerShell command “Set-ExecutionPolicy

RemoteSigned” to at least temporarily enable the execution of unsigned scripts. This command requires the

PowerShell to be started with administrative privileges.

For the DLL(s) to be installed the absolute path must be given to the script, for example

.\gacinstall C:\CVB\iManto.dll

After they have been installed into the Global Assembly Cache the copied DLLs are no longer needed and

may be deleted.

2.2.5 Install VC Runtimes

Furthermore, it is also necessary to install the VC Runtimes used by the 32 Bit version of Common Vision Blox.

The setups for these are located in the directory “\Redist\Runtime Setups\Microsoft” on the Common Vision

Blox DVD. Only those setups that bear a “_x86” in their name need to be installed.

2.2.6 Adapt Environment Variables

The following environment variables should now be adapted or added:

%GENICAM_GENTL32_PATH% has to be added. It should point to the sub-directory

“GenICam\bin\win32_i86\TLIs” of the Win32 file set (e. g. C:\CVB\Win32\GenICam\bin\win32_i86\TLIs).

A reference to the base folder of the Win32 file set must be added to the %PATH% variable.

2.2.7 Register ActiveX Controls and Overlay Plugins

For this step a new4 command line with administrative privileges will be required. First you’ll need to point the

working directory to the base directory of the Win32 file set. Then you can use the command line

for %i in (*.ocx) do C:\Windows\SysWOW64\regsvr32.exe /s %i

4 This step may fail when using a command line that was already open before the environment variables were

modified in step 2.2.6. The windows command line will generally not notice a change in the environment and

continue using the old variables. It is therefore recommended to always open a new command line for this step.



to register all the Win32 ActiveX controls on the system5.

Then change to the sub-directory “OverlayPlugins” and use the command line

for %i in (*.opi) do C:\Windows\SysWOW64\regsvr32.exe /s %i

to register the Win32 versions of the Common Vision Blox Overlay Plugins.

2.2.8 Modify Registry

So far the registry only contains those entries that have been added by the x64 installer. Some components,

however (e.g. the overlay plugins of the Common Vision Blox display or the GenICam.vin) rely on the correct

entries for the Win32 part to work correctly. The easiest way to get a complete set of entries is to first export the

key “HKEY_LOCAL_MACHINE\Software\Common Vision Blox” and all its sub keys into a file and carry out the

following substitutions:

“HKEY_LOCAL_MACHINE\Software\Common Vision Blox” is to be replaced with

“HKEY_LOCAL_MACHINE\Software\Wow6432Node\Common Vision Blox”

The entry “Directory” in “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Common Vision

Blox\Image Manager” needs to be modified to point to the base directory of the Win32 file set.

After making these substitutions the new keys can be imported into the system by double-clicking the reg-file.

If a suitable set of Win32 registry keys has been exported in step 2.2.1 then it may of course simply be

imported here (rather than making the substitutions above).

2.3 Uninstallation

To remove an installation of Common Vision Blox that has been carried out using the method described in

chapter 2.2 the individual installation steps need to be carried out in reverse order.

1. First, the registry entries added in step 2.2.8 to

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Common Vision Blox need to be removed (easiest

with regedit.exe).

2. After that, the 32-bit versions of the ActiveX controls and the overlay plugins need to be unregistered.

The necessary calls (and preconditions) are the same as for step 2.2.7, however this time the

command line option /u needs to be added. The command lines for unregistering therefore are

for %i in (*.ocx) do C:\Windows\SysWOW64\regsvr32.exe /s /u %i

and

for %i in (*.opi) do C:\Windows\SysWOW64\regsvr32.exe /s /u %i

3. The environment variables that have been set in step 2.2.6 also need to be removed manually.

4. Uninstalling the runtime setups that have been installed in step 2.2.5 is optional. It can be carried out

via the Windows Control Panel.

5 Hint: If this call is to be placed into a batch file, the “i” will have to be prefixed with two instead of one percent

signs. When working with a full setup of Common Vision Blox (as opposed to a runtime setup, see chapter 3), it

is recommendable to first unregister the WOW versions of the Common Vision Blox ActiveX Controls by calling


in the directory %CVB%\Wow6432.



5. If files have been installed into the Global Assembly Cache in step 2.2.4 they will need to be removed

manually at this point (e.g. using Windows Explorer in the folder C:\Windows\assembly and right

clicking the DLLs).

6. Finally the Win32 Fileset copied in step 2.2.3 can be deleted. From here on, uninstallation works as

usual (i.e. through the Windows Control Panel).

3 Extension to Development Systems

3.1 Problem ActiveX Control

The approach described in chapter 2, although in principle applicable for all flavors of the Common Vision Blox

setups, has been described only for the runtime environment so far for two reasons:

Common Vision Blox uses the environment variable %CVB% which in the case of a parallel installation would

need to point to two different directories.

Common Vision Blox needs three(!) different ActiveX Controls to fully support the most popular development

environments. The operating system, however, only supports two different ActiveX controls under the same

GUID.

The first point is certainly no particularly serious issue as developers can keep that in mind and abstain from

using %CVB% in their applications.

The second item, however, weighs heavier and probably requires some explanation. Almost all ActiveX

Controls installed by Common Vision Blox carry a property named “Image” that gives access to the image

handle on which the control is currently working. On the Common Vision Blox DLL layer, image handles are

always pointer types (for example IMG in C++ is just a typedef for void*). The use of pointer types,

however, is not permitted in the definition of an ActiveX Control Interface6, therefore the 32-bit version of

Common Vision Blox maps the Image-property to LONG, in this case a 32-bit integer type. When building the

64-bit release of Common Vision Blox these properties were changed to LONG LONG, a 64-bit integer type to

make sure that 64-bit programs can pass pointers properly7.

So far this would work fine, as Windows permits the installation of different ActiveX Controls (for 32- and 64-bit)

with the same GUID. Unfortunately, the popular development environments that are capable of working with

6 To be precise: There are two cases where pointer types can be used in MIDL: When passing arguments by

reference in functions and as an LPUNKNOWN pointer. The first one is not applicable to ActiveX properties, the

latter implies that the pointer points to a valid COM object. Both cases are therefore not applicable for the

Image property.

7 Of course other approaches could have been imagined, but each of them has its specific flaw. Changing the

Image property to a 64-bit integer for both architectures for example would have jeopardized the binary

backward compatibility of the 32-bit build and would have made general support for Visual Basic 6 nearly

impossible. Introduction of a supplementary Image64 property as a 64-bit integer type on the other hand would

have made it easy for users to run into runtime problems caused by pointer aliasing when using Image where

Image64 should have been used.



ActiveX Controls are all 32-bit applications. Whenever an ActiveX Control is placed on a form in such a

development environment it is therefore always the 32-bit build of the control that is instantiated. On the other

hand it is the type library of this very control that will be used for generating the language-specific wrapper

class8 – which leads to the situation that for generating an application for 64-bit platforms a 32-bit compiled

ActiveX control needs to be available that has the same type library as the 64-bit compiled ActiveX control. The

Common Vision Blox setup installs these ActiveX Controls into the folder %CVB%\Wow64329. They are only for

use in the development environment and should never be used for production systems.

In summary, three varieties of each ActiveX Control exist in Common Vision Blox:

A 32-bit build with the 32-bit type library (installed by the 32-bit version of the setups)



As no more than two of these controls may installed at the same time, a parallel installation of the developer

setups for 32- and 64-bit requires some extra effort.

3.2 Workarounds

The workaround for the issue described in chapter 3.1 depends on the programming language involved.

3.2.1 Common Grounds

No matter what language will be used – the system setup is the same and boils down to following the guide in

chapter 2.1 – this time however with a full setup instead of a runtime setup (e. g. “Common Vision Blox

12.01.000 (Win32).exe” and “Common Vision Blox 12.01.000 (x64).exe”).

3.2.2 Before Step 2.2.6

… the ActiveX Controls from the Wow6432 directory should be unregistered. This is done on a command line

with administrative privileges. Change to the directory %CVB%\Wow6432 and enter the line


After this, the files in the folder %CVB%\Wow6432 won’t be needed any more and may be deleted. The files in

the two subdirectories “.Net OCX Wrappers” and “Visual C++ OCX Wrappers” may yet be useful and should be

spared.

All other steps can (and should) be carried out according to the instructions in chapter 2.1.

8 A process that – as far as we have seen – only works properly with the .Net languages. Delphi as well as the

MFC wizard apparently are unable to correctly map 64-bit integer types and produce flawed wrappers.

Therefore, when using Delphi or MFC/C++ customers should always use the corrected ActiveX wrappers

shipped with Common Vision Blox.

9 Those controls are recognizable by the suffix _wow64 in the file name.



3.2.3 Visual C++ / MFC

Compiling a project with Common Vision Blox based on C++ and MFC for 32- as well as 64-bit is comparatively

easy:

First of all the project must contain a Win32 and an x64 configuration10.

If a suitable directory layout has been chosen in step 2.2.2 and 2.2.3 it may make sense to define an

environment variable at this point that points to the directory level right before the split between Win32 or

x64 (for example CVBSDK=C:\CVB if Common Vision Blox has been installed to C:\CVB\Win32 and

C:\CVB\x64).

For both configurations the directory containing the C/C++ headers must be specified under “C/C++”

“General” in the box “Additional Include Directories”. It hardly matters whether you specify the Win32 or the

x64 directory here – the header files are identical for both platforms11. If the Win32 and the x64 have been

installed into accordingly named sub-directories of the same folder we can now use the aforementioned

environment variable and a predefined macro of Visual Studio:

Under “Linker” “General” the directory holding the *.lib files must be specified in the “Additional Library

Directories” box. This time, distinction between the Win32 and the x64 path is essential as the binary

function signatures differ between the Win32 and the x64 build and therefore different *.lib files have to be

used. With a directory layout choice as described in the previous bullet point you may, however, actually use

the same entry as for the header files (the macro $(Platform) reliably makes this distinction), otherwise the

10 Older versions of Visual Studio versions by default will only generate a Win32 configuration when starting a

new project.

11 Of course under Win32 a few more files are present than under x64 – however in those cases x64 cannot be

sensibly used as a target platform anyway.



respective path needs to be entered:

When working with ActiveX Controls, make sure you are always working with the wrapper files modified by

STEMMER IMAGING as the scripts used by Visual Studio to generate the wrappers from the type library

cannot handle 64-bit integer types properly. The modified wrappers are located in the folder

“%CVB%\Wow6432\Visual C++ OCX Wrappers”. To use those files, please proceed as follows:

1. Add the ActiveX Control in the dialog editor to your form. As usual, right-click on the control

and select the menu item “Add Variable…”.

2. In the dialog that opens please remove the trailing “1” from the predefined file and type name,

then press “Finish”.

3. Now copy the wrappers (*.cpp and *.h file) that go with your ActiveX Control into your project

folder over the identically named files that have been generated in the previous step by Visual

Studio.

Besides correctly handling the 64-bit types the modified wrappers have the added advantage that they are

suitable for targeting 32-bit as well as 64-bit.

From here on, the project may be compiled and started for Win32 as well as x64. Additional ActiveX Controls

may later on be imported using the same pattern.

3.2.4 Delphi

With Delphi, the generation project targeting both the Win32 and the Win64 architecture is similarly easy12. Also

Delphi does not handle 64-bit types in ActiveX Controls gracefully and therefore Delphi programmers will also

need to use the wrappers modified by STEMMER IMAGING. These are installed to the directory

%CVB%\Lib\Delphi\Packages\DelphiXE2. Instructions on how to install these wrappers are located in the folder

%CVB%\Lib\Delphi\Packages. Like with C/C++ it does not really matter whether the unit path points to the

Win32 or the x64 folder with the Delphi headers (%CVB%\Lib\Delphi) as these are again identical for both

platforms. Unlike MFC/C++ the installation of the wrappers needs to be done only once in Delphi – from then

on the development environment will automatically use the correct wrappers (which are again identical for

Win32 and x64).

12 Keep in mind, however, that not all editions of the Embarcadero RAD Studio are capable of building 64-bit

applications.



3.2.5 C#/VB.Net

Applications written in C# or VB.Net that do not use ActiveX Controls may be run as 32-bit or 64-bit applications

on a system configured according to chapter 2.1 without further ado13.

When using ActiveX Controls, however, some additional effort is necessary to make things work:

First of all, generate the project as usual and add the desired configurations (“Any CPU”, “x86” and “x64”).

Then place the required ActiveX Controls in your application in the Forms Editor. As usual, Visual Studio will

automatically generate wrapper DLLs by means of the tools aximp and tlbimp named for example

“AxInterop.CVIMAGELib.dll” and “Interop.CVIMAGELib.dll” and add these as references to the project. For

the moment these DLLs reside in the “obj” subdirectories of the project. On a system configured according

to chapter 2.1 these wrappers of course have been generated using the type library of the 32-bit version of

the ActiveX Controls and are therefore mostly unusable in 64-bit applications.

Now close the project, open the project folder in the Windows Explorer and generate two subdirectories –

for example “ocx_x86” and “ocx_x64”. They will receive the wrappers for the respective architecture.

The files for the “ocx_x86” directory may be copied from any of the C# or VB.Net tutorials found in the

Win32 directory tree of Common Vision Blox. The files for the “ocx_x64” directory may be either copied from

the “%CVB%\Wow6432\.Net OCX Wrappers” folder or any of the C# or VB.Net tutorials of the x64 directory

tree of Common Vision Blox.

For each ActiveX Control two files need to be copied – one fitting the name pattern

“AxInterop.<OCXName>.dll” and one fitting the name pattern “Interop.<OCXName>.dll”.

Now reopen the project in Visual Studio, delete the ActiveX Control references that have been added in step

2 and instead add references to all the wrapper DLLs that have been copied in the previous step (right-click

on references and choose “Add New Reference…”, then “Browse”) – but only from one of the folders

generated in the previous step (e.g. “ocx_x64”). After that, save the project and close Visual Studio again.

Now the project file (*.csproj or *.vbproj) needs to be edited in a text editor. This step is greatly simplified

when using an editor with syntax highlighting for XML files.

Locate the <ItemGroup> tag with the references added in the previous step. In a project that contains e.g.

a Common Vision Blox Display Control and a Common Vision Blox Image Control these entries look like

this:

13 The P/Invoke wrappers installed to the Global Assembly Cache are MSIL assemblies.



First of all remove all the <EmbedInteropTypes> under the tags of the Interop.<OCXName>.dlls, then

duplicate the complete block with all the (in this case four) relevant <Reference> tags so that one block

per target platform is available (up to three blocks for “Any CPU”, “x64” and “x86”).

Now give the <Reference> tag in each block a new “Condition” attribute that limits its use to one target

platform:

Any CPU14: Condition="'$(Platform)' == 'AnyCPU'"

x64: Condition="'$(Platform)' == 'x64'"

x86: Condition="'$(Platform)' == 'x86'"

Additionally, change the <HintPath> tags in the x86 cases to point to the “ocx_x86” directory.

The result should look similar to this:

You may now close the project file in your text editor and reopen it in Visual Studio. In the “References”

node of the project tree Visual Studio will still only show each wrapper DLL only once, however they will now

be picked from different directories depending on the selected target platform. You may verify this e.g. by

opening the wrapper DLLs in “bin\x86\Debug” and “bin\x64\Debug” in a disassembler like ILDASM. When

14 Hint: “Any CPU” targets built like this are strictly speaking only suitable to run on a 64-bit operating system. It

is generally preferable for use the platforms “x86” and “x64” for applications using the Common Vision Blox

ActiveX Controls.



looking at the type of the Image property (getter/setter) it should be “int32” in the DLL from the x86 directory

and “int64” in the DLL from the x64 directory.

The project may now be built and started for one of the available target platforms. The wrapper DLLs that

will be used will automatically be picked accordingly. One thing should, however, be kept in mind: If you

need to add a new instance of one of the ActiveX Controls that have already been imported into the project

it is recommendable to not do this via the tool box (like the initial one) but via the clipboard using Copy +

Paste. For example if you application already uses a Common Vision Blox Display Control and you want to

add another one, don’t click on the toolbox and enter it into the form – instead select the existing one, copy it

to the clipboard and paste it into the target form.

The reason for this is that when adding from the tool box Visual Studio will again add the original

<COMReference> which leads to the wrappers being regenerated at different occasions with aximp and

tlbimp dynamically – a mechanism that although fairly elegant is not suitable for our scenario.

Should you accidentally add a control from the tool box it is recommendable to immediately remove the

newly generated reference entries (they are easily distinguishable from the manually entered once as they

have an abbreviated name). Otherwise compilation errors will be raise due to the duplicate definition of the

wrapper classes involved.

When adding completely new controls at a later point, simply treat them as described here.

► Contact


4 Contact and Feedback

We hope that these notes were useful for you and look forward to your feedback. In case of further questions,

please do not hesitate to contact our technical support.

Additional information and a lot of valuable details regarding image processing, can also be found on our

website.

DENMARK

Phone: +46 8 555 110 27

E-Mail: [email protected]

Web: www.stemmer-imaging.dk

FINLAND

BALTICS

Phone: +358 9 43 555 012


Web: www.stemmer-imaging.fi

FRANCE

Phone: +33 1 45069560


Web: www.stemmer-imaging.fr

GERMANY

AUSTRIA

Phone: +49 89 80902-200


Web: www.stemmer-imaging.de

POLAND

Phone: +46 8 555 110 27


Web: www.stemmer-imaging.pl

SWEDEN

NORWAY · ICELAND

Phone: +46 8 555 110 27


Web: www.stemmer-imaging.se

SWITZERLAND

LIECHTENSTEIN

Phone: +41 55 415 90 90


Web: www.stemmer-imaging.ch

THE NETHERLANDS

BELGIUM · LUXEMBOURG

Phone: +31 575 798881


Web: www.stemmer-imaging.nl

UNITED KINGDOM

IRELAND

Phone: +44 1252 780060


Web: www.stemmer-imaging.co.uk

Documents

Parallel Installation of Common Vision Blox for 32 and 64 Bit...Parallel Installation of Common Vision Blox for 32 and 64 Bit W W W . C O M M O N V I S I O N B L O X . C O M Page 4