Skyline.DataMiner.CICD.DMProtocol 6.6.1

Skyline.DataMiner.CICD.Packages

About

About Skyline.DataMiner.CICD.Packages packages

Skyline.DataMiner.CICD.Packages packages are NuGet packages available in the public nuget store that contain assemblies that enhance the CICD experience.

The following packages are available:

• Skyline.DataMiner.CICD.DMApp.Automation
• Skyline.DataMiner.CICD.DMApp.Common
• Skyline.DataMiner.CICD.DMApp.Dashboard
• Skyline.DataMiner.CICD.DMApp.Visio
• Skyline.DataMiner.CICD.DMProtocol

Depending on the chosen NuGet, these libraries will provide the ability to easily convert from a DIS-provided Visual Studio Solution of your chosen type into either a .dmapp or .dmprotocol file. These files can then be installed on a DataMiner system.

About DataMiner

DataMiner is a transformational platform that provides vendor-independent control and monitoring of devices and services. Out of the box and by design, it addresses key challenges such as security, complexity, multi-cloud, and much more. It has a pronounced open architecture and powerful capabilities enabling users to evolve easily and continuously.

The foundation of DataMiner is its powerful and versatile data acquisition and control layer. With DataMiner, there are no restrictions to what data users can access. Data sources may reside on premises, in the cloud, or in a hybrid setup.

A unique catalog of 7000+ connectors already exist. In addition, you can leverage DataMiner Development Packages to build you own connectors (also known as "protocols" or "drivers").

Note See also: About DataMiner

About Skyline Communications

At Skyline Communications, we deal in world-class solutions that are deployed by leading companies around the globe. Check out our proven track record and see how we make our customers' lives easier by empowering them to take their operations to the next level.

Getting Started

Build-only dependencies

When a selected NuGet package has no compatible managed library, reference, or runtime assemblies, discarded versions of that package do not contribute directory hints, script references, or assembly payload. This includes build/analyzer-only packages and placeholder-only asset groups. Selected transitive runtime dependencies are still processed normally.

This correction preserves the existing version-selection policy and legacy directory hints for assembly-bearing packages, including packages with compatible ref or RID-specific managed runtime assets. It does not unify assemblies across an entire application package. Unreadable package metadata remains an error, not an empty-asset result.

Regenerate previously created application packages with corrected tooling; updating the tooling alone does not repair existing script XML.

Referenced C# libraries

Automation scripts and GQI ad hoc data sources can reference ordinary C# library projects, including legacy .NET Framework projects. Their built DLLs are included in the generated script imports and application package, and their NuGet dependencies participate in resolution, including solution-runner dependency grouping. Automation script-library references continue to use scriptRef.

Build referenced libraries before packaging. Harvesting uses the active build configuration and the nearest compatible target framework, including conditional and transitive project references. Missing outputs or incompatible frameworks fail packaging explicitly. Cyclic references are visited once, and excessive reference depth produces an error rather than incomplete output.

Harvested DLL import identities use the library's package ID, built assembly version, target framework, and assembly filename. Build-only package filtering does not discard these project DLLs.

The code is loosely based on the Builder design pattern. You can create a builder object using one of the provided static Factory classes:

var builder = await ProtocolPackageCreator.Factory.FromRepositoryAsync(logCollector, repositoryPath);
var builder = AppPackageCreatorForVisio.Factory.FromRepository(logCollector, repositoryPath, packageName, packageVersion);
var builder = AppPackageCreatorForDashboard.Factory.FromRepository(logCollector, repositoryPath, packageName, packageVersion);
var builder = AppPackageCreatorForAutomation.Factory.FromRepository(logCollector, repositoryPath, packageName, packageVersion);

In most cases you don't need to add or configure additional things to the builders, they will contain all necessary information. To actually create the .dmapp or .dmprotocol on your system you can call:

await builder.CreateAsync(destinationFolder, packageFileName);

There is also an option to create the package in memory and return the byte array.

byte[] package = builder.CreateAsync():

And lastly there is also an option to return an IAppPackage object that represents the package, allowing validation of all assemblies, scripts, ... before creating the .dmapp file.

var package = await creator.BuildPackageAsync();
package.CreatePackage(destinationFilePath);

Complete Example:

ILogCollector logCollector = new LogCollector();
string repositoryPath = @"C:\GITHUB\SLC-AS-EmpowerDemo1Room0";
string packageName = "EmpowerDemo1Room0";
var packageVersion = DMAppVersion.FromProtocolVersion("1.0.0.1");
string destinationFolder = @"C:\MyPackages\"
string packageFileName = "EmpowerDemo1Room0.dmapp";

var builder = AppPackageCreatorForAutomation.Factory.FromRepository(logCollector, repositoryPath, packageName, packageVersion);
await builder.CreateAsync(destinationFolder, packageFileName);

Advanced Usage

You can also use these libraries, combined with the Skyline.DataMiner.Core.AppPackageCreator NuGet to create advanced packages containing multiple scripts, connectors, visio's, dashboards or other files.

Start by creating a new AppPackageBuilder

var appPackageBuilder = new AppPackage.AppPackageBuilder(PackageName, PackageVersion.ToString(), GlobalDefaults.MinimumSupportDataMinerVersionForDMApp);

You can now create one or more of the builders as shown in [Getting Started](### Getting Started)

Those builders can then be asked to add their contents to your appPackageBuilder like so:

builder.AddItemsAsync(appPackageBuilder);

You can also add other things to the appPackageBuilder itself at this point. Like additional files or other artifacts.

Once you've added all items from the individual builders to the appPackageBuilder you can create an object representing your complete package. This allows for final validation if needed.

var appPackage = appPackageBuilder.Build();

You can now create the .dmapp file.

package.CreatePackage(destinationFilePath);

Complete Example:

string packageName = "EmpowerDemoRoom0";
string destinationFilePath = @"C:\MyPackages\EmpowerDemoRoom0.dmapp";
var packageVersion = DMAppVersion.FromProtocolVersion("1.0.0.1");
ILogCollector logCollector = new LogCollector();

string repositoryPath1 = @"C:\GITHUB\SLC-AS-EmpowerDemo1Room0";
string childPackageName1 = "EmpowerDemo1Room0.dmapp";
string repositoryPath2 = @"C:\GITHUB\SLC-AS-EmpowerDemo2Room0";
string childPackageName2 = "EmpowerDemo2Room0.dmapp";

var appPackageBuilder = new AppPackage.AppPackageBuilder(packageName, packageVersion.ToString(), GlobalDefaults.MinimumSupportDataMinerVersionForDMApp);
var builder1 = AppPackageCreatorForAutomation.Factory.FromRepository(logCollector, repositoryPath1, childPackageName1, packageVersion);
var builder2 = AppPackageCreatorForAutomation.Factory.FromRepository(logCollector, repositoryPath2, childPackageName2, packageVersion);
builder1.AddItemsAsync(appPackageBuilder);
builder2.AddItemsAsync(appPackageBuilder);

var appPackage = appPackageBuilder.Build();
package.CreatePackage(destinationFilePath);

Scripted connectors (Skyline.DataMiner.CICD.DMProtocol)

Besides the regular protocol package contents (Protocol.xml, help files, Visio drawings, alarm/trending/information templates, ...), Skyline.DataMiner.CICD.DMProtocol also resolves and embeds scripted connector ("script") projects declared in the protocol solution. A scripted connector is never authored or distributed on its own — it is always a "script project" living inside a protocol solution. Discovery and validation of script projects (parsing manifest.json) is handled by Skyline.DataMiner.CICD.Assemblers.Protocol; DMProtocol resolves each script's Python dependencies via pip and embeds the resulting wheels into the built .dmprotocol package.

The dependency-resolution logic is a C# port of the reference implementation available at PythonScriptedConnectorWheelsResolver.

Source directory layout

A script project lives in a folder at the root of the protocol solution (a sibling of the existing Dlls/ and QAction_{n}/ folders). The folder name is chosen freely by the developer — it is not significant. The script project folder is instead identified by its content: it must contain a .pyproj file (the Visual Studio Python Tools project file) and a manifest.json. The matching folder for a given <Script> declaration is found by its manifest.json's project.id, which must match the guid attribute of a <Script id="..." guid="..."> declared under <Protocol><Edge><Scripts> in protocol.xml:

MyProtocolSolution/
├── protocol.xml
├── Dlls/
├── QAction_1/
└── ConnectorScript_1/                (folder name is arbitrary, e.g. assigned by Visual Studio)
    ├── ConnectorScript_1.pyproj   (Visual Studio Python Tools project file, not packaged)
    ├── requirements.txt              (direct dependencies only, no transitive dependencies; not packaged)
    ├── manifest.json
    ├── README.md                     (optional, copied as-is into the package)
    ├── run/
    │   └── main.py                   (or whichever file 'runtime.python.entry_point' declares)
    └── Tests/                        (not packaged)

Packaging is opt-in: only manifest.json, an optional README.md, and the full contents of run/ are copied into the built package's Scripts/{guid}/ folder, alongside the resolved dependencies/. Everything else in the project folder (requirements.txt, the .pyproj file, Tests/, and any other development-only content) is left out of the package.

manifest.json schema (see Edge Node "Scripted Connector Packaging" documentation for the authoritative description):

Dependency resolution and platform-specific wheel selection

requirements.txt must only list the connector's direct dependencies (not their transitive dependencies). This maximizes the chance of finding a wheel set that is valid for both Windows and Linux.

For each declared dependency (and its transitive dependencies, resolved by pip), wheels are downloaded separately for:

• Windows (win_amd64 platform tag).
• Linux (manylinux2014_x86_64, then manylinux_2_17_x86_64 through the latest known manylinux_2_<x>_x86_64 tag — the tool queries the GNU glibc mirror to determine the latest available glibc 2.X version, falling back to a hardcoded version if that lookup fails).

Once downloaded, wheels are post-processed and organized into the script project's Scripts/{guid}/dependencies/ folder within the built .dmprotocol package:

• Wheels that are identical on both platforms are moved to dependencies/universal/.
• If one platform only has a platform-specific wheel for a package, but the other platform has a universal (py3-none-any) wheel for the same package/version, the platform-specific wheel is dropped in favor of the (now shared) universal wheel — this reduces overall package size, since a universal wheel only needs to be shipped once.
• Remaining platform-specific wheels stay in dependencies/x86_64-windows-msvc/ or dependencies/x86_64-linux-gnu/ respectively.

This requires a working pip installation on the machine performing the resolution (python -m pip, python3 -m pip, pip3 or pip, tried in that order on PATH) — the same requirement as the original Python reference implementation.

Validation and exceptions

• RequirementsNotFoundException — a declared script's requirements.txt does not exist.
• ConflictingDependenciesException — pip detected conflicting dependencies during a dry-run install; the pip standard output/error are available on the exception for diagnostics.
• PipNotFoundException — no working pip invocation could be found on the current system.
• InvalidManifestException — a declared script's manifest.json is missing, malformed, fails schema validation (missing required fields, an empty runtime.supported_platforms list, or an entry_point that is rooted/absolute or contains ./.. path segments), its declared entry point is not located under run/ (only run/ is included when the package is built), or its declared entry point file does not exist, or no run/ folder exists at all. A ParserException is raised instead (from Assemblers.Protocol) if no script project folder (a .pyproj file alongside a manifest.json) at the solution root has a manifest.json whose project.id matches the guid declared for a <Script id="..." guid="..."> in protocol.xml, or if more than one folder's manifest matches the same guid.

A warning (not an exception) is reported through the supplied ILogCollector if a platform declared in runtime.supported_platforms could not be resolved at all (e.g. no compatible wheel exists for that platform for one of the requirements).