Impact Acquire SDK .NET
Building, Linking And Running Applications Using Impact Acquire

Target Frameworks

The Impact Acquire .NET API has been built for the following .NET platforms:

Impact Acquire versionInstallation Folder.NET platforms supported
since 1.12.68$(MVIMPACT_ACQUIRE_DIR)/bin/.NET.NET Framework 3.5 and above
since 2.38.0$(MVIMPACT_ACQUIRE_DIR)/bin/.NET.NET Framework 4.5.1 and above
since 2.38.0$(MVIMPACT_ACQUIRE_DIR)/bin/netstandard2.0.NET Framework 4.6.1 and above
.NET Core 2.0 and above
Mono 5.4 and above

Supported Compilers

Note
For additional details on supported platforms and releases also see here: Device And Operating System Support Across Released Versions

Windows®

The following compilers have been tested successfully with the Impact Acquire .NET API targeting the .NET Framework build on Windows:

  • Microsoft Visual Studio® 2008 2010, 2012, 2013, 2015, 2017 and 2019

The following compilers have been tested successfully with the Impact Acquire .NET API targeting the .NET Standard 2.0 build on Windows:

  • Microsoft Visual Studio® 2019

Linux

Note
Since version 2.40.0 all Linux packages are shipped with a .NET Standard 2.0 compatible version of Impact Acquire SDK.

With an installed version of the .NET Core SDK (see https://docs.microsoft.com/en-us/dotnet/core/install/linux) it is possible to build an application by calling from a directory containing the project file or solution of the project which should be compiled.

dotnet build
Note
Since the Mono project will eventually be superseded by .NET Core, .NET Standard and .NET 5.0 sooner or later we do NOT recommend developing a new Mono application today. Instead the .NET Standard / .NET Core API should be used if this is already an option (please check if all the APIs needed for your application are already available). Only if there are good reasons to go with Mono these days the following section is worth reading.

The following versions of Mono (http://www.mono-project.com) have been tested successfully with the Impact Acquire .NET API targeting the .NET Framework build on Linux:

  • 2.8.10.1

Building

  • Impact Acquire versions smaller than 2.38.0 did target the .NET framework 3.5 which was part of Visual Studio® 2008
  • Since version 2.38.0 Impact Acquire is shipped with 2 different versions of the .NET API

The first version of Microsoft Visual Studio® fully supporting .NET standard 2.0 is 2017. For new developments .NET standard is recommended, existing applications should be ported to use this version as well. No changes in the code are necessary. Only existing references to the Impact Acquire assemblies must be updated to the .NET Standard version and of course the application itself must be ported to target the .NET Standard. This provides a couple of advantages regarding platform independence as this e.g. allows to develop .NET Core applications as well as various other things. Please refer to the corresponding documentation throughout the Internet for additional information and how you can benefit from a migration to .NET Core / Standard.

The Impact Acquire .NET interface can be used with all its functionality when targeting at least the same version of the .NET framework as the one used for building the Impact Acquire .NET binaries.

When the .NET runtime version the application will be compiled against is known only the code that is suitable for that runtime version can be used of course or in order to be compatible with most version of the .NET runtime only the stuff that does not require a certain version of the runtime can be used as well.

The full Impact Acquire .NET interface currently consists of 4 assemblies:

  • mv.impact.acquire.dll (The main assembly providing the Impact Acquire SDK interface)
  • mv.impact.acquire.display.dll (Contains functions to display arbitrary image data either in an existing GUI component or in a window created by the assembly)(Windows only!)
  • mv.impact.acquire.display.extensions.dll (Contains convenience functions to display image data using the internal Impact Acquire format)(Windows only!)
  • mv.impact.acquire.examples.helper.dll (Contains convenience functions used by most of the example applications. Some of these might also be interesting for other applications)

Windows®

No special knowledge regarding the Impact Acquire .NET interface is required to compile and link .NET applications using the Impact Acquire interface. Everything just works the way it does when using any other vendor's assemblies.

For reasons mentioned above when creating a new .NET library in your application we recommend to target the .NET Standard and NOT .NET Core if possible:

Note
After the project has been created it is not possible to switch between .NET Core and .NET Standard from the IDE even though in the project file this is possible very easily by changing the value of the TargetFramework property e.g. from
<TargetFramework>netcoreapp3.1</TargetFramework>

to

<TargetFramework>netstandard2.0</TargetFramework>

For applications (*.exe) this choice doesn't exist. But when targeting the .NET Standard with all your libraries you can build applications either targeting the .NET Framework or .NET Core while when targeting .NET Core in your libraries your applications will be bound to use .NET Core as well.

Linux

On Linux all the data types belonging to the namespace mv.impact.acquire.display will currently not be available. This is because the underlying native code modules dealing with the displaying of image data are not available on Linux.

Note
Since the Mono project will eventually be superseded by .NET Core, .NET Standard and .NET 5.0 sooner or later we do NOT recommend developing a new Mono application today. Instead the .NET Standard / .NET Core API should be used if this is already an option (please check if all the APIs needed for your application are already available). Only if there are good reasons to go with Mono these days the following section is worth reading.

Building The Examples Using The Mono Command-Line Compiler gmcs

You may build the sample applications on a Linux PC with Mono already installed by specifying the path to the mv.impact.acquire assembly.

Assuming the current directory contains the source files for the applications, you can build them like this:

gmcs CaptureToUserMemory.cs UserSuppliedMemory.cs -lib:/usr/lib/mono/mv.impact.acquire/ \
  -r:mv.impact.acquire \
  -out:CaptureToUserMemory-no-display.exe

gmcs SingleCapture.cs -lib:/usr/lib/mono/mv.impact.acquire/ \
  -r:mv.impact.acquire \
  -out:SingleCapture-no-display.exe

gmcs ContinuousCapture.cs  -lib:/usr/lib/mono/mv.impact.acquire/ \
  -r:mv.impact.acquire \
  -out:ContinuousCapture-no-display.exe
  • MSBuild like files (e.g. *.csproj) can also be build on Linux using xbuild.
  • IDEs for developing Mono application are available. See MonoDevelop for example.
  • When developing applications using Microsoft Visual Studio® on Windows the Mono Migration Analyzer (MoMA) can be used to track down compatibility issues. This can get interesting if an application compiled on Windows is deployed on a Linux System(This IS possible and works pretty well!)

mvBlueGEMINI

In fact, it is possible to build the sample applications directly on a mvBlueGEMINI camera that already has Mono and mvimpact-acquire-dotnet IPKs installed. However if all the required IPKs just mentioned are installed on the device it is also possible to develop an application solely on Windows using Microsoft Visual Studio® as mentioned above and then copy the binary files of this application onto a mvBlueGEMINI device. The same of course applies to an application compiled on any Linux system. .NET / Mono applications are binary compatible!

Running

To run an application that has been built using the Impact Acquire framework all native user mode libraries belonging to the framework must be located in the library search path of the application using it. The minimal list of libraries that must be present when working with the Impact Acquire .NET framework consists of

  • mv.impact.acquire.dll
  • mvDeviceManager-lib
  • mvImageProcessing-lib
  • mvPropHandling-lib
  • at least one device specific Impact Acquire library(e.g. mvBlueFOX-lib, mvGenTLConsumer-lib, ...)
  • at least one device specific device driver(IF the driver comes with a device driver(mvVirtualDevice-lib for example doesn't))

So with 4 libraries only a .NET application using the mvVirtualDevice can be developed.

Note
Whenever the postfix -lib is used in this list, this refers to the platforms native extension for shared libraries, thus e.g. to mvPropHandling.dll on Windows, to libmvPropHandling.so on Linux and to libmvPropHandling.dylib on macOS.

A detailed list of the files and settings needed to deploy an Impact Acquire device driver can be found in the chapter Installation From Private Setup Routines.

The native libraries will automatically be loaded by the Impact Acquire .NET assemblies when needed. In addition to that the Impact Acquire .NET assemblies used by the application (at least mv.impact.acquire.dll, maybe mv.impact.acquire.display.dll and mv.impact.acquire.display.extensions.dll) must be present as well.

Windows®

When an application that has been developed for Windows shall be deployed on a target system please refer to Installation From Private Setup Routines to find out which files must be copied onto the target system.

Linux Using "dotnet run"

Note
Since version 2.40.0 all Linux packages are shipped with a .NET Core compatible version of Impact Acquire SDK.

On Linux PCs, with an installed .NET Core SDK it will be sufficient to run use the dotnet binary within a directory containing a .NET solution or project file.

dotnet run

Linux Using Mono

On Linux PCs, depending on the way your distribution is set up, you may have to use the Mono command to run the applications. E.g.

mono ./ContinuousCapture-no-display.exe

Please read here for more information.

Setting Up The Environment

  • To allow the Impact Acquire .NET assemblies to dynamically load native libraries and drivers that are needed to operate Impact Acquire compliant devices under Mono it is crucial, that these native libraries can be located in the systems search path. Alternatively LD_LIBRARY_PATH can be set to point to the required libraries as well. Please have a look here for more information and here for troubleshooting.
  • When debugging an application setting the environment variable MONO_LOG_LEVEL might be of help. Here you can find additional information.
  • Consider using the built-in profiler for your development, which is invoked like this: mono –profile=log program.exe.

mvBlueGEMINI

On the mvBlueGEMINI you can execute Mono or .NET applications directly e.g.

./ContinuousCapture-no-display.exe 
[0]: MS000208(mvBlueGEMINI-1013C, family: mvBlueGEMINI)
[1]: VD000001(VirtualDevice, family: mvVirtualDevice)
[2]: VD000002(VirtualDevice, family: mvVirtualDevice)
Please enter the number in front of the listed device followed by [ENTER] to open it: 
...

Also modifying the library search path of the system is not required.