Skyline.DataMiner.CICD.DMProtocol 6.4.0

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);