App-Validierungs-Regeln

Dieser Artikel behandelt folgende Punkte:

App-Validierungs-Regeln Einführung
App-Validierungs-Regeln

App-Validierungs-Regeln Einführung

Bevor eine App validiert werden kann, muss sie verschiedene Tests durchlaufen. Diese Tests gewährleisten die Qualität, Leistung und Stabilität der ETS. Die Testergebnisse werden dem Entwickler mitgeteilt, wenn eine App-Version zur Validierung hochgeladen wird. (siehe App-Validierung)

Die Prüfungen sind in 2 verschiedene Schweregrade unterteilt:

Fehler: Diese Tests sind eindeutig. Jeder fehlgeschlagene Test verhindert automatisch die Validierung der App.

Warnung: Diese Tests deuten darauf hin, dass ein Verstoß gegen die Regeln vorliegen könnte. Die App muss manuell überprüft werden. Wenn eine solche manuelle Überprüfung ergibt, dass die Regel nicht verletzt wird, kann die App validiert werden. Andernfalls wird bei Verletzung der Regel die Validierung verweigert.

Da eine App zusätzliche Assemblies enthalten kann, wie z.B. eine Logging-Komponente oder eine Zip-Assembly, müssen die Prüfungen entsprechend angepasst werden. Einige Regeln, die von der App selbst strikt eingehalten werden müssen, können Warnungen für einige andere Assemblies sein. Während die App beispielsweise unter .NET Framework 4.0 kompiliert werden muss, können Komponenten von Drittanbietern unter anderen .NET Frameworks kompiliert werden. Andernfalls wäre die Nutzung von z.B. log4net überhaupt nicht möglich. Es ist aber auch keine Option, die Strenge der Regeln für zusätzliche Assemblies zu stark zu lockern, da es Entwickler einladen könnte, problematische Codes in diese zusätzlichen Assemblies auszulagern.

Die Lösung für dieses Problem besteht darin, die Assemblies in 2 Läufe aufzuteilen:

Alle Assemblies vom App-Entwickler selbst müssen der strengen Auslegung der Regeln folgen. Dadurch wird sichergestellt, dass die App selbst nach den strengen Regeln implementiert wird, ebenso wie jede Komponente desselben Entwicklers.

In einem zweiten Prüflauf werden alle Assemblies von Drittanbietern geprüft. Für diese Assemblies werden einige Regeln weniger streng geprüft, da der App-Entwickler kaum die Möglichkeit hat, die Implementierung dieser Assemblies zu beeinflussen. Die weniger streng gehandhabten Regeln werden als Warnungen gemeldet und müssen vor der Validierung manuell überprüft werden. Dennoch bleiben einige Regeln streng, z.B. ist die Nutzung des direkten Buszugangs in jedem Fall verboten.

Die Liste der Regeln, denen jede App folgen muss, ist unten aufgeführt. Darüber hinaus wird auch eine kurze Beschreibung gegeben, wie der Entwickler das Problem vermeiden oder lösen kann. Für beide Fälle wird der Schweregrad angegeben: Die strenge Version (App-Entwickler-Assemblies) und die weniger strenge Version (Drittentwickler-Assemblies)

Automatisch geprüfte Regeln

Starker Name fehlt
Mehr als ein ETS AddIn gefunden
Starten eines externen Prozesses
Verwendung von nicht verwaltetem Code
Verwendung verbotener KNX Assemblies
App-Instanz kann nicht erstellt werden
Erstellung App-Instanz zu langsam
Direkte Verbindung zu KNX-Bus
App-Datei zu groß
Englische Hilfe-Datei fehlt
.Net runtime zu alt
App hat keine Version
App-Attribut hat andere Version als in der Assembly-Version angegeben
Container muss gültige Manifestdatei enthalten
Container darf keine SDK-Assemblies enthalten
Verwendung einer nicht-offiziellen SDK-Version
SQL-Verbindung gefunden
Verwendung verdächtiger Namensräume gefunden
Sprachunterstützung in Englisch fehlt
Unerwartete App-ID
Ungültige DCA Hersteller-ID
DCAs können die UI-App-Funktion nicht verwenden
DCA muss x64 unterstützen
App verwendet Komponenten, die von der ETS5 in einer anderen Version verwendet werden
Die App-Assembly, wie im Attribut AddInAssembly in der Manifest-Datei angegeben, wurde nicht gefunden

ID	Name	Schwergrad für Entwickler	Schweregrad Drittentwickler	Beschreibung	Lösung
1	Starker Name fehlt	Fehler	Fehler	Jede .Net-Assembly innerhalb eines etsapp-Containers muss mit einem starken Namen versehen sein, um Zweideutigkeiten zu vermeiden.	Fügen Sie der Lösung einen Strong Name Key (snk-Datei) hinzu.
2	Mehr als ein ETS AddIn gefunden	Fehler	Fehler	Jeder etsapp-Container darf nur genau eine Klasse enthalten, die von IEts4App erbt und das System.App.AppAttribut hat, oder anders ausgedrückt: In jedem etsapp-Container darf es nur eine App geben.	Entfernen Sie alle anderen Klassen, die von IEts4App erben, aus der etsapp.
3	Starten eines externen Prozesses	Fehler	Fehler	Die App darf keinen externen Prozess starten	Code entfernen, der den externen Prozess startet.
4	Verwendung von nicht verwaltetem Code.	Warnung	Warnung	Die App verwendet Aufrufe an native Komponenten (DLLImport). Dies hat eine manuelle Überprüfung zur Folge.	Wenn die manuelle Überprüfung eine illegale Verwendung von nicht verwaltetem Code feststellt, entfernen Sie diese Verwendungen.
5	Verwendung verbotener KNX Assemblies	Fehler	Fehler	Verweise auf KNX-Komponenten sind nur zulässig, wenn sie zum SDK gehören, d.h. Knx.Ets.SDK., Knx.Ets.CommonTypes, Knx.Ets.CommonResources sind erlaubt. Knx.Ets.SDK., Knx.Ets.CommonTypes, Knx.Ets.CommonResources sind erlaubt. Alle anderen KNX-Verweise sind untersagt. Verweise auf das.Net-Framework oder eigene Assemblies sind erlaubt..	Entfernen Sie alle Verwendungen verbotener Namensräume.
6	App-Instanz kann nicht erstellt werden	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Beim Erstellen einer Instanz der App darf keine Ausnahme ausgelöst werden.	Beheben Sie das Problem, das die Ausnahme auslöst.
7	Erstellung der App-Instanz zu langsam	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Das Erstellen einer Instanz der App darf nicht länger als 5 Sekunden dauern. Dies soll die negativen Auswirkungen der App auf die Gesamtleistung von ETS5 begrenzen.	Identifizieren Sie den Grund für das Performance-Problem, ändern Sie die Implementierung, so dass die Instanz innerhalb von weniger als 5 Sekunden erstellt werden kann.
8	Direkte Verbindung mit KNX-Bus.	Fehler	Fehler	Falcon-Verbindungen sind nicht erlaubt. Keine App darf eine direkte Verbindung zum KNX-Bus herstellen.	Entfernen Sie alle Verwendungen des direkten Zugriffs auf den KNX-Bus.
9	App-Datei zu groß	Fehler	n.a. - Die Regel wird für die ETSApp geprüft, nicht für jede Assembly.	Die maximale Größe des etsapp-Containers beträgt 100 MB.	Lösung: Reduzieren Sie die Dateigröße, z.B. entfernen Sie zusätzliche Dateien wie PDF-Dokumente, Videos oder Bilder oder reduzieren Sie deren Größe.
10	Englische Hilfe-Datei fehlt	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly	Es muss mindestens eine englische kompilierte HTML-Hilfedatei (*.chm) zur Verfügung gestellt werden.	Fügen Sie eine englische kompilierten HTML-Hilfedatei zur etsapp hinzu.
11	.NET runtime zu alt	Fehler	Warnung	Alle Assemblies im etsapp-Container müssen mit .NET Runtime 4.0 erstellt werden. Ältere Versionen werden nicht unterstützt.	Erstellen Sie die App mit dem Ziel-Framework .NET Framework 4 neu.
12	App hat keine Version	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly	Die App muss eine Versionsnummer haben. Diese Version wird verwendet, um verfügbare Updates zu identifizieren und/oder den Aufwand bei Supportfällen zu minimieren.	Erstellten Sie die App mit einer bestimmten Dateiversion neu.
13	Das App-Attribut hat eine andere Version als in der Assembly-Version angegeben.	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly	Die App-Version und die Assembly-Version (App-DLL) müssen die gleiche Nummer haben. Diese Version wird verwendet, um verfügbare Updates zu identifizieren und/oder den Aufwand bei Supportfällen zu minimieren.	Erstellen Sie die App mit einer bestimmten Dateiversion oder Assembly-Version neu.
14	Der Container muss eine gültige Manifestdatei enthalten.	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Jeder ETS-App-Container muss eine gültige Manifestdatei enthalten.	Fügen Sie dem Container eine gültige Manifestdatei hinzu.
15	Der Container darf keine SDK-Assemblies enthalten.	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Der ETS-App-Container darf keine Assemblies aus der ETS-SDK enthalten.	Entfernen Sie alle SDK-Assemblies aus dem Container.
16	Verwendung einer nicht-offiziellen SDK-Version	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Es ist nicht erlaubt, ETS-App-Container zu veröffentlichen, die mit einer unveröffentlichten Version von ETS-SDK erstellt wurden.	Erstellen Sie die App neu, indem Sie nur auf Dateien aus freigegebenen SDK-Versionen verweisen.
17	SQL-Verbindung gefunden	Warnung	Warnung	Wenn die Assembly den SQL-Namensraum (System.Data.SqlClient) verwendet, erscheint eine Meldung. Dies hat eine manuelle Überprüfung zur Folge. Wird beispielsweise der SQL-Namensraum zum Importieren von Daten aus einer Access-Datenbank verwendet, ist dies erlaubt. Jeder Versuch, ohne das SDK ObjectModel auf die ETS4-Datenbank zuzugreifen, sei es lesend oder schreibend, ist verboten.	Wenn die manuelle Überprüfung eine illegale Nutzung des SQL-Namensraums feststellt, entfernen Sie diese Verwendungen..
18	Verwendung verdächtiger Namensräume erkannt	Warnung	Warnung	Die Verwendung der Namensräume System.Net.*, System.Data.Sql und System.Web hat eine Meldung zur Folge. Eine manuelle Überprüfung muss nachweisen, ob diese Namensräume in einer Weise verwendet werden, die den etsapp-Regeln entspricht. Ist dies nicht der Fall, wird die Validierung verweigert.	Wenn die manuelle Inspektion eine illegale Verwendung dieser verdächtigen Namensräume ergibt, entfernen Sie diese Verwendungen.
19	Sprachunterstützung in Englisch fehlt	Warnung	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Wenn die App Unterstützung für mehrere Sprachen bietet, muss Englisch zu den unterstützten Sprachen gehören. Die Prüfung sucht nach einer englischen Lokalisierung für die App. Wird keine gefunden, muss manuell geprüft werden, ob die neutralen Texte bereits englisch sind.	Fügen Sie eine Unterstützung in englischer Sprache hinzu.
20	Unerwartete App-ID	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Die App-ID, die von der AddIn-Instanz zurückgegeben wird, muss die gleiche sein wie in der AddIn-Manifest-Datei.	Verwenden Sie die gleiche App-ID in der AddIn-Klasse und in der Manifest-Datei.
21	Ungültige DCA Hersteller-ID	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Hersteller-ID in DeviceConfiguration stimmt nicht mit Hersteller-ID von AddIn überein.	Verwenden Sie die gleiche Hersteller-ID für App-ID und Anwendungsprogramm-IDs.
22	DCAs können die UI-App-Funktion nicht verwenden	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Eine DCA darf die folgenden Funktionen nicht verwenden: Ein AddIn-UI zurückgeben Subskribieren zum Projekt-Opening Event Subskribieren zum ProjectClosing Event Das SingleInstance Attribut auf true setzen Implementierung der IMonitorAddIn-Schnittstelle	Verwenden Sie keine AddIn-Funktionen in Ihrem DCA.
23	DCA muss x64 unterstützen	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Jede DCA muss x64 unterstützen, damit die ETS nicht im Kompatibilitätsmodus ausgeführt werden muss.	Erstellen Sie Ihre App x64 zu unterstützend und setzen Sie die Is64BitCompatible im Manifest auf wahr.
24	App verwendet Komponenten, die von der ETS5 in einer anderen Version verwendet werden	Warnung	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly.	Das ETS verwendet eine Komponente, die auch von der App verwendet wird, aber in einer anderen Version	Um mögliche Inkompatibilitätsprobleme zu vermeiden, verwenden Sie die gleiche Komponentenversion wie die ETS
25	Die App-Assembly, wie im Attribut AddInAssembly in der Manifest-Datei angegeben, wurde nicht gefunden	Fehler	n.a. - Die Regel wird für die App geprüft, nicht für jede Assembly	Die ETS App Assembly konnte nicht gefunden werden	Stellen Sie sicher, dass die (in der Manifestdatei angegebene) App Assembly existiert

Regeln, die formell bestätigt werden müssen

Diese Regeln müssen von den Entwicklern manuell bestätigt werden, da eine automatische Überprüfung nicht möglich ist.

Wenn der Entwickler gegen eine der Regeln verstößt (entweder automatisch verifizierte oder formal bestätigte), wird die Validierung verweigert. Wird nach der Validierung ein Verstoß gegen eine der Regeln festgestellt, kann die Validierung widerrufen werden.

Name	Beschreibung	Lösung
Aktulaisierungen nur über MyKNX möglich	Die App verfügt möglicherweise über keinen eigenen Aktualisierungsmechanismus. Aktualisierungen für eine App sind nur über KNX OLT verfügbar. Dadurch wird die Verbreitung von nicht validierten Apps verhindert.	Entfernen Sie alle Mechanismen, die zum Aktualisieren der App unter Umgehung des KNX OLT verwendet werden.
Keine SQL-Verbindungen zur ETS4-Datenbank	Keine App darf direkt auf die Datenbank zugreifen.	Entfernen Sie alle Mechanismen, die direkt auf die ETS4-Datenbank zugreifen.
Apps dürfen keine Daten im Dateisystem behalten.	Projektbezogene Daten: Die Aufnahme von projektbezogenen Daten in AddInData ist unerlässlich. Diese Daten umfassen alle Elemente, die für die Funktionalität und Integrität des Projekts von entscheidender Bedeutung sind. Ohne sie wäre das Projekt unvollständig und nicht funktionsfähig. Das primäre Ziel ist es, kritische Fehler zu vermeiden, wie sie bei Import/Export von ETS3-Plugins aufgetreten sind. Durch die Zentralisierung projektbezogener Daten in AddInData wird sichergestellt, dass das Projekt stabil und betriebsbereit bleibt. Nicht-projektbezogene Daten: Dazu gehören benutzerbezogene oder temporäre Daten, die getrennt von Projektdaten gespeichert werden sollten. Das Platzieren solcher Daten in den Projektdaten oder den App-Installationsordner kann die Integrität des Projekts beeinträchtigen, wodurch seine Signatur möglicherweise gebrochen wird.	Entfernen Sie alle Mechanismen, die Daten direkt im Dateisystem speichern und ersetzen Sie diese durch die Verwendung der AppDaten des Projekts.
Apps dürfen nicht im Vollbildmodus ausgeführt werden.	Eine App darf das ETS-Fenster nicht ausblenden und als Hauptanwendung fungieren. Die ETS muss immer als Hauptanwendung erkennbar sein.	Entfernen Sie jeden Code, der die App als Hauptanwendung fungieren lässt.
Die App muss entweder responsiv sein oder einen Busy-Status anzeigen	Wenn die App einen zeitaufwendigen Vorgang durchführt, bei dem ETS nicht mehr reagiert, muss die App einen Fortschritt oder einen Busy-Status anzeigen	Implementieren Sie bei zeitaufwendigen Vorgängen eine Fortschrittsanzeige.
Die App darf nicht unerwartet geschlossen werden.	Die App muss auf Ausnahmen mit einer benutzerfreundlichen Fehlermeldung reagieren. Nach Anzeige der Meldung muss die App weiterlaufen. Generische oder unzureichende Fehlermeldungen werden nicht akzeptiert, ebenso wie das unerwartete Schließen der Anwendung nach unbehandelten Ausnahmen.	Implementieren Sie eine korrekte Fehlerbehandlung, die in jeder Situation benutzerfreundliche Meldungen anzeigt. Stellen Sie sicher, dass keine unbehandelte Ausnahme die App zum Absturz bringen kann.

Suche

ETS App-Entwicklung