Projekt, Manifest und Paket

Ein Modul besteht aus einer .NET-Klassenbibliothek und einer manifest.json. Seine Funktionen definieren Sie über Modulklassen, Actions, Trigger und UI-Bausteine.

Projektdatei konfigurieren

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <!-- net10.0 ist der Normalfall; net10.0-windows nur, wenn die COM-Verbindung genutzt wird -->
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BpNexT.Actions.Sdk" Version="*" />
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

  <ItemGroup>
    <None Include="manifest.json" CopyToOutputDirectory="PreserveNewest" />
  </ItemGroup>

</Project>

Version="*" übernimmt die jeweils verfügbare SDK-Version. Für reproduzierbare Builds können Sie eine konkrete, mit Ihrer Runtime kompatible Version festlegen.

Die Frameworkreferenz stellt unter anderem Logging- und DI-Typen bereit. Wenn Sie generierte COM-Datensatztypen wie Artikel verwenden, benötigen Sie zusätzlich die zur Runtime passende, separat bereitgestellte BpNexT.NET.Models.dll. Für eine Kopie im Projektordner lib ergänzen Sie:

<ItemGroup>
  <Reference Include="BpNexT.NET.Models">
    <HintPath>lib/BpNexT.NET.Models.dll</HintPath>
    <Private>false</Private>
  </Reference>
</ItemGroup>

Die Runtime stellt die Modellassembly zur Ausführung zentral bereit; Private=false verhindert das Kopieren als private Modulabhängigkeit. GraphQL-Datensatztypen stammen entsprechend aus BpNexT.NET.Models.GraphQL.dll.

Behalten Sie im Vorlagenprojekt den Build-Target zur Erzeugung des Debugprofils bei.

Verwenden Sie net10.0-windows für COM-Module mit IBpSession und net10.0 für plattformunabhängige GraphQL-Module mit IBpQlSession. Bestehende Module mit net8.0 oder net8.0-windows laufen unverändert weiter. Ändern Sie das Zielframework in Projektdatei und Manifest gemeinsam.

Manifest definieren

Die Datei manifest.json liegt neben der Projektdatei und enthält die Identität sowie die technischen Eckdaten des Moduls:

{
  "id": "meinefirma.lagerbuchung",
  "name": "Lagerbuchung",
  "version": "1.0.0",
  "author": "Meine Firma",
  "description": "Bucht Bestände in Lager ein.",
  "entryAssembly": "Meinefirma.Lagerbuchung.dll",
  "targetFramework": "net10.0"
}

Feld	Bedeutung
id	Dauerhafte Kennung im Format hersteller.modulname
name	Anzeigename in Studio und Portal. Muss ModuleName der Modulklasse entsprechen.
version	Paketversion. Muss ModuleVersion der Modulklasse entsprechen.
entryAssembly	Dateiname der gebauten Assembly.
targetFramework	Zielframework der Assembly.

Halten Sie Name und Version im Manifest und in der Modulklasse übereinstimmend. Erhöhen Sie bei einer Veröffentlichung die Version an beiden Stellen.

Behalten Sie die id bei Updates bei. Eine andere ID bezeichnet ein neues Modul.

Modulmetadaten im Code definieren

Definieren Sie die Metadaten der BpModule-Klasse als konstante Property-Overrides:

public sealed class LagerModule(
    IBpSession session,
    AutomationContext context,
    ILogger<LagerModule> logger) : BpModule
{
    public override string ModuleName => "Lagerbuchung";

    public override string ModuleVersion => "1.0.1";

    public override string ModuleAuthor => "Meine Firma";

    public override string ModuleDescription => "Bucht Bestände in Lager ein, zwischen Lagern um und aus Lagern aus.";
}

Modul mit F5 debuggen

Die Projektvorlage erzeugt beim ersten Build ein Launchprofil, das die installierte Runtime startet und das Projekt aus seinem Build-Ausgabeverzeichnis als Dev-Modul lädt. Ein entsprechendes Profil sieht so aus:

{
  "profiles": {
    "BpNexT.NET Runtime (debug this module)": {
      "commandName": "Executable",
      "executablePath": "C:/Program Files/BpNexT/Runtime/BpNexT.Runtime.Host.exe",
      "commandLineArgs": "run --dev-module \"C:/Projekte/Meinefirma.Lagerbuchung\"",
      "workingDirectory": "C:/Program Files/BpNexT/Runtime"
    }
  }
}

Studio zeigt das Entwicklungsmodul unter Pakete mit dem Kennzeichen dev.

Installationspaket erstellen

Erstellen Sie mit dotnet build -c Release einen Release-Build. Laden Sie die Moduldateien in Studio unter Builder hoch, erzeugen Sie das .bpnpkg-Paket und installieren Sie es unter Pakete in Studio.

Optionale .pdb-Dateien ergänzen Stacktraces um Dateinamen und Zeilennummern. Updates mit derselben Modul-ID ersetzen die vorherige Version; die Historie bleibt erhalten.

Ladeprüfungen verstehen

Prüfen Sie bei einem Ladefehler die Meldung in Studio. Häufige Ursachen sind:

Bereich	Prüfen
Metadaten	Stimmen Name und Version in Manifest und Modulklasse überein?
Action-IDs	Hat jede Action eine eigene ID?
Webhook-Namen	Sind die Namen eindeutig und ohne Großbuchstaben oder Leerzeichen?
Änderungstrigger	Sind [OnChanged] und ChangedSet<T> gemeinsam angegeben?
Dependency Injection	Passen die Lebensdauern der registrierten Dienste zusammen?
Lizenz	Ist für HTTP-Endpunkte das Addon Integrationen vorhanden?

Die letzten beiden Punkte sind ausführlicher beschrieben in Dependency Injection und Integrationen.