Ich erhalte einen Codeanalysefehler auf meinem Build-Server, der Fehler ist
... NETFramework, Version = v4.6.AssemblyAttributes.cs (3,1): Fehler CS8019: Unnötige Verwendung der Direktive.
Dies ist in einer Temp-Datei, die Visual Studio erstellt.
In meinem Projekt habe ich " Ergebnisse aus generiertem Code unterdrücken (nur verwaltet ) "angekreuzt. Ich hätte gedacht, das wäre genug.
Aber ich bekomme immer noch den Fehler auf dem Server und lokal bekomme ich keine.
Irgendwelche Ideen?
Googlen für CS8019 AssemblyAttributes ergab viele interessante Artikel, z. B. dieser Blogpost . Zitat:
%Vor%Zum Glück für uns ist MSBuild flexibel genug, damit wir es umgehen können. Das gute Design besteht darin, diese Datei in das Intermediate-Verzeichnis (normalerweise Obj genannt) zu schreiben, da alle transienten und temporären Dateien während eines Build-Prozesses dorthin gehen sollten. Wir können diese Eigenschaft entweder in unserer Projektdatei festlegen:
Wenn Ihr Build eine gemeinsame .props-Datei verwendet, legen Sie diese Eigenschaft dort fest. Dadurch wird sichergestellt, dass Ihr Build nicht vom TEMP-Verzeichnis abhängt und isolierter, wiederholbar und inkrementell ist.
TargetFrameworkMonikerAssemblyAttributesPath entfernt die Warnung nicht. Es verschiebt die Datei, die die Warnung generiert, was sich als nützlich erweisen wird. TargetFrameworkMonikerAssemblyAttributeText funktioniert nicht. Es scheint, dass diese Eigenschaft vom Ziel überschrieben wird, das diese Datei generiert. (In MSBuild 14.0 wird die Eigenschaft vom Ziel _SetTargetFrameworkMonikerAttribute in der Datei Microsoft.CSharp.CurrentVersion.targets überschrieben und wird später im Ziel GenerateTargetFrameworkMonikerAttribute in der Datei Microsoft.Common.CurrentVersion.targets bezeichnet. )
(Arbeitslösung) Wenn Sie TargetFrameworkMonikerAssemblyAttributesFileClean auf "false" setzen, wird verhindert, dass die Datei überschrieben wird, wenn sie bereits existiert. Sie können das Build-Skript damit generieren lassen, die using ...; -Linien manuell korrigieren, speichern und sehen, dass es beim Neuaufbau nicht neu generiert wird. Zu diesem Zeitpunkt ist es sinnvoll, die Datei in einen nicht temporären Pfad zu platzieren.
Wenn Sie Folgendes zu einer SharedBuildScript.msbuild.xml -Datei hinzufügen und in einzelnen Projektdateien darauf verweisen, stellen Sie sicher, dass alle auf dieselbe einzelne Datei verweisen:
%Vor% Michals Antwort hilft hier nur teilweise. Ja, Sie können umleiten, wo diese Datei geschrieben ist, aber trotzdem die CS8019 Regel verletzen.
Sie haben zwei Möglichkeiten:
Legen Sie auch die & lt; TargetFrameworkMonikerAssemblyAttributeText & gt; Eigenschaft für etwas, das nicht gegen die Regel verstößt. Zum Beispiel:
Oder leiten Sie die Datei an eine nicht temporäre Stelle um. In meinem Fall entschied ich mich, es in den Lösungsstamm zu schreiben, so dass alle Projekte die Datei gemeinsam nutzen würden. Ich habe dann die Datei manuell bearbeitet, um die Verstöße zu entfernen und die Datei zusammen mit dem Rest meines Codes zu übertragen. Die Datei wird nicht überschrieben, wenn sie bereits existiert. Dies ist im Allgemeinen sicher.
Tags und Links .net c# msbuild code-analysis fxcop