.NET Core で遭遇するいくつかの落とし穴の詳細なグラフィックとテキストの説明

最近、.NET Core を 2.0 にアップグレードしてから、いろいろいじり始めたのですが、落とし穴がたくさんあったので、ここに記録しておきます。

最初の落とし穴は条件付きコンパイル演算子です

メソッドを作成するとき、通常はデバッグ モードの出力ログを追加して、リリース モードの特定のパラメータを確認したり、追加または変更したりできますが、今日はこれを書いているときにこの落とし穴に遭遇しました
#if !DEBUG #endif 途中のコードは変更できません。設定環境を変更するにはどうすればよいですか? これは、VS 2017 の .NET Core は条件付きをサポートしていないのではないかと思います。編集？

そこで、新しいコンソール プログラムを作成し、以下をテストしましたが、それでも機能することがわかりました:

ここで、明らかにデバッグ環境ではないことがわかりますが、#if DEBUG はまだ正常です。 DEBUGはまだ灰色のままです。F5で直接実行したところ、結果は予想外でした

結果は実際には正常でしたが、VSを更新した後に何か問題が発生したのではないかと思い、別のものを作成しました。古い .net Framework 形式を使用してプロジェクトに取り組んだところ、やはり古いものが良いことがわかりました

2 つ目の落とし穴は、.NET Core MVC の一部のファイルがダウンロードできないことです

サイトを作成しました.NET Core MVC を使用しました。最初はかなりうまくいきましたが、その後、apk ファイルを Web サイトの wwwroot ディレクトリに直接配置し、名前を app.apk に変更して、http にアクセスしました。 ://127.0.0.1/app.apk Return to me A 404 not find

IIS がまだたくさんあるので、毎日 mime を追加していることが原因だとすぐに思い、 IIS サイトに追加しようとしたところ、存在することが分かりました

そこで私は、そこで禁止されているかどうかを確認するためにリクエストフィルターを調べましたが、役に立たないことがわかったので、ファイルをアプリに変更しました。 .apk.zip を試してみたところ、zip がダウンロードできることが分かりました

3 番目の落とし穴は、.NET Core 2.0 MVC のビュー ファイルです

2.0 からは、ビュー ファイルは、従来の mvc のようにリリース後に shtml ファイルではなくなり、dll ファイルに直接パッケージ化されます。コンパイルされた dll ファイルの命名規則は、プロジェクト名です。PrecompiledViews.dll

4 番目の落とし穴は .NET Core DLL 参照の問題です

以前は、よく使われる機能を常に追加して、別のクラス ライブラリを作成し、それをプロジェクト用の DLL にコンパイルしていましたが、これは では機能しないようです。 NET Core プロジェクト最初に、パブリック クラス ライブラリを作成し、ソリューションに新しいクラス ライブラリを追加して、パブリック クラス ライブラリのプロジェクトを参照しました。これを行うときは何も異常はありませんが、別の vs を開始すると、新しいソリューションを作成してプロジェクトを追加します。パブリック クラス ライブラリの DLL を参照した後、 vs にコードを記述するのが通常です。コード プロンプトもあります

しかし、F5 キーを押してデバッグするとすぐにトラップが表示され、レポートが表示されます。型または名前空間が見つからないこと

解決策は、パブリック クラス ライブラリをパッケージ化して NuGet パッケージを生成することです

その後、NuGet パッケージを管理して参照を追加しますが、多くの場合、いくつかのクラス ライブラリを nuget.org に置きたくないのですが、生成された nuget パッケージを Microsoft Visual Studio オフライン パッケージに置くことができます

Microsoft Visual Studio オフライン パッケージに対応するディレクトリに置くだけです

以上が.NET Core で遭遇するいくつかの落とし穴の詳細なグラフィックとテキストの説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。