Creating an installer for a CVB C# project


What is the best way to create an installer for a C# CVB project using a combination of .DLLs and ActiveX. This project uses minos, polimago and foundation. The customer will deploy this software via the installer on a Windows 7 64 bit PLC. CVB obviously works on the PLC as this is what I have prototyped the system on, which currently has the full CVB distribution installed. The customer is adamant to create a installer which just includes the runtime rather than the full version as SSD space is limited on the PLC which already runs a file datastore.

I have created and distributed applications before but never with CVB.

Before I spend anytime on this I would be interested in hearing the most efficient route.

Hi @BBQRibs!

That’s not really easy to answer, as the best approach is usually dependent on the circumstances. Luckily there are only two basic options, so I’ll just describe both of them to you - you can then pick which of them is the best for your scenario :slightly_smiling_face:

Option 1: Use the Runtime Installers silently

In terms of implementation, this is by far the simpler choice, but it’s also less flexible than the alternative described further down.

Since version 10.2 we always provide runtime setups for :cvb:. Runtime setups contain everything that is installed with the “full” installer, minus the tutorials, sample images or videos, API documentation and header/wrapper files (in other words: the runtime setups contain everything that comes with the “full” installer except for those files that we think are only needed for development).

Since version 11.0 the runtime installer comes in two flavors, “regular” and “CameraSuite”: The “regular” version comes with the DLLs and ActiveX controls of all the tools in :cvb:, whereas the “CameraSuite” version only contains what is covered by the CameraSuite license (basically all the components of the Image Manager, including the GenICam infrastructure).

You will find these installers in the Windows entries of the #downloads topic (there are links to the sections with each installer flavor at the top of each page). Typically the runtime installers are significantly smaller than the “full” versions.

Regardless of the precise version you are looking at, each of these installers is technically just an MSI setup database wrapped in an executable that bundles it with whatever prerequisites (CodeMeter Runtime, potentially specific .Net Framework version) the selected version of :cvb: needs. And as such, it is possible with each of the installers to invoke it from the command line and run it silently (please note that even in silent mode up to two dialogs may prompt the user to confirm the installation of a system driver).

Each setup accepts the same command line parameters. The full set of available parameters may be conjured up by calling the setup with the parameter /?. The two that are relevant for silent invocation are

Parameter Effect
/s runs the encapsulating setup.exe silently (including all the bundled prerequisite installers)
/v"STRING" passes STRING to the msiexec call that installs the MSI package

The second one is particularly useful. STRING may be any command line that msiexec understands and accepts, allowing you to customize the installation to a certain degree. The most relevant command line parameters in our context are (the full list of all parameters is available here):

Parameter Effect
/qn have msiexec run completely without user interface (i. e. skip the User Interface sequence in the database and run only the Execute sequence)
/qb, /qb!, /qb+, /qb- have msiexec with one of several possible reduced user interfaces (i. e. skip the User Interface sequence in the database and run only the Execute sequence, but show a minimal UI (progress bar) with (/qb) or without (/qb!) a cancel button and with (/qb+) or without (/qb-) a modal dialog box at the end (you may combine ! with + or - if needed)
/Lx FILENAME generate a log file FILENAME during the installation; x may be a selection of [i|w|e|a|r|u|c|m|o|p|v|x|+|!|*], selecting what events to be logged, see here for details; in case of problems you should at least specify m here, * generates a full log of several megabytes

On top of those parameters you can set installer property values on the command line. For example specifying a custom value for INSTALLDIR you’ll be able to install to a non-default location.

Example: Suppose you want to silently install the :cvb: CameraSuite runtime package version 13.00.005 on 64 bit to a directory of your choice and generate a log file while doing so, your command line would be:

"CommonVisionBlox CameraSuite Runtime 13.00.005 (x64).exe" /s /v"/L*v C:\cvbsetup.log /qn INSTALLDIR=C:\MyCVB"

mind the quotation marks…

BTW: On the download pages for Linux you will not find a separate runtime installer package. However, in the downloadable *.zip archives you will find several *.deb packages from which you may choose what fileset to install:

Package Fileset
cvb-camerasuite-<version>-<platform>.deb corresponds to a CameraSuite Runtime installer on Windows
cvb-camerasuite-dev-<version>-<platform>.deb together with the cvb-camerasuite-<version>-<platform>.deb package this corresponds to a CameraSuite installer on Windows
cvb-tools-<version>-<platform>.deb together with the cvb-camerasuite-<version>-<platform>.deb package, this corresponds to a Runtime installer on Windows
cvb-tools-dev-<version>-<platform>.deb together with the three aforementioned packages this corresponds to a “full” installer on Windows

Option 2: Build a Custom Installer

This approach is a lot more flexible and it makes :cvb: less visible on the target system - however it is also fairly demanding and requires a significant maintenance effort.

Background: The :cvb: installers are MSI setup databases that have been authored with the tool InstallShield. For bigger MSI databases it is a common approach to split them up into separate so-called merge modules (MSM) from which a setup authoring tool can then build an MSI setup. You can think of MSM files like library files in regular programming - you can link them to make use of what is contained in them (with the subtle difference that linking an MSM file always imports everything contained in the MSM file).

For the :cvb: installers we have taken the same approach: For each architecture (Win32 and x64) we have generated a set of MSM files (depending on the version between 5 and 7 packages with the necessary runtime files, plus one MSM file per tool with the development resources like tutorials, headers, API documentation, sample images, …) from which we assemble the four different installer flavors that are available per platform (full, CameraSuite, Runtime and CameraSuite Runtime).

In the past these MSM files have been shipped on the DVD, but currently they are only (but happily) available upon request (few people actually use/need these files…). Just send an E-Mail to support"at" if you want to give them a try (please include the precise version and the platform(s) you are interested in)…

One thing to be aware of is that when authoring your own installer, you will need to take care yourself that all the necessary runtime files (Visual C++ runtime, MFC, .Net Framework, CodeMeter Runtime, potentially Sentinel Dongle Driver) are available on the target machine after running your setup - either by running the respective installers or by including the respective MSM files in your installer. Of course the precise versions depend on the version of :cvb: that you’re installing - and overview can be found on the Redistributables download page, but some setup authoring tools are also capable of scanning for dependencies and adding them automatically. Node that some of these dependencies might only be available as a separate setup…

It should also be pointed out that not all setup authoring utilities are suitable for building an installer that encapsulates the :cvb: setup. For some of the installation steps, our MSMs rely on so-call installer custom actions that need to be invoked in the Execute sequence. However, not all utilities support editing the Execute sequence (for example Visual Studio doesn’t).

The custom actions from the :cvb: MSMs that should be invoked in the Execute sequence current (version are:

Custom Action MSM Placement Condition Comment
RemoveFilterDriverNG CVBGenICam after CostFinalize (REMOVE = "ALL") Or (REMOVE >< "CoreComponents") Or IS_MINOR_UPGRADE removes the siNetFilter.sys from the network stack during uninstall
DPUnInstU3V CVBU3V after RemoveExistingProducts (REMOVE = "ALL") Or (REMOVE >< "CoreComponents") Or IS_MINOR_UPGRADE removes the U3V camera class driver during uninstall
InstallFilterDriverNG_Step2 CVBGenICam after InstallFinalize Not REMOVE step 1 (sic!) of installing the siNetFilter.sys; call during install and upgrade
InstallFilterDriverNG_Step3 CVBGenICam after InstallFilterDriverNG_Step2 Not REMOVE step 2 (sic!) of installing the siNetFilter.sys, call during install and upgrade
DPInstU3V CVBU3V after InstallFinalize Not REMOVE installs the U3V camera class driver, call during install and upgrade

(note that older or newer versions may have different requirements; in case of doubt please contact support"at"


That’s basically it. Personally I think that in most cases calling the runtime installers silently is the way to go because it’s easiest to adopt and easiest to adapt to newer versions when necessary. The extra effort of authoring a custom setup is probably only warranted when targeting a system that is extremely tight on disc space.


Hi @illusive,

The detailed reply is very much appreciated - thank you. I think I will go with calling the runtime installer silently because of all the benefits described.