Heim > Artikel > Backend-Entwicklung > Detaillierte Grafik- und Texterklärungen einiger Fallstricke, die in .NET Core auftreten
Vor kurzem habe ich nach dem Upgrade von .NET Core auf 2.0 angefangen, immer mehr zu basteln, bin aber auf viele Fallstricke gestoßen, deshalb werde ich sie hier aufzeichnen.
Die erste Gefahr ist die bedingte Kompilierung
Wenn wir einige Methoden schreiben, fügen wir normalerweise einige Ausgabeprotokolle für den Debug-Modus hinzu, damit wir sie überprüfen können, und auch für Release The Der Modus fügt einige spezifische Parameter hinzu oder ändert sie, aber heute bin ich beim Schreiben auf diese Grube gestoßen. #if !DEBUG #endif Der Code in der Mitte kann nicht geändert werden. Er ist immer grau Ich fange an zu zweifeln. Unterstützt .NET Core in VS 2017 keine bedingte Kompilierung?
Die zweite Gefahr sind einige Dateien darunter .NET Core MVC kann nicht heruntergeladen werden
Ich habe eine Website mit .NET Core MVC erstellt. Anfangs war sie ziemlich gut, aber dann wurde sie mit einer App ausgestattet, also habe ich Ich habe die APK-Datei direkt auf die Website heruntergeladen, den Namen in app.apk geändert und dann http://127.0.0.1/app.apk aufgerufen. Es wurde die Meldung „404 nicht gefunden“ zurückgegeben 🎜>
Da es immer noch viele iis gibt, dachte ich sofort, dass es durch das tägliche Hinzufügen von Mime verursacht wurde, also ging ich zur iis-Site, um es hinzuzufügen , und stellte fest, dass es existierte
Ich war einen Moment verwirrt, also durchsuchte ich den Anfragefilter, um zu sehen, ob es dort verboten war, stellte aber fest, dass es nutzlos war, Also habe ich die Datei in app.apk.zip geändert und es ausprobiert und festgestellt, dass die Zip-Datei heruntergeladen werden kannDie dritte Falle ist die Try-Datei von .NET Core 2.0 MVC
Ab 2.0 scheint es, dass die Ansichtsdatei direkt in eine DLL-Datei gepackt wird. Nach der Veröffentlichung handelt es sich nicht mehr um eine SHTML-Datei wie bei einer herkömmlichen MVC, sondern sie wird in eine DLL-Datei kompiliert. Die Benennungsregel ist der Projektname.PrecompiledViews.dll
Der vierte Fallstrick .NET Core-Referenz-DLL-Problem
uns In der Vergangenheit wurden einige häufig verwendete Funktionen immer in einer separaten Klassenbibliothek zusammengefasst und Zur Projektverwendung in eine DLL kompiliert, aber dies scheint in .NET Core-Projekten nicht zu funktionieren.
Zuerst habe ich eine neue Klassenbibliothek für die öffentliche Klassenbibliothek zur Lösung hinzugefügt, um auf das Projekt zu verweisen Die öffentliche Klassenbibliothek war dabei nichts Ungewöhnliches, aber als ich eine andere vs. erstellte und das Projekt in hinzufügte, ist es normal, Code in VS zu schreiben, nachdem ich auf die DLL der öffentlichen Klassenbibliothek und den Code verwiesen habe Eingabeaufforderungen sind ebenfalls . Sobald ich jedoch F5 zum Debuggen drücke, erscheint eine Falle und meldet, dass der Typ oder Namespace nicht gefunden werden kann
Die Lösung besteht darin, die öffentliche Klassenbibliothek zu packen, um ein NuGet-Paket zu generieren Dann fügen Sie Referenzen hinzu, indem Sie NuGet-Pakete verwalten. aber in vielen Fällen möchte ich einige Klassenbibliotheken nicht auf nuget.org stellen, ich kann die generierten Nuget-Pakete in die Microsoft Visual Studio Offline Packages Platzieren Sie es im Verzeichnis, das den Microsoft Visual Studio Offline Packages entspricht
Das obige ist der detaillierte Inhalt vonDetaillierte Grafik- und Texterklärungen einiger Fallstricke, die in .NET Core auftreten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!