Deutsch

Hintergrund

Beispiel: Besondere Warnungen oder Fehler durch "Obsolete"-Attribute

Konkretes Beispiel für das Ausblenden bestimmter Warnungen bei der Sage 100-Entwicklung

Beispieldateien für das Ausblenden von Warnungen

Deutsch

Hintergrund

In der täglichen Praxis beim Umgang mit Visual Studio-Projekten anderer Entwickler , z.B. im Sage 100-Entwicklungsumfeld , fällt immer wieder auf, dass dort zahlreiche Visual-Studio-Warnungen auftreten und offensichtlich von den Entwicklern komplett ignoriert werden.

Die Warnungsprüfungen von Visual Studio 2022 sind jedoch inzwischen sehr gut.

Man kann immer wieder staunen , was alles inzwischen korrekt als Problem erkannt und dem Entwickler beim Build-Prozess als Hinweis gegeben wird 👍🏻.

So werden eine Vielzahl von Problemen und teils auch indirekt logische Fehler im Sourcecode erkannt und als Warnung ausgegeben.

Diese Meldungen haben in der Regel einen eindeutigen Code.

• Meldungen, die mit "BC" beginnen, beziehen sich auf spezifische Compiler-Warnungen in Bezug auf den Compiler, wie z. B. mögliche Laufzeitfehler, veraltete Konstrukte oder andere potenzielle Probleme im Code.

• Meldungen, die mit "MS" beginnen, stammen aus dem MSBuild-System und betreffen typischerweise Build-Prozesse, wie z. B. fehlende Dateien, Probleme mit der Paketwiederherstellung oder Konfigurationsmängel.

  Derartige Warnungen sind oft spezifischer und lassen sich in der Regel nicht einfach über die Visual-Studio-Konfigurationsoptionen dauerhaft ausblenden, sondern erfordern Anpassungen in Projektdateien oder MSBuild-Skripten.

Die Warnungen wurden von Microsoft somit nicht ohne Grund eingebaut , und man ist als Entwickler gut beraten , diese genau zu prüfen , da sie potenzielle Probleme frühzeitig erkennen lassen.

Beispiel: Besondere Warnungen oder Fehler durch "Obsolete"-Attribute

Insbesondere Obsolete-Warnungen sollte man beachten und nicht einfach auf Dauer ignorieren!

Diese entstehen , wenn Entwickler während der Entwicklung des eigenen Quellcodes z. B. bestimmte Methoden mit dem "Obsolete"-Attribut versehen , weil eine bestimmte Klasse , Funktion etc. in Zukunft nicht mehr benutzt werden soll.

In der Regel wird von dem ursprünglichen Entwickler , der das "Obsolete"-Attribut einbaut , auch ein Hinweis ergänzt , was der Verwender des Quellcodes zu tun hat , damit die Warnung bzw. Fehler verschwindet.

Diese Metadaten können vom Compiler ausgewertet werden und erscheinen dann ebenfalls als Warnung während des Build-Vorgangs , oder sogar als Fehler , je nachdem, wie der Entwickler das "Obsolete"-Attribut im Code konfiguriert hat!

⚠️Auch Sage hat einige eigene .NET-Klassen in Bezug auf den neuen Smart Client als "obsolete" markiert.

Solche Warnungen sind demnach wichtig und eine gute Erinnerung , dass im Code irgendwann Anpassungen vorgenommen werden müssen , damit der Code mit dem neuesten Smart Client der Sage 100 kompatibel bleibt.

Konkretes Beispiel für das Ausblenden bestimmter Warnungen bei der Sage 100-Entwicklung

Insbesondere, wenn man Sage-Assembly-Visual Studio-Projekte für Anpassungen in eigene Solutions übernimmt , dann wird man mit teils Hunderten von Warnungen konfrontiert , die der Compiler in den Sage-Projekten findet.

Sage ignoriert diese Warnungen ganz offensichtlich , blendet die Warnungen aber nicht (alle) für den Visual Studio Compiler aus.

Wenn man als Entwickler nun daran gewöhnt ist , die Visual-Studio-Warnungen ernst zu nehmen , ergibt sich durch die Übernahme von Sage-Quellcode in die eigene Solution ein entsprechendes äußerst "unschönes" Problem.

Natürlich könnte man die angepassten Sage-Assemblies auch in eine eigene Solution packen. Das Grundproblem bleibt jedoch auch dort bestehen und eine eigene Solution ist u.U. sogar kontraproduktiv für den Projektablauf.

Nachfolgend einige Tipps , wie man bei angepassten Sage-Assemblies die darin enthaltenen Warnungen sehr leicht dauerhaft für die eigene Solution ausschalten kann , sodass man dann in der eigenen Solution weiterhin sinnvoll mit den Warnungen von Visual Studio arbeiten kann und nicht Gefahr läuft , diese zu ignorieren , nur weil Sage hunderte von Warnungen generiert.

Der Sage-Code ist nun einmal von Sage, und wenn Sage dort die Warnungen ignoriert hat, dann ist das als Entscheidung von Sage hinzunehmen. Das geht in Ordnung. Aber im Rest der eigenen Solutions möchte man ggf. die Warnungen durchaus ernstnehmen!

Um nun z. B. für Sage-Projekte, die man in eigenen Solutions anpassen muss , gezielt Warnungen ausschalten zu können, kann man wie folgt vorgehen.

Man bearbeitet dazu die *.vbproj-Dateien direkt. Dies ist der schnellste Weg und 100% sicher.

• Zuerst entfernt man eventuell vorhandene "CodeAnalysisRuleSet"-Definitionen von Sage (es sei denn , man hat dieselben Rulesets in Visual Studio aktiv, i.d.R. wohl nicht der Fall).

  Diese betreffen den MS-Build-Vorgang und wie weiter oben erklärt lassen sich solche Warnungen nicht ohne Weiteres auf die hier beschriebene Weise ausblenden.

• Alle vorhandenen "WarningsAsErrors" von Sage auskommentieren oder entfernen.

  Bzw. darauf achten , dass es mit der eigenen Unterdrückung keine logischen Konflikte gibt.

  Es ist so , dass die einzelnen Bedingungen am Anfang der jeweiligen "PropertyGroup" natürlich von Visual Studio beachtet werden , wenn dies die Ausgabe-Konfiguration des Compilier-Vorgangs betrifft.

• Folglich ebenfalls vorhandene "NoWarn" von Sage auskommentieren oder entfernen bzw. auch dort eventuelle Konflikte mit der eigenen Liste zum Ignorieren von Warnungen ausräumen.

• Nun zum Schluss irgendwo möglichst an den Anfang der Projekt-Datei in die gewünschten Warnungen ausblenden , d.h. die eigene Liste zum Ignorieren der gewünschten Warnungen deklarieren.

  Dies kann in einer eigenen "PropertyGroup" erfolgen , die an keine speziellen Konfigurationsbedingungen gekoppelt ist. Beispiel:

  <PropertyGroup>
    <!-- Suppress the following warnings because Sage ERP assemblies always(!) cause several warnings due to low code quality. -->   <NoWarn>BC42355,BC42307,BC40000,BC42105,BC42104,BC42025,BC42024,BC42030,BC42353</NoWarn>
  </PropertyGroup>

Alternativ baut man diese Bedingung in die erste "PropertyGroup" ein , z.B. nach dem Festsetzen des Target-Frameworks.

Beispieldateien für das Ausblenden von Warnungen

Nachfolgend zwei entsprechende Beispiele für das Ausblenden typischer Visual Studio-Warnungen, die sich immer wieder in Sage Assemblies finden.

Sagede.OfficeLine.Wawi.BelegEngine:

Sagede.OfficeLine.Wawi.PrintEngine: