SOを検索しましたが、多くの回答が見つかりましたが、質問を対象としていません。
定義が言うように：
クロスプラットフォームアプリケーションを開発するために、以下を使用する可能性のある他のクラスライブラリを参照する可能性のあるASP.NETコアアプリケーション（.NET）を作成する予定です。
いずれか（標準またはコア）を使用する場合、アプリケーションは引き続き他のOSをサポートすると思います。
場合によっては、クラスライブラリで従来の.NET Framework With .NET Standardを使用している人を見かけますか？
たとえば、project.jsonを持つクラスライブラリがあるとします。
"dependencies": {
"Microsoft.Extensions.Caching.Abstractions": "1.0.0",
"Microsoft.Extensions.Options": "1.0.0",
"StackExchange.Redis.StrongName": "1.1.608",
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.5": { }
}
依存関係はフレームワークとどのように異なりますか？標準ライブラリは単なる仕様であるため、プロジェクトはどのようにアセンブリを解決しますか。
この場合、.NET Frameworkを使用しているときに、アプリケーションはまだクロスプラットフォームですか？
実際には、.NetFrameworkアプリケーションは.NetCoreでは実行されません。ただし、LinuxおよびMacOSで使用可能なmonoで実行される場合があります。
いつ組み合わせて使用する必要がありますか（標準、コア、NET）？
可能であれば（つまり、フレームワーク固有の依存関係がない限り）、ライブラリに.NetStandardを使用する必要があります。
アプリケーションに.NetFramework固有の依存関係がある場合、またはアプリケーションをWindowsのみにすることができる場合は、アプリケーションに.NetFrameworkを使用します。
クロスプラットフォームにする必要がある場合、または最新のAPIを使用する場合は、アプリケーションに.NetCoreを使用します。（.Net Coreは通常、.Net Frameworkよりも高速に更新され、プレビューバージョンもあります。）
フレームワークを使用および混合する際のベストプラクティスは何ですか？
質問がわかりません。同じアプリケーションに.NetFrameworkと.NetCoreを混在させることはできません。
競合を回避して失敗を構築する方法は？
私はいくつかの明白なアドバイスを提供することができますが、それは答えられる質問ではないと思います：
編集：
依存関係はフレームワークとどのように異なりますか？
"frameworks": { "netstandard1.5": { } } これは、ライブラリが.Net Standard 1.5ライブラリであり、使用できるフレームワークを決定することを意味します。
"dependencies": { "NETStandard.Library": "1.6.0" }実際には、.Net標準ライブラリの一部であるパッケージを取り込みます。また、ライブラリは、そのサブセットだけでなく、すべての.Net標準ライブラリにアクセスできることも意味します。
標準ライブラリは単なる仕様であるため、プロジェクトはどのようにアセンブリを解決しますか？
NETStandard.Library依存するパッケージは単なる仕様ではありません。たとえば、パッケージにSystem.IO.Compression.ZipFileは次のものが含まれています。
ZipFile転送するfor.Net Framework4.6の実装System.IO.Compression.FileSystemZipFile（パッケージの内部を自分で調べるには、NuGetPackageExplorerをお勧めします。）
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加