What’s new in DataMiner Integration Studio v2.39

What’s new in DataMiner Integration Studio v2.39

DIS version 2.39 is now available for download! This new version features multiple improvements, including the highlights presented below.

Not familiar yet with the DataMiner Integration Studio? You can learn all about it on the DIS expert hub.

No downloads found!

    For a complete overview of all changes in this new version, check the release notes.


    DataMiner DevPack NuGet Packages

    When working on protocols and Automation scripts, the QAction or Script C# projects need to reference some DataMiner DLLs.

    Up until now, DIS was first trying to reference DLLs, found under a local DataMiner installation folder. If no DataMiner installation was found on the local machine, DIS was falling back on a specific version of DataMiner DLLs, included in DIS itself. This means that if you wanted to develop a protocol or Automation script for a specific DataMiner version, you had no other option than to have the same DataMiner version installed locally.

    This has now been made a lot more flexible and coder friendly by allowing DIS to use so-called DataMiner DevPacks. DataMiner DevPacks are NuGet packages containing DataMiner DLLs. For each released version of DataMiner, there is a DataMiner DevPack version publicly available.

    This means that we can now very easily configure a solution to use a specific DevPack version and that switching from one version to another can be done conveniently, efficiently, and completely independently of your local DataMiner installation. This also means the DataMiner version is configured on solution level and no longer on user/developer level. Collaborating with multiple developers on the same solution, without having to worry about DataMiner versions, has thus been made highly straightforward.

    The DataMiner DevPacks can be found on the official public NuGet store https://www.nuget.org/.

    When opening a pre-existing protocol or Automation script solution that was not yet making use of DevPacks, a banner will be shown at the top. This banner will allow us to update the projects in order to use the new DataMiner DevPack NuGet packages. It will remove the references to the local DLLs and add the necessary NuGet packages.

    To be able to work with the DevPacks, a setting will need to be manually updated in Visual Studio. Under ‘Tools > Options -> NuGet Package Manager > General’, you will find the ‘Default package management format’. This needs to be set to PackageReference.

    For solutions that were already making use of NuGet packages but were using the old approach (packages.config), we’ll need to migrate each project to the new approach (PackageReference).

    This can be done by going to the Solution Explorer pane in Visual Studio, navigating to a project, right-clicking on “References” and selecting “Migrate packages.config to PackageReference…”. This needs to be repeated for all projects within a given solution.

    Note that these DataMiner DevPacks are not only applicable to protocols and Automation script solutions (!). They can also be used on custom solutions, functioning as API within protocols or Automation script solutions. The most common examples of this are the Class Library Community Packages. All these packages should now be updated to make use of the new DataMiner DevPacks as well, instead of referencing DataMiner DLLs added to the solution.

    NuGet Support – Improved Publishing

    Up until now, when pressing the publish button in DIS, it would take the protocol/Automation script XML and publish it on the DataMiner Agent.

    As a protocol/Automation script can use custom DLLs (e.g. through NuGet packages that are being used), the publishing has now been updated so that in the background a .dmprotocol package (for protocols) or .dmapp package (for Automation scripts) is created.

    This package is then installed on the Agent automatically during publishing, eliminating the need to manually put the required DLLs on the Agent. The .dmapp also gets removed again automatically.

    NuGet Support – Improved Saving

    Up until now, it was only possible to save a protocol/Automation script as an XML file. Now for protocols, you can choose to either save it as an XML or as a .dmprotocol package. With an Automation script, you can choose to save it as XML or a .dmapp package.

    The .dmprotocol/.dmapp package contains the protocol/Automation script alongside the required DLLs (e.g. DLLs of NuGet packages that are used in the protocol/Automation script).

    Improved DVE support

    When DVE(s) are defined in the protocol, a dropdown control is now being shown in the top left corner of the display editor.

    The developer can select one of the DVEs or the main control. After doing that, only the pages and parameters of this selected DVE are shown. The positions of parameters can now be adapted per DVE. ExportRule tags are automatically created to override things in the DVE.

    Main protocol
    DVE

    Improved MIB Browser

    The MIB browser now contains an internal list with the most common MIB files from IANA and IETF. These MIBs contain common definitions that are typically used by mode-specific vendor MIBs. This avoids users having to search for those MIBs themselves.

    Leave a Reply