Aspnetcore: ディスカッション：ASP.NET Core3.0は.NETCoreでのみ実行されます

これは今の全体像において非常に理にかなっていると思います。 .NETCoreとASP.NETCoreはどちらも、大きな問題を引き起こすことなく、人々がすでにそれに切り替える機会を持っているか、まだ持っているほど長い間存在しています（2.0でサポートが最初に削除されたときと比較して） 。

ただし、現在個別の依存関係として存在する可能性のあるASP.NET Coreの特定のコンポーネントについては、その影響については悲しいです。 これはおそらく、個々のコンポーネントがnetstandardのサポートを終了し、代わりにnetcoreapp3.0が必要になることを意味するためです。 特に＃3756では、これらのコンポーネントはASP.NETCoreコンテキストの外部では使用できません。

たとえば、 RazorLightのような.NETStandardサポートを削除することを余儀なくされます。

これにより、組織内の新しいASP.NET Coreプログラミングモデルへの移行を販売した多くの人々が、サポートされていないプラットフォームで3年以内に、サポートされ、積極的に開発されたプラットフォームにとどまることになります（。 NET Core 2.1 LTS）。

この動きを正当化するためにどの分析を使用したかはわかりませんが、 .NETFrameworkでServiceStackASP.NET Core AppsをASP.NETCoreプロジェクトを実行するための最も人気のあるWebテンプレートが.NETCoreで実行するための最も人気のあるプロジェクトテンプレートです。

IMO 3年は、新しいASP.NETプログラミングモデルに移行し始めた、または移行した顧客を放棄するのに十分な時間ではありません（停滞したASP.NET Frameworkプラットフォームを回避するため）。移動する組織への移動は放棄されました。

何らかの理由で、.NETFrameworkのみの依存関係に依存しているために.NETCoreに移行できないお客様がいます。MSが将来のIMOでASP.NETCore3.0で.NETFrameworkのサポートを維持したくない場合は、サポートを拡張する必要があります。 .NETFramework上のASP.NETCore2.1の場合は7年などの長期間。 .NET Coreの開始以来、ASP.NET Frameworkが停滞していることは明らかであるため、既存の本番システムの移行には数年かかる可能性があります。ASP.NETCoreは.NETの将来のプログラミングモデルであるという公式のスタンスで、同じ顧客がすぐに、彼らが移動/移動した新しいプログラミングモデルが数年以内にサポートされなくなることを発見し始めます。 これらの既存の.NETのお客様に対応する最善の方法は、少なくともセキュリティパッチ（理想的にはバグの解決）について、追加のLTS期間で.NET2.1をサポートすることです。

「.NETFrameworkの殺害」、エピソード2：同じストーリー、同じキャラクター：rofl：

残念ながら、これは1つのことを浮き彫りにしているだけです。

おそらくそれは私だけですが、なぜそれがnetcoreapp （定義上、新しいAPIを最初に取得したもの）ほど速く移動しなかったのか理解できませんでした。

あなたはNuGetパッケージの作成者であり、最新のものを使用してもらいたいですか？ 最新のnetstandardバージョンをターゲットにします。最初はnetcoreappベースのアプリケーションのみがそれらを使用できますが、最終的にはXamarin、Mono、.NETFrameworkなどの他のプラットフォームが追いつくでしょう。そして人々はあなたが何も変更することなくあなたのパッケージを使うことができるでしょう。 それが物事が機能する方法です。

もちろん、.NETFrameworkのような非.NETCoreプラットフォームが追いつくまでには時間がかかる場合があります。これは、リリースがまれであり、安定性の基準がはるかに高いためですが、6か月、12か月、さらには18か月かかるとしても私はそうしません。 .NET Frameworkを使用するときに人々が望んでいるのは、問題だと思います。安定したフレームワークであり、動きの速いターゲットではありません。

私見ですが、ASP.NET Core3.0が新しいnetstandard TFMをターゲットにして、必要なすべての.NET CoreAPIを公開する方がはるかに優れたアプローチです。 新しいAPIが十分に安定していることを確認したら、それらを.NET Frameworkにバックポートして、最新の標準と互換性があるようにします。

3年間のサポートが非常に短い古いバージョンで永久にブロックされるのではなく、.NETFrameworkアプリを最新のASP.NETCoreバージョンに移行できるようになるまでに数か月待つ必要があると確信しています。

約束したことを実行します。ASP.NETCoreに移行するときに信頼していた人にとって、.NET Frameworkは行き止まりではなく、ゆっくりと進化する安定したフレームワークにします。

私はこれが好きではありません。 .netコアの開始時に、Microsoftはクロスプラットフォームとしてmonoまたは.net frameworkしていませんmono 、複数の.netランタイムがあると言ったので、 .netstandard設計しました。 .net standardは名前のみで存在します（少なくともasp.netコアの場合、人々はnetcoreappのみのパッケージのビルドを開始します）。
いつの日か、.netコアがウィンドウ上の.netフレームワークを置き換えることができますが、monoや他のプラットフォームはmono（xamarin、unity3d）に依存しています。
.netフレームワークを好むもう1つの理由は、.netコア共有フレームワークが非常に大きいことです。アプリを.netコア2.0から最新の.netコア2.1にアップグレードした場合、 C:/program file/dotnetフォルダーの大きさはどれくらいですか。 私のフォルダにはGBsファイルがあり、.netコアランタイムを更新すると大きくなります。 ただし、.netフレームワークは古いバージョンを置き換えるだけです。

約束したことを実行します。ASP.NETCoreに移行するときに信頼していた人にとって、.NET Frameworkは行き止まりではなく、ゆっくりと進化する安定したフレームワークにします。

FWIWこれが最適な戦略ですが、LTSを拡張するという私の提案は、ASP.NET Coreに移行するために積極的にマーケティングされ、将来のサポートされていないプラットフォームで放棄された既存の顧客により多くの時間を与えるための最小の基準です。発表。

では、.net標準は冗談ですか？ モノチームがaspnetcoreリポジトリをフォークし、名前をaspnetmonoに変更することを願っています。そうしないと、.netスタックを残す可能性があります。😔

これは、私の仕事ではASP.NETCoreを使用しないことを意味していると思います。 ASP.NETにとどまり、アプリをCoreに移植してもかまいません。これにより、さらに多くの変更が必要になるためです。

確かに、あなたの目標が変更を加えないことであるなら、あなたは永遠に同じことをし続けることができます。 私が働いている場所では、数年前にASP.NET Coreの使用を開始し、最初は.NETFrameworkで実行していました。 時間の経過とともに、.NET Coreプラットフォームが成熟して機能を獲得するにつれて、プロジェクトをnetcoreappに切り替えました。 1つまたは2つの古いプロジェクトがまだASP.NETを使用しており、それらを書き直す予定はありません。コードは機能しています。 しかし、新しいものについては、Spanのような機能を楽しみにしています。

変更は延期することができますが、それはあなたが永遠に避けることができる、または避けるべきものではありません-テクノロジーは変化であり、開発者の仕事は常に新しいことを学ぶ必要があります。 現在.NETFrameworkでASP.NETCoreを使用している場合、.NETCoreに移行するのに3年かかることはほとんどありません。

.NET Coreに来てください、水は暖かいです...

何らかの理由で、.NETFrameworkのみの依存関係に依存しているために.NETCoreに移行できないお客様がいます...

さらに深刻なことに、.NET Standard2.0以降の.NETCore2.0で.NET4.xライブラリを使用できます。 .NETCoreにはない機能を使用する可能性はありますが。 これらの穴の多くを埋める.NETCore用のますが、 COM相互運用機能やWinFormsやWPFなどの他のアプリモデルなど、.NET Core3.0ではさらに多くの機能がサポートされています。

.NET Frameworkのから.NETのコアに移動するASP.NET Coreアプリケーションを防止どれブロッカーは、おそらくに提起しなければならないDOTNET / corefx 。

Xamarinの場合; 私は間違っている可能性がありますが、iOSまたはAndroidでWebサーバーを実行するためにそれを使用する可能性は低いと思います。

Monoクライアントアプリの場合、UIがMonoで実行されているときに、Webサーバーがアウトプロセスで実行され、.NETCoreで実行される可能性があります。 BSDフレーバーは現在.NETCoreのギャップですが、KestrelはMonoの他のプラットフォームの一部を切り取ったビッグエンディアンプラットフォームでません。

Unityの場合; ゲームはあらゆる種類の奇妙なことをするので、おそらくそれはカバーされていないシナリオです。 ゲームがクライアントでWebサーバーを使用していた場合。 サーバー上やproc外ではなく; .NETCoreがその部分を実行できるとき。

ASP.NETCoreアプリモデルの外部。 たとえば、ライブラリの場合、ASP.NET Coreにはあらゆる種類の便利な機能があり、Razorが特定の例であるため、.NETStandardの方が重要です。

すべてのライブラリが.NETCoreのみに移行しているわけではありません（たとえば、 Microsoft.Extensions.*は.NET Standardのままです）。 @ daveaglickがhttps：//で行ったように、影響を受ける特定のシナリオを提供すると役立つ可能性があります。 github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416なので、

ASP.NET Coreは、.NET Coreで多くの変更と新しいAPIを推進しており、それらの機能を使用したいという願望を理解できます（これは、それらのユースケースの1つであったため）。 そうでなければ、それは少し自己敗北します。

一方、他のランタイムがASP.NET Core 3.0の実装に取り​​掛かったときにサポートできるように、それらも.NETStandardバージョンであると便利です。 現実的にはそうなることはありません（.NET Standard 2.1はまだ完成しておらず、それ以降のバージョンである必要があるため）。

おそらく、ASP.NET Coreアプリモデルは、後日、問題が発生したときに.NET Standardに戻るのでしょうか。 現在機能しているため、.NET Standardプロセスでは常に動きが速すぎる可能性がありますか？

@gulbanana comを使用して.netフレームワーク上のasp.netコアがある場合はどうなりますか？ または、.netフレームワークのみをサポートするnugetパッケージがありますか？

移動を行うべきかどうかという問題ではなく、いつ行うべきかという問題ではなかったと思います。
前回これが〜議論〜の大騒ぎを引き起こしたとき、エコシステムは既存のアプリを移植する準備ができていませんでした。
現在、Windows互換パッケージがあり、WinFormsとWPFが.NETCoreに導入されています。

.NET Framework用の2.1パッケージは、適切な移行パスを提供すると思います。netfxで2.1に移行してから、.NETCoreに移行します。

これはAngularJSとAngularに似ています。既存のコードを最新の1. *のコンポーネント（ハード）に移行してから、最新のAngularバージョンに移行します。 それは非常に難しいですが、実行可能です。

CoreCLRとmonoの両方にエキサイティングな新機能が追加されています（s）.NET Frameworkに到達することは決してないので、ある時点で.NETFrameworkを残しておくのは合理的と思われます。
これは、必ずしも.NET Frameworkを「サポートしない」ことを意味するのではなく、そのままにしておくことを意味します。

従来のASP（ASP.NETではなく、本当に古いもの）を使用しているサイトがまだいくつかあります。 それはまだ機能し、Windowsで出荷されます、あなたはそれで新しいアプリを作成しないでしょう。
10年以内に、これは.NETFrameworkの状況になる可能性があると思います。

要求された2.1の拡張サポートに同意しますが、チームが2.1パッケージのダウンロードを監視して、サポートが必要かどうか（=重要なセキュリティ問題を修正する必要があるかどうか）を2〜3年以内に決定してほしいと思います。少し長いです。

@ John0King COMは、.NET

また、.NETRemotingなどを使用したレガシーアプリケーションもあります。
しかし、それらはすでにレガシーです。

世界は基本的にレガシーコードで実行されており、今後もそうし続けます。 これは、何かを「サポートされている」または「新しい」ものに移植するかどうかのビジネス上の決定ですが、それまでは、 @ dylanbeattieが次のように

ええ、何かが「サポートされている」かどうかはそれほど重要ではないことを言及する価値があります-古いアプリは、それが利用可能であるという理由だけで実際に新しいフレームワークに移植する必要はありません。 Webサーバーは、セキュリティ上の脅威があるため、少し特殊なケースです。 LTSのセキュリティパッチサポートの長期化は人々を助けるでしょう。

@gulbanana Webフレームワーク、基盤となるアプリケーションフレームワークを変更してから、互換性のない依存関係をアップグレードまたは交換する必要があるため、System.WebからASP.NET Coreへのアプリケーションの移植に高い

その後、費用便益分析を行うとしたら、それがASP.NETCoreの利益になるかどうかはわかりません。

これは、プロジェクトベースでソフトウェアを開発する場合に特に当てはまります。もちろん、各プロジェクトは予算内で十分に厳しいため、定期的なメンテナンスはもちろん可能ですが、明確な具体的なメリットなしにフレームワーク全体を交換することを正当化することは困難です。 。

その後、費用便益分析を行うとしたら、それがASP.NETCoreの利益になるかどうかはわかりません。

だから..まあ..それを残しますか？ ASP.NET Coreに移行する必要がない
皮肉なことを言っているわけではありませんが、アプリケーションを「最新のもの」に保つ必要がない場合は、移植しないでください。 利点は、.NET Framework / ASP.NETクラシックが引き続きサポートされ、アプリケーションがそのまま実行されることです。

移植はしばしば不必要です、私は同意します-ASP.NETからASP.NET Coreへの大きな変更であり、その変更の一部はCoreがより速く動くことです（3.0は2.0と同様にAPIを壊す変更もあります）。 この議論の問題は、もはや大きな変化ではありません、しかし、ほとんどのASP.NETコアアプリケーションのためのcorefx変化にnetfxについてです

これにより、移行がより段階的かつ簡単になる「ASP.NET Core on.NETFramework」の中間点が削除されたようです。 この後、ASP.NET MVC / WebAPI / etcを移行します。 ASP.NET Coreへのアプリケーションは非常に大きな変更であり、Webフレームワークと基盤となるランタイムの両方を一度に変更します。

大規模なエンタープライズアプリの場合、これは非常に苦痛だと思います。 私のチームはこれを1、2年注意深く見守っていますが、次の点に注意してください。

• EntityFrameworkCoreは、必要なすべてを実行するわけではありません。.NETCore3.0でのみ、EntityFramework自体が.NETCoreに導入されます。 その量とそれが実行されるプラットフォームは、明確に伝達されているとは思わないので、プレビュービルドを実際にテストして確認する必要があります。

• ODataの話は、大規模なアプリケーションの観点からはまだ空中に浮かんでいるようです。 OData 3 /System.Data.ServicesからOData4 / WebAPI以降に移動するには、_かなりの_量の（再）作業が必要です。 これは数年前から解決されていない問題であり、正直なところ、解決されるかどうかはわかりません。

さらに、サポートされていない他のすべてのテクノロジー（AppDomains、Remotingなど）を並行してまたは後の段階で実行するのではなく、_最初に_削除する必要があります。

さらに、サポートされていない他のすべてのテクノロジー（AppDomains、Remotingなど）を並行して、または後の段階で実行するのではなく、最初に削除する必要があります。

最初に2.1に移行できないのはなぜですか？

@davidfowl 3.0 / 3.1 / etcでいくつかの新機能に

移行に必要なASP.NETCore 2.1の新機能？ .NETFramework上のASP.NETCore2.1を意味しました。

この問題が数年前に発生したとき、すべてを移植するのが難しすぎると不平を言ったことを覚えています。 これは、当時私が行った古いgithubコメントからの引用です。

ActiveDirectoryまたはOfficeCOMの自動化を使用する、またはSystem.Drawingベースのライブラリを使用してサムネイルを作成する、またはWPFアプリとコードを共有するWebアプリを想像してみてください。

すばらしいのは、.NET Core 3.0以降、これらすべてのシナリオがサポートされていることです。 それを簡単にするために膨大な量の作業が行われました。

@davidfowl私もそうしました。

仮に、ASP.NET / MVC / WebAPIで使用している機能が、2.1では実装されていないが、それ以降のバージョンで提供されている可能性があります。 その場合、2.1は実行可能な足がかりにはなりません。

ただし、2.1にない重要なものが実際に必要かどうかを確認するには、より徹底的な分析を行う必要があります。

@PinpointTownes

残念ながら、これは1つのことを浮き彫りにしているだけです。

あなたは間違っていませんが、.NET標準の目標をいくらか知らないのです。 この規格の目標は、イノベーションを推進することではなく、収束を推進することでした。 その角度からアプローチする場合、どの概念が普遍的であるか、あるいは普遍的である必要があるかを考える必要があるため、設計上遅れる必要があります。 これがどのように見えるか知りたい場合は、すべての.NET実装所有者によるレビュー後、過去3週間にマージした35以上のPRをご覧ください。

.NET Coreは、イノベーションが発生する最先端のプラットフォームであると考えています。 チャーンとそれに伴うリスクに対処できるようにするいくつかの機能を構築しました。これは、.NETFrameworkよりもはるかに優れています。 ただし、.NETエコシステムにとって重要なすべての機能が.NETCoreエクスペリエンスの一部であるとは限りません。 たとえば、事前コンパイルはXamarinとUnityではるかに目立ちます。 また、.NET Coreの機能を標準に追加する場合は、それらのランタイム環境、オペレーティングシステム、およびハードウェアの制約を考慮する必要があります。

おそらくそれは私だけですが、なぜそれがnetcoreapp （定義上、新しいAPIを最初に取得したもの）ほど速く移動しなかったのか理解できませんでした。

現実には、「速く動き、物事を壊す」ことは、私たちの聴衆全体が評価するものではありません。 .NET CoreのメジャーバージョンでAPIを削除する必要がある場合は十分に悪いですが、.NETStandardで行うことは事実上不可能です。 したがって、少しゆっくりと移動し、追加するのに十分成熟していると思われる概念のみを含める必要があります。

約束したことを実行します。ASP.NETCoreに移行するときに信頼していた人にとって、.NET Frameworkは行き止まりではなく、ゆっくりと進化する安定したフレームワークにします。

それでも、.NETFrameworkが最終的に.NETCoreのすべての機能を取得することを前提としていますが、時間の遅れがあります。 それは単に現実的ではないことを学びました。 .NET Coreを大幅に革新しないことを決定するか、新機能のかなりの部分が.NETFrameworkに戻らないというエンジニアリングの現実を受け入れることができます。 .NET Frameworkのコアバリュープロップ（成熟した豊富な開発プラットフォーム）を維持しながら、お客様が.NET Coreの新機能を活用できるようにするために、お客様に最善のサービスを提供できると確信しています。 今後は、 Span<T>場合と同様に、ランタイム、ライブラリ、言語の変更が必要な領域で、より積極的にイノベーションを起こすことを期待しています。 これらはコストがかかりますが、人々がコードを書く方法を変えることもできます。 この良い例は、インターフェイスのデフォルトの実装、算術演算を含むジェネリックコードを作成する機能、ハードウェア組み込み関数を使用できることなどです。これらの機能は、リスクのために.NETFrameworkにバックポートしない種類のものである可能性があります。 。

私たちのWebスタックがこれらの機能を利用できることは完全に理にかなっていると思います。 これを行う唯一の方法は、ASP.NETCoreを.NETFrameworkでも実行するための制限を取り除くことです。 ASP.NETCoreを.NETFrameworkで実行した当初の理由は、.NETCoreに十分なAPIがなかったためであることに注意してください。 .NET Core 3.0には、 120kを超える

@ yaakov-hもしそうなら、私は驚きます。 あなたが分析をするとき、私に知らせてください。

あなたは間違っていませんが、.NET標準の目標をいくらか知らないのです。 この規格の目標は、イノベーションを推進することではなく、収束を推進することでした。

そして、あなたは正反対の方向に向かっています。ASP.NETCore用の.NET Standardは十分に速く移動しないために放棄し、ASP.NETCoreを対象とするNuGetパッケージもそれを放棄することを余儀なくされます。 それが収束だと思わせないでください、私はそれほど無知ではありません：rofl：

その角度からアプローチする場合、どの概念が普遍的であるか、あるいは普遍的である必要があるかを考える必要があるため、設計上遅れる必要があります。

これは選択であり、技術的な問題ではありません。特定のAPIをcorefx / coreclrに含めるかどうかを確認するときに、新しいバージョンの.NETStandardに含める必要があるかどうかを判断することを妨げるものは何もありません。

これがどのように見えるか知りたい場合は、すべての.NET実装所有者によるレビュー後、過去3週間にマージした35以上のPRをご覧ください。

私はそれが簡単な作業だと言っているわけではなく、それは私の主張を証明しています：あなたは新しいnetstandardバージョンを作成するのを待ちすぎています、そしてあなたがそれをすることはまれです、それはたくさんの同時に新しいAPI。

現実には、「速く動き、物事を壊す」ことは、私たちの聴衆全体が評価するものではありません。

それでも、これがすべてのASP.NET Coreイテレーションの仕組みです。バージョン用に作成されたパッケージを次のバージョンと互換性のないものにする（場合によっては大規模な）重大な変更が伴います。 それでも、多くのオプションを提供することはできません。以前のバージョンとは関係のないサポートポリシーを使用して、レガシーバージョンを永久に更新または維持します（ASP.NET/.NETだけでなく、Windowsのライフサイクルも多くなります）。最近は短くなっています）。

今後は、Spanの場合と同様に、ランタイム、ライブラリ、言語の変更が必要な領域で、より積極的にイノベーションを起こすことを期待しています。。 これらはコストがかかりますが、人々がコードを書く方法を変えることもできます。 この良い例は、インターフェイスのデフォルトの実装、算術演算を含むジェネリックコードを作成する機能、ハードウェア組み込み関数を使用できることなどです。これらの機能は、リスクのために.NETFrameworkにバックポートしない種類のものである可能性があります。 。

これらの「危険な」変更を含む新しいサイドバイサイドの.NETFrameworkバージョン（たとえば.NET Framework 5）を導入できない理由は何ですか？ 繰り返しますが、これは技術的な問題ではありません。

Microsoft.AspNetCore.Razor.LanguageとMicrosoft.AspNetCore.Razorをaspnet外で宣伝したり、 netstandard波に乗せたりするチャンスはありますか？ かみそりはhtml専用ですが、メールテンプレートに使用するライブラリがいくつかあります。そのまま使用し続けることができれば素晴らしいと思います。

この動きは、以前に言われたことに反して、.NETロードマップでのnetstandardのサポートの欠如を示しています。 主要な新しいライブラリの1つがnetstandardを放棄した場合、その採用の前兆にはなりません。

これは、Microsoftがオープンに開発した他のすべての新しいライブラリに対して.NET開発者が予想すべき動きですか？ コミュニティは、netstandardの将来とその採用についてより公式な声明を得ることができますか？

@terrajobstすべてのプラットフォームにまたがる準備ができていないように見える（そしておそらくそうなることはない）APIを.netstandardに追加しないことに関してあなたが指摘していることを完全に理解しています。 ただし、たとえばUWPでサポートする準備ができていない場合でも、netstandard2.0の導入を妨げることはありませんでした。 私が理解しているように、しばらくしてからそのサポートを追加するのにかなりの努力が必要でしたが、あなたはそれを行いました。 それはどういうわけか別の話でしたか？

そして、あなたは正反対の方向に向かっています。ASP.NETCoreの.NET Standardは、十分な速度で移動しないため、放棄します。

ASP.NET Coreは、.NETFrameworkと.NETCoreでのみ意味がありますが、.NETStandardはすべての人が実装する必要があります。 たとえば、Xamarin / UnityにサーバーWebスタックで主に使用されるAPIを提供させることは単に意味がありません。

これは選択であり、技術的な問題ではありません。特定のAPIをcorefx / coreclrに含めるかどうかを確認するときに、新しいバージョンの.NETStandardに含める必要があるかどうかを判断することを妨げるものは何もありません。

これは、.NET Corev1の時代に行ったことです。 標準を.NETCoreからv2で分離しました。 そうです、それは選択ですが、それは恣意的なものではありませんでした。 目標は、.NETCoreを使用してより高速に移動できるようにすることでした。 単一のランタイム以外のN個のランタイムのコンテキストで機能がどのように機能するかを検討するには、単に時間がかかります。

同時に大量の新しいAPIが付属しているため、これは面倒なプロセスです。

いいえ、複数の実装者と複数の異なるランタイムを使用して設計を確認する必要があるため、面倒なプロセスです。 ただし、事後にそれを行うと、集約およびバンドルは、私たちが進むにつれてそれを調整する必要があるよりもはるかに安価です。 CoreFxレポは大量のレポです。 XamarinとUnityは、Firehoseから飲んで、CoreFxに関するすべてのAPIディスカッションにサブスクライブするよりも、バンドルされている機能を確認する方がはるかに簡単です。

それでも、これがすべてのASP.NET Coreイテレーションの仕組みです。バージョン用に作成されたパッケージを次のバージョンと互換性のないものにする（場合によっては大規模な）重大な変更が伴います。

そして、これが気に入らないので、.NETStandardを.NETCoreと一致させることで、すべての人にそれを課したいですか？ 申し訳ありませんが、この議論は私には意味がありません。

これらの「危険な」変更を含む新しいサイドバイサイドの.NETFrameworkバージョン（たとえば.NET Framework 5）を導入できない理由は何ですか？ 繰り返しますが、これは技術的な問題ではありません。

技術的な問題ではないと思われる理由は何ですか？ .NET Frameworkのバージョンを並べて出荷することは、実行可能なソリューションではありません。 まず第一に、それはOSコンポーネントであり、したがってサービスが必要であるという事実のためにかなり高価です。 .NET Framework3.5および4.xの分岐/サービス/パッチ適用戦略がどれほど複雑かはわかりません。 3番目のものを追加することはほとんど実用的ではありません。 次に、これを行うだけでもリスクがあります。アクティベーションを変更する必要があるため、COMでアクティベートされた管理対象コンポーネントなどの正しいランタイムを選択します。 そして、それは、私たちがインプロセスを並べてサポートするかどうか、そしていくつの組み合わせをサポートするかという問題を提起します。 それは簡単な作業ではなく、リスクもありません。

収束だと思わせないで

@PinpointTownesそれは収束です.... NETCoreで😉

たとえば、Xamarin / UnityにサーバーWebスタックで主に使用されるAPIを提供させることは単に意味がありません。

.NETCoreだけでなくUWPでもASP.NETCoreを使用したいという人がいるので、Xamarinでも使用してみませんか？ https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

意味のないもの（あなたにとって）とサポートしたくないものには違いがあります。

CoreFxレポは大量のレポです。 XamarinとUnityは、Firehoseから飲んで、CoreFxに関するすべてのAPIディスカッションにサブスクライブするよりも、バンドルされている機能を確認する方がはるかに簡単です。

私はそのような極端なアプローチを提案しましたか？ 新しい標準APIが.NETCoreに導入されてから間もなく（つまり数週間）、ほこりが少し落ち着いたら話し合うなど、妥協点があると思います。

そして、これが気に入らないので、.NETStandardを.NETCoreと一致させることで、すべての人にそれを課したいですか？ 申し訳ありませんが、この議論は私には意味がありません。

あなたは私がそれを好きではないと思いますが、あなたは間違っています：私は動きの速いものが好きです-60のNuGetパッケージのメンテナーとしてそれが時々かなり苦痛であるとしても。 私が嫌いなのは、全員が同じ速度で移動することを強制し、道路の真ん中で人々が追いつけないために放棄することです。

.NETStandardを.NETCoreと同じくらい速く動かすことは、罰と見なすことができるのかわかりません。最新のnetstandard TFMをターゲットにする必要はありません。 これは、最新のAPIセットが必要な場合にのみ行います。 不要な場合は、古いバージョンをターゲットにして、パッケージをより幅広いプラットフォームのセットで使用できるようにします。

平均的な開発者の観点からは、それは完全な勝利です。最新の.NETCoreランタイムで使用できる最新の光沢のあるAPIを使用してパッケージを作成できます。 他のプラットフォームが追いつくと、パッケージもそこで使用できます。マルチターゲティングを使用したり、パッケージを再公開したりする必要はありません。

まず第一に、それはOSコンポーネントであり、したがってサービスが必要であるという事実のためにかなり高価です。 .NET Framework3.5および4.xの分岐/サービス/パッチ適用戦略がどれほど複雑かはわかりません。 3番目のものを追加することはほとんど実用的ではありません。

ASP.NET Core3.0の.NETFrameworkサポートを削除しても、.NET Coreに移行できない人にとっては理想的ではないのと同じように、それはあなたにとって理想的ではないと確かに想像できます。 しかし、私はあなた（マイクロソフト）が平均的な企業が.NET Coreに移行しなければならないよりもはるかに多くのリソースを持っていると考えるのは完全に間違っていますか？ （私はあなたが所有および管理していない外部依存関係についてさえ話していません）。

次に、これを行うだけでもリスクがあります。アクティベーションを変更する必要があるため、COMでアクティベートされた管理対象コンポーネントなどの正しいランタイムを選択します。 そして、それは、私たちがインプロセスを並べてサポートするかどうか、そしていくつの組み合わせをサポートするかという問題を提起します。 それは簡単な作業ではなく、リスクもありません。

確かに、それは簡単ではありません。 そしてそれは危険です。 しかし、それはメジャーバージョンが示していることです：物事が壊れるかもしれないリスクがあります。 さて、ASP.NET Core 2.2に永遠にとどまることを余儀なくされることと、ASP.NET Core3.0を使用するために.NETFramework 5に移行するリスクを冒すこととの間で、人々は何を選ぶと思いますか？

しかし、私はあなた（マイクロソフト）が平均的な企業が.NET Coreに移行しなければならないよりもはるかに多くのリソースを持っていると考えるのは完全に間違っていますか？

私の経験では、人々は一貫して、現状だけをサポートするために、私たちが持っているリソースの数と、私たちがしなければならないリソースの量を過大評価しています。

しかし、この場合、それはリソースの問題でさえありません。 オープンソースの.NETFrameworkを使用するだけで、すべてのPRが.NETFrameworkに直接送信される可能性があります。 それは、機械の複雑さと互換性のリスクと関係があります。 これは一元化されたフレームワークであり、リリースを並べても、アクティベーションなどの共通のリソースセットを共有します。 私たちは、賢い人にそれが正しく出てきたら割り当てることができるということを何度も間違っていることが証明されています。

さて、ASP.NET Core 2.2に永遠にとどまることを余儀なくされることと、ASP.NET Core3.0を使用するために.NETFramework 5に移行するリスクを冒すこととの間で、人々は何を選ぶと思いますか？

私の見解では、サポートされているAPIのエンベロープを.NET Coreにプッシュして、.NETCoreの機能を.NETFrameworkにバックポートしようとするよりも、より多くの人が.NETCoreにスムーズに移行できるようにする方がはるかに実用的です。 そこでできることは、原因の悲しみだけです。 サイドバイサイドリリースには、ITにインストールを許可する、インストーラーにチェーンする、ホスティング業者からマシンが提供されるのを待つなど、他の課題が伴うことに注意してください。

これはASP.NETCoreのすべての部分に適用されますか、それともいくつかの便利で一般的に再利用可能な部分（ Microsoft.AspNetCore.Http.Extensions ）は.NET Standardに残りますか？

@andriysavin

@terrajobstすべてのプラットフォームにまたがる準備ができていないように見える（そしておそらくそうなることはない）APIを.netstandardに追加しないことに関してあなたが指摘していることを完全に理解しています。 ただし、たとえばUWPでサポートする準備ができていない場合でも、netstandard2.0の導入を妨げることはありませんでした。 私が理解しているように、しばらくしてからそのサポートを追加するのにかなりの努力が必要でしたが、あなたはそれを行いました。 それはどういうわけか別の話でしたか？

はい。 .NET Standard 2.0には、まったく新しいAPIがありませんでした。 これは、.NETFrameworkとXamarinの共通部分として定義されました。 デルタが何であれ、既存のコードとの妥当な互換性バーに到達するために必要なのは単にそれです。 唯一の作業はUWPと.NETCoreでした。 そして、これらのコードベースは元々、実行不可能であることがわかった.NETの最新のリセットとして設計されました。 追加されるAPI /テクノロジーはほぼ成熟しており、制約のある環境（Xamarin iOS）でサポートされているため、複雑さは低く、移植作業は1トンに過ぎません。

しかし今、私たちはまったく新しい機能と概念を追加することについて話している、そしてそれは運転する別の獣である。

私の経験では、人々は一貫して、現状だけをサポートするために、私たちが持っているリソースの数と、私たちがしなければならないリソースの量を過大評価しています。

私の経験では、Microsoftは常に、現状だけをサポートするために、私たちが持っているリソースの数と、私たちがしなければならない作業の量を過大評価しています。 あなたの議論は本当に両方向で機能します：sweat_smile：

私の見解では、サポートされているAPIのエンベロープを.NET Coreにプッシュして、.NETCoreの機能を.NETFrameworkにバックポートしようとするよりも、より多くの人が.NETCoreにスムーズに移行できるようにする方がはるかに実用的です。

はっきりさせておきましょう。私はそれですべてですが、.NET Coreが追いついて、.NETFrameworkが持っていたほとんど/すべての機能を実装するまで機能しません。 それまでは、機能やAPIが不足しているためにブロックされているユーザーが表示されます。 不足しているものが非常に多いため、ビッグレガシーのモノリシックアプリが問題を発生させることなく.NETCoreに移行できると考えるのは合理的ではありません。

私はあなたの懸念を確実に理解しています。 しかし、最終的には、あなたの生活を楽にするものは、私たちの生活をより苦痛にする可能性があります。.NETFrameworkをサポートしないことは、私たちにとってPITAになるでしょう。

私はあなたの懸念を確実に理解しています。 しかし、最終的には、あなたの生活を楽にするものは、私たちの生活をより苦痛にする可能性があります。.NETFrameworkをサポートしないことは、私たちにとってPITAになるでしょう。

私が理解しているその部分。 ただし、代替手段は.NET Frameworkの機能を増やすことではなく、ASP.NETCoreの機能を弱めることです。

過去数年間、.NETFrameworkと.NETCoreを共進化させてきました。 仕事を避けようとしていたわけではありません。 私は個人的に、たとえばバインディングリダイレクトの悪夢を修正しようとしているランタイムエンジニアと話をするのに何億時間も費やしました。 または、4.6.1で壊れた.NET Standard2.0サポート。 やってみました。 それは意志力の問題ではなく、実用性の問題です。

.NET Coreが追いつき、.NETFrameworkが持っていたほとんど/すべての機能を実装するまで機能しません。

私の経験では、いくつかのAPIの利用可能性は、それさえも関係ありません。 企業環境で非常に重要なのは、サポートと展開の複雑さです。 また、 「サポートされ、出荷され、オペレーティングシステムで自動的に更新される」ことは、.NET Core LTSリリースから得られる3年間のサポートと、現在も使用されている厄介な展開よりもはるかに魅力的です。 そして、ここで正直に言うと、.NETCoreとASP.NETCoreの安定したツールはまだありません。1年後も現状維持であると自信を持って言えます。 リリースごとに変更があり、3.0の新しいフレームワークリファレンスが適切なソリューションになるかどうかは誰にもわかりません。 だから、それはあなたがただ物事を更新したり、それが行われるべき方法でそれを行うことができない企業を扱うとき、間違いなく大きな問題点です。 通常、彼らは過去5年以上のやり方でそれをやりたいと思っています。 彼らはフレームワークによって台無しにされており、彼らにとってそれほど快適ではないものはほとんど見事なものです。

ただし、代替手段は.NET Frameworkの機能を増やすことではなく、ASP.NETCoreの機能を弱めることです。

これは、昨年私が提案したこととほぼ同じです。.NETFrameworkで引き続き機能するASP.NET Coreパッケージ（たとえば、 netstandard20とnetcoreapp30をターゲットにすることにより）が、より限定された機能セットを提供し、はるかに少ない興味深いパフォーマンス。 時々人々が望むのはうまくいくものです。 新しい光沢のあるものではありません。 超高速のものではありません。

過去数年間、.NETFrameworkと.NETCoreを共進化させてきました。 仕事を避けようとしていたわけではありません。 私は個人的に、たとえばバインディングリダイレクトの悪夢を修正しようとしているランタイムエンジニアと話をするのに何億時間も費やしました。 または、4.6.1で壊れた.NET Standard2.0サポート。 やってみました。 それは意志力の問題ではなく、実用性の問題です。

私たちは明らかにすべてに同意しませんが、言うまでもなく、私はあなたたちがしたことに非常に感銘を受けています（はい、 HttpClientしゃっくりのようなものは対処するのがかなり苦痛

あの男になって本当にごめんなさい：sweat_smile：

これまでのところ、ASP.NET Coreの面では、Razorは、一般的にASP.NETCoreの外部で利用できるようにしたいと考えている具体的なものとして登場しました。 それは合理的だと思います。そのような分野をもっと特定する必要があります（より有益な議論になるでしょう）。 ASP.NET Core 2.1および2.2は引き続き.NETFrameworkをサポートしますが、.NETFrameworkを永久にサポートすることは合理的ではないと思います。

@terrajobst

この良い例は、インターフェイスのデフォルトの実装です...そして、これらの機能は、リスクのために.NETFrameworkにバックポートしない種類のものである可能性があります。

そしてその声明でDIMは死んだ。 重要なのは、レガシーの進化です。 それがレガシーに適用されず、レガシーと新しいものを橋渡ししようとしているライブラリにも適用できない場合、それは誰の助けにもなりません。

これまでのところ、ASP.NET Coreの面では、Razorは、一般的にASP.NETCoreの外部で利用できるようにしたいと考えている具体的なものとして登場しました。

Microsoft.Owin.Security.Interop backcompat 'パッケージ、ASP.NET Core Data Protection、および基礎となる依存関係をリストに追加できます。

これは、昨年私が提案したこととほぼ同じです。.NETFrameworkで引き続き機能するASP.NET Coreパッケージ（たとえば、 netstandard20とnetcoreapp30をターゲットにすることにより）が、より限定された機能セットを提供し、はるかに少ない興味深いパフォーマンス。 時々人々が望むのはうまくいくものです。 新しい光沢のあるものではありません。 超高速のものではありません。

これについても説明しました。 そこにある課題は、基盤となるプラットフォームAPIと機能の一部をパブリックAPIにブリードする必要があるため、これを完全にカプセル化できないことです。 つまり、ASP.NET Coreのミドルウェアに統合するライブラリも、複数の実装を提供する必要があります。 しかし、さらに悪いことに、パブリックエクスチェンジタイプはコアのみであり、互換性がなくなったASP.NET Coreの2つのバージョンが作成される可能性があるため、分裂を作成しないと不可能な場合もあります。

@HaloFour

そしてその声明でDIMは死んだ。 レガシーの進化の全体的なポイント。 それがレガシーに適用されず、レガシーと新しいものを橋渡ししようとしているライブラリにも適用できない場合、それは誰の助けにもなりません。

レガシーコードを既存のインストールと混同していると思います。 DIMを.NETFrameworkに移植した場合でも、この機能を使用するには、新しいバージョンにアップグレードする必要があります。 おそらく.NETCoreのみの機能ですが、.NET Frameworkに対してコンパイルされたコードを使用しながら、.NETCoreを進化させることができます。

@terrajobstあなたはUnityについて言及し続けています。 彼らは独自のCLR実装を持っていますか？ 彼らがMonoを使っているという印象を受けました。

Unityには、独自の非モノAOTバージョンであるIL2CPPを含む、複数の.NET実装があります。 それらのクラスライブラリとサポートされているAPIも、標準のMonoとは異なります。

@terrajobst

レガシーコードを既存のインストールと混同していると思います。

まだ積極的に維持および開発されている「レガシー」アプリケーションに関しては、大きな違いはありません。 フレームワークのアップグレードと.NETCoreへの移行の必要性には大きな違いがあります。

おそらく.NETCoreのみの機能ですが、.NET Frameworkに対してコンパイルされたコードを使用しながら、.NETCoreを進化させることができます。

何のために？ .NET Coreのこれらの「進化した」APIは、.NETStandardには適用されません。 また、ライブラリライターは、独自のAPIで互換性のない相違をどのように作成するかを考えると、それに触れることはありません。

@HaloFourに同意します。 DIMを利用できるのは、.NET Coreのみを対象とするライブラリ作成者だけです。つまり、基本的にはcorefxとaspnetcoreだけです。 他の誰かがそれに近づくとは想像できません。

DIMを利用できるのは、.NET Coreのみを対象とするライブラリ作成者だけです。つまり、基本的にはcorefxとaspnetcoreだけです。

別の言い方をすれば、それを使用できない唯一のプラットフォームは.NET Frameworkであり、.NET Core、Xamarin、Mono、およびUnityでは使用できます。

他の誰かがそれに近づくとは想像できません。

このような機能には、ライブラリでホッケースティックの採用パターンがあると思います。これは理にかなっています。 最終的に、ライブラリの作成者は常にリーチと機能セットを検討します。 アプリの場合、ターゲット環境を知っている（そして多くの場合制御している）ため、決定が簡単です。

@ yaakov-h

これはASP.NETCoreのすべての部分に適用されますか...

どのパッケージに何が起こっているかの暫定リストはここにあります： https ：

@terrajobstデフォルトのインターフェイス実装はC＃の言語機能になると思いました。 .NET Frameworkはそれをサポートしないと言って、あなたは実際には.Net FrameworkがC＃バージョン7.3またはせいぜい次のバージョンで永遠に立ち往生するだろうと言っています。 その相違は、誰もがエコシステムで起こりたいことではありません。

いくつかの.NETCoreワークロードを実行しますが、複数年の.NETFXであるプロジェクトも実行します。

.NET Coreへの安全なアップグレード（最初は.NET Frameworkでも）は非常に大きな作業です。

マイクロソフトが、プロジェクトを少なくとも.NETFX上のASP.NETからASP.NETCore、.NET FXに「アップグレード」するのに役立つツールをリリースする予定はありますか？

新しいVSプロジェクトの作成、ビューのインポート、プロジェクトの再調整に関するMSDNの記事がありますが、レガシーなもの（Global asax、routing、....）がたくさんあるので、古い方法と新しい方法を文書化した中心的な場所があればいいのにと思います。すべてを移植します。

これらの「危険な」変更を含む新しいサイドバイサイドの.NETFrameworkバージョン（たとえば.NET Framework 5）を導入できない理由は何ですか？

その時点で、.NET Core 3.0ではないことに利点はありますか？ そのすでに並んでいて、「危険な」変化があります。 .NET Coreの次の機能セットには、.NET Framework 6などが必要ですか？

すでに.NETCore 2.0にAPIがあり、.NET Core 3.0に新しい機能セットが導入されているため、.NETCoreは「.NETFramework5」を満たしていません。Framework4.xは非常に長いLTSバージョンです。

推測では; この時点で、.NETFrameworkを.NETCoreとして動作するように変更するのではなく、.NET Core3.0が.NETFramework4.xから持つ特定の特定されたギャップをカバーすることはエンジニアリング上の小さな課題になります。

実用的な提案：ASP.NET Core 2.2が一般的な3年を超える_延長された_サポート期間でLTSになる可能性はありますか？

これにより、（1）実際に.NET Coreに移行するための十分な時間と、（2）ASP.NET MVCからASPに移行するための十分な動機を与えながら、今のところ完全なフレームワークに固執する必要がある人々を満足させると確信しています。 .NET Core（.NET Coreにまだ移動できない場合）。

これはまだ明確ではないと思います。.NETFramework上のASP.NETCoreは.NETCore 2.1 LTSに準拠していますか、それとも.NET Framework v4.6.1 +のサポートサイクルに準拠していますか（つまり、.NET FXで実行されているため）。予見可能な将来にサポートされますか？

@mythz ASP.NET Coreは、実行しているプラ​​ットフォームに関係なく、 サポートライフサイクルの対象です。

ここでの最善の策は、実際に.net標準を少なくとも3.0、4.0、および5.0に更新し、ある時点で.netフレームワークが.netコアに完全に移行されることを実際に伝達することだと思います。
他のすべては半分焼かれています。

今日、すでにLTSサポートにお金を払っている顧客がいますか？ （詳細な質問です）。 十分な時間はどれくらいですか？

@terrajobst本当の問題は、netstandardがモノリシックであるということです。 netstandardは必要ないようですが、代わりにバージョン管理されたAPIセットが必要です。 これらはTFMにもなります。たとえば、base2.0 + spanは2つのAPIセットになります。

次に、APIセットに基づいて標準を進化させ、場合によっては完全なフレームワークで一部のAPIセットのみを実装することができます。 （これにより、一部のAPIセットを省略できるため、他のプラットフォームでnetstandardを実装しやすくなります）。

APIセットを配置すると、完全なフレームワークなど、サポートの少ないターゲット用にASP.NETCoreの個別のビルドが作成されます。

@Sebazzzそれは非常に奇妙なトピックです。 netstandardを再設計しようとして、このスレッドを脱線させることはできませんか？ そのためにdotnet / standardに問題を提出することができますが、このアイデアはすでに提案され、撃墜されたと言います。

@davidfowl私はそれが「奇妙な」または「

@Sebazzz @masonwheeler

@terrajobst本当の問題は、netstandardがモノリシックであるということです。 netstandardは必要ないようですが、代わりにバージョン管理されたAPIセットが必要です。 これらはTFMにもなります。たとえば、base2.0 + spanは2つのAPIセットになります。

これをさまざまなフレーバーで試しました（プロファイル、PCL、緩いコントラクト、および.NET Standard 1.xになったバージョン管理されたコントラクトセット）。 時間の経過とともに互換性ルールをツール化して理解することは非常に困難です（プラットフォームのバージョンとAPIセットが進化するとき）。 現在の.NET標準は、これまで実行可能なモデルに最も近いものです。 完璧ではありませんが、少なくとも数分で説明でき、人々の頭が爆発することはありません。

.NET Standardについて詳しく説明できてうれしいですが、 @ davidfowlがここに属していないことに同意します。 必要に応じて、 https：//github.com/dotnet/standardで問題をください。

編集私は.NET標準コメントをトピック外としてマークしました。

@ Shayan-To

@terrajobstデフォルトのインターフェイス実装はC＃の言語機能になると思いました。 .NET Frameworkはそれをサポートしないと言って、あなたは実際には.Net FrameworkがC＃バージョン7.3またはせいぜい次のバージョンで永遠に立ち往生するだろうと言っています。 その相違は、誰もがエコシステムで起こりたいことではありません。

これは、実行時の変更だけでなく言語の変更も必要とする機能です。 型システムのルールを変更するという点で、ジェネリックスに似ています。 一般的に、C＃は、コンパイルするフレームワークを認識していません（フレームワークが提供するAPIを説明する一連の参照アセンブリが渡されるだけです）。 APIの変更を必要としないC＃機能（たとえば、null合体演算子?.または式を破棄するための_ ）がサポートされます。 これは、最新のコンパイラと言語バージョンを使用し、対応するAPIがない古いバージョンの.NET Frameworkを対象とした場合に、コンパイラが常に機能していた方法と同じです。 たとえば、.NET Framework 3.5または4.0をターゲットにしている場合、async / awaitは機能しません。 Taskを使用するには、4.5以上である必要があります。

皆さんのために私が感じている人... netコアに完全に移行することは、imo、長期的に行うための正しいことであり、私は提供する革新のより速いペースを好みます。

しかし、人々はこれに腹を立てるでしょう。それのかなりの部分はコミュニケーションです。 2.1 3年LTSが発表されたとき、fullfxの人々は、3.0に移行しても、fullfxを実行できると期待されていました。彼らは、asp.netコアを雇用主とクライアントに販売し、独自の評判を確立しました。今、彼らは敷物が彼らの下に引き出されたように感じるでしょう。 彼らが長期的なソリューションとして販売したもの、asp.netの未来は、現在（知覚的に）3年間のサポートに制限されています

今すぐ移行するのが簡単であることは問題ではありません。プラットフォームの切り替えは常にリスクであり、それはこれらの人々が予期していなかった、計画も予算も立てなかったリスクと開発の努力になります。

ほとんどの開発者は.netコア3に移行したいと考えていますが、依存関係がある可能性があることに加えて、変更できない（またはリスクの変更を伴う）ため、移行を再度提案し、今回は長期的な投資になることを約束する必要があります。 。それは難しい販売かもしれませんが、3年のサポートサイクルのために彼らはそれをしなければならないと感じるでしょう。

繰り返しになりますが、私はfullfxを削除するつもりですが、LTSをサポートする最後のバージョンのLTSをかなりの量拡張することを検討する必要があると思います。 また、ブログ、会議/セッションなどのように、どの部分が依然としてネットスタンダードであり、2.1 /フルフレームワークを使用している人々がそれらをどのように活用できるかなど、非常に明確に伝達します。

そうでなければ、物語が「マイクロソフトは専任の開発者を再び置き去りにする」という大きなリスクがあります。それが公正で

LTSの時間についてはどのくらい合理的ですか？

たぶん6年？ でも、レセプションではメッセージングが大きな役割を果たすと思います。結局、何があっても動揺する人もいるでしょう：/

@davidfowl @ aL3891

参考までに、Java LTSの「プレミアサポート」は5年間で、「延長サポート」（有料）はさらに3年間です。 LTSリリースで先月リリースされたJava11は、それぞれ2023年9月と2026年9月までサポートされます。

「拡張サポート」LTSオファリングを調査しており、詳細がわかり次第お知らせします。 これにより、サポートされているASP.NET Core on .NET Frameworkバージョン（2.1.x）を必要とするお客様に、現在のLTSサポート期間よりも長いオプションが提供される可能性があります。

また、参考までに、ASP.NET Community Standupでの本日の発表について少しお話ししました： https ： ＆ list = PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL

.net標準をターゲットにしてください。 asp.netコアは.netstandard2.1または3.0をターゲットにして、後でmonoと.netframeworkをキャッチアップさせることができますが、asp.netコアがnetcoreappターゲットにする場合、任意のライブラリがタイプにアクセスしようとしますそれらのaspnetcoreライブラリの内、 .netcoreappライブラリである必要があります。

.netコアは常に.net frameworkおよびmonoよりも速くリリースされます。
マイクロソフトがより多くのフレームワーク/ライブラリをnetcoreappターゲットする場合、monoおよび.netframeworkは最終的に.netcoreappアセンブリを消費します（これにより、nugetターゲット.netcoreappもより多くのライブラリが作成されます）。

もしそうなら、 .netstandardは.netcoreapp 😂

@ John0Kingは、ASP.NETCore以外で必要なタイプの例を

1. @pokeが述べたようにかみそり
2. MVCフィルターインターフェイス/属性（いくつかのActionFiltersとTagHelpersを含むヘルパークラスライブラリと、string、int、long ectの一般的な静的/拡張メソッドがあります。MVCパッケージを参照するためにPrivateAssert="All"を使用するため、これを使用する場合他の場所のライブラリ、そのプロジェクトはMVCアセンブリを参照する必要はありません。ライブラリを2つに分離する必要があると思います。1つは.netstandard 、もう.netcoreapp ）

別の質問は次のとおりです。どのタイプのクラスライブラリを作成する必要があるかは問題になりますか？ （ .netstandard vs .netcoreapp ）。 今日はasp.netコア2.1では非常に簡単です。 クラスライブラリには.netstandardを選択し、Webプロジェクトには.netcoreappまたはnet461を選択します。

マイクロソフトがnetcoreappに対してより多くのフレームワーク/ライブラリをターゲットにし始めた場合、monoおよび.netframeworkは最終的に.netcoreappアセンブリを消費します（これにより、nugetターゲットの.netcoreappにもより多くのライブラリが作成されます）

これは、 .netstandardライブラリに何が来るのかと.netcoreappライブラリに何が来るのかを区別しようと努力しない場合に発生します。

MVCフィルターインターフェイス/属性（いくつかのActionFiltersとTagHelpersを含むヘルパークラスライブラリと、string、int、long ectの一般的な静的/拡張メソッドがあります。PrivateAssert= "All"を使用してMVCパッケージを参照するため、このライブラリを使用します他の場所では、そのプロジェクトはMVCアセンブリを参照する必要はありません。ライブラリを2つに分離する必要があると思います。1つは.netstandardで、もう1つは.netcoreappです）

詳細を教えていただけますか？ これは意味がありません。 MVCはASP.NETCoreフレームワークであり、スタンドアロンで使用することはできません。

@davidfowlこのライブラリはヘルパークラスライブラリですみその拡張メソッドを使用できます。

@davidfowlこのライブラリはヘルパークラスライブラリですみその拡張メソッドを使用できます。

まだわかりません。 MVCのものと他のランダムなものがあるライブラリについて話しているのですか？

残念ながら、そのようなことはエンタープライズソフトウェアでは一般的です-「ヘルパーライブラリ」には、MVC用の会社のユーティリティ+ WPF用の会社のユーティリティ+ telerik用の会社のユーティリティがあります...
'.NET'が単一の統合プラットフォームであった場合はより理にかなっています。

@davidfowlはい。 ヘルパーライブラリには、これらのタイプをどこでも使用できるクラス/メソッドがいくつかあります。 そして、mvcプロジェクトでこのライブラリを参照すると、mvc関連のクラス/メソッドを使用できます。

まあ、これはあなたのライブラリをより良く階層化することを強制するだけです😉

残念ながら、これは、オンプレミス展開をまだ行っている人は、3年以上ソフトウェアをサポートできないことを意味します。 たとえば、.netcore 3.0を対象とするアプリをリリースするとすぐに、顧客は3年を経過し、アップグレードを余儀なくされます。 うまくいく業界もあれば、そうでない業界もあります。

これが最大の問題であり、多くの人にとって.netCoreが完全に機能しなくなっていると思います。 私は実際、これが最終的に正しい方向であることに同意しますが、これにより多くの場所が.netCoreに移行するのを防ぐことができると確信しています。

これについての.netチームからの返信を本当にお願いします。

重要なのは、ASP.NETCoreはWebフレームワークです。 まったく変更せずに3年以上ウェブサイトを運営するのはどの業界で安全ですか？ それがセキュリティの脆弱性でない場合、それはあなたが依存していたもの、またはTLS 1.4を非推奨にするブラウザ、またはサイトが新しいウォッチレットで機能することを要求するユーザーです。

その期間中、わずかな調整と小さな依存関係の更新で逃げることができるはずですが、何年もの間Webアプリケーションをまったく更新しない計画は無謀です。

ASP.NET Core 2.1のLTS期間を5〜7年に増やすだけで、これはコミュニティにとってより口に合うと思います。

私たちの経験では、企業の開発は「最新の」Web開発と比較して氷河期のペースで進んでいますが、それでも彼らはかなり古いプラットフォームに新しい投資をしていないことを確認したいと考えています。 これらのアプリケーションは、3年以内に大規模な重大なアップグレードを行うことができるのは言うまでもなく、「起動」するまでに1年以上かかることがよくあります。 これらのエンタープライズ（通常は内部向けのみ）のWebアプリケーションは、多くの場合7〜10年間サポートされますが、ASP.NET Core2.1のLTSが10年間になるのは無理だと思います。 5年は3年よりも良い解決策のように感じます。7年はほぼすべての人を快適にする数字です。

そして、これが必要なのは、ASP.NET Core 3.0では、.NETFrameworkのサポートを削除するという重大な変更が必要なためです。 重大な変更がそれほど大きくないと仮定すると、将来のLTSリリースはこの標準に保持されるべきではありません。

.NETStandardを.NETCoreと同じくらい速く動かすことは、罰と見なすことができるのかわかりません。最新のnetstandard TFMをターゲットにする必要はありません。 これは、最新のAPIセットが必要な場合にのみ行います。 不要な場合は、古いバージョンをターゲットにして、パッケージをより幅広いプラットフォームのセットで使用できるようにします。

プラットフォームが追いつかない場合はどうなりますか？ 次に、機能Aを必要とするnetstandard2.3を対象とするライブラリが作成されます。この機能は、.NET CoreとXamarinでのみ使用できますが、.NETFrameworkでは使用できません。

次に、 netstandard2.4が出てきて、いくつかの新しいApiがあり、これらのAPIのいくつかは.NETFrameworkに移植できます。 今何？

.NET Frameworkで実行されるnetstandad2.4の機能を必要とするライブラリをどのようにターゲットにしますが、 netstandard2.4はnetstandard2.2実装できないため、.NETFrameworkをターゲットにできません。

次に、3つのプラットフォームにクロスコンパイルする必要があります。
netstandard2.2古いプラットフォームとのためのnet4xネット標準のためだけに追加された機能をサポートするためにnetstandad2.4とnet4x can also implement but not support because of APIs that went into netstandard2.3`を。

これにより、パッケージの作成者がナゲットパッケージを簡単に作成して出荷できるようになりますか？

すべてのプラットフォームがサポートする最小公分母がnetstandardに流れ込む場合にのみ、すべてが機能します。 さらに多くのAPIがPlatformNotSupported例外をスローすることを望まない限り、そうでない場合は、netstandard内で断片化が発生します。

ASP.NET Core3.0の.NETFrameworkサポートを削除しても、.NET Coreに移行できない人にとっては理想的ではないのと同じように、それはあなたにとって理想的ではないと確かに想像できます。 しかし、私はあなた（マイクロソフト）が平均的な企業が.NET Coreに移行しなければならないよりもはるかに多くのリソースを持っていると考えるのは完全に間違っていますか？ （私はあなたが所有および管理していない外部依存関係についてさえ話していません）。

ここで実際の問題は何ですか？ ASP.NETLegacyからASP.NETCoreに移行できない場合、ASP.NETCoreが.NETFrameworkを対象としているかどうかに関係なく、移行することはできません。 できない、またはできない理由として最も可能性が高いのは、 System.Web固有のライブラリであり、.NETFramework上のASP.NETCoreでも機能しません。 現在アプリケーションを持っている人々は、明らかにすでにワーキングセットを持っています。

そして、.NETFramework上のASP.NETCore 2.1を既に使用している人は、それが機能しているのであれば、なぜ移動したいのでしょうか。 明らかに、必要なものはすべてすでにそこにあり、ASP.NET Core3.0に新しく登場する他のすべてのものがあれば便利です。

その他について：
アプリケーションを.NETCoreに移行する方法はたくさんあります。つまり、古いモノリシックアプリケーションからパーツを切り離し、マイクロサービスとして再実装することで、リスクを軽減し、時間をかけて分散させることができます。

プラットフォームが追いつかない場合はどうなりますか？ 次に、.NET CoreとXamarinでのみ使用できるが、.NETFrameworkでは使用できない機能Aを必要とするnetstandard2.3を対象とするライブラリが作成されます。

.NET Standardをサポートするプラットフォームの大部分でAPIを実装できない場合は、標準の一部にすべきではない可能性が高いですよね？ （実際には、Xamarinが実行されるプラットフォームは一般的にはるかに制約されているため、逆の可能性が非常に高くなります）。 .NET Standardに含めるためのAPIを確認するときに、この種の問題が検出されると思いますが、間違っている可能性があります。

そして、.NETFramework上のASP.NETCore 2.1を既に使用している人は、それが機能しているのであれば、なぜ移動したいのでしょうか。

• サポート？ （3年間のサポートはめちゃくちゃ短いです）
• 3.0にのみ存在するバグ修正？ （LTSバージョンは重大なバグと脆弱性の修正のみを取得します）
• 最新のASP.NETCoreバージョンとのみ互換性のあるライブラリを参照する必要がありますか？

アプリケーションを.NETCoreに移行する方法はたくさんあります。つまり、古いモノリシックアプリケーションからパーツを切り離し、マイクロサービスとして再実装することで、リスクを軽減し、時間をかけて分散させることができます。

ええ、確かに、理論的にはそれがそれに対処するための理想的な方法です。 だが：

• 一部のアプリは、制御できない外部ライブラリに依存しています。 ライブラリが.NETCoreで機能せず、ベンダーがライブラリを移植したくない（または移植できない）場合は、運が悪いことになります。
• .NET Coreへの移行には、コストと時間がかかる可能性があります。 マイクロソフトの最高のチームでさえもそれに苦労しているとしたら、平均的なチームにとっては本当に簡単だと思いますか？ Entity Framework6が最終的に.NETStandardと互換性を持つようになるには、3.0を待つ必要があります。

私が言っていることを誤解しないでください。私はすべて、新しいアプリに.NETCoreを使用することに賛成です。 しかし、ASP.NETCoreが.NETFrameworkと互換性があるという事実は、多くの企業が妥当なコストでASP.NETCoreに移行するのに役立ちました。 その「それほど難しくない」移行パスがなければ、これほど人気が​​あったことはなかったと私は確信しています。

マイクロソフト、2.1のサポートを拡張するように依頼するのは多すぎるでしょうか？ 2021年は私たちにとって十分な長さではなく、その変換を行うのに十分なリソース/時間がありません。 多分少なくとも2022年まで？ 苦痛なものではありますが、1年余分に変更を加える機会が本当にあります。

サードパーティベンダーの多くは、ライブラリを.Net Core互換性にまだ移行していないことに注意してください。これが、ハングアップの最大の理由です。

参考までにhttps://github.com/aspnet/AspNetCore/issues/3753#issuecomment-434521855

必要に応じてLTSを拡張することを検討していますが、.NETFX上のASP.NETCoreを.NETFXサポートサイクルにローリングするIMOも考慮する必要があります。 初心者にとっては、.NET Frameworkのさまざまな部分をさまざまなサポートサイクルに配置することは混乱を招き、一緒にロールする方が理にかなっています。 第二に、2.1のコードはすでに作成され、リリースされ、依存しているため、2.1をサポートするために必要なリソースは、.NET Core3.0と連携して積極的に開発するよりもはるかに少なくなります。 同じチームが両方を維持している場合は、最近のより馴染みのあるモジュラーASP.NET Coreアクティブコードベースは、まったく異なる従来のASP.NETコードベースよりもサポートが容易になると思います。

MSが2012年にSilverlight5のEOLを発表したとき、2021年10月までサポートを続けています（2015年にChromeで、2017年にFirefoxで削除されましたが）。 これは完全に放棄されたテクノロジーのためのものであり、ここではそうではありません。ほぼ同じコードベース、プログラミングモデル、アクティブな開発チームがまだ取り組んでおり、放棄されている.NETFramework上の既存のソフトウェアのみを実行しています。

この発表の前は、MSが.NET Frameworkを放棄することはなく、Windowsのみのワークロードに最適であり（クロスプラットフォーム/高性能ワークロードの.NET Coreとは対照的に）、ASP.NETCoreが未来であるという強力なメッセージがありました。複数のプラットフォームを対象とするライブラリを開発するためのソリューションとして.NETStandardを使用して、将来的に.NETFrameworkと.NETCoreの両方をサポートするプログラミングモデル。

.NET Coreがすべての新しいプロジェクトの未来であることは明らかですが、これは、これまでこのガイダンスに基づいて決定を下した既存の投資と既存の顧客をどのように扱うかについてです。 既存のシステムをサポートする必要がある場合、既存の.NET Devチームはどのように進歩しますか？新しいアプリを開発するためにコンテキストを切り替える間、既存のASP.NET（既存のスキル/知識は日ごとに古くなっています）を維持することを余儀なくされます.NETCore上。

.NET Frameworkでシステムを維持することを余儀なくされた場合は、アクティブなナレッジベース/エコシステムにアクセスできる新しいASP.NETプログラミングモデルでシステムを開発し、古いASP.NETの使用に戻すことを余儀なくされます。無期限ですが、FX上のASP.NET CoreがWebFormsと同じレベルのサポートを備えていない限り、それは不可能です。

MSには、FX上のASP.NET Coreを「安定した」開発環境として位置付ける機会もあります（つまり、ASP.NET Core 2.1で修正されています）。 .NET Coreが開始されてから、ここ数年、.NET開発者になるのは簡単ではありませんでした。 .NET Core <1.xに移植しようとするすべての努力を事実上放棄しなければならず、絶え間ない変化の流れに追いつくのは困難でした。それは.NET Core2.xが可能になるまででした。それをサポートし、既存のアプリを移行します。 一方、既存のASP.NET Framework開発者は、選択したプラットフォームが停滞し、新しいASP.NET Coreプログラミングモデルに取って代わられ、ひいては既存のスキル/知識が損なわれているのを見てきました。 FXでのASP.NETCoreのサポートを終了すると、システム全体を.NET Coreにアップグレードできない限り、放棄されたプラットフォームで実行されるリスク（偶発的なフォールバックなし）が発生する.NET Coreへの一般的な段階的移行戦略が無効になります（リスクこれにより、移行の試行が考慮されなくなる可能性があります）また、日常的に作業している既存のシステムを移行できない場合、将来のASP.NETCore開発モデルに参加できる機会が失われます。 WebFormsと同じサポートを享受している場合にのみ可能です。これはまだ検討中です。

誰も言及していません。asp.netコアアプリケーションでは、WCFサービスをホストする必要があり、これが.netフレームワークから移行する唯一の問題点です。 残念ながら、.net Core3でのサーバー側のwcfサポートに関するニュースはありません。

@DamianEdwards @ davidfowl @ natemcmaster私たちは同じ船に乗っています。 私の会社には、.NetFullフレームワーク上のASP.NetCoreで実行される製品が多数ありますが、販売する業界の動きが遅いため、3年よりもはるかに長い期間これらをサポートしています。 ASP.netコアアプリケーションをASP.Netに移植し直す必要があるため、.netコア2.2のLTSを拡張することは私たちの状況では無意味です。 確かにこれはポイントの人を打ち負かしています！ 短期間でアプリケーションをサポートすることを提案しますか？ 残念ながら、これも私たちが制御できないものです。 私たちが働いている業界は、新しいソフトウェアを展開するだけで1年かかる場合があります。

残念ながら、これは、オンプレミス展開をまだ行っている人は、3年以上ソフトウェアをサポートできないことを意味します。 たとえば、.netcore 3.0を対象とするアプリをリリースするとすぐに、顧客は3年を経過し、アップグレードを余儀なくされます。 うまくいく業界もあれば、そうでない業界もあります。

これが最大の問題であり、多くの人にとって.netCoreが完全に機能しなくなっていると思います。 私は実際、これが最終的に正しい方向であることに同意しますが、これにより多くの場所が.netCoreに移行するのを防ぐことができると確信しています。

これについての.netチームからの返信を本当にお願いします。

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

まあ、これはあなたのライブラリをより良く階層化することを強制するだけです😉

この議論は反対方向に働いていませんか？

私が理解できないのは、ASP.NET Coreの適切な階層化アーキテクチャを実際に妨げるものは何ですか？
したがって、はい、 Span<T>などの一部のランタイム機能は.Net Frameworkで使用できませんが、まったく使用できないという意味ではありません。 利用可能ですが、.NetCoreほどのパフォーマンスはありません。 私たちはそれに対処することができました。

一部の低レベルの実装は、特に.netコアおよび.net標準のバリエーションで実装できます。 APIは通常NuGetパッケージとして利用できるため、その余地はあまりないと思います。
多くのライブラリ作成者は、プラットフォームごとに異なる実装をサポートしています。これは常に行われていることです。

.Net Framework / .NetStandardをサポートできない原因を詳しく説明してください。 プラットフォーム固有の実装を実現する方法で抽象化できない簡単な例をいくつか挙げてください。

.Net Framework / .NetStandardをサポートできなくなります。 プラットフォーム固有の実装を実現する方法で抽象化できない簡単な例をいくつか挙げてください。

頭から離れて、ランタイムまたはフレームワークの変更が必要なアイテム

• 内部GCポインター; したがって、オブジェクトなしでのみ参照から安全なスパンを作成します： MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• デフォルトのインターフェース実装
• スレッドプールのカスタム作業項目
• 基本タイプのスパンオーバーロード：Stream、Sockets、TextReader / TextWriter、WebSockets
• 基本タイプのIAsyncDisposableオーバーロード：Stream、Sockets、TextReader / TextWriter、WebSocketsなど。
• IAsyncEnumerator基本タイプのオーバーロード：Stream、Sockets、TextReader / TextWriter、WebSocketsなど。

ボーナスアイテム

• ハードウェア組み込み関数（x86、x64、ARM）
• エスケープ分析（スタックへの新しい割り当て）
• サイドバイサイドランタイムバージョン
• バインディングリダイレクトとバージョン管理の修正

なぜnetframeworkをサポートしなくなったnetstandardバージョンを入手できないのか理解できません。 Windows Phoneと同じように、1.2以降のネットスタンダードサポートはありません。 標準を前進させて、netcore、mono、xamarinなどの実装を最終的にまたはまったく一致させないのはなぜですか。 次に、カバレッジを最大化するために実装するネットスタンダードバージョンを決定するのはライブラリメーカー次第です。

この変更により、xamarinとmonoはaspnetcoreを使用できなくなります。 これにより、ライブラリはnetcoreとnetstandardの両方をターゲットにするか、さらに悪いことにnetstandardをすべて一緒に放棄し、netcoreのみをターゲットにするように強制されます。

これは最終的にnetstandardの死につながります。

.Net Framework / .NetStandardをサポートできなくなります。 プラットフォーム固有の実装を実現する方法で抽象化できない簡単な例をいくつか挙げてください。

頭から離れて、ランタイムまたはフレームワークの変更が必要なアイテム

• 内部GCポインター; したがって、オブジェクトなしでのみ参照から安全なスパンを作成します： MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• デフォルトのインターフェース実装
• スレッドプールのカスタム作業項目
• 基本タイプのスパンオーバーロード：Stream、Sockets、TextReader / TextWriter、WebSockets
• 基本タイプのIAsyncDisposableオーバーロード：Stream、Sockets、TextReader / TextWriter、WebSocketsなど。
• 基本タイプ（Stream、Sockets、TextReader / TextWriter、WebSocketsなど）でのIAsyncEnumeratorオーバーロード。

ボーナスアイテム

• ハードウェア組み込み関数（x86、x64、ARM）
• エスケープ分析（スタックへの新しい割り当て）
• サイドバイサイドランタイムバージョン
• バインディングリダイレクトとバージョン管理の修正

その最初のリストの項目は、netstandardへの変更の候補になるもののように聞こえますか？

それらのほとんどは、他のランタイムに持ち込むことが不可能ではないようですが、デフォルトのインターフェイス実装を.NETFrameworkに持ち込むために新しいバージョンのCLRを改訂したいと思う人はいないようです。

同時に、Microsoftは、.NETFrameworkと永久に互換性のないバージョンの.NETStandardを推進したいとは思わないようです。 そうでなければ、これは実際には問題にはなりません。 netstandard30またはnetstandard40で前進し、フレームワークのサポートを終了するだけです。 .NETCoreがこれらの新しい標準の1つをターゲットにしている。

このスレッドなどは、マイクロソフトが効果的に隅に塗りつぶした結果だと思います。

同時に、Microsoftは、.NETFrameworkと永久に互換性のないバージョンの.NETStandardを推進したいとは思わないようです。

この不誠実な; .NET Standard 2.1は完成中であり、基本フレームワークタイプでのSpanオーバーロードを含む、.NET Standard2.0を超える3104の新しいAPIがあります。 .NETFrameworkとの互換性がなくなる可能性があります。

.NETStandardはまだ前進しています。

そうでなければ、これは実際には問題にはなりません。netstandard30またはnetstandard40を進めて、フレームワークのサポートを終了するだけです。 .NETCoreがこれらの新しい標準の1つをターゲットにしている。

問題は、フレームワークだけでなく、すべてのランタイムを新しい標準の1つと互換性がないようにすることです。 その後、すべての規格と互換性がなくなります。 .NET Standardに組み込まれる内容は、実装可能なものとしてさまざまなランタイムによって合意される必要があります。

MonoとUnityのさまざまなGCは、間もなく内部ポインターをサポートしますか？ それらを.NETStandardに追加しない場合、それらを処理するためにGCが変更されるまで、将来の.NETStandardからそれらをその.NETStandardからブロックします。 しかしながら; 現在実装できるAPIを追加し、将来の標準のために実装できないAPIを保存することをお勧めします。

Coreに追加されているAPIは、永久に永続的に修正され、すべてのランタイムを強制する適切なAPIですか。 実装するために、次の標準との互換性を望んでいますか？

一部のCore2.1 APIは、プレビュー1とプレビュー2の間で変更されました（使用状況のフィードバックのため）。 そのため、リリースされるまでCore Xで新しいAPIが何であるかを知ることすら困難であり、その時点でそのセットは石になります。 次に、すべてのランタイムが実装する（または取り残される）ために標準に追加する正しいセットはどれですか。

.NET標準へのアプローチは、標準が受け入れられる前に2つのブラウザーが機能を実装する必要がある場合、ブラウザー標準よりもさらに積極的です。

新しい.NETStandardが.NETCoreと同時に出荷され、すべてのランタイムが即座にそれを実装し、ASP.NETCoreが.NETStandardを介してすべての新しいAPIを使用できると便利です。 しかし、理想としては素晴らしいものですが、実用的でもありません。 .NETCoreに実装されていない承認済みのAPIもます。

基本的な質問は、ASP.NET Coreが要求されたAPIを使用して、同梱されている.NET Coreバージョンで出荷できるかどうかです（同時に出荷されます）。 または、以前のバージョンの.NET Coreに同梱されていたAPIのみを使用できますか？したがって、その.NETCoreの.NETStandardバージョンになる可能性がありますか？ （.NET Standardバージョンのように見えるため、現在.NETCoreよりもapis1バージョンで遅れています。サンプルサイズ1を使用）

ASP.NETCoreがAPIを使用できる場合。 次に、APIは使用状況テストを取得し、それらが適切なAPIであるかどうかを評価します。 そうでない場合は、より良いAPIを提案できます。 ASP.NET Coreがそれらを使用できない場合、それらが.NET Standardの候補になったときに、それらが優れたAPIであるかどうかはまだかなり不明です。

デフォルトのインターフェイス実装を.NETFrameworkに導入するために、CLRを新しいバージョンに改訂することは誰も望んでいません。

従来の.NETFrameworkワークロード（WinFormsとWPFを含む）をサポートすることによる.NET Coreは、本質的にCLRの改訂版です。 しかし、より持続可能で将来性のある方法で行われていますか？

この不誠実な; .NET Standard 2.1が完成し、ベースフレームワークタイプのスパンオーバーロードを含む、.NET Standard2.0を超える3104の新しいAPIがあります。 .NETFrameworkとの互換性がなくなる可能性があります。

.NET Framework4.8と.NETFramework 4.9を含みますか？

将来のフレームワークの更新でこれらの新しいAPIが取得される可能性は常にあります。 現時点では、.NET FrameworkがDIMを取得することはないため、DIMメソッドを使用するインターフェイスを.NETFrameworkに移植することはできません。

従来の.NETFrameworkワークロード（WinFormsとWPFを含む）をサポートすることによる.NET Coreは、本質的にCLRの改訂版です。 しかし、より持続可能で将来性のある方法で行われていますか？

そして、後方耐性ではありません。 Microsoftが.NETCoreで実行されているPaint.Netのようなものを披露したのと同じように、私は既存のサーバー側プロジェクトを.NET Coreで実行できず、ほとんどの人も実行できません。

新しい.NETStandardが.NETCoreと同時に出荷され、すべてのランタイムが即座にそれを実装し、ASP.NETCoreが.NETStandardを介してすべての新しいAPIを使用できると便利です。 しかし、理想としては素晴らしいものですが、実用的でもありません。

これも実用的ではないかもしれませんが、ASP.NET Coreの2つのバージョンがあれば、全体的に少し幸せになると思います。

• .NET _Core_に関連付けられており、必要に応じて新しいAPIを使用できる、動きの速い最先端バージョン。
• .NET _Standard_に関連付けられ、より多くの場所で実行される、動きの遅いLTSバージョン。 最終的には古い最先端のビルドに追いつきますが、常に遅れをとっています。

それを.NETCoreに結び付けることで、誰もが満足できるわけではないというトレードオフを余儀なくされます。 最速のアプローチの背後にある理由はわかりますが、.NETエコシステム全体に対する正当な懸念もあります。

• .NET Coreに関連付けられており、必要に応じて新しいAPIを使用できる、動きの速い最先端バージョン。
• .NET Standardに関連付けられ、より多くの場所で実行される、動きの遅いLTSバージョン。 最終的には古い最先端のビルドに追いつきますが、常に遅れをとっています。

したがって、ASP.NET Core3.0が.NETCore3.0としてのみリリースされた場合。 しかし、後日、APIを備えた.NET標準でした。 .NETStandardでもあるASP.NETCore 3.xのパッケージがリリースされました（ASP.NET Coreが4.0に移行した場合でも）。 それはあなたの要件を満たしますか？

@ yaakov-h

.NET Standardに関連付けられ、より多くの場所で実行される、動きの遅いLTSバージョン。 最終的には古い最先端のビルドに追いつきますが、常に遅れをとっています。

これは何を意味するのでしょうか？ @DamianEdwardsが言及した拡張サポートを使用して、ASP.NET

ASP.NET Core 2.1は、次のような拡張サポートとともにいつでも使用できます。

コミュニティを分割しないでください!!
（投票に基づく）1/3の開発者がasp.netコア2.1にとどまると思いますか？ または、ライブラリの2つのバージョンを維持する必要があるnugetパッケージを作成する2/3の開発者を期待しますか？

@benaadams

したがって、ASP.NET Core3.0が.NETCore3.0としてのみリリースされた場合。 しかし、後日、APIを備えた.NET標準でした。 .NETStandardでもあるASP.NETCore 3.xのパッケージがリリースされました（ASP.NET Coreが4.0に移行した場合でも）。 それはあなたの要件を満たしますか？

正確に。

@davidfowl

@DamianEdwardsが言及した拡張サポートを使用して、ASP.NET

ここに矛盾するメッセージがあるようです：

1. 古いLTSバージョンである2.1をそのまま使用しても問題ありません。
2. ASP.NET Coreは非常に高速であるため、.NETCoreと後続の.NETStandardの間で1つのリリースサイクルを待つことすらできません。

（2）は多くの混乱と取り残されることへの恐れを引き起こしていると思います。

@ John0King

（投票に基づく）1/3の開発者がasp.netコア2.1にとどまると思いますか？ または、ライブラリの2つのバージョンを維持する必要があるnugetパッケージを作成する2/3の開発者を期待しますか？

ライブラリの作成者は、サポートに関心のあるASP.NET Coreの最小バージョンを決定し、それをターゲットにすることを期待しています。 それは彼らが今日すでにしていることです。 一部のライブラリはASP.NETCore 1.xおよび2.xをサポートし、一部は2.xのみをサポートします。 これも違いはありません。

@ yaakov-h

矛盾するメッセージが何であるかはよくわかりません。 現在の2.1はLTSであり、.NETCoreおよび.NETFrameworkで実行され、3年間サポートされます。 これは新しいメッセージではなく、最初から持っていたメッセージと同じです。

ASP.NET Coreは非常に高速であるため、.NETCoreと後続の.NETStandardの間で1つのリリースサイクルを待つことすらできません。

これは、ここで行われたコメントに基づく推測です。 公式には、.NET Coreの出荷サイクルに関連付けられており、リリースごとに新しいAPIを追加して使用しています。 .NETFrameworkで実行されているASP.NETCoreは、永続的なものになることを意図したものではなく（ASP.NET Coreとも呼ばれます）、常に踏み台として意図されていました。 顧客が完全に機能するアプリケーションを合理的に作成できるように、コアAPIを十分に追加し直す必要がありました。

msチームからのこれに対する応答はありますか？

残念ながら、これは、オンプレミス展開をまだ行っている人は、3年以上ソフトウェアをサポートできないことを意味します。 たとえば、.netcore 3.0を対象とするアプリをリリースするとすぐに、顧客は3年を経過し、アップグレードを余儀なくされます。 うまくいく業界もあれば、そうでない業界もあります。

これが最大の問題であり、多くの人にとって.netCoreが完全に機能しなくなっていると思います。 私は実際、これが最終的に正しい方向であることに同意しますが、これにより多くの場所が.netCoreに移行するのを防ぐことができると確信しています。

これについての.netチームからの返信を本当にお願いします。

残念ながら、これは、オンプレミス展開をまだ行っている人は、3年以上ソフトウェアをサポートできないことを意味します

それはただのでたらめです、あなたは実際にただアップグレードすることができます。 それが機能しないのは組み込み環境内だけですが、組み込みソフトウェアには3年間のサポート期間よりもはるかに多くの問題があります。

@schmitchどういう意味か

@davidfowl

そのサポートが10年だったとしても、不満を言う人を満足させることはできないと思います。

人々がそれをどのように受け止めるかわからない、この決定効果は、彼らが移動するために販売されたプラットフォームに直面しているすべての人に未来がないだけでなく、最新のプログラミングモデルに基づいて構築された既存の投資は実行に向かっています3年以内にサポートされていないプラットフォーム（この発表の時点で）。 最初に.NETFrameworkへの移行を介して.NETCoreに慎重に段階的に移行することを考えた他の人は、フォールバックの偶発性がないというリスクに直面しています。新しい.NETCoreランタイムまたはバストで実行されています。

プラットフォーム上で作成される価値は指数関数的に大きく、プラットフォーム自体の価値よりも大きいため、開発者プラットフォーム自体を目標にするべきではありません。 このようなブラインドサイドの動きは、プラットフォームの速度を上げるためのリソースの最大効率が、プラットフォーム上に作成されているエコシステムへの投資よりも重要であるように見えます。 .NET Core 2.1ビットのインクはまだ乾燥していませんが、既存のシステム（FX上）は、エコシステムに追加する資産や価値ではなく、（最小限のサポートを提供するという観点から）すでに責任として扱われています。

すでに述べたように、エンタープライズシステムは氷河のペースで移動でき、多くの場合、開発者のチームのバランスを取りながら、継続的な改善を実現します。これにより、多くの従業員と顧客が一定のROIを得ることができます。 多くの移行は、慎重な計画と厳密なテストを伴う「機内」で行う必要があります。これには数年かかる場合があります。価値を創造し、スクランブルして、サポートが下から引き出されているプラ​​ットフォームから降りることを好む時間です。 大規模なブラウンフィールドシステムは、iPhoneのように簡単に廃棄でき、数年ごとにシームレスにアップグレードできる商品ではありません。古くて長いシステムが開発されているほど、より多くの価値が投資され、移行が難しくなります。これは特に重要になります。移行に価値がないことを考えると、吸収するのは困難です。リソースが必要であり、機会費用を吸収し、リスクが高まります。彼らが期待できる最善の方法は、既存のシステムを以前とまったく同じように実行する完璧な移行です。

FXサポートに有効期限が設定されていても、それを過ぎて実行されている既存のシステムは、障害にぶつかるか、そうでなければ移行することが不可能でした。 では、何がガイダンスになるのでしょうか。

ASP.NET Core 2.1はすでに開発されており、FX / .NETCoreでASP.NETCoreを実行するための努力は、すでに投資された埋没費用です。 したがって、（LTS後の）すでに開発されたプラットフォームを維持するためのMSリソースの問題として、人気のあるプラットフォームを放棄するために生成されるコスト、悪意、慣性の累積量に対して決定を組み立てる必要があります。

その時何が求められているのか理解できません。 LTSのライフサイクルは、2.1がリリースされてから変更されていません。 .NETCoreまたは.NETFrameworkのいずれのLTSバージョンでアプリを作成した場合でも、「サポートされていない」状態になるまで3年かかります。 サポートの観点から、ラグがあなたの下からどのように引っ張られているのかよくわかりませんが、それは変わっていません。 プラットフォームのアップデートを取得するには、アップグレードする必要があります。

今、私は2.1が最後のLTS版は、.NET Framework上で支持されることにアップグレードする場所がありません意味を理解しますが、LTSのサポートを拡張しているのはでてくる。APIがあるため、アプリケーションでもこれらの6年後、.NETのコアに移動することはできませ

その時何が求められているのか理解できません。

このスレッドは、MSにさまざまなレベルのコミットメントを要求しています。.NETCoreと連携して開発を続け、ASP.NET Core 2.1を放棄せずに「スロートレイン」で開発し、WebFormsと同じレベルのサポートを維持し、LTSを拡張します。 。 私の好みは、ASP.NET Coreのホスティングオプションとしてそれを放棄しないことです（編集：上記のものがより望ましい）。既存の.NETに多くのユーティリティを提供しながら、.NETCoreのみv3 +を抑制しません。 FX投資。

2.1が.NETFrameworkでサポートされている最後のLTSバージョンであるということは、アップグレードする場所がないことを意味することを理解しました。

つまり、サポートされていないプラットフォームになっているため、サポートされていないEOLの終わりに達する前に、溶岩のように扱い、スクランブルして降りる必要があります。

• .NET Coreに移行するためのステージングプラットフォームとして使用することを考えた人は、移行に予想よりも時間がかかる場合や、依存関係がある場合に障害にぶつかると、サポートされていないプラットフォームで立ち往生するリスクに直面するため、実行不可能なオプションになりました。依存しているのは.NETCoreでは実行できません。
• 企業の既存のマネージドインフラストラクチャの.NETFrameworkサーバーの使用を余儀なくされた人は、新しい開発モデルとエコシステムの使用に参加できず、既存の従来のASP.NETの知識/スキルの価値が日々低下することを確認する必要があります。
• チームは、既存の.NET Frameworkに必要なシステムを移行できず、.NETCore上の新しいASP.NETCoreプロジェクトにコンテキストを切り替える必要があります。
• 予算、計画、投資の決定に基づいて信頼していたガイダンスが変更されたため、計画外の移行を余儀なくされることを望んでいる組織はありません。

ここでも、グリーンフィールドプロジェクト、とにかく.NET Coreに移行できる、または移行を計画している人、またはレガシーシステムを維持する必要がない人にとっては問題ではありませんが、既存の.NETFXエコシステムとASP.NETCoreに影響を与えます。 .NET FXでホストするという一般的なオプションの利用を検討できなくなったため、状況は悪化しました。

完璧な世界では、誰もが.NET Coreを使用しますが、この決定によって切り下げられている.NETFXへのかなりの投資が存在します。

APIがないために、この6年経ってもアプリケーションが.NET Coreに移行できない場合は、

.NET Coreに移行できない、または移行したくない人はたくさんいます。彼らは、従来のASP.NETと同じレベルのサポートを共有したいと考えています（現在のメッセージングでは無期限に提案されています）。

APIがないことが移行を妨げる唯一の理由ではありません。たとえば、開発チームが作成した依存関係に依存している可能性があります。APIは変更できず、安全にリファクタリングできない重要なコンポーネントです（たとえば、テストなし）、他の.NET FXのみのシステムと共有され、予算や変更能力がない別の部門によって維持されているか、企業が管理するインフラストラクチャが.NETFrameworkサーバーでの実行のみをサポートしているなどの外部要因が原因です。

この種の決定で.NETStandardを殺してくれてありがとう。

まだCoreをターゲットにしていないサードパーティのアセンブリがたくさんあるため、これまで.NETCoreを無視してきました。

Coreをサポートすることをいとわないベンダーの多くは、中途半端な方法でサポートしています。たとえば、.NETFrameworkでのみ使用可能なネイティブAPIを使用しないマネージドODP.NETです。

次に、この種の決定を行います。

いいえ、Microsoftが.NET Frameworkをサポートするには手間がかかりすぎて、最初からプッシュした.NET Standardを提供できないという理由だけで、.NETCoreをより早く採用することはありません。

@davidfowl .NET Coreへの移行を困難にしている-WCF （多くの既存のエンタープライズアプリがそれを使用しています、他の人がすでにその問題を提起していると思います）、および.NET Core / NETのAdomdライブラリの欠如標準（SSASとの通信用であり、エンタープライズアプリでも使用され、SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-coreで追跡されます）。 他のいくつか（winforms）は.net core 3互換性パックで修正する必要があります（イェーイ！）-それが実際にどのように機能するかを待つ必要があります。

@mythz

このスレッドは、MSにさまざまなレベルのコミットメントを要求しています。.NETCoreと連携して開発を続け、ASP.NET Core 2.1を放棄せずに「スロートレイン」で開発し、WebFormsと同じレベルのサポートを維持し、LTSを拡張します。 。 私の好みは、既存の.NET FX投資に多くのユーティリティを提供しながら、.NETCoreのみv3 +を抑制しないASP.NETCoreのホスティングオプションとしてそれを放棄しないことです。

現在、LTSサポートの拡張を検討していますが、ASP.NETCoreのファーストクラスの.NETFrameworkサポートを永久に検討しているわけではありません（これはあなたが求めているものです）。 WebFormsと同じレベルのサポートを探しているこのバージョンのASP.NETCoreは、セキュリティ修正と信頼性修正のみを取得します。 ASP.NET Coreの新しいバージョンに機能が表示されると、ASP.NET Core 2.1を使用しているユーザーの満足度が低下することを保証できます（少なくとも、私の直感ではそうです）。リーチ。

APIがないことが移行を妨げる唯一の理由ではありません。たとえば、開発チームが作成した依存関係に依存している可能性があります。APIは変更できず、安全にリファクタリングできない重要なコンポーネントです（たとえば、テストなし）、他の.NET FXのみのシステムと共有され、予算や変更能力がない別の部門によって維持されているか、企業が管理するインフラストラクチャが.NETFrameworkサーバーでの実行のみをサポートしているなどの外部要因が原因です。

これは（Microsoft内でも）非常に一般的であり、.NET Core 2.0で.NETFramework dllを参照する機能を追加したのは、.NETCore用にコンパイルされていなくてもほとんどのアセンブリに互換性があることがわかったためです。 現在、機能しないものがいくつかあります（AppDomains ...など）が、APIサーフェスを追加すると、機能しないライブラリのセットがわずかな数に縮小することを期待しています。

@pjmlp

これが.NETStandardをどのように殺すのかわかりません。 .NET Standardは、ASP.NETCoreよりもはるかに大きいです。 これは、サポートする.NETプラットフォームで動作する再利用可能な共有ライブラリ（Microsoft.Extensions *など）を作成することです。

まだCoreをターゲットにしていないサードパーティのアセンブリがたくさんあるため、これまで.NETCoreを無視してきました。

どれ？ それらのサポートは進行中ですか、それともそれらのアセンブリは.NET Coreをサポートしませんか？

Coreをサポートすることをいとわないベンダーの多くは、中途半端な方法でサポートしています。たとえば、.NETFrameworkでのみ使用可能なネイティブAPIを使用しないマネージドODP.NETです。

私はこれに同意し、.NET Coreでライブラリの機能不全のバージョンをたくさん見ました（Microsoftが出荷するいくつかのライブラリでも）が、流れはそれをオンにしていると思います。 その理由のいくつかは、.NET Core1.0に存在していたAPIの最初の欠落セットが原因でした。 2.0および2.1では、ライブラリの大規模なセットが、機能を大幅に失うことなく、コア/標準に簡単に移植できるようになりました。

@voltcode具体的なフィードバックをありがとう！ これらのタイプの互換性の問題のいくつかは、現在.NET Coreプロジェクトをサポートしている期間（3年程度）で解消されるか、最小限になると予想されます。

@davidfowl

...。

まだCoreをターゲットにしていないサードパーティのアセンブリがたくさんあるため、これまで.NETCoreを無視してきました。

どれ？ それらのサポートは進行中ですか、それともそれらのアセンブリは.NET Coreをサポートしませんか？

私たちの場合、Oracleはドライバー機能の100％をCoreに移植していないため、ODP.NETは明らかです。

Coreをサポートすることをいとわないベンダーの多くは、中途半端な方法でサポートしています。たとえば、.NETFrameworkでのみ使用可能なネイティブAPIを使用しないマネージドODP.NETです。

私はこれに同意し、.NET Coreでライブラリの機能不全のバージョンをたくさん見ました（Microsoftが出荷するいくつかのライブラリでも）が、流れはそれをオンにしていると思います。 その理由のいくつかは、.NET Core1.0に存在していたAPIの最初の欠落セットが原因でした。 2.0および2.1では、ライブラリの大規模なセットが、機能を大幅に失うことなく、コア/標準に簡単に移植できるようになりました。

しかし、それは私たちの顧客の多くがそれを見ているわけではありません。

この種の決定が.NETの将来にどのように影響するかを理解するためだけに、最近のプロジェクトで、顧客はアプリケーションを.NETFrameworkからJavaforUNIX展開に移行するための開発努力を払った。 JDBCドライバーは.NETFramework ODP.NETドライバーと1：1の機能同等性を提供しますが、.NETCoreと機能不全のODP.NET実装に賭けます。

他の人も同様に別の代替スタックを選択するかもしれません。

平均的なエ​​ンタープライズアプリに移植できない、または移植できない依存関係がたくさんあります。

この問題はHNの上部に現れました。 皆さん（@MSFT）もそこでチェックしたいかもしれません。 たった1時間ですでに50以上のコメント。

@davidfowl

これが.NETStandardをどのように殺すのかわかりません。 .NET Standardは、ASP.NETCoreよりもはるかに大きいです。 これは、サポートする.NETプラットフォームで動作する再利用可能な共有ライブラリ（Microsoft.Extensions *など）を作成することです。

再利用可能な共有ライブラリでない場合、ASP.NET Coreとは何かわかりませんか？ ライブラリが最新かつ高速になる傾向が.NETStandardのサポートを終了することである場合、それはトリッキーなメッセージです。 Newtonsoft.Jsonは、はるかに高速に実行できる場合、.NET Core 3のみに切り替える必要がありますか？ Autofacをすべきですか？

その理由は理解できますが、前回の発表から議論や評価が大きく変わったのかわかりません！ 待って見てみようかな…

私はユースケースをそこに投げ出し、これに関連する現在の当店の様子についていくつかの視点を示します。

AspNetCoreは、セルフホスティング（http.sys）Web APIおよびさまざまなサービスに関する静的Webコンテンツの点で、スタックにとって素晴らしいものでした。 私たちは堅実なナンシーから来ましたが、私たちの観点からも多くの欠陥があったので、約1年前にAspNetCoreに切り替えました。 現在、2.xですべてのコードベースを実行しています。 多くの場合、純粋な.NETCoreターゲットに移行することはまったく問題ありません。 ただし、AspNetCoreを活用するために構築した、 System.DirectoryServicesやSystem.Drawingなどにも依存するサービスも多数あります。 これらのサービスの観点から、.Net Frameworkから移行する前に、Webホスティングテクノロジーを変更します。 残念ながら、2つの異なるWebホスティングテクノロジーを同時に管理することの複雑さとチームの規模のために、両方のターゲット間でより互換性のあるものを支持して、残りのサービスからAspNetCoreを完全に攻撃する可能性があります。

簡単に言えば、この決定により、現時点ではわからないことですが、将来のある時点（LTSが2.xで期限切れになる可能性が高い）でAspNetCoreを完全にオフにすることになります。 結局のところ、使用されているAspNetCore機能の実際の数に関するユースケースは非常に狭いため、AspNetCoreを置き換える独自の社内ソリューションを作成する可能性があります（とはいえ、私たちが提供する機能は今日の私たちにとって大きな付加価値）。

他の人も同様に別の代替スタックを選択するかもしれません。

それは公平ですが、代替スタックには同じサポートポリシーがあります。 Javaは同様のLTSモデル（https://www.oracle.com/technetwork/java/javase/eol-135779.html）に移行しました。

平均的なエ​​ンタープライズアプリに移植できない、または移植できない依存関係がたくさんあります。

@bencyoung

これはフレームワークであり、ライブラリではありません。 これは、一緒に出荷される非常に大きなライブラリのセットで構成されています。

再利用可能な共有ライブラリでない場合、ASP.NET Coreとは何かわかりませんか？ ライブラリが最新かつ高速になる傾向が.NETStandardのサポートを終了することである場合、それはトリッキーなメッセージです。 Newtonsoft.Jsonは、はるかに高速に実行できる場合、.NET Core 3のみに切り替える必要がありますか？ Autofacをすべきですか？

トリッキーなのかわかりません。 私は、それらのライブラリが顧客から不満を言うのでフレームワークを削除しないと97％確信しています。 フレームワークを削除するための基準は非常に高く、Microsoft.Extensions。*を.NET Standard2.0に保持したのと同じ理由です。 すべてをそこに移動するとあいまいになることに同意しますが、それはここで起こっていることではありません。

ある意味で、これは.NETCoreにすでにある現実を形式化したものにすぎません。 ASP.NETCoreは.NETCoreとともに出荷されます。 .NETCoreではASP.NETCoreは共有フレームワークであり、単なるパッケージのセットではありません。 これらのパッケージは製品全体とは別に出荷されることはないため、これらの個々のパッケージを参照するメリットはわずかです（パッケージリストも小さいです）。

@robkeimig

ただし、AspNetCoreを活用するために構築した、System.DirectoryServicesやSystem.Drawingなどにも依存するサービスも多数あります。

これらは、.NET Corehttps ：//docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-packのWindowsコンパクトパックに含まれています

簡単に言えば、この決定により、現時点ではわからないことですが、将来のある時点（LTSが2.xで期限切れになる可能性が高い）でAspNetCoreを完全にオフにすることになります。 結局のところ、実際に使用されているAspNetCore機能の数に関するユースケースは非常に狭いため、AspNetCoreに代わる独自の社内ソリューションを作成する可能性があります（とはいえ、私たちが活用している機能は提供しています今日の私たちにとって大きな付加価値）。

サポートが延長された場合も同様ですか？

さらに、サポートされていない他のすべてのテクノロジー（AppDomains、Remotingなど）を並行して、または後の段階で実行するのではなく、最初に削除する必要があります。

最初に2.1に移行できないのはなぜですか？

私が躊躇する最大の理由は、3年間のサポート制限はあなたが彼らを維持することができないことを意味するということです。 これは短期間の移行の足がかりであり、安定した長期的なプラットフォームを持つことができるポイントではありません。 つまり、途中で移行するリスクを冒すことはできないため、移行を一時停止して優先度の高い新しい機能をいくつか構築し、移行を完了してハードブロックを見つけて、すべての新機能を古いコードベースにバックポートする必要があります。

私が躊躇する最大の理由は、3年間のサポート制限はあなたが彼らを維持することができないことを意味するということです。

確かに、@ DamianEdwardsが述べたように拡張サポートを提供するのはそのためです。

この決定がどの程度の結果を生み出すかを示すためだけに、Blazorはどうですか？ ネットスタンダードに基づくことをやめますか？ 私たちもそれを期待すべきですか？ Blazorは次の大きなものとして宣伝されています。 現在netstandardに依存しているgithub.com/aspnetの他に何がありますか？それを捨てて、次のメジャーリリースでネットコアに移行しますか？ MSFT制御ではあるが、aspnetcoreの運命を共有するaspnetリポジトリの外部で、他のことについてどのような計画がありますか？

@davidfowl

他の人も同様に別の代替スタックを選択するかもしれません。

それは公平ですが、代替スタックには同じサポートポリシーがあります。 Javaは同様のLTSモデル（https://www.oracle.com/technetwork/java/javase/eol-135779.html）に移行しました。

見落としている小さな詳細は、Javaやその他のスタックは、ランタイム実装全体で部分的にしか実装されていない標準を必要とせずに、.NETFrameworkや.NETCoreとは異なりバージョン間で互換性があることです。

その価値のために、私は現在、会社の最初のASP.Netコアアプリの展開に取り組んでいます。 .NET Frameworkに非常に多額の投資を行っているため、.NETCoreではなく.NETFrameworkでASP.NetCoreを使用することは明らかなアプローチでした。

今、私は後で私たちに多くの苦痛を与える準備をしているのだろうかと思っています。

ここには相互に関連する懸念がたくさんあります。 ASP.Netコアは、.NETFrameworkでのみ実行することを意図したものではなかったとあなたは言います。 過去のASP.NetCoreに関するMicrosoftのメッセージでは、それを明確にすることはできませんでした。

同様に、多くの.NET開発者は、.NET Frameworkがメインの実装であり、もちろん環境固有のAPIを除いて、他の開発者は一般的にサブセットであるという考えに慣れています。 これは.NETCoreで変更されましたが、多くの人は一般に、「完全な」.NET Frameworkがほぼ.NET Coreがサポートするすべてのものをサポートすることになるという印象を受けていました（ツールとクロスプラットフォームの互換性を除く）が、ちょうど遅いタイムスケールで、ねじれが解決されるのを待ってからそれらを含めます。

最近、いくつかの本当に重要な機能が.NETFrameworkに到達しない可能性があるという多くの提案がありました。 （例えば、スパンの互換性リスク.NET Framework 4.8で実装するには厳しすぎると見なされるタイプは、これらのリスクが4.9で低くなるのはなぜかという理由で、実装されない可能性があることを示しています。 同様の懸念がデフォルトのインターフェースメソッドを取り巻いているようです。）これは、多くの開発者が満足できない大きなパラダイムシフトです。

このスレッドのメッセージは、Microsoftが.NET Frameworkをレガシー機能と見なし始めていることを示唆しています。これは、実際にセキュリティ修正が行われるまで、時間の経過とともに開発の注目を集めることは少なくなります。

Microsoftはこれまで、積極的に開発しているもの、散発的な新機能のみで維持しているもの、セキュリティと安定性の修正のみを実際に提供する予定のものについて明確にすることにひどい思いをしていました。 .NET Frameworkが現在その2番目のカテゴリに含まれているだけでなく、3番目のカテゴリに非常に近いように思えます。

それは本当に迷惑です。 .NET Coreにはいくつかの問題があり、一部のエンタープライズアプリケーションには最適ではありません。 継続的に開発が進んでいるアプリケーションで使用しても問題ないかもしれません。 ただし、例として、ほとんどの企業には、デプロイされるアプリケーションがいくつかあり、数年に1回しかアクセスされません。 これは.NETCoreではうまく機能しません。 ここでは、企業はほとんどのリリースで短いサポートサイクルに苦労する必要があります。 また、Windowsには現在、セキュリティ更新プログラムなどを取得するために新しいパッチリリースを自動的にインストールするメカニズムはありません。

そのため、新しいプロジェクトを開始する企業は、何をすべきか疑問に思っています。 よりエンタープライズフレンドリーな.NETFrameworkは、非推奨になるというかなり明確な兆候を示しているため、新しい開発では避けたほうがよいでしょう。 一方、.NET Coreは存在しますが、企業向けではありません。

したがって、これは基本的に暴言になりましたが、これが多くの開発者が抱えている懸念をよりよく示していることを願っています。

@davidfowl

ただし、AspNetCoreを活用するために構築した、System.DirectoryServicesやSystem.Drawingなどにも依存するサービスも多数あります。

これらは、.NET Corehttps ：//docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-packのWindowsコンパクトパックに含まれています

互換性パックがこのユースケースをサポートしていることを知りませんでした。 理想的には、すべてを.NET Coreに移行したいと考えています。これは、非常に良い答えのようです（最初は見落としていたかもしれません）。 サービスのホスティングをLinux / OSXに移行する予定はないので、これらの要素をうまく組み合わせることができます。

サポートが延長された場合も同様ですか？

サポートの観点から-2021年までの2.xのLTSは、これほど広範囲にわたる何かに関連する他のすべての制約を考慮すると、合理的であるように感じます。

私が今理解していることに基づいて、.NETFrameworkプロジェクトをレビューして.NETCoreプロジェクトに変換する機会があれば（必要に応じて互換性パックを使用して）、AspNetCore3.xへのアップグレードを快適に感じるでしょう。

フォローアップありがとうございます。

私は高圧プロジェクトで15年間.NET（主にC＃）で書きました。 私は何年も無駄にし、顧客は過剰に設計されたフレームワークを使用して時間を無駄にしました。 .NETCoreの概念が気に入りました。 私にとって、それはNodeJSプロジェクトを書く速度でしたが、驚くべき.NETエコシステム（すべての脂肪を含む）でした。 残念ながら、それはその約束に失敗しました、それはまだ（この新しい発表でさえ）血まみれの使用にはあまりにも複雑すぎます。 過去3年間、私はNodeJSで構築してきましたが、申し訳ありませんが、比較はできません。 よりシンプルで使いやすくすると、幅広い開発者コミュニティを再び引き付けることができます。

Windowsにデプロイされた.NETFrameworkを対象とするASP.NETCore 2.1アプリで実行できる、ハードでコンパイルされたバイナリ.NET Framework依存関係（ソースコードのないベンダーのもの）を持つプロジェクトの場合、プロジェクトにWindows互換性パックを追加して作業を継続しますパックによって提供されるハード依存関係参照型の場合、コア3.0？

非常に成熟した商用ライブラリの大規模なエコシステムがありますが、残念ながらSystem.Drawing、GDI、場合によってはレジストリ（！）に依存しています。 これらが2.1でのみ機能し、3年間しかサポートされない場合、これは一部の企業でCoreの採用を停止する可能性がある問題です。

.NET Coreは、出発点に到達するために完全な円を描いています。

別のアプローチを提案します。.NETFrameworkに.NETCoreの便利な機能を組み込み、実験的な行き止まりのブランチとして.NETCoreを完全に排除します。 したがって、セグメンテーションを停止し、顧客のより大きな利益のためにテクノロジーを保存します。 やや物議を醸すが、製品的には非常に賢明なアプローチ。

@davidfowl

.NETFrameworkで実行されているASP.NETCoreは、永続的なものになることを意図したものではなく、常に足がかりとして意図されていました。

それはまったく真実ではありません。 ASP.NET Coreでのメッセージングは​​、常に.NETCoreと.NETFrameworkの両方でサポートされているというものでした。 .NET Coreの最初の発表でさえ、ASP.NET Core（当時はASP.NET 5）の両方のプラットフォームについて言及しています。

.NET Standardを示す非常によく知られている「ASP.NETCoreで.NETFrameworkをターゲットにするためのサポートを削除する予定はありません」とさえ書か

そうです、この決定が今までに変わっ長年にわたって行った非常に悪いコミュニケーションのいずれかであると言っています。

ASP.NETCoreとも呼ばれます

さあ。 結局のところ、私のような人々は、.NETCoreとASP.NETCoreを分離するために人々と戦わなければなりませんでした。なぜなら、それらは同じものではないからです。ここであなたの利益のために同じ名前を使用しないでください。 それは公正ではありません。 「コア」への名前の変更は、確かにそれを.NETCoreに明示的にリンクすることではありませんでした。 また、EF Coreにも「コア」がありますが、netstandardで引き続き実行されるため、引数は機能しません。

そこで、拡張LTSサポートが登場します。この6年経ってもアプリケーションが.NETCoreに移行できない場合[…]

これは今からどこから来たのですか？ 前回のメッセージは、「「拡張サポート」LTSオファリングを調査中です」というものでした。 これは今では本物で、6年になりますか？

@pjmlp

見落としている小さな詳細は、Javaやその他のスタックは、ランタイム実装全体で部分的にしか実装されていない標準を必要とせずに、.NETFrameworkや.NETCoreとは異なりバージョン間で互換性があることです。

フェアポイントですが、それがより良いサポートと何の関係があるのか​​理解できません。 不自由なライブラリ（ある時点の問題）とエンタープライズサポート（より長いサポートサイクル）が少ないため、Javaへの切り替えがより良いと主張されました。

@KevinCathcart

このスレッドのメッセージは、Microsoftが.NET Frameworkをレガシー機能と見なし始めていることを示唆しています。これは、実際にセキュリティ修正が行われるまで、時間の経過とともに開発の注目を集めることは少なくなります。

Microsoftはこれまで、積極的に開発しているもの、散発的な新機能のみで維持しているもの、セキュリティと安定性の修正のみを実際に提供する予定のものについて明確にすることにひどい思いをしていました。 .NET Frameworkが現在その2番目のカテゴリに含まれているだけでなく、3番目のカテゴリに非常に近いように思えます。

https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/を参照して

Windowsにデプロイされた.NETFrameworkを対象とするASP.NETCore 2.1アプリで実行できる、ハードでコンパイルされたバイナリ.NET Framework依存関係（ソースコードのないベンダーのもの）を持つプロジェクトの場合、プロジェクトにWindows互換性パックを追加して作業を継続しますパックによって提供されるハード依存関係参照型の場合、コア3.0？

はい、バイナリ互換です。

非常に成熟した商用ライブラリの大規模なエコシステムがありますが、残念ながらSystem.Drawing、GDI、場合によってはレジストリ（！）に依存しています。 これらが2.1でのみ機能し、3年間しかサポートされない場合、これは一部の企業でCoreの採用を停止する可能性がある問題です。

このスレッドで何度か言及したように。 .NETCoreプロジェクトで.NETFrameworkに対してコンパイルされた依存関係を直接参照する機能を追加しました。

@pokeあなたはメッセージングについて正しいです、それはまったく明確ではありませんでした、私の間違い。

これは今からどこから来たのですか？ 前回のメッセージは、「「拡張サポート」LTSオファリングを調査中です」というものでした。 これは今では本物で、6年になりますか？

私は6人で構成しましたが、提供するときにどの程度の拡張サポートが提供されるかわかりません。

.NETのコアは常に交換するつもりだったの.NET Framework （もともとは、.NET Frameworkの5になる予定だったが）が、書き換えは、デスクトップアプリケーションをサポートするために、今UTILかかったように野心的でした。

うわー、ここに陽気なコメントがたくさんありますか？ 記事を読まない人が散在している、見当違いのオタクの怒りがたくさんあるようです。

待機する

@edandersenこれらの外部dllでApiPortを実行し
Windows互換性パックは、system.drawingとレジストリの機能をすでに提供しています。 これらを.NETCoreで実行しようとしましたか？ System.Drawingは、monoのlibgdiplusを使用する* nixでも機能します。 これにより、Windows以外のシステムでClosedXMLを使用してExcelファイルを操作できます。

当社の「最近の」アプリケーションに対する.NETFrameworkの最大の依存関係は、WCF機能です。
.NET CoreWCFクライアントライブラリは改善されています。 私たちが利用しているいくつかのサービスでそれらがどれだけうまく機能しているかの現在の状況を確認していませんが、過去にいくつかのサービスと話すことができませんでした。 しかし、不足している機能はすでに問題リストに含まれていました。 一方、シンプルなサービスはうまく機能します！
一方、.NETCoreでSOAPサービスをホストするための「ドロップイン」代替品はありません。 これにより、一部のアプリケーションの.NET Coreへの移行がブロックされます（ただし、前述のとおり、移行する必要はありません）。
最近のASP.NETCoreアプリケーションでは、WCFサービスをホストするだけでHTTP / JSONを介してASP.NETCoreアプリケーションに転送する追加のASP.NETプロキシWebアプリを作成しました。 あまりきれいではなく、展開が複雑になりますが、いくつかの統合ポイントが可能になります。

構成に問題があることを考えると、.NETCoreでWCFホスティング機能が本当に必要だと言っているのではありません。 ただし、SOAPサービスをホストしてWSDLを生成するためのいくつかのオプションはすばらしいでしょう。 私はすでにいくつかのOSSライブラリがそれを行おうとしているのを見てきました。 多分これで十分でしょう。

@ davidfowl

フェアポイントですが、それがより良いサポートと何の関係があるのか​​理解できません。 不自由なライブラリ（ある時点の問題）とエンタープライズサポート（より長いサポートサイクル）が少ないため、Javaへの切り替えがより良いと主張されました。

重要なのは、Java LTSバージョンも3年ですが、すべての主要な実装間の互換性はゴールドです。これは、皆さんがここでウィンドウから外して喜んで投げ出すものです。

この.NETFramework、.NET Core、Xamarin、.NET Standardのミスステップ全体は、変更のための.NETチーム内で、WinDevとDevToolsの古き良き時代のように見え始めています。

したがって、当然のことながら、顧客は、内部チームがロードマップ機能を求めて戦っているように見えないプラットフォームに進んで移行します。

これらの決定は自信を刺激しません。

これは、特に現在の状況において、.NETチーム側の間違いのように感じます。

Javaについて言及している人たちのために、最近そこで何が起こっているのかを実際に見ましたか？ Androidでの使用をめぐるグーグルに対する彼らの絶対に狂った訴訟と彼らの最新のライセンスの悪党の間で、オラクルの行動は一貫して、それが繁栄することを望んでいるのではなく、不要な製品を殺したい会社の行動であるように見えます！

これは、マイクロソフトがこれを活用して強力なマーケティングを行い、正反対のことをしていることを示唆する絶好の機会です。.NETは、正気で安定した安全な開発オプションを提供する場所です。 代わりに、これを取得します。 ：がっかり：

@masonwheeler

両方の環境で働く私たちは、実際にOracleの仕事に感謝しています
Javaでやっています。

オラクルを軽蔑し、本番環境でJavaをめったに使用しないのは
それらに対する憎悪の議論で失われました。

Androidに関しては、Googleとして、私は訴訟を全面的に支持しています。
なんとかJavaプラットフォームをフォークしたので、Microsoftが失敗したところで成功しました
J ++で。 MavenCentralのランダムなJARが実際にAndroidで動作することが保証される日を楽しみにしています。

.NETに関しては、私はの継続的な再起動にうんざりし始めています
Microsoftプラットフォームをどのようにターゲットにするか。

WinRT、UAP、UWP、.NETネイティブドロップF＃、XNA、Core1.0全体が残っています
酸っぱいブドウがたくさんあり、この最近の決定は物事を良くしません
全体。

.NETは私のお気に入りのプラットフォームなので、これ以上台無しにしないでください。

@mythz

2.1が.NETFrameworkでサポートされている最後のLTSバージョンであるということは、アップグレードする場所がないことを意味することを理解しました。

つまり、サポートされていないプラットフォームになっているため、サポートされていないEOLの終わりに達する前に、溶岩のように扱い、スクランブルして降りる必要があります。

それは、私が議論全体で本当に理解していない点の1つです。 セキュリティ修正（拡張LTSサポートでカバーできる）以外のLTSサポートから実際に何を得ますか？

主流のLTSサポートでは、期待できることが2つだけあります。

• セキュリティ修正
• 重大なバグ修正

以前のもの（セキュリティ修正）のほとんどは、Windows Updateを介してパッチが適用されます（.NET Frameworkを対象としているため）。 したがって、残っているセキュリティと重大なバグ修正のみがASP.NETCore自体にあります。

サポートが2018年に終了することはすでにわかっているとしましょう。2020年に新しいプロジェクトを開始する人はいないと思います。そのため、2021年（または2026年または拡張サポートの期間）以降に重大なショーストッパーバグが見つかる可能性はほとんどありません。することが）。

それはセキュリティバグを開いたままにするだけであり、LTSでカバーするのは合理的です。

以前の回答では、TLS 1.4などについて言及していましたが、これはとにかく新しい機能であるため、LTSではカバーされません。これはJavaでも同じです（Java6はTLS1.0をサポートしているだけです-TLS1.1を考慮に入れると、非公開の更新は、Oracleの拡張サポートサブスクライバーのみが利用できます）。

• .NET Coreに移行するためのステージングプラットフォームとして使用することを考えた人は、移行に予想よりも時間がかかる場合や、依存関係がある場合に障害にぶつかると、サポートされていないプラットフォームで立ち往生するリスクに直面するため、実行不可能なオプションになりました。依存しているのは.NETCoreでは実行できません。
  しかし、.NETFramework上のASP.NETCoreで使用できるが、.NET Framework +互換性パッケージ上のASP.NETCoreでは使用できないAPIはどれですか？

これがここでのより重要なポイントだと思います。これを特定し、不足しているAPIを将来の互換性パッケージとともに出荷するか.NET Coreに追加して、.NETCoreをターゲットにしている場合でも.NETFrameworkライブラリを参照できるようにします。

.NET Core以降、.NETStandardまたは.NETCoreで使用可能なAPIのみを使用する限り、 .NETCoreプロジェクト内の任意の.NETFrameworkライブラリを参照（および使用）できます。

これには、ライブラリの作成者が自分のライブラリを更新してnetstandard / netcoreappをターゲットにする必要はありません。

Microsoftがnuget.orgの各nugetパッケージの横にある機能/リンクによってNuGetWebページ/ライブラリを拡張し、このライブラリが特定のバージョンの.NET Coreで使用できない互換性のないAPIを使用している場合のレポートを表示すると、役立つかもしれません。

例えば

'Company.Example.MyLib`は表示されます

• .NET Core 2.1：部分的なサポート（詳細レポート）-詳細レポートには、機能するApiと機能しないApiが表示されます
• .NET Core 3.0：; 完全にサポート

これは、.NET Portability Analyzerを実行することで可能になるはずですか？ ボーナスは、安全に呼び出すことができるパブリックAPIのリストを追加する場合です（ILコードを分析し、呼び出している他のAPIを確認して、安全かどうかを確認します）。

これにより、開発者は、プロジェクトに必要な特定のライブラリが.NET Coreで実行できるかどうかを、明示的に呼び出さなくても判断しやすくなりますか？

今のところ、APIがサポートされているかどうかを判断するのはちょっと面倒です。ライブラリが必要であり、その上でローカルでアナライザを実行します。 多くの開発者は、netstandardを公式にサポートしていないライブラリのいくつかを使用できることを知らないかもしれません。

@davidfowl @terrajobstそれはNuGetへの実行可能な追加でしょうか？ -NETCore互換の.NETFrameworkライブラリの検出可能性をより簡単かつ迅速にするには？

• 企業の既存のマネージドインフラストラクチャの.NETFrameworkサーバーの使用を余儀なくされた人は、新しい開発モデルとエコシステムの使用に参加できず、既存の従来のASP.NETの知識/スキルの価値が日々低下することを確認する必要があります。

これは、.NETFrameworkのサポートに賛成か反対かという議論はほとんどありません。 レガシーの依存関係に固執し、.NET Core（互換性パックまたは.NET Frameworkライブラリを使用）に移行できない人は、その後はどちらも移行できません。 それはどのように何かを変えるでしょうか？

それでも、モノリシックアプリケーションの一部を分割して、レガシーアプリケーションの一部を徐々に新しいアプリケーションに移動することができますが、それは別の話です。

• 予算、計画、投資の決定に基づいて信頼していたガイダンスが変更されたため、計画外の移行を余儀なくされることを望んでいる組織はありません。

利益が投資を上回っているのなら、なぜですか？ つまり、見返りに大きな価値をもたらしたり、パフォーマンスを大幅に向上させたりする独自の機能がある場合です。

そうでない場合は、古いシステムを使用してください。 ソフトウェア開発は永遠にこのようなものでした。 FortuneとCobolで開発されたソフトウェアを実行している企業はまだあります。

.NET Coreに移行できない、または移行したくない人はたくさんいます。彼らは、従来のASP.NETと同じレベルのサポートを共有したいと考えています（現在のメッセージングでは無期限に提案されています）。

APIがないことが移行を妨げる唯一の理由ではありません。たとえば、開発チームが作成した依存関係に依存している可能性があります。APIは変更できず、安全にリファクタリングできない重要なコンポーネントです（たとえば、テストなし）、他の.NET FXのみのシステムと共有され、予算や変更能力がない別の部門によって維持されているか、企業が管理するインフラストラクチャが.NETFrameworkサーバーでの実行のみをサポートしているなどの外部要因が原因です。

ええ、しかしどの依存関係？ これらの外部依存関係が使用しているAPIを特定するには、具体的な例が必要です。 このAPIは、.NET Core3.0または.NETCoreの将来のバージョンに追加される可能性があります。

これにより、この.NETFrameworkライブラリを.NETCoreプロジェクトで使用できるようになります。 唯一の問題は、.NETFrameworkライブラリが.NETStandardまたは.NETCoreでは使用できないAPIを使用する場合です。 ただし、その修正には、ライブラリを識別するためのフィードバックが必要です。

@pjmlp

@davidfowl

他の人も同様に別の代替スタックを選択するかもしれません。

それは公平ですが、代替スタックには同じサポートポリシーがあります。 Javaは同様のLTSモデル（https://www.oracle.com/technetwork/java/javase/eol-135779.html）に移行しました。

見落としている小さな詳細は、Javaやその他のスタックは、ランタイム実装全体で部分的にしか実装されていない標準を必要とせずに、.NETFrameworkや.NETCoreとは異なりバージョン間で互換性があることです。

これは、後のJavaエディションにも当てはまりません。 Java 9は、ランタイムをモジュール化するための最初のステップを追加しました。これは重大な変更です。 バージョン9では、これはデフォルトで無効になっていますが、将来のバージョンでは、フラグはデフォルトで有効になり（またはオフにできなくなり）、レガシーアプリケーションに重大な変更が加えられます。

たとえば、いくつかのリフレクションマジックを介して内部APIを使用する多くのライブラリの場合、その変更で機能しなくなる可能性が

@ TsengSR

Java 9で導入された重大な変更にもかかわらず、関連するすべてのJavaフレームワークの100％がJava 9、10、および11で機能します。これは、.NET Framework、UWP、およびCoreでは明らかに当てはまりません。

Coreの公式ロードマップがまだ得られていないのに、2つの公式クロスプラットフォームGUIフレームワークがあると想像してみてください。

@pjmlp

@ TsengSR

Java 9で導入された重大な変更にもかかわらず、関連するすべてのJavaフレームワークの100％がJava 9、10、および11で機能します。これは、.NET Framework、UWP、およびCoreでは明らかに当てはまりません。

Coreの公式ロードマップがまだ得られていないのに、2つの公式クロスプラットフォームGUIフレームワークがあると想像してみてください。

申し訳ありませんが、それはまったくナンセンスです。

--add-opensが呼び出されない限りこれらのモジュールに反映されないJava 9の内部モジュール（そしてiircは常に一時的な解決策であると想定されていたため、人々はレガシーアプリケーションを実行し続け、後でいくつかのバージョンを削除できます）。

Java 9がリリースされようとしていたときにドラマとシットストロームを見逃した場合、これはそれに対する応答でした。
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

エコシステム全体がモジュラーJavaプラットフォームに移行するのを支援するために
よりリラックスしたペース私はここに違法な反射アクセスを許可することを提案します
JDK 9ではデフォルトでクラスパス上のコードから、それを禁止する将来のリリース。

その他、Java EE 9で非推奨になったJAX-WSは非推奨になり、Java EE11で削除される予定です。これはおおよそWCFと同等と見なすことができます。 それを使用して適用可能なものは、移行プロセスである他のものに置き換えることなく、新しいバージョンに移植することはできません。 .NETFramework上のASP.NETCoreから.NETCore上のASP.NETCoreへの移行（またはASP.NETからASP.NET Core @ .NETコアへの移行）とほぼ同じです。

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

プラットフォームの整合性の向上-Java9より前は、アプリのクラスでの使用を目的としていない多くのクラスをプラットフォームで使用することが可能でした。 強力なカプセル化により、これらの内部APIは真にカプセル化され、プラットフォームを使用するアプリから隠されます。 これにより、コードが内部APIに依存している場合、レガシーコードをモジュール化されたJava9に移行する際に問題が発生する可能性があります。

これらの内部APIを使用したアプリケーション（古いライブラリの一部が使用していたsun.*名前空間内のすべてを含む-またはJava 9がリリースされようとしていたときに使用していた）または依存するサードパーティライブラリを使用するアプリケーションこのAPIまたは別のライブラリでは、この重大な変更が行われる可能性があります。 問題は、.NETFrameworkや.NETCoreの場合と同様に、ライブラリだけではどのAPIが呼び出されているかがわからないことです。

@TsengSR

--add-opensが呼び出されない限りこれらのモジュールに反映されないJava9の内部モジュール（およびiircは常に一時的な解決策であると想定されていたため、人々はレガシーアプリケーションを実行し続け、後でいくつかのバージョンを削除できます）。

または、クラスパスモードを使用して、モジュールである混乱をスキップすることもできます。 そのモードは、当面の間残ります。 また、モジュールに入る場合は、他のモジュールのパッケージへの依存関係を明示的に宣言できます。

その他、Java EE 9で非推奨になったJAX-WSは非推奨になり、Java EE11で削除される予定です。これはおおよそWCFと同等と見なすことができます。

J2EEはすべて非推奨になり、Java11で削除されました。Java11はすでにリリースされています。 ただし、J2EEはインターフェースのみを定義し、実装は定義しません。 私が行っているJ2EEを引き続き使用するには、依存関係を切り替える必要があります。 とにかくすべての実装は別々であり、Java11では正常に機能します。

これらの内部API（古いライブラリの一部が使用していたすべてのsun。*名前空間を含む-またはJava 9がリリースされようとしていたときに使用していた）を使用したアプリケーション、またはこのAPIに依存するサードパーティライブラリを使用するアプリケーションまたは、別のライブラリがこの重大な変更の対象となる場合があります。

これは常にそうでした。 それらは文書化されていないAPIでした。 誰もそれらを使用するべきではなく、いつでも変更または削除された可能性があります。 一般的に（乱用されている）内部APIの多くは、既存のプログラムを壊さないように残されているため、将来的に適切なAPIに移行できます。

一部のAPIは非推奨になりましたが、JREまたはJavaエコシステム全体ではなく、特定のAPIについて説明しています。 これらのAPIから新しい公式の文書化されたAPIに移行するために必要な作業は、通常最小限です。

そして、Javaは常に.NETよりも下位互換性を破ることをいとわない。 たとえば、Javaでは、 varという名前の型を宣言することは、ローカル推論用に予約されているため、現在は違法です。 Javaでは、変数に_という名前を付けることは違法です。これは、変数が破棄/ワイルドカードとして使用するために予約されているためです。 C＃は、下位互換性を維持するという名目で、どちらの場合も正反対の決定を下しました。

誤解しないでください、Javaはそれ自身の混乱です。 モジュール間で、Java 8のサポートが終わりに近づき、OracleがJREライセンスに貪欲になり、Microsoftが人々を改宗させる大きな機会があります。 しかし、Microsoftがプラットフォームの将来のサポートと進化に関してさまざまなメッセージを出す場合、それが起こる可能性はほとんどありません。

@TsengSR

それは、私が議論全体で本当に理解していない点の1つです。 セキュリティ修正（拡張LTSサポートでカバーできる）以外のLTSサポートから実際に何を得ますか？

そのLTSには時を刻む時計があり、アップグレードする場所がないために終了し

この決定の最も近いメタファーがJavaの土地で何であるかわからない、おそらく既存のシステムをGraalVMでの実行に移行することを余儀なくされ、多くのことが機能します。移行が物理的に試行されるまで問題が発生します。

.NET Coreへの移行を可能にするために多くのことが行われたことに同意しますが、移行を妨げる多くの外部要因（MS制御外を含む）がまだ存在し、この決定は行われるだけです。この発表以前のように移行の可能性は低くなりましたASP.Core / FXは一般的な移行パスでしたが、将来のサポートされていないプラットフォームへの移行を含む全体的な移行戦略を推奨することはもはや賢明ではありません。これにより、多くの移行が妨げられます。発生することから、より多くの既存のシステム/開発者が停滞した従来のASP.NETに残されます。

以前のもの（セキュリティ修正）のほとんどは、Windows Updateを介してパッチが適用されます（.NET Frameworkを対象としているため）。 したがって、残っているセキュリティと重大なバグ修正のみがASP.NETCore自体にあります。

組織は、将来のバグやセキュリティの問題がサポート用に指定されたライブラリでのみ発生することを期待して、部分的にサポートされているプラ​​ットフォームに基づいて企業を構築することを望んでいません。 ASP.Core / FXが、将来のセキュリティの脆弱性が解決される他の.NET Frameworkと同じレベルのサポートでカバーされるとしたら、それは大いに役立ちます。

現在、MSのみが更新されたASP.Core NuGetパッケージにパッチを適用してリリースできます。依存関係の相互接続ツリーはOSSであり、受信した2.1 PR（LTS後）がレビューされ、受け入れられ、リリースされました。

結局、すべての詳細が議論された後、まだ重要な最終的な質問は次のとおりです。

ASP.Core / FXで既存のシステムを引き続き実行できますか？

技術的には可能ですが、将来の重大なバグ/セキュリティの脆弱性が解決されるという保証がなければ、推奨事項はNOになり、影響を受ける外部エコシステムがこの決定の苦痛を吸収します。

ASP.NETCoreが.NETCoreのみになる場合、.NET Standard全体についてどのように感じるべきですか？

マイクロソフト自体が（間違いなく有効な）理由でそれに賭けていないのなら、なぜ私たちはすべきですか？

ファーストクラスの最先端の.NETCoreのみのライブラリと、「よりシンプルな」、それほど高度ではない.NET Standardライブラリはありますか？

これは、.NET-Core以外のプラットフォームを改善するためにドライブを強制終了するようです。

うまくいけば、誰かが私が間違っていることを私に示し、私の懸念を和らげることができます。

こんにちは、
私は前進することに価値を見出し、それを気に入っていますが、この決定について3つの主要な問題があります。
1）マイクロソフト内の誰もそれで難しいものを構築しない場合、netstandardは二級市民になります。あなたたちがドッグフードをしない場合、他の開発者にそれを行うようにどのように依頼できますか？ 今日、ライブラリの作成者は本当に一生懸命働かなければなりません。内部のpplが標準を使用しない場合、サポートは改善されません。
2）他のランタイムでaspnetコアを実行することには価値があります。
3）古いランタイムで実行されているソフトウェア（依存関係は決して触れられない）には、軽く破棄してはならない価値があります。

次に、コミュニケーションがあります。誰もがどこでも実行できる1つの.netランタイムが好きだと思いますが、それは当面のユートピアであり、netstandardは代理として作成されました。 私の見解では、ネットスタンダードではなくプラットフォームを対象とするすべてのプロジェクトは、そのビジョンの方向に進まないステップです。
.netフレームワークがメンテナンスモードにあり、.netcoreがその代わりになり（死体を残して）、monoがデバイス上で実行されることは明らかです。ストーリーとCoreRTは進歩するようには見えません。

netcore 3.0では、デスクトップワークロードのサポートと、「関連性を維持するためにすぐにジャンプするようにpplに指示する」という2つのことを同時に実行します。 これには開発者からの信頼の飛躍が必要だと思います。依存関係が欠落しているために多くのプロジェクトが移行されないことを誰もが知っているため、楽観的すぎます。おそらく、将来の3.1 / 3.2リリースで1〜2年で追加されるでしょう（ 2.1の3LTS年に非常に近い）。 その間、関連性を求めている開発者は、依存関係を制御できないため、3.0ビットを使用するようにブロックされます。

pplがテストした後、この決定を延期して実際の影響を確認することは可能ですか？
ライブラリの作成者に指示しているように、aspnetコアをnetstandardとnetcoreappの両方にコンパイルすることは可能ですか？ .netフレームワークでパフォーマンスの低下を実行しても問題ありません😄

Roslynは.NETStandard2.0で実行されるようになりました-> https://github.com/dotnet/roslyn/pull/30914

それは確かに難しいこととして数えられます！

@davidfowl

コミュニティがASP.NetCoreに取り組みをシフトしているため、これにより、さまざまな理由で移行できない.NetFrameworkシステムの将来の開発のオプションが大幅に制限されるようになると思います。

たとえば、 IdentityServerはすでにASP.NetCoreに移行しており、SignalRの

ASP.NET CoreのLTSサポートはすでに3年に設定されていることは知っていますが、オンプレミス展開では、これらのラインに沿ったサポート（4年）をお客様に提供する必要があるため、より長いライフサイクルが必要です。
この期間中、アプリケーションを大幅に変更することなく、セキュリティ修正を含むパッチをリリースできる必要があります。 これは、より大きな変更についてお客様による広範なユーザー受け入れテストを必要とするお客様の変更管理プロセスと整合性を保つためであり、メンテナンスモードのリリースで新しいバージョンに移行するなどの大きな変更を行う必要がありません。 。

LTSポリシーが変更される可能性はありますか？ 5年のサポートで2年ごとにLTSをリリースするというUbuntuの戦略のようなものですが、新しいバージョンへの移行作業が行われている間、現在のリリースで3年以上のサポートができるように6を要求します。

拡張サポートについて言及されていることは理解していますが、これは各クライアントが購入する必要があるものだと思います。最初のインストール（開発、販売プロセス、UATなどの後）がせいぜいあれば、それは口に合うとは思いません。 2年間のサポート。

また、.netcoreで.netstandardライブラリを3.0回処理する方法に興味があります。
.netstandardのスローガンは、「それらすべてを統治する1つのライブラリ」です。
これの前に、それはそれがすべてを意味するように見えます。
この後、少し意味があるように見えます。

この決定がどの程度の結果を生み出すかを示すためだけに、Blazorはどうですか？ ネットスタンダードに基づくことをやめますか？ 私たちもそれを期待すべきですか？

誰かがこれを明確にすることができますか？

では、Newtonsoft.Json（高性能の恩恵を受けることができる）のようなライブラリーが.NETStandardではなく.NETCoreに切り替えることをお勧めしますか？ この種のライブラリとASP.NETCoreの違いはあまりわかりません。 RESTサービスをより大きなアプリケーションに組み込みます。その中には.NETCoreに簡単に移行できるものと、移行できないものがあります。

私の理解では、新しいAPIの利点を活用したいが、対象者を失いたくない場合は、.NET Core3と.NETStandard2.xの両方をターゲットにすることをお勧めします。

私の理解では、新しいAPIの利点を活用したいが、対象者を失いたくない場合は、.NET Core3と.NETStandard2.xの両方をターゲットにすることをお勧めします。

今後の道のりはどこでもネットスタンダードだと思っていましたが、現在は過渡期にあります。 しかし、このような動きで、他の人が従う（または必要になる）ので、マルチターゲティングに戻ります。

.NETFrameworkと.NETCoreは同じ役割を果たします。したがって、ASP.NET Coreは、現在または将来を問わず、いつか.NETFrameworkで実行されなくなることがほぼ予想されます。

ただし、 .NET Standard X実行されないことに大きな問題があります。 正直なところ、xamarinまたはUnityで実行するのにasp.netコアは必要ありませんが、可能であると言えるのは嬉しいことです。これは、.NETプラットフォームで実行されるライブラリの別のセットです。 中断することで、 .NETCoreとMicrosoft.AspNetCoreと@davidfowlを非難していると

一方、.NET Standardは絶対に実験する場所ではなく、物事を適切に取り込むのは難しいので、妥協することはできますか？ ASP.NETCoreを現在.NETCoreのみを対象とし、LTSバージョンを.NET Standardを対象とすることは可能でしょうか？ APIが.NETStandardへの道を見つけられない場合、それを使用する価値は本当にありますか？

また、これをおそらく意図した方法で見ることもできます。

• .NET Coreは、コンソール/ Web / 3サードパーティデスクトップ用です（標準+ Web固有のAPI）
• Unityはゲーム用です（標準+ゲーム固有のAPI）
• Xamarinはデバイス/デスクトップ用です（標準+デバイス/デスクトップ固有のAPI）

しかし、誰が.NET Standardを前進させるのでしょうか？ 前に言ったように、リソースが限られているので、実際に物事をプッシュする必要はありません（私の提案では、LTSをリリースするための変更が必要になるため、.net core / asp.netコアチームに分類されます）。 NETStandardはすぐに古くなります。

注意を払っていない人にとっては、.NET Standard2.1は.NETFrameworkのサポートをやめたようです。

.NET Standard 2.1でのAPIの追加の多くは、意味のあるものにするために実行時の変更が必要であるため、.NET Framework 4.8は、.NET Standard 2.1を実装するのではなく、.NET Standard2.0のままになります。 .NET Core 3.0、およびXamarin、Mono、Unityの今後のバージョンは、.NET Standard2.1を実装するように更新されます。

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

それは.NET FrameworkがSilverlightの-EDを取得して見るために私に痛み限り、どのようなASP.NETコアに関して私に重要なのは、それは、.NETの標準を対象とすべきであるということです。

Core / Standardエコシステムで最大の参照アプリケーションの1つである可能性が高いため、ASP.NET Coreには、.NetStandardとそれが表すすべての優れた点のチャンピオンになる責任があると思います。

ASP.NET Coreが標準の変更を要求し、それを.NETCoreに実装するのは合理的だと思います。

Spanなどがnugetパッケージを介して.NetFrameworkで利用できるのと同じように、ASP.NET Coreがまだ.Net標準に含まれていないものに依存する必要がある、または依存したい場合は、その依存関係を含める必要があると思います。 nugetパッケージを介して。

最後に、私は、.NETの標準3.0+を対象とし、4.xとサイドバイサイドインストールされます.NET Frameworkの5.0があること、（逆にすべての証拠に対して）を望みます

最後に、私は、.NETの標準3.0+を対象とし、4.xとサイドバイサイドインストールされます.NET Frameworkの5.0があること、（逆にすべての証拠に対して）を望みます

はい、正確に。 これは私が何年も前から言っていることです。CLR2.0アーキテクチャは長い間私たちに役立ってきましたが、長くなり始めており、ジェネリックスと同じ種類の基本的なアップグレードの時が来ました。 必要な変更を行うために多少痛みを伴うかもしれないが、彼らが必要です。 ジェネリックスが必要だったのと同じように、新しい、より強力な機能で更新する必要があります。それを延期すると、最終的に発生したときに、痛みが軽減されるのではなく、悪化するだけです。

それがまさに.NETCoreであり、このスレッドは一時的な苦痛です。

@terrajobstはそれが起こらないと言った：スレッドを参照してください： https ： //twitter.com/terrajobst/status/1059525279431815168？s = 19

@gulbanana
はい、2つを除いて。

1. CoreはFrameworkからのアップグレードではありません。 それは平行した概念です。 それができない本当に基本的なことはたくさんありますが、AppDomainsなど、その多くは起こりそうもないと言われています。 天国のために、私たちはまだ機能しているReflection.Emitさえ持っていません！ コンパイラやコード生成ツールでそれがどれほど一般的であるかを考えると、それは文字通り最優先事項の1つだったと思うでしょうが、それでもここでは4年後、機能しません。 このため、「。NetFrameworkの代替/アップグレードとしてのコア」の概念を真剣に受け止めることは非常に困難です。
2. Coreは、ランタイム、CLR2.0スタイルを根本的にアップグレードしていません。 「CLRの変更からどの言語の提案が恩恵を受けるでしょうか？」で終わりました

いいえ、.NETCoreはアップグレードされた.NETFrameworkではありません。これはアップグレードされた.NETFrameworkではなく、プロジェクトチームは可能な限りCLRの更新を回避するためにできる限りのことを行っているためです。 それは文字通りそれの正反対です。

天国のために、私たちはまだ有効なReflection.Emitさえ持っていません！ それがコンパイラやコード生成ツールでどれほど一般的であるかを考えると、それは文字通り最優先事項の1つだったと思うでしょうが、それでもここでは4年後、機能しません。 このため、「。NetFrameworkの代替/アップグレードとしてのコア」の概念を真剣に受け止めることは非常に困難です。

何が機能しないのかを理解するのは素晴らしいことです。 ASP.NET CoreとEFは、いくつかの場所で反射放出を使用しているため、大きなギャップに気づいていません。 ここで詳しく説明していただけますか？

少なくとも2.0から存在しています。iircは1.0でもDefineDynamicAssemblyを持っていましたが、emitのもののスイート全体ではないかもしれません。

また、CLRの更新を回避しているという考えを真剣に受け止めるのは難しいと思います。 膨大な量の作業が行われているのを見たことがありますか？ https://github.com/dotnet/coreclr/commits/master
C＃8で予定されている言語機能もありますが、CLRの変更により、.NETCoreでのみ機能します。 これらの反対意見の多くは古い情報のようです（Microsoftの計画は時々急速に変更されているので、これは十分に公平です...）

@davidfowl

何が機能しないのかを理解するのは素晴らしいことです。 ASP.NET CoreとEFは、いくつかの場所で反射放出を使用しているため、大きなギャップに気づいていません。 ここで詳しく説明していただけますか？

確かに、チェックしてから数か月が経ちましたので、最近変更された可能性がありますが、私が知る限り、メモリに新しいアセンブリを作成することはできますが、 PDBファイル。これにより、Coreは私のようなコンパイラメンテナにとって役に立たなくなります。

これは修正されましたか？ 私はそれが持っていると聞いてうれしいです...

@gulbanna

また、CLRの更新を回避しているという考えを真剣に受け止めるのは難しいと思います

私が言ったことは、2.0アップデート（ジェネリック）と同じ方法でCLRを根本的にアップグレードすることを避けているということです。

具体的には、型システムに新しい基本的な種類の型（形状、メタクラス、DUなど）を追加する変更や、命令セットに新しいIL命令を追加する変更を積極的に回避しているようです。

@masonwheeler

確かに、チェックしてから数か月が経ちましたので、最近変更された可能性がありますが、私が知る限り、メモリに新しいアセンブリを作成することはできますが、ディスクに保存することはできません。

https://github.com/dotnet/corefx/issues/4491 （過去にコメントした場所）を見ると、状況は同じだと思います。 特定の機能が1つ欠けていると（それが重要な機能であっても）、「まだ機能するReflection.Emitさえありません」とはまったく異なります。

これは私のようなコンパイラメンテナにとってCoreを役に立たなくします

Reflection.Emitは、コンパイラの作成者にとってどのように役立ちますか？ 現在のフレームワークのアセンブリの作成に限定されていると思ったので、たとえば.Net Standardアセンブリの作成にはまったく使用できませんでした。これは、どのコンパイラにとっても重大な制限になると思います。

私が言ったことは、2.0アップデート（ジェネリック）と同じ方法でCLRを根本的にアップグレードすることを避けているということです。

CLRを変更しないという慣性があったと思いますが、その理由もいくつかあります。特に、プラットフォームが若いときにそのような変更が最も有用で痛みが少ないと考える場合はなおさらです。

DIMはこれが変化している可能性があることを示していると思いますが、JIT組み込み関数が同じように機能することが多い場合は、新しいIL命令や、既存の型システムで合理的にエンコードできる場合は、新しい種類の型を期待していません。

@svick

特定の機能が1つ欠けていると（それが重要な機能であっても）、「まだ機能しているReflection.Emitがない」とはまったく異なります。

テキストファイルを入力しても保存できないテキストエディタがある場合は、機能しないと思いませんか？

Reflection.Emitは、コンパイラの作成者にとってどのように役立ちますか？

これまでのところ問題なく動作しています。 そして、私が知る限り、新しいアセンブリを生成して保存するか、メモリ内に新しいアセンブリを生成して実行することができるのは、利用可能な唯一のコンパイラバックエンドです。

JIT組み込み関数が同じように機能することが多い場合でも、新しいIL命令は期待できません。

もちろんですが、そうでない場合はどうでしょうか。

または、既存の型システムで合理的にエンコードできる場合は、新しい種類の型。

既存の型システム内にShapesを実装する提案を見たことがありますか？ それについて合理的なことは何もありません。 それは最初から最後まで大きくて醜い応急修理です。 （それを思いついた人々に反対するものは何もありません。それが機能している制限を考えると、そうしなければなりません。）そしてCLRレベルのサポートなしでメタクラスを実装する幸運を祈ります！

あらゆる種類の効率的な方法で高レベルの機能を開発するには、更新されたCLRが必要であり、実際にCoreでそれを実現するために取り組んでいる人は誰もいません。

.netチームの誰かが、オンプレミス展開の推奨事項を明確にできますか？ それは単に「asp.netを定期的に使用する」だけですか？ 私は特に@ Edward84のコメントに話している

これはMicrosoft.Extensions.*サポートライブラリに影響しますか？ 具体的には、 Microsoft.Extensions.LoggingとMicrosoft.Extensions.Configurationです。

共通のコアAPIを共有する大規模なコードベースがあります。 一部はWinForms、一部は従来のASP.NET、一部はWCFなどです。最新のアプリケーションは.NET Coreです（現在はありませんが、最終的にはコアライブラリを.NET標準に移植したとき）

上記のライブラリの抽象化に基づいてコアロギングおよび構成APIを作成することを選択しました。

それで、これらが.NETCoreと.NETFramework（4.7.2+）の両方によって参照される.NET Standard APIで安全に使用できるかどうか、または.NET Coreのみの機能の使用を開始できるかどうか疑問に思っていますか？

@mvestergaard発表自体で述べたように：

Microsoft.Extensionsパッケージ（ロギング、依存性注入、構成など）は、引き続き.NETStandardをサポートします。

そして、このスレッドの@benaadamsのコメントで：

すべてのライブラリが.NETCoreのみに移行しているわけではありません（たとえば、 Microsoft.Extensions.*は.NET Standardのままです）

すでに述べたように、 @ mvestergaardは、LTSポリシーを調べて、延長サポート、長期間、「メンテナンスモード」期間などが役立つかどうか、およびそれらがどのように見えるかを判断しています。 また、新しいLTSトレインのタイミングをより予測可能にすることができるかどうかを確認するために取り組んでいます（LTSモデルを持つ他のスタックから私たちが見て本当に賞賛しているモデル）。

これに関する最大の問題は、.NET Frameworkを対象とする場合にのみ使用できる成熟したパッケージ、またはSystem.DrawingやGDI +を必要とするような.NETFrameworkの外部では利用できないパッケージを使用できないことです。

後者のシナリオは.NETCore 3.0でサポートされるようですが、AFAICTでは、.NETFrameworkでのみ使用できる安定した成熟したライブラリを使用できません。

その一例がEntityFrameworkです。 未熟なEFコアに切り替える必要があります。これは、完全なEFで可能なすべての複雑なシナリオの処理から遠く離れているようで、パフォーマンスの原因となる問題を隠すために、メモリ内クライアントの評価にフォールバックします。問題。

その一例がEntityFrameworkです。 未熟なEFコアに切り替える必要があります。これは、完全なEFで可能なすべての複雑なシナリオの処理から遠く離れているようです...

今週の@DamianEdwardsによる説明に従って、 予定ですASP.NETCommunity Standup- 2018年11月6日-19 ： 機能

@benaadamsそれは素晴らしいニュースです！ そのような大したことのためにかなりあいまいです！ :)それを見つける良い仕事。 ここでそれについての別の言及を見つけまし

@SaebAmini ：システムを使用できます。 .NETCoreでの描画。 System.Drawing.CommonおよびScottHanselmansのブログ投稿を参照してください： https ：//www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx、

その前は、MonoのSystem.Drawingのポートとして、 CoreCompat.System.Drawingが存在していました。

.NET Coreで実行する場合、ユースケースに欠けている機能はありますか？

@TsengSR .NETFrameworkをターゲットにした私の特定のシナリオは次のとおりです。

1. .NETFrameworkでのみ使用可能なMicrosoftSolverFoundationパッケージを使用する必要があります。
2. System.Drawingを使用したバーコード画像生成パッケージ。
3. EF6を使用する必要性。

これは約1年前のことです。

@SaebAmini ：前述のように、EF6サポートは.NET Core 3.0で提供され、System.Drawingはすでに存在し（その前はCoreCompatパッケージが存在し、あなたのケースでは機能していた可能性があります）、Microsoft SolverFoundationパッケージの場合はPortability API Analyzerの実行：

PortabilityAnalyzerの使用方法を参照してください

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 （ダウンロードしてHTMLを開きますが、他に配置する場所が見つかりませんでした）。

.NET Core 2.0 + Platform Extensions（約1年前にリリースされた）との97.93％の互換性を示し、非推奨となったSystem.WebとSystem.ServiceModel /に主に関連する互換性のないAPIを一覧表示します。 System.Data.Linq 。

さて、私は以前にこのパッケージを使用していませんでした。ソルバーがSystem.WebとHttpContextまたはSystem.ServiceModelにアクセスする必要がある理由はわかりませんが、これらのいずれも必要ありません（そして、ユースケースがこのAPIを呼び出していないことを知っています）、. NET Core 2.0 / 2.1 + PlatformExtensionsまたは.NETCore 3.0でさえ、それを使用できる可能性はかなり高いです。 netstandardまたはnetcoreapp20ターゲットモニカを特にターゲットにしていない場合。

技術的には、EF Core 2.0がアプリケーションのニーズをカバーできれば、1年前にアプリケーションを.NET Core 2.0 + Platform Extensionsに移行できた可能性があります（もちろん、移行作業と更新が必要です）。 EF Core 2.0を使用）。

はい、問題のライブラリまたは置換フレームワーク（EF6-> EF Core 2.0 / 2.1）の機能を分析するにはもう少し作業が必要ですが、不可能にはほど遠いです。 （ASP.NET Core自体の外で）変更をまったく行わずに、すべてのコードを1：1でASP.NETCoreに移植できると期待できるとは思いません。

パッケージをダウンロードするよりもわかりやすくするために、「バッジ」（.NET Core 3.0互換）やnugetページのどこかにある詳細なAPI互換性レポートなど、API互換性を表示する方がわかりやすいことを願っています。次に、パッケージアナライザーで実行します。

この発表は、.NETCoreの互換性がどれだけ向上したかを強調した方がよかったと思います。 ASP.NETCoreを.NETFrameworkから移動するための2つの有効な要因があります。
1）.NET Frameworkの必要性を減らし、レガシー部門を利用可能にし、相互運用性を改善するなど
2）.NET Core、機能、パフォーマンスのメリットを増やし、メンテナンスの負担を軽減します

ファクター2は、実際にASP.NETを構築する必要がある人々の心に大きく浮かび上がります。 ただし、ユーザーの観点からはほとんどメリットはありません。 人々はうまくいくものを持っており、彼らの最優先事項はそれが働き続けるべきであるということです。 良いニュースは、ほとんどの場合、そうなるということです。

@gulbananaに同意します。 .NET Coreは、.NETFrameworkとの互換性が大幅に向上しました。 実際、.exeの名前を.dllに変更し、不足している.DLLをプローブパスに追加するだけで、かなり大きな.NETFrameworkアプリを起動できました。

dotnetコマンドラインツールの進歩は印象的です。 特に.NETCoreグローバルツールの追加。 それらは開発を簡単にします。

crossgenしたAOTコンパイルは素晴らしいです。 私は続けることができます。

tl / dr .NET Coreは、最近非常に印象的です。

何が欠けている：

• 現在の顧客コミュニケーション戦略は欠けています。 お気に入りの.NETプラットフォームがMicrosoftによって断片化されていると聞いたとき、顧客は大きな失望を覚えます。 ここでもっと明確にする必要があります。 たとえば、単一の、互換性が高く、高速で将来性のある.NET実装を人々に直接宣伝する方がはるかに優れたアプローチです。 .NET Coreのように、.NETの未来は、問題のほとんどを解決し、生産性、創造性、新しい市場のニッチ市場を開拓します。
• 箱から出してさらに多くの互換性戦略
• グラフィカル・ユーザー・インターフェース。 dotnetコマンドラインツールは素晴らしいのですが、現在、.NET SDK形式のほぼすべてのプロジェクトで作業するには、追加のテキストエディターとコンソールを使用する必要があります。 Visual Studio UIには、この点が欠けています。 これは、ポイントアンドクリックするだけの習慣を持つ多くの人々に大きな障壁をもたらします。 これも改善する必要があります
• LTSサポート

@TsengSR詳細なレスポンスメイト、素晴らしい情報をありがとう！ 当時、バーコードパッケージを使用しても、プロジェクトはさまざまなターゲットについて不平を言ってコンパイルされないため、機能しませんでした。 多分私はそれをもう一度試してみる必要があります。 （自分で再コンパイルして、ちょっと継承するつもりでない限り）

それが合理的であれば、努力については本当に心配していません。 私の主な関心事は、EFが主なブロッカーであり、オプションがないまま高く乾燥したままであるということでした。 それがよく考えられているのを見るのは素晴らしいことです。 私は@gulbananaに同意し

ここには多くの混乱した問題があります。 私の個人的な2セントは、.NETFrameworkを残しておくことはそれほど大したことではないということです。 ただし、懸念されるのは、標準化の取り組み（.NET標準）に対する明らかなサポートがまったくないことです。 確かに、今日のUnityなどでASP.NET Coreを実行したくないと思うかもしれが登場するできるようになります」と言いたいです。 ..。。

少なくともASP.NETCore3用の.NETCore 3で必要なすべての変更を「収集」し、提案として.NET Standardワーキンググループに転送する機会はありますか？

こんにちは。.NetStandard2.0または.NetCore2.0用に公開されたパッケージは引き続き.NetCore3.0で動作します。 例：Oracle.ManagedDataAccess.Core target .NetCore 2.0

下位互換性がある場合は、.NetCore 3.0に移行するのが適切ですが、古いバージョンがサポートされていない場合は、すべてのプレイが追いつかない限り、実際には役に立ちません。

.NetFrameworkには、最新バージョンで.NetFramework 2.0を使用できる場合でも互換性の履歴があるため、.NetCoreでも少なくとも2.0から3.0などを維持する必要があります。

ありがとう

こんにちは。.NetStandard2.0または.NetCore2.0用に公開されたパッケージは引き続き.NetCore3.0で動作します。 例：Oracle.ManagedDataAccess.Core target .NetCore 2.0

はい、.NET Core 3.0は後方互換性を維持しているため、.NetStandard 1.0-> .NetStandard2.1および.NetCore1.0-> .NetCore2.2ライブラリを使用できます。

@benaadamsそれならいいですね。 また、不足しているAPIを使用しない場合、.net Framework dllは機能しますか？

ありがとう

また、不足しているAPIを使用しない場合、.net Framework dllは機能しますか？

はい。ただし、.NET Core（およびMono、Xamarin、Unity、UWP）で動作することをご存知のとおり、.NET標準ライブラリを使用する方が安全です。

さらに、 Windows互換性パックを使用すると、.NET Standard2.0にさらに20,000個のAPIが追加され、.NETCoreを.NETFrameworkに近づけることができます（.NET Core 2.1で実行できます）。 .NET Core 3.0は、EF6（クロスプラット）との互換性が最も高く、WindowsではWinForms、WPF、COMInteropなどです。

こんにちは皆さん、
アプリケーションを.NETCore上のASP.NETCoreに移行するための合理的な足がかりを顧客に提供するために、現在のサポートに一致するように.NETFramework上のASP.NETCore2.1.xのサポートとサービスを拡張します。他のパッケージベースのASP.NETフレームワーク（MVC 5.x、Web API 2.x、SignalR 2.xなど）のポリシー。 これは事実上、ASP.NET Core 2.1.x関連パッケージ（最終的な詳細リストTBD）が、.NET Core 2.1トレイン全体の3年間のLTS期間を超えて、無期限にサポートされることを意味します。

素晴らしいニュース。 お客様の声に耳を傾けていただき、ありがとうございます。

CTP3以降MVCを使用しており、ほぼすべての拡張ポイントが使用されているため、古いMVCアプリを移植するのに非常に長い時間がかかります。 これは私たちの懸念をカバーしています。

@DamianEdwardsそれは素晴らしいニュースです！ しかし、これは2.1.xに修正されているのでしょうか、それともLTSリリースになる場合は2.2.xに更新されるのでしょうか。 2.2には多くの努力が払われており、まだリリースされていません。 また、netstandardの互換性を維持し、完全なフレームワークで正常に動作するため、拡張サポートのためにこれを完全にスキップするのは無駄です。

@pokeはあなたの懸念を理解していますが、どこかに線を引く必要があります。この場合、バージョンを前のLTSに合わせておく方がよいと思います。 これは、LTSまたは現在の列車のどちらかを選択するときに顧客が自分で決定しなければならないトレードオフです。 新機能は安定性に関するものであるため、LTSには付属していません。 フィードバックは長期的なサポートのためのものであり、そのための列車がすでにあるので、これは列車の延長です。 2.2はLTSにはなりません。

@DamianEdwardsええ、私はそれを理解しています、あなたの返事に感謝します。 これについての最後のコメントはまだ決定されていないということだったので、私はただ尋ねていたので、2.2がLTSになった場合にこの拡張サポートが引き継がれるかどうかを知りたかっただけです。

そして、この拡張サポートに依存する必要がある場合にフレームワークアプリを2.2にアップグレードしないように、これを強調することは十分に重要だと思います。 それ以外の場合は、再度ダウングレードする必要があります。

新機能は安定性に関するものであるため、LTSには付属していません。

ただし、これは以前のLTSの決定とは実際には一致しません。

@ポーク

ただし、これは以前のLTSの決定とは実際には一致しません。

これは私を混乱させました。 どのように？ 1.1が1.xLTSトレインに追加されたという事実に言及していますか？ もしそうなら、それは繰り返されない私たちの最初のリリーストレインの異常でした。 今後、私たちの意図は、どのリリースがLTSと現在になるか（つまり、どこで安定性と機能を取得するか）の一貫性を高めることです。

@DamianEdwards私は主に、これまでのすべてのリリースが大規模な機能リリースであり、各LTSの決定は通常（少なくとも公的に）振り返って行われたという事実に言及していました。

@pokeOK 。 さて、これまでに4つのリリース（1.0、1.1、2.0、2.1）があり、5つ目はまもなくリリースされます（2.2）。 これらのうち、当初は1.0と2.0のみがLTSを意図していましたが、多くの要因（主に、この方法でエンジニアリングを行うのが本当に新しいことに関連しています😉）により、最終的に1.0、1.1、および2.1がLTSトレインになりました。 2.0と2.2は（以前は）現在のリリースです。 この段階では、3.1が3.xトレインLTSになる前に、3.0もほぼ確実に現在になります（2.2が3か月の現在の「猶予」期間に入ります）。 私たちの希望はその後、パターンとリズムがより一貫したものになることです（私たちはそれが大好きです）が、これまでのところ私たちの水晶玉は私たちに失敗しました。

@DamianEdwards洞察に感謝します！ 😄（ところで、私はこれについて議論しようとしていませんでした、私はただ興味がありました;））

私たちにとってより大きな問題は、レガシーアプリケーションによってインプロセスでホストされる新しいREST APIであり、すぐに.NETFrameworkから移行する可能性は低いです。 少なくとも、.NET Standard2をサポートするライブラリとASP.NETCore2.1を超えて進歩しないことはわかっています。 LTS期間が延長されるのは良いことです

ちょっと質問です。C++ / CLIの形式でネイティブパッケージを使用している私たちについてはどうでしょうか。 それはすぐに.NetCoreでサポートされる予定ですか、それともP / Invokeを使用するために大規模な手直しを行わない限り、孤立していますか？

@ lokitoth-ASP.NET Coreよりも一般的であるため、 https：//github.com/dotnet/coreの人々にとっては良い質問です。

@lokitothはい、サポートされます。https：//github.com/dotnet/coreclr/issues/18013を参照して

oOどうして私はそれを逃したのですか？

さて、私はこれに問題はありません。

@ danroth27この問題がClient-Side-Blazorに与える影響を教えてください。

@Slkebe影響はないと思います。 クライアント側のBlazorアプリは、サーバーで実行することを決定したランタイムやプラットフォームに依存しません。

@ danroth27私の理解では、依存するMicrosoft.AspNetCore.*パッケージはnetstandardをターゲットにしているため、クライアント側のBlazorはmonoで実行できます。
私は何かが足りないのですか？ BlazorはMicrosoft.AspNetCore.* 2.1.Xをターゲットにし続ける必要がありますか？

@Slkebeクライアント側のBlazorライブラリは、.NET Standardを引き続きターゲットとするコンポーネント（Microsoft.Extensions。*やその仲間など）にのみ依存します。 ASP.NET Coreに依存するBlazorのサーバー側の部分は、この問題で説明されているように.NETCoreを対象とします。

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

今の決定は何ですか？ .net標準2.1をターゲットにしますか？

@ John0King新しい決定はありません。

これはバナナです！ バナナ

私はあなたの見方に同情しています。

これがすでに提起されている場合はお詫びしますが、ASP.NET以外のアプリケーションの一部としてKestrel +一部のミドルウェアを使用したいだけのユースケースはどうですか？ 3.0ツリー全体をプルする必要がありますか（私のユースケースではコンシューマー用のカスタムSDKを定義する必要があるため、これは理想的ではありません）、またはこのユースケースは3.xでサポートされていませんか？

ライブラリが含まれているため、現在、.NETFrameworkで実行されるASP.NETCoreアプリケーションを開発しています。 マルチ認証機能があるため、ASP.NETCoreを使用しています。 私はだまされて、完全にロックされていると感じています。

マルチ認証機能があるため、ASP.NETCoreを使用しています。

@FlorianGrimm具体的には何ですか？ Microsoft.Owinは、ASP.NET4に同様の認証機能を提供しました。

これは、オンプレミスとAzureで実行され、現在Windows auth、aad、basic auth、anonymousを使用しているハイブリッドアプリの1つのソースコード（.exe）です。

@FlorianGrimmどのライブラリの依存関係が

Microsoft.Office.Project.Schema、Microsoft.SqlServer.TransactSql.ScriptDom、およびMicrosoft.SharePointOnline.CSOM。

SharePointチームが終了することを願っています
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
そして私はilspy以外のオプションを見つけます。

いずれにせよ、私はASP.NET Coreが好きで、他のMicrosoftTeamsがより多くの.NETCoreアセンブリを提供してくれることを願っています。

長期間更新されていない「ディスカッション」の問題は定期的にクローズします。

ご不便をおかけして申し訳ございません。 それでも問題が発生する場合は、更新された情報を使用して新しい問題をログに記録してください。調査いたします。