Clever Geek Handbook

AAA！ .NET Coreに書き換えるときです！

私たちは皆、長い間.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にドラッグします。 ゾウを少しずつ食べるほうがいいです：









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







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







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







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







成分 ステータス Windowsのみ
Microsoft.Win32.Registry 利用可能 はい
Microsoft.Win32.Registry.AccessControl 利用可能 はい
System.CodeDom 利用可能
System.ComponentModel.Composition 来る
System.Configuration.ConfigurationManager 利用可能
System.Data.DatasetExtensions 来る
System.Data.Odbc 来る
System.Data.SqlClient 利用可能
System.Diagnostics.EventLog 来る はい
System.Diagnostics.PerformanceCounter 来る はい
System.DirectoryServices 来る はい
System.DirectoryServices.AccountManagement 来る はい
System.DirectoryServices.Protocols 来る
System.Drawing 来る
System.Drawing.Common 利用可能
System.IO.FileSystem.AccessControl 利用可能 はい
System.IO.Packaging 利用可能
System.IO.Pipes.AccessControl 利用可能 はい
System.IO.Ports 利用可能 はい
System.management 来る はい
System.Runtime.Caching 来る
System.Security.AccessControl 利用可能 はい
System.Security.Cryptography.Cng 利用可能 はい
System.Security.Cryptography.Pkcs 利用可能 はい
System.Security.Cryptography.ProtectedData 利用可能 はい
System.Security.Cryptography.Xml 利用可能 はい
System.Security.Permissions 利用可能
System.Security.Principal.Windows 利用可能 はい
System.ServiceModel.Duplex 利用可能
System.ServiceModel.Http 利用可能
System.ServiceModel.NetTcp 利用可能
System.ServiceModel.Primitives 利用可能
System.ServiceModel.Security 利用可能
System.ServiceModel.Syndication 来る
System.ServiceProcess.ServiceBase 来る はい
System.ServiceProcess.ServiceController 利用可能 はい
System.Text.Encoding.CodePages 利用可能 はい
System.Threading.AccessControl 利用可能 はい


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をマークします。













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









写真の例では、誰かがレジストリの設定を減算しようとしています。 この行をチェックでラップし、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に移植したりして、スピーカーに対する質問のプールが蓄積されるようにすることを強くお勧めします。







More articles:


All Articles