私たちは皆、長い間.NET Coreに移行したいと考えていますが、常に何かが干渉します。 たとえば、重要なAPIが十分にない場合は何もできません。 バージョン2.0は、 .NET Standard 2.0でプロセスを簡素化しましたが、それだけではありません。 さて、Microsoftの神は私たちの祈りに耳を傾け 、NuGetの単一パッケージとして利用可能な20,000個のAPIをもたらしました ！

誰がこれを必要としますか？

要するに、誰もがそれを必要としています。 私見、多くのレガシーを.NET Coreにドラッグする可能性は、すでに被害者にとって十分な言い訳です。

.NET Coreは、すべての合理的なオペレーティングシステム（GNU / Linux、macOS、およびWindows）上のスケーラブルなWebアプリケーション用に特別に作成されていることを思い出す必要があります。

使い方は？

最初に、レガシー預金自体はレーキ処理されないことを理解する必要があります。 100万個のクラスを取得して1つのボタンでドラッグすることについて考えることすらありません。

Windows localhostのASP.NET MVCでアプリケーションを実行しており、これに対して解雇されていないとします。 Azureで実行されているTrue-on Linuxにドラッグします。 ゾウを少しずつ食べるほうがいいです：

• すべてをASP.NET Coreにドラッグアンドドロップします（ただし、.NET Frameworkをターゲットプラットフォームとして保持し続けます）。
• .NET Coreにクロールします（ただし、引き続きWindowsを使用します）。
• GNU / Linuxにジャンプします。
• Azureで起動します。

この素晴らしい計画は、共産主義の構築としてではなく、合理的にアプローチされるべきであることは明らかです。 たとえば、大ボスにAzureでの起動を表示する必要がある場合は、ここから開始します。 怠laz（たとえば、怠inessなど）を考える場合、リーダーは.NET Coreへの信頼を得るための特別なトレーニングマニュアルを作成しました 。

つまり、NuGetを明らかにし、 Microsoft.Windows.Compatibilityパッケージをインストールして、必要なAPIと不要なAPIの膨大な数が利用可能になっていることを確認する必要があります。

このMicrosoft.Windows.Compatibilityが依然として激しく吹き替えられていることを理解することが重要です。そのため、すべてのドロップデッドストーリーは私たちのすぐ前にあります。

現在、次の一連のニシュテクがあります（テーブルは巨大であることが判明しました;携帯電話からこの投稿を読んでいる男：ご容赦ください！）：

Windows専用APIで何をしますか？

苦しむ

タンカー用。 すべてのAPIが同等に移植できるわけではありません。 Windowsを使用している場合、問題はありません。 リチャード・ストールマンとティム・クックの神聖さをそれぞれGNU / LinuxとmacOSに参加させたいなら、苦しむ必要があります。

nishtyakovタブレットを見ると、Windows専用のコンポーネントがほぼ半分になっています。 ただし、Microsoftの優れた存在により、このようなコードをどのプラットフォームでも正常にコンパイルできます。 存在しない機能を使用しようとすると、実行時にPlatformNotSupportedExceptionするため、そのような機能はすべてRuntimeInformation.IsOSPlatform()呼び出しでRuntimeInformation.IsOSPlatform()カバーする必要があります。

 private static string GetLoggingPath() { // Verify the code is running on Windows. if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement")) { if (key?.GetValue("LoggingDirectoryPath") is string configuredPath) return configuredPath; } } // This is either not running on Windows or no logging path was configured, // so just use the path for non-roaming user-specific data files. var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData); return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging"); } 

どのAPIスケールがWindowsでのみ機能するかを理解する方法は？ ドキュメントを読む人はいないでしょう？

StackOverflowを使用した私のコピーペーストプログラミング愛好家です！ Microsoft-神々は厳しいが、公平であるため、数週間前にAPI Analyzerツールを見た 。 Roslynを使用すると、このツールは、ターゲットが.NET Coreまたは.NET Standardに設定されている場合にのみ、Windows専用APIをマークします。

間違いをどうするか？ 前述のように、苦しみます。

• 移植不可能なコードを削除します。 macOSで起動しないのに、なぜ機能が必要なのですか？ :-)
• 他のより多くのクロスプラットフォームAPIを使用してコードをリファクタリングするために一生懸命働きます。 この更新の利点は、非常に多くをもたらしました。
• GNU / Linux固有のことが起こる、Windowsでは単に必要のない場所で、OSのタイプをチェックします。

写真の例では、誰かがレジストリの設定を減算しようとしています。 この行をチェックでラップし、Windowsでのみ実行できます。 GNU / Linuxでは、この行に相当するものは異なり、はるかに苦痛です。

Windows Compatibility Packはメタパッケージであることに注意してください。 マイクロソフトは、一般の人々が個々の小さなパケットを探すことで苦しむことはなく、1回のジャンプで新しいプラットフォームに切り替えることをよく知っていました（上記の予約が必要です）。 それでも、思慮深いクールな開発者であれば、機能を1つずつドラッグできます。 したがって、不要なごみにさらに多くの依存関係をスローすることが可能になります。

次は？

移植の道徳的な準備。 Windows Compatibility Packをインストールします 。 イベントログ、WMI、パフォーマンスカウンター、Windowsサービスなど、2万を超えるニシュティアキを学習します。

アプリをクロスプラットフォームにしたい場合は、API Analyzerを起動します。 少し泣くか、ウォッカを引くことができます。

残念ながら、現在.NET Coreはデスクトップ開発のニーズをカバーしていません。 おそらくいつかこれは変わるでしょう。 しかし、これはまったく異なる話です。

一般的な.NET、特に.NET Coreについて詳しく知りたい場合は、突然サンクトペテルブルクで開催されるDotNext 2018 Piterでお待ちしています。 この会議に何かを接着したり、Coreに移植したりして、スピーカーに対する質問のプールが蓄積されるようにすることを強くお勧めします。