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

English

Background

Example: special warnings or errors caused by “Obsolete” attributes

Concrete example of suppressing specific warnings in Sage 100 development

Example files for suppressing warnings

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 , 2026 etc. 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:

English

Background

In day-to-day practice when working with Visual Studio projects created by other developers - for example in the Sage 100 development environment - it is repeatedly noticeable that numerous Visual Studio warnings occur and are evidently ignored completely by the developers.

The warning checks in Visual Studio 2022 , 2026 etc. are, however, very good by now. Time and again, one can be amazed at what is correctly recognised as an issue and flagged to the developer during the build process 👍🏻.

In this way, a wide range of problems - and, in some cases, indirect logical errors in the source code - are identified and output as warnings.

These messages usually have a clear, specific code:

• Messages that begin with “BC” relate to specific compiler warnings, such as possible runtime errors, obsolete constructs, or other potential issues in the code.

• Messages that begin with “MS” come from the MSBuild system and typically concern build processes, such as missing files, package restore issues, or configuration deficiencies.

Such warnings are often more specific and generally cannot simply be permanently hidden via Visual Studio configuration options; instead, they require adjustments to project files or MSBuild scripts.

Microsoft did not add these warnings without reason, and as a developer you are well advised to review them carefully, because they can help you identify potential problems early.

Example: special warnings or errors caused by “Obsolete” attributes

In particular, you should pay attention to Obsolete warnings and not simply ignore them long-term.

They occur when developers, during the development of their own source code, mark certain methods with the “Obsolete” attribute because a particular class, function, etc. is no longer intended to be used in future.

As a rule, the original developer who adds the “Obsolete” attribute also includes a note explaining what the consumer of the source code needs to do in order for the warning or error to disappear.

This metadata can be evaluated by the compiler and will then appear as a warning during the build process - or even as an error - depending on how the developer has configured the “Obsolete” attribute in the code.

⚠️ Sage, too, has marked some of its own .NET classes relating to the new Smart Client as “obsolete”.

Such warnings are therefore important, and a helpful reminder that code changes will eventually be required so that the code remains compatible with the latest Sage 100 Smart Client.

Concrete example of suppressing specific warnings in Sage 100 development

Especially when you take Sage assembly Visual Studio projects into your own solutions for customisations, you are often confronted with hundreds of warnings that the compiler finds in the Sage projects.

Sage quite clearly ignores these warnings, but does not (fully) suppress them for the Visual Studio compiler.

If, as a developer, you are used to taking Visual Studio warnings seriously, importing Sage source code into your own solution creates a rather unpleasant problem.

Of course, you could also place the customised Sage assemblies into a separate solution. However, the underlying problem remains there as well, and a separate solution may even be counterproductive to the overall workflow.

Below are a few tips on how you can permanently disable the warnings contained in customised Sage assemblies for your own solution with minimal effort. This allows you to continue working sensibly with Visual Studio warnings in your own solution and avoids the risk of ignoring warnings simply because Sage generates hundreds of them.

Sage’s code is Sage’s code. If Sage has chosen to ignore those warnings, that is a decision to be accepted. That is fine. But in the rest of your own solutions, you may very well want to take warnings seriously.

To selectively disable warnings for Sage projects that you need to customise within your own solutions, you can proceed as follows.

Edit the "*.vbproj" files directly. This is the quickest approach and 100% reliable.

• First, remove any Sage "CodeAnalysisRuleSet" definitions (unless you have the same rule sets enabled in Visual Studio - which is usually not the case). These affect the MSBuild process and, as explained above, such warnings cannot easily be suppressed in the manner described here.

• Comment out or remove any existing "WarningsAsErrors" settings from Sage. Or, at least, ensure there are no logical conflicts with your own suppression, because the conditions at the beginning of each "PropertyGroup" are of course respected by Visual Studio when they affect the output configuration of the compilation process.

• Accordingly, also comment out or remove any existing Sage "NoWarn" settings, or resolve any conflicts with your own list of suppressed warnings.

• Finally, add your own list of warnings to suppress somewhere near the beginning of the project file - i.e. declare your own suppression list.

  This can be done in a separate "PropertyGroup" that is not tied to any specific configuration conditions.

  Example:

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

Alternatively, you can add this setting to the first "PropertyGroup", for example after defining the target framework.

Example files for suppressing warnings

Below are two corresponding examples for suppressing typical Visual Studio warnings that repeatedly appear in Sage assemblies.

Sagede.OfficeLine.Wawi.BelegEngine:

Sagede.OfficeLine.Wawi.PrintEngine: