Project folders and files¶

All data belonging to an application are stored in a Viper.NET project folder. This folder normally has the following structure:

File/Folder	Description
Project.makproj	The project file. Can be started directly.
Configuration	Folder with configuration files that are normally only changed during the first setup of the project.
Data	Default data folder for the project. The folder path is configurable as paramsDirectory
Plugins	Project-specific plug-ins can be stored here.
Doc (optional)	Project-specific documentation.

Projects are designed so that all file paths of project-internal dependencies are relative to the makproj project file. Thus, project folders can be stored and moved arbitrarily in the file system.

Hint

The recommended default location for project folders is C:\Gefasoft.

New projects are derived by the Viper.NET installation from ProjectTemplates. The templates to the standard files are located in the ProjectTemplates subfolder of the Viper.NET installation. For example under C:\Program Files\Gefasoft\GEFASOFT Viper.NET 6.4.3.0\ProjectTemplates\

The project file “.makproj”¶

A project file with suffix .makproj is the central entry point for Viper.NET projects. All project-related files are searched relative to it. Double-clicking a project file in Windows Explorer starts Viper.NET in the version assigned to the project. In the context menu of the explorer two actions are offered:

Upgrade project version: Upgrades the project to a newer version of Viper.NET.
Start with “-repair “: Forces a autoinstall which updates the dependencies of the Viper.NET version in the system.

The .makproj project file defines basic settings of the project in XML format. For example, it defines subdirectories and paths of the other project files.

<dataStore guid="81f2f63a-9ffa-4313-ae3f-39dc2a7e8a4a" name="GConfiguration" architecture="MSIL" Version="6.4.3.0">
<param name="applicationName" value="Vision_Gefasoft" />
<!-- ... Allgemeine Projekt-Parameter -->
<childStores>
  <!--
    Hier werden die globalen Parameter der aktiven Plugins jeweils in ihrem
    eigenen "Child-Store" gespeichert.
  -->
<childStores>
  <complex name="supportedLanguages">
  <ArrayOfString xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <string>en-US</string>
    <!-- ... Weitere unterstütze Sprachen -->
  </ArrayOfString>
</complex>
<complex name="environmentVariables">
  <ArrayOfEnvironmentVariableData xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <EnvironmentVariableData>
      <Name>GEFASOFT_REFERENCE_TOOLBLOCKS</Name>
      <Value>$paramsDirectory$\ReferenceToolblocks</Value>
    </EnvironmentVariableData>
    <!-- ... weitere Umgebungsvariablen -->
  </ArrayOfEnvironmentVariableData>
</complex>

The project file contains a set of common parameters that are specified as name-value pairs in the format <param name="..." value="..." />. They are initialized with default or user values during project creation. The following parameters are available:

applicationName: Freely selectable project name, assigned when creating the project. The project name is displayed in the sidebar.
autoCreateParamsFile: specifies whether the GlobalParams file should be automatically recreated if it is not found.
autoInstall: obsolete parameter, no longer used.
autoLogoutMinutes: Time in minutes after which a user is automatically logged out if there was no user interaction within the time period.
autoLogoutSkipOnSuperDongle: True disables automatic user logout if a superdongle is attached to the system.
batOnAutoLogout: Path to a batch script (relative to .makproj), which is additionally executed in case of an auto logout.
callConfigCheckerOnStartup: True enables configuration checking at program startup.
conStreamTelPoolFile: Name of the XML configuration file for Stream-Connections, relative to the Data subfolder
defaultCommandLine: command-line arguments for Viper.NET to use when starting automatically, for example when opening the project by double-clicking in Explorer.
extAppLayoutChildsConfig: for backward compatibility, must not be used in new projects. Instead, should be configured in the UserTabs of type ControlLayoutExtApps. The option can specify the path to an extAppLayoutChild.xml with an extAppTabs configuration. The configured tabs are then displayed in the Vision tab when the Vision plugin is active.
extAppTabsConfig: Specifies the path to the ExtAppTabs configuration
gioPlcSecurityUserManagerXml:
gioTypeDataManagersXml:
gioTypeDataManagerXml:
ioIni: Path to Viper.xio, relative to the project directory.
log4net: Path of log configuration, relative to the project folder
parametersFile: Path to the global parameters, relative to the paramsDirectory
paramsDirectory: Directory path for parameter data, relative to the project directory. Default is the subfolder Data
persistentData: Filename of the XML file containing persistentdata, relative to the paramsDirectory
pluginConfig: Path to plugin-configuration, relative to the project directory
pluginsIgnoreUncriticalChange: True suppresses the plugin configuration dialog if detected differences between installed and configured plugins are insignificant. This includes plugins that are detected as newly installed or uninstalled, but are not active in the project configuration.
projectNumber: Project number for identification, displayed in the sidebar.
saveVersionConfiguration: Path of save-version-configuration file, relative to the project directory
screenshotWidgetVisible: Controls the visibility of the screenshot button in the function-panel. This can be used to free up space for other widgets.
shellConfiguration: Path of shell-configuration to customize the main interface. The path refers to the project directory.
shellType: Can be used to use an alternate shell interface from a plugin instead of the default interface. Specifies the type name of the shell form.
stationConfiguration: Path to station-configuration, referring to the project folder.
userAuthXml: Path of userTabs.xml, relative to the project folder.
userTabsConfig: Path of the user-tabs configuration file, relative to the project folder.

Configuration folder¶

The subdirectory Configuration of a Viper.NET project folder contains configuration data that is human readable and editable. The settings mostly concern the basic structure of a project and are therefore usually only edited initially during project creation.

When a new project is created, the folder is populated with copies of a project-templates.

stations.xml¶

Stations must initially be created in stations.xml. The configuration differs depending on the station type and is therefore described in their documentation.

Additionally the following elements can be defined in the stations.xml:

LiveBitsToggler: Cyclic state change of one or more bits. Can be used to signal to a PLC that Viper.NET is active and running.

<stationConfig>

  <liveBitsToggler cyleTimeMs="500">
    <bit id="1"/>
    <!-- <bit id="2"/> -->
  </liveBitsToggler>

  ...

Note

The LiveBitsToggler is especially recommended when using I/O couplers such as Modbus-coupler that buffer the state of digital inputs and outputs.

ResetBits: One or more bits that the PLC can use to trigger a reset of all stations. Alternatively, a reset bit can be defined for each station.

<stationConfig resetBits="10,11,12">
  ...

Log configuration - log4net.config¶

The configuration file of the logging system defines which log contents are written to which files and log displays. The file path can be set in the project-file.

shellConfiguration.xml¶

The shell configuration file shellConfiguration.xml specifies the appearance of the main interface. The file path is specified in the project-file.

In the configuration file, for example, the display colors and the logo of the sidebar can be customized. The configuration is done in XML format. The file template contains explanatory comments about the configuration options.

userTabs.xml¶

The tab configuration file userTabs.xml together with the extAppTabs.xml defines the display of tabs in the sidebar of a project. In the userTabs.xml all tabs are configured, which are provided by Viper.NET or its plugins. The extAppTabs.xml defines tabs for the integration of external applications into the project interface.

The file describes the displayed tabs as a list. Each tab is described by an XML account. For example, the vision tab:

<tab name="#Vision" type="VisionTab">
  <param name="operation" value="MainForm.Tabs.Vision"/>
  <param name="sortId" value="0" />
</tab>

The name of the tab is used for identification. The type of the tab defines the interface displayed when the tab is clicked. The following types are available by default in Viper.NET:

StationsIO: station-view with visualization of the current bit-states
HardwareExplorer: displays the GInOut Hardware-Explorer
ControlLayoutExtApps: Integrates interfaces of external programs as tabs in Viper.NET. The programs and the interface layout are configured in extAppLayoutChilds.xml files.
GAppenderLog or synonymously Log: displays the Log view

This list can be extended by active plugins. For example, the Vision plugin implements additional tabs.

The display order of the tabs in the sidebar is controlled by the param node with name attribute "sortID": the tabs are arranged from top to bottom according to the value attribute of the sortID in ascending sort order

The user tabs are linked in the configuration by the param node with name attribute "operation" to operations from the user-management: The permission of the logged-in user for the respective operation controls whether the user can switch to the respective tab.

extAppTabs.xml¶

In the extAppTabs.xml Sidebar-Tabs are defined, which are used to display external applications within the project. When the project is loaded, the associated external applications are launched and their main windows are integrated into the Viper.NET interface. The path of the configuration file can be customized in the project-file.

The project template contains a template with commented out example template which embeds the Windows editor as a tab. Comments in the template explain the meaning of the individual parameters.

userTabs.xml¶

The userAuth.xml defines in XML format the basics of user-management. Changes should only be made via the Viper.NET GUI.

Data folder¶

The Data folder serves as a storage location for configuration data created or customized in the Viper.NET interface. Manual changes to the data are usually not necessary.

When a new project is created, the folder is populated with copies of a projkettemplates.

globalParams.xml¶

The globalParams.xml file stores global program parameters. For example, the global-settings are usually stored here, both by Viper.NET and by all plugins. Included parameters should normally only be edited via the Viper.NET GUI.

The file path can be adjusted in the project-file if needed.

persistentData.xml¶

The persistentData.xml file serves as a centralized repository for Viper.NET and its plugins to store application state data across application launches. For example, the last loaded type of vision-plugin is stored here to be reloaded at application startup. The file should not be edited manually.

Plugins¶

The plugins.xml contains the plugin configuration of a project. All installed plugins of the computer are recorded with their respective version, as well as which of them are active and in which order they are loaded when starting the project.

The settings should preferably be adjusted via the Viper.NET GUI, for example in the info-dialog.

When loading a project, the Viper.NET installation is checked for changes in the plugin configuration. If such are detected, the user will be prompted to confirm or correct the configuration.

In the project-file both this check behavior and the path of the configuration file can be adjusted.

Plugins” folder (optional)¶

The Plugins subfolder of a project directory is the default location for deploying project-specific plugins. Viper.NET scans the folder for plugin dlls at project start and adds the folder as assembly directory. Via command-line parameter the path can be overridden to use a different folder as project plugin directory.