Aspnetcore: 新しいASP.NETCore2.0パッケージは.NETデスクトップでは使用できなくなりました

作成日 2017年05月05日  ·  761コメント  ·  ソース: dotnet/aspnetcore

編集:「ASP.NETCore2.0の.NETFrameworkサポートなし」プランは正式にキャンセルされ、.NETDesktopでのASP.NETCore2.0の実行は次のプレビューでサポートされる予定です。 詳細については、ASP.NET Core 2.0.0- Preview1および.NETWeb開発者向けの更新プログラムの発表を参照するか、.NETStandard2.0および.NETCore2.0をご覧ください。

このスレッドに参加するために時間を割いてくれた皆さんに感謝します; 間違いなく、Microsoftの責任者は、コミュニティに相談したり、エコシステム全体に対する一方的な決定の実際の影響を測定したりせずに、このような大きな重大な変更を最後の最後に黙って採用することはできないことを認識しました。

私たち全員が異なる意見を持っていましたが、最も重要なことは、この変化について実際に話し合うことでした。 これは明らかに大きな成功であり、前例のない成功です(150人を超える参加者と700を超えるメッセージ、うわー!)

このような素晴らしいコミュニティが活動しているのを見るのは驚くべきことです。私はその一部であることをとても誇りに思っています:call_me_hand:


元のメッセージ:本日、ほとんどのASP.NET Core 2.0パッケージは、 netstandard1.*およびnet4* $ではなくnetcoreapp2.0を対象とするように更新されました(例:https://github.com/ aspnet / Security / pull / 1203およびhttps://github.com/aspnet/Mvc/pull/6234)、.NETDesktopおよびMonoとは完全に互換性がありません。

この大きな重大な変更は、ASP.NETエコシステム全体に大きな影響を与える可能性がありますが、議論も公表もされていません(ASP.NETチームはコミュニケーションがあまり得意ではなく、実際に議論する意思がないことをもう一度示していますそのコミュニティでのそのような重要な変化ですが、それは別の話です)。

このスレッドでは、 @ Eilonはこの決定の背後にある理由について部分的に言及しましたが、それほど極端でないオプションが考慮されているかどうかについては述べていません(たとえば、クロスコンパイル、 netstandard2.1 TFMの導入など)。

はい、ASP.NET Core 2の場合、ほとんどのライブラリは、.NET Standard TFMでまだ使用できない新しいAPIを使用するために、.NETCore2を対象としています。 Microsoft.Extensions。*、Entity Framework Core、およびその他のいくつかのライブラリなど、複数のプラットフォームを対象とする必要があるコードは、引き続き.NETStandardを使用します。

私の質問は単純です。RTMの前のある時点でこれらの変更を修正/元に戻して、人々が.NETデスクトップでASP.NET Core 2.0パッケージを使用できるようにするのでしょうか、それとも.NETデスクトップ上のASP.NET Core 2.0が完全に機能しなくなるのでしょうか? (これは私を含む多くの人々にとって大きな障害となるでしょう)。

ありがとう。

最も参考になるコメント

これが最初は恐ろしいWTFの瞬間である理由がわかります。 見た目よりも気紛れではないので説明させてください。

  • .NETのお客様は相互運用する必要があるとおっしゃいました。 完全に同意する。

    • ASP.NETCore2.0とEVERYWHEREの間でnetstandardライブラリを共有できます。

    • タイプフォワーディングとnetstandard20により、ASP.NETCore2.0から多くのnet461+アセンブリを参照することもできます。

  • WebAppsは以下を使用する必要があるかもしれないとあなたは言いました:

    • AD –全体として、LDAPを直接呼び出したい場合、これはギャップです。 あなたは確かに今すぐWindows認証に対して認証することができます。 特に夏の時間枠の前後にCore2.0のDirectoryServices名前空間を使用する予定です。

    • 描画–全体として、これはギャップです。 これは、夏の時間枠の前後にCore2.0で使用する予定です。 これまで、これらのnetstandardオプションには、ImageSharp、ImageResizer、Monoオプションなどもあります。

    • COM自動化–これはCore 2.0では不可能でしたが、自分を傷つけたい場合は確かにPInvokeを使用できます。 本当に自分を傷つけたい場合は、WebAPIをnet461+プロセスにローカル化することもできます。

    • WFPアプリとのコード共有–はい。 netstandard2.0で完全に可能です。

  • これは奇妙な変更です。

    • 感じますが…

このように考えてください。 WPFはnetstandard2.0ではなく、net461 +上にあることを認識しており、問題ありません。 最適化されていますが、netstandardライブラリを参照できます。 ASP.NET Core2.0はCore2.0用に最適化されていますが、共有ライブラリを参照できます。 Xamarinも同じです。

.NET Coreは並んでいて、高速で移動しています。 .NET(フル)フレームワークが移動できるよりもはるかに高速です。これは良いことです。 .NET Core 2.0(これは.NET StandardのSUPERSETであることを忘れないでください)の上にASP.NET Core 2.0を構築することにより、NetFxやNetstandardよりも高速に構築できることを意味します。

開発のスピードと革新に関しては、NetCore> NetStandard>NetFx。

ポイントは、新しい作業をしている場合は、netstandard20です。 古いnet461+ライブラリを使用している場合、それらのほとんどはASP.NETCore2.0で参照できます。

.NETFrameworkで実行されるASP.NETCore1.1は、2.0のリリース後1年間完全にサポートされます。 そのワークロードは、少なくとも2018年7月まで完全にサポートされます。

.NET Core 2に欠けている残りの大きなギャップは、System.DirectoryServicesとSystem.Drawingです。 この夏、Windows上の.NETCoreで両方を有効にするWindows互換パックの作成に取り組んでいます。

皆さんから必要なのは、net461+で実行するためにASP.NETCore2.0が必要であると考える理由の明確なリスト/理解です。

全てのコメント761件

これは非常に奇妙で悪い変更になります。 私は多くのnetfxのみのasp.netコアコードを作成しましたが、その投資が無駄になるのを見たくありません。 より一般的には、.NETのお客様は、近い将来、ASP.NET CoreとDesktopコード間で相互運用できる必要があります。ActiveDirectory、Office COMの自動化を使用する、またはSystem.Drawingベースのサムネイルを使用するWebアプリを想像してみてください。ライブラリ、またはWPFアプリとコードを共有します。 このような多くのシナリオを考えるのは簡単であり、何が起こっているのかを単に誤解していることを願っています。

現在、AspNetCore 1.1.1を使用しています。つまり、「現在の」サポートブランチです。 Net4XXに依存しているために2.0に移行できない場合、2.0 + 3か月が経過するとサポートされなくなるということですか?

WPFとASP.NETCoreの組み合わせを使用し、どちらの場合も完全なフレームワークをターゲットにします。
それで、私は予見可能な将来に2.0がないと思いますか?

しかし、完全なフレームワーク4.6.1はnetstandard 2をサポートしますか? 私は何かが足りないのですか? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

これは、現在のツールが更新されていないということではありませんか?

完全に問題なく、ネット標準2でasp.netコアが実行されることが期待されます。憂慮すべきことは、ネットコアapp2.0に移行するというこの見通しです。これは、asp.net内でレガシーコードを使用できなくなることを意味します。コアWebサイト

ああ、それは問題です。古いアセンブリを参照できるnetcore2の互換シムによって少し軽減されたと思いますが、それでも、すべてのプロジェクトを新しいプロジェクトシステムや他の多くの作業に移植することを意味します。

チームがこれについて推論しているのを聞いてうれしいです

ああ、それであなたはnetcoreapp2.0プロジェクトが型の統一のおかげでnetfxライブラリを単に参照することができると思いますか? それは多くのことを説明するでしょう。 もしそうなら、私の質問は、Windows上でコアCLR上で実行されたときに実際にどのくらいのコードが機能するかということです。

おお。 これは私たちにとって完全にブロックされ、基本的に、これらのパッケージを近い将来に更新できないようにします。 現在、net462 +をターゲットにすることはできないため、MvcCoreプロジェクトをMvcに戻す必要がある場合もあります。

これについても非常に興味があります。 私はこれが中間の(そして短命の)ステップまたは大きな誤解でこれを本当に望んでいます。 それは確かに私たちのアプリケーションのほとんどにも採用を妨げるでしょう。

すべてをCoreに移動することは、既存の大規模なコードベース(devを停止せずに)には多すぎます。メインプロジェクトの中間ステップとして、新しいASP.NETクラス(HttpRequest、コントローラーなど)に移動する必要があります。

おそらく@DamianEdwardsまたは@davidfowlはここで計画についてコメントできますか? また、追加の理由を見つけるのに苦労しています。

これが最初は恐ろしいWTFの瞬間である理由がわかります。 見た目よりも気紛れではないので説明させてください。

  • .NETのお客様は相互運用する必要があるとおっしゃいました。 完全に同意する。

    • ASP.NETCore2.0とEVERYWHEREの間でnetstandardライブラリを共有できます。

    • タイプフォワーディングとnetstandard20により、ASP.NETCore2.0から多くのnet461+アセンブリを参照することもできます。

  • WebAppsは以下を使用する必要があるかもしれないとあなたは言いました:

    • AD –全体として、LDAPを直接呼び出したい場合、これはギャップです。 あなたは確かに今すぐWindows認証に対して認証することができます。 特に夏の時間枠の前後にCore2.0のDirectoryServices名前空間を使用する予定です。

    • 描画–全体として、これはギャップです。 これは、夏の時間枠の前後にCore2.0で使用する予定です。 これまで、これらのnetstandardオプションには、ImageSharp、ImageResizer、Monoオプションなどもあります。

    • COM自動化–これはCore 2.0では不可能でしたが、自分を傷つけたい場合は確かにPInvokeを使用できます。 本当に自分を傷つけたい場合は、WebAPIをnet461+プロセスにローカル化することもできます。

    • WFPアプリとのコード共有–はい。 netstandard2.0で完全に可能です。

  • これは奇妙な変更です。

    • 感じますが…

このように考えてください。 WPFはnetstandard2.0ではなく、net461 +上にあることを認識しており、問題ありません。 最適化されていますが、netstandardライブラリを参照できます。 ASP.NET Core2.0はCore2.0用に最適化されていますが、共有ライブラリを参照できます。 Xamarinも同じです。

.NET Coreは並んでいて、高速で移動しています。 .NET(フル)フレームワークが移動できるよりもはるかに高速です。これは良いことです。 .NET Core 2.0(これは.NET StandardのSUPERSETであることを忘れないでください)の上にASP.NET Core 2.0を構築することにより、NetFxやNetstandardよりも高速に構築できることを意味します。

開発のスピードと革新に関しては、NetCore> NetStandard>NetFx。

ポイントは、新しい作業をしている場合は、netstandard20です。 古いnet461+ライブラリを使用している場合、それらのほとんどはASP.NETCore2.0で参照できます。

.NETFrameworkで実行されるASP.NETCore1.1は、2.0のリリース後1年間完全にサポートされます。 そのワークロードは、少なくとも2018年7月まで完全にサポートされます。

.NET Core 2に欠けている残りの大きなギャップは、System.DirectoryServicesとSystem.Drawingです。 この夏、Windows上の.NETCoreで両方を有効にするWindows互換パックの作成に取り組んでいます。

皆さんから必要なのは、net461+で実行するためにASP.NETCore2.0が必要であると考える理由の明確なリスト/理解です。

.NET Standard 2.0は、互換性と相互運用性がすべてだと思っていました。これは、誰もが待ち望んでいた.NETCoreと.NETfxの間のギャップを埋めるものです。

何らかの理由で、カスタム外部依存関係、商用コンポーネント、レガシーlib依存関係など、.NET4.xを必要とする依存関係を持つ多くの顧客がいるでしょう。

お客様がデスクトップCLRで実行されるASP.NETCore2.0アプリを作成して、既存の.NET 4.x depsを参照できるようにすることは意図されていますか?

@shanselman返信ありがとうございます-そこにはたくさんの良い例があります。

ライブラリに関するフォローアップ:
すべての抽象化ライブラリはクロスコンパイルされたままになりますか? たとえば、 HttpRequestを使用している場合、使用しているASP.NET Coreのバージョン(少なくともTFMにクリーンにマップされる)で1.xおよび2.xビルドを維持することは何かになります。避けたいので...抽象化がnetstandardに残ることを望んでいます。 それは一般的な計画ですか?

System.WebHttpRequestは完全に異なるため、ASP.NET / MVCに依存するものについては、すでに複数のバリアントを維持しています。これは完全に別のライブラリです(たとえばMiniProfiler vs 。 MiniProfiler.AspNetCore )。 依存関係がnetstandardから外れた場合に、lib作成者のために維持するためにロードしているバリアントの数を念頭に置いていることを確認したいだけです...そして、うまくいけば、その頭痛の種をすべて一緒に避けてください。

これが見た目ほど大したことではないように思われることを非常に嬉しく思います。詳細な説明をありがとうございます。

私には2つの質問/懸念があります:

  • ASP.NETCoreから.NETFrameworkライブラリを使用することで、摩擦を最小限に抑えることができるようです。 それは素晴らしいことです! 逆はどうですか? Mvcやその他のサポートするASP.NETCoreライブラリのパーツやコンポーネントを埋め込んでいる.NETFrameworkまたはnetstandardライブラリやアプリケーションがおそらく存在します(私はいくつか持っているので知っています)。 それらは壊れますよね? そのシナリオを回避するためのヒントはありますか? netstandardライブラリがASP.NETCoreライブラリを使用できなくなった場合、それは組み込みASP.NETCoreシナリオにとって大きな問題のように思われます。

  • 非技術的な観点からは、これは多くの混乱を引き起こすように思われます。 GitHubで活動している人や、Twitterでフォローしている人以外にも、さまざまなプラットフォームなどを取り巻く混乱がすでにかなりあります。部分的にしかフォローしていない開発者や、立ち上がったばかりの開発者を見ることができます。 ASP.NET Coreを使用するときに(おそらく古いチュートリアルに従って)非常にイライラし、.NETFrameworkプラットフォームで動作させることができない場合にスピードを上げるためです。 それについて何ができるかわからない。

タイプフォワーディングとnetstandard20により、ASP.NETCore2.0から多くのnet461+アセンブリを参照することもできます。

残念ながら、これは、完全なフレームワーク用にコンパイルおよび設計されたライブラリが.NET Coreで機能することを意味するものではありません(実行時に爆発するリスクが高くなります)。

.NET Core 2.0で再導入された「古い」APIの多くは、(機能的に)機能しないスタブです。 言うまでもなく、不足しているAPIはまだ多く、.NET Coreから意図的に除外された領域全体(IdentityModel、WCFサーバー、リモート処理、完全なAppDomainサポートなど)もあります。

ASP.NET Core 1.0 w/.NETデスクトップアプリをASP.NETCore2.0 w /.NETCoreに「安全に」移行できることを人々に納得させようとするのは-私見-嘘です。

.NET Coreは並んでいて、高速で移動しています。 .NET(フル)フレームワークが移動できるよりもはるかに高速です。これは良いことです。 .NET Core 2.0(これは.NET StandardのSUPERSETであることを忘れないでください)の上にASP.NET Core 2.0を構築することにより、NetFxやNetstandardよりも高速に構築できることを意味します。

それが(ほとんどの)人々が探しているものだとは思いません。 多くの人は動きの速いライブラリを必要としません。すべてを壊すリスクを冒すことなく、古いものに優雅に統合できる安定したものが必要です。

@daveaglick

  • net461またはnetstandard2.0 netcoreapp2.0を参照する暗黙の機能がないという点で修正してください。 橋は一方向に行きます。 パッケージフォールバックにTFMを指定することでいつでも回避できますが、これは明らかにエスケープハッチであり、サポートされているシナリオではありません(ただし、多くの人のブロックを解除するには十分です)。 より大きなスタックの外部でASP.NETCoreのサブシステムをサポートすることは、私たちにとって重要な作業です(これは、 netstandardをターゲットにすることを意味します)。
  • 混乱の可能性は双方向に行きます。 たとえば、「ASP.NETCore」が.NET Framework(.NET Coreではない)で実行できるという事実は混乱を招くという多くのフィードバックがありました。 この変更により、ASP.NETCoreは事実上.NETCoreスタックの一部になります。つまり、ASP.NET Coreを使用している場合は、.NETCoreを使用しています。

@shanselmanところで、クロスコンパイルがオプションではなかった理由は言わなかった。 netcoreapp2.0のみのAPIの恩恵を受ける可能性のあるASP.NET Coreコンポーネントは、 net46 / netstandard1.x / netstandard2.0netcoreapp2.0の両方のTFMと新しいクール/高速なものを.NETCoreのみにします。

@NickCraverの現在の計画には、 netstandardを対象とする*.Abstractionsパッケージを残すことは含まれていません。 分離は、全体的な分離ほどきれいではありません。 しかし、あなたが提案しているような移行を試みる誰かの目的のために、パッケージターゲットフォールバックを使用すると、とにかくそこに到達するはずです(しかし、私はあなたを誤解しているかもしれません)。

また、クリーンなTFM分割が正しく、TFMをピボットとして使用して、単一のパッケージでASP.NETCore1.xと2.0+を同時にターゲットにできるという点でこのプランの利点があります。

私は「混合アプリケーション」のアイデアをいじくり回してきました。 たとえば、Web APIを公開するWPFアプリケーション、またはREST APIとWCFエンドポイントの両方を提供するサーバー(これは、以前のクライアントとの互換性のためである可能性があります)。 これらのシナリオはこの変更により不可能になり、ASP.NET Coreは「単なるライブラリ」ではなく、新しいアプリケーションにのみ適したものになります。

@shanselmanが述べたように、 @ PinpointTownesは、.NET Frameworkを直接ターゲットにし続ける必要性に関して、お客様が持つ特定の要件とブロッカーに非常に関心があります。 これまでのところ、このボートでのお客様との作業では、 System.DirectoryServicesSystem.Drawing 、およびNo.1と2のブロッカーが示され、それに対処する計画があります。 それを超えて、私たちはフィードバックを見て、評価します。

クロスコンパイルはオーバーヘッドであり、顧客や製品のニーズとバランスを取る必要があります。 これが、このフィードバックを取得したい理由です。これにより、ASP.NET Coreを進化させながら、お客様と私たちの両方の状況をより具体的に定義できるようになります。

@DamianEdwardsさらに明確にしていただきありがとうございます。 netstandard-> ASP.NET Coreライブラリは、私にとって大きな問題です。 Kestrel(これもnetcoreappに移行しているようです)をいくつかのnetstandardライブラリに埋め込みます。 また、Razorをいくつかの場所に埋め込んでいます。あなたが新しいよりモジュール化されたバージョンに取り組んでいることは知っていますが、それがnetcoreappのみを対象としている場合も問題が発生します。 ASP.NET Coreの「一部」であるが、それ以外にも多くのユーティリティを備えたライブラリもたくさんあります。

言い換えれば、私はその逆よりも、netstandardライブラリがASP.NETCoreパッケージを消費する機能を削除することについてはるかに懸念しています。 これにより、ユースケースのクラス全体が検討対象から外されているようです。

@daveaglick Razor自体(エンジン)は引き続きnetstandardをターゲットにします。 繰り返しになりますが、さまざまなプラットフォームで大規模で複雑なグラフ(ASP.NET Core 2.0など)の特定のサブシステムをサポートするには、コストがかかります。 埋め込みのようなものについては、他のオプション(ソースの埋め込み、コピーなど)がありますが、もちろん、それらには独自のトレードオフがあります。

さまざまなクラスのユースケースについてお聞きしますが、私たちのようなスタックを設計および出荷する際には、実際にさまざまな顧客グループを検討する必要があります。

ここで@daveaglickの懸念を共有します。最新のAPIを使用したいASP.NETCoreは完全に理解できますが、ダウンストリームで同じものを必要とする他のすべてのものについては、少し面倒になります。 1.0の安定またはアップグレードの後は、選択肢がありませんnetcoreapp2.0で利用できる最速の電車に乗っているので、それが唯一の選択肢です。 ユーザーにnetcoreapp2.0を消費させることなく、すべてのビット(基本的な抽象化でさえ)を消費できない場合、それは、ライブラリのその行全体に実質的にnetstandard2.0がないことを意味します...そしてすべての人それは彼ら次第です。

コアアプリケーションスタックを動かしますが、特に抽象化に同意する必要はありません。 抽象化の主要なポイントの1つは、少なくとも消費者としての私の見解では、このような緊密な結合を回避することでした。 netstandard2.0に必要なAPIがないが、 netcoreapp2.0には必要なAPIがある例をいくつか見てみたいと思いますが、そこにいくつかの例がありますか? これは主にメソッドパラメータの新しいタイプに関するものですか? 十分な理由があることは間違いありません。私は非常に興味があります。例を見ると、毎日の洞察がほとんどないメンテナンスコストを示すのに役立ちます。

Kestrelのケースはもっと複雑ですが、最新のAPIセットでそれを使用することについての議論は確かにわかります。 Kestrelが推進している作業を考えると、Kestrelに新しいAPIが継続的に作成されると思います。

@shanselmanが述べたように、 @ PinpointTownesは、.NET Frameworkを直接ターゲットにし続ける必要性に関して、お客様が持つ特定の要件とブロッカーに非常に関心があります。

コンサルタントとして、私は多くのクライアントがアプリをASP.NET Coreに移行するのを手伝い、 IdentityModel / WCFに依存する、またはAppDomainに依存するサードパーティ(クローズドソース)ライブラリを使用できるように、.NETデスクトップをターゲットにする必要がありました。サポート。

ASP.NET Core 2.0にこれらのものがないことは、それらの主要な障害になります。

APIがあったとしても、機能が異なるため、.NETCoreでは機能しないライブラリもあります。 これは私が何度も見た具体的なケースです:

.NET Coreでは、 RSA.Create()はWindowsではRSACngインスタンスを返しますが、.NET DesktopではRSACryptoServiceProviderインスタンスが返されます。 それでも、BLC自体を含む多くのライブラリはRSARSACryptoServiceProviderにキャストしようとしますが、 RSACngRSACryptoServiceProviderにキャストできないため、.NETCoreでは常に失敗します。

@NickCraver特にどの抽象化ですか? 抽象化だけを移動する場合の問題は、次に、それらの抽象化に基づいて構築されたすべてのものが必要になることです(Microsoft.AspNetCore.Http.Abstractionsだけが必要であると文字通り言っている場合を除きます)。

@davidfowlはい、抽象化のみです。たとえば、HTTP、ホスティング、HTML、ロギングなどです。 Microsoft.Extensions.*は以前のコメントでカバーされているようですが、これはこれらのほとんどです。 それらは私が今日接触しているものです。

具体的な例として、MiniProfilerミドルウェアは抽象化以外には応答しません(リンク

MVCなどを上で使用している場合は、とにかくnetcoreapp2.0を使用しているので、それがそれです(IMO、それで問題ありません)。 しかし、現在、共有されている場所でAPIを論理的に分割する自由があり、それらは抽象化されているため、簡単に分割できます。 私は現在のスプリットのファンです。不必要にそれをロックダウンしないでください。

ふふ。 コンサルタントとして、私は間違いなく「何ですか?ASP.NETCoreはデスクトップ.N​​ETFrameworkで実行されます!?」と聞いたことがあります。 かなりの回数質問します。 「ASP.NETCore」の名前に文字通り「.NETCore」が含まれているという事実は、本当に残念なことです。

とにかく....NETCoreが開始されたときに廃止された/レガシー/壊れたAPIを削除するのが好きだったのと同じように(「新たな」スタート)、より高速でスリムなフレームワークを取得するためのこの変更のファンでもありますより多くの機能とより高いイノベーション率を備えています。

そうは言っても、来年の6月までにすべてのコードを.NETCoreに移行できないすべての開発者に同情しています。

これには、現在並行して開発されている複数のASP.NET Coreプロジェクトによって消費される、.NET Frameworkを対象とした、非常に大きなレガシーライブラリ/フレームワークを備えた現在のクライアントが含まれます。 これらのシステムが本番環境に移行するまでに、ASP.NET Core 1.xがサポートされなくなる前に、a)すべてを.NET Coreに移植するか、b)すべてを完全なフレームワークASP.NETに移動する時間はほとんどありません。

ここでは1年間のサポートで本当に十分ですか? 私はそこに他の同様のケースがあると想像することができます...

@khellangは前述のように、.NET Frameworkをターゲットとするライブラリ/フレームワークを引き続き参照できます。これは、呼び出すAPIがnetstandard2.0のクロージャの一部であると仮定すると問題なく機能します。 彼らがその空間の外のものに依存しているかどうか知っていますか? これらのAPI( System.DirectoryServicesSystem.Drawingなど)の移植の優先順位を評価できるように、フィードバックを受け取りたいと思っています。

では、現在のWindowsサービスやWPFデスクトップアプリでは、Web API(通信レイヤーなど)や今後のasp.netコアソケットをホストすることは不可能になるのでしょうか? (サポートされているバージョンを使用)。

以前はnetstandard1.xたが、現在はnetcoreapp2.0になっているもののリストが間もなく登場すると思います。

リポジトリを閲覧しましたが、MVC固有のものはnetcoreapp2.0のようですが、HttpAbstractions、Logging、Configurationなどはまだnetstandardですか、それとも今後さらに変更がありますか?

@NickCraver拡張機能を使用しているようですが、まだSystem.Webを使用しています。 System.Web.HttpContext Microsoft.AspNetCore.Http.HttpContextをシムする計画はありますか? 必要なAPIの量がわかりますか?

MVCなどを上で使用している場合は、とにかくnetcoreapp2.0を使用しているので、それがそれです(IMO、それで問題ありません)。 しかし、現在、共有されている場所でAPIを論理的に分割する自由があり、それらは抽象化されているため、簡単に分割できます。 私は現在のスプリットのファンです。不必要にそれをロックダウンしないでください。

私はMVCについて話しているのではなく、基礎となる抽象化に加えてより多くの機能を公開する他のヘルパーについて話しているだけです。 私たちが選んだ「抽象化」パターンの大きな価値は、抽象化自体ではなく、他のものがそれらの上に構築できることです。 私の直感によると、ASP.NET抽象化をネット標準にすると、すべてのミドルウェアもネット標準にする必要があります。

@dasMulli Windowsサービスは、APIが移植されると機能します(.NET CoreでWindowsサービスをサポートするオープンソースライブラリもあります)。

WPFデスクトップアプリ? (サポートされているバージョンを使用)。

はい。 これはもうデフォルトではありません。 .NET Core 2.0では、そのままではサポートされなくなります。

@davidfowlあなたがそこで正しい部分を見たかどうかはわかりません:

しかし、まだSystem.Webを使用しています

...この分割のため、同じライブラリにはありません。 消費者の依存関係のトラックロードではなく最小限のオーバーヘッドを実現するために、ASP.NET MVC <6(System.Web)の場合MiniProfilerMiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (多くのNuGet)があります。 )。

MiniProfiler.SharedにあったSystem.Webの痕跡について話していると思います-昨夜フレームワークアセンブリでNuGetの問題が修正されるまで、それらをクリーンアップするのを待っていました。 私は物事を片付けるためにそれを削除しました。

@DamianEdwards私はnetstandard2.0の閉鎖に100%満足しているわけではありませんが、(彼らの許可を得て)移植性アナライザーを実行して結果を共有したいと思います。 移植性アナライザーはまだ最新のものですか?

ASP.NetCoreはすぐに新しいPython3*になりつつあります。 悪いだけです。 これは私には間違った方向への動きのようです。 これは、大量のシナリオにより、開発者が移動する代わりに、今後何年にもわたって「古いプラットフォーム」でコードを維持(および新しい作成)することを余儀なくされることを意味します。 「より速い開発」は、それが意味するすべてがあなたがより悪い/不適切な場所「より速い」に到達することであるならば、あまり良い議論のようには思えません。

*私はPython3が好きですが、それはほぼ10年が経過しており、Pythonコミュニティはまだ崩壊しています

明確にするために-技術的なブロッカー(派手なパフォーマンスのもの)はありますか、それとも将来の互換性を維持するためのコストを節約するためだけですか?
私たちのほとんどはこの動きが来ることを知っていたと思いますが、誰もすぐにそれを期待していませんでした..移行時間がまだ続いていることを考えると(ライブラリが移植されているように、.net標準2.0が間近に迫っていますが、ライブラリはまだ構築されていません) -少なくとも1つのリリース(たとえば、2.1ではなく2.0)のnet*サポートを維持するのは素晴らしいことです。

@shanselman私はあなたの主張を理解しており、個人的にも同意しますが、多くの人々はそれをそのように見るつもりはありません。

主な問題はコアからnet46アセンブリを呼び出すことではなく、ほとんどの場合、互換性のあるシムがそれを処理します。 問題は、既存のnet46コードとasp.netコア1. *コードが46で実行されていることです。誰かが述べたように、netstandardの全体的なポイントは、asp.netを含むコードをどこでも実行できるようにすることでした。これは、一歩のように感じます。それから離れて、そしておそらく何人かの人々へのそのビジョンの失敗さえ。

問題は、人々がネットコアに移行したくないということではないと思います。 問題は、組織、管理者、CTOなどが、そうすることのコスト/利益がそれだけの価値があることを確信しなければならないということです。 移植は、配達に食い込むのに十分な時間がかかるだけでなく、退行などのリスクももたらします。

言い換えれば、人々が動くのを妨げるのは必ずしも技術的な理由ではありません。 私は、そのまれな、_技術的に_ほとんどすべてのプロジェクトがジャンプをすることができるとさえ言うでしょう。 しかし、そのコスト/納期のスリップを動機付けることは、問題です。 それは非常に難しい販売になる可能性があり、私は何度かフェアを行わなければなりませんでした。 そのような場合、「しかし、完全なフレームワークで実行できます」と言うことができることは、その動きを推進する方法でした。

自分を傷つけたいなら

これはまさにそれです。 Net46の開発者と管理者はそれをそのように見ないでしょう、彼らはそれを_you_、マイクロソフト、最新のリリースに追いつくために彼らを傷つけたいと思うでしょう。 「それなら動かないでください」と言う人もいるかもしれませんが、asp.net core 1.xのサポートが短いので、少なくとも、次の場合に責任を負わなければならないマネージャーの観点からは、そうしなければなりません。バグはダウンタイムまたは情報の損失を引き起こします。 (フレームワークが責任を負わない場合でも)

asp.netコア1.1を実際に推進した多くの開発者も、コアなしでは2.0に移行できないことに裏切られたと感じるでしょう。 それは正当化されるかもしれないし、正当化されないかもしれませんが、私はあなたに言っているだけです、多くの人々はそのように感じるでしょう、彼らは彼らのより保守的な同僚に答えなければならない人になるでしょう

それは重要ですか? このため、asp.net core2 / dotnet core2は「死ぬ」のでしょうか? いいえ、しかしそれは採用を遅らせ、生態系を破壊します、そしてそれは本当に悲しいimoです。 私は人々が2.0で来るこれらすべての素晴らしいものを使用できるようにしたいので、クロスコンパイルをネット標準にカットすることはそれに影響を与えます。 確かに、これらのリポジトリにたむろしているほとんどの人は問題を抱えていません。そのジョーとジェーンの開発者、さらには彼らのマネージャーが問題です。

@DamianEdwards
これが混乱の原因であることに同意します。何度も説明しなければなりませんでしたが、その結果、新しいクールなものを使用できないと思ったため、常に失望した開発者が興奮した開発者になりました。しかし、それは可能であることが判明しました。

夏に向けて、この決定は軽々しく行われなかったと思いますが、これを行う必要がある場合は、メッセージングに本当に_本当に_注意する必要があると思います。特に1からasp.netコアに移行することを示す必要があります。 net46のxは、非常にシンプルで洗練されています。 net46から他のnetstandardライブラリをプロジェクト参照として参照するためのストーリー、またはそれ以外の場合は堅実である必要があります。 人々がびっくりするのを避けるために、これを明示的に示す/対処する必要があると思います

移植性アナライザーの質問に対する@khellangページング@terrajobst

@khellang

はい、2017年にVSIXを更新しましたが、ここからコマンドラインバージョンを使用するだけです。

@NickCraver確かに、netstandardをターゲットとするミドルウェアを作成できます。これは、ASP.NET Coreがnetcoreapp2.0をサポートしている場合、ライブラリの作成者としてどのようなメリットがありますか。

@ aL3891素晴らしい要約! 私たちが今後抱えている大きな問題の1つは、netstandardにも含まれているものに新しいAPIをどのように活用するかです。 .NET Core、新しい機能を実装するために必要な新しいAPIを取得します(頭に浮かぶのは、KestrelでのHTTP2サポートのSSLStream ALPNサポートです)。 したがって、私たちはnetstandardにとどまり、常に最高のバージョン(.NET Frameworkはまだサポートしていません)を使用していると主張することができますが、そうすると私たちは同じ船に乗ります。

私たちが今後抱えている大きな問題の1つは、netstandardにも含まれているものに新しいAPIをどのように活用するかです。 .NET Coreは、新しい機能を実装するために必要な新しいAPIを取得します(頭に浮かぶのは、KestrelでのHTTP2サポートのSSLStream ALPNサポートです)。

https://github.com/dotnet/corefx/issues/4721によると、 SslStreamのALPNサポートは.NETCore2.0の準備ができていません。 これが最終的に数か月後に実装されると仮定すると、それはnetcoreapp2.0 TFMをターゲットにするときにそれを使用できることを意味しますか? この場合、ユーザーが古い.NET Coreランタイムを使用している場合、最初のnetcoreapp2.0シェイプの一部ではなかった新しいAPIを使用するnetcoreapp2.0ベースのライブラリをリリースするとどうなりますか? クラッシュしますか? または、 netcoreapp2.xnetstandard1.x $と一致しますか?その契約はTFMバージョンをインクリメントせずに変更することはできませんか?

スタックの任意の部分のその他の実装とテストについては、 @davidfowl 。 そして、抽象化は(MVCを必要としない)「すべての人がMVCを持っていて、すべての依存関係を望んでいると仮定する」のではなく、2つのライブラリ間の適切な分割であるためです。

抽象化が実際には抽象化ではなく、ASP.NET Core自体と緊密に結合されている場合は、それらのパッケージを削除してみませんか? それが全体的な関係の目標であるならば、それは人生をより簡単でより明確にするであろうので、それは正直な質問です。 私は、抽象化を個別のパッケージとして持つことのポイントを理解しようとしています。それは、それらが単純な実装/使用に効果的に結び付けられているかどうかです。 マイクロソフト以外の誰も、競合するnetcoreapp2.x Webサーバーに専念するためのリソースを望んでいない、または持っていないと思います(そこで修正されてうれしいです!)。

netcoreapp2.xの世界で抽象化のポイントが何であるかを明確にできますか? または、2.0で単にそれらを非推奨にする計画がある場合はどうなりますか?

dotnet / corefx#4721によると、SslStreamのALPNサポートは.NETCore2.0の準備ができていません。 これが最終的に数か月後に実装されると仮定すると、それは、netcoreapp2.0 TFMをターゲットにするときにそれを使用できることを意味しますか? この場合、ユーザーが古い.NET Coreランタイムを使用している場合、最初のnetcoreapp2.0シェイプの一部ではなかった新しいAPIを使用するnetcoreapp2.0ベースのライブラリをリリースするとどうなりますか? クラッシュしますか? または、netcoreapp2.xはnetstandard1.xと連携しますか?netstandard1.xのコントラクトは、TFMバージョンをインクリメントせずに変更することはできませんか?

ASP.NETバージョンxは、.NETCoreバージョンxに合わせて調整されます。 TFMは、.NETCoreのすべてのリリースに合わせて更新されます。 それは最終的にそのように扱うことができる単一の製品です。 これは、 @ DamianEdwardsが前述したように、私たちが行っている主要な簡略化の1つです。 TFMを変更せずに、コアに新しいAPIを追加することで、ライブラリを構築する人々を壊すことはありません。

@NickCraver

スタックの任意の部分のその他の実装およびテスト用。

他にどのような実装がありますか? ASP.NETCoreを実装するスタックの他の部分はありますか。

抽象化が実際には抽象化ではなく、ASP.NET Core自体と緊密に結合されている場合は、それらのパッケージを削除してみませんか? それが全体的な関係の目標であるならば、それは人生をより簡単でより明確にするであろうので、それは正直な質問です。 私は、抽象化を個別のパッケージとして持つことのポイントを理解しようとしています。それは、それらが単純な実装/使用に効果的に結び付けられているかどうかです。 マイクロソフト以外の誰も、競合するnetcoreapp2.x Webサーバーに専念するためのリソースを望んでいない、または持っていないことを私は思います(そこで修正されてうれしいです!)。

netcoreapp2.xの世界で抽象化のポイントが何であるかを明確にできますか? または、2.0で単にそれらを非推奨にする計画がある場合はどうなりますか?

すべてを1つのアセンブリにまとめることもできますが、リファクタリングにより、これを行った場合には得られなかった将来の柔軟性が得られます。 それは他の実装を持つ可能性さえも開き、長期的にはそれを実際に排除するものではありません。

簡単に言えば、抽象化とは、プラットフォームの移植性ではなく、依存関係の数を減らすことです。

TFMを変更せずに、コアに新しいAPIを追加することで、ライブラリを構築する人々を壊すことはありません。

皆さんは、 netcoreapp2.0を選択したいと言っていましたが、.NETデスクトップ、ひいては.NET Standardと比較して、移動速度が速かったためです。しかし、代わりにnetcoreapp2.0をターゲットにすることのポイントは何ですか。 TFMを変更せずに新しい.NETCoreAPIを利用できない場合は、 netstandard2.0ですか? (例: netcoreapp2.1

皆さんは、netcoreapp2.0を選択したいと言っていました-.NETデスクトップ、ひいては.NET Standardと比較して、より高速に移動しているためです-しかし、可能であれば、netstandard2.0ではなくnetcoreapp2.0をターゲットにすることのポイントは何ですか? TFMを変更せずに新しい.NETCoreAPIのメリットを享受しませんか? (例:netcoreapp2.1)

申し訳ありませんが、私は間違って話しました。つまり、$#$ 1 $#$ではなく$ netcoreapp2.x netcoreapp2.0です。

さて、私は今、完全に混乱しています。

image

申し訳ありませんが、私は間違って話しました。つまり、netcoreapp2.0ではなくnetcoreapp2.xです。

私は上手く理解できていない気がします。 ASP.NET Core2.1パッケージとnetcoreapp2.1 TFMの間に同等性があるということですか?

ASP.NET Core2.1パッケージとnetcoreapp2.1TFMの間に同等性があるということですか?

うん。 2つを同じものと考えてください。 https://github.com/aspnet/Home/issues/2022#issuecomment-299544884を参照してください

では、 netstandardを使用して、同様のパターンを採用することを妨げるものは何ですか? これが最善のアプローチです。IMHO:新しいAPIは新しいTFMを介して採用でき、.NET Desktopをサポートする必要がある人は、ASP.NETCoreアプリを完全なフレームワークで実行できます。

ASP.NET Core 2.1 / .NET Core 2.1 / .NET Desktop 4.7.1-> netstandard2.1
ASP.NET Core 2.2 / .NET Core 2.2 / .NET Desktop 4.8-> netstandard2.2

@PinpointTownesデスクトップ上の.NETFrameworkは十分な速度で出荷できないため、これがCoreのほとんどのバージョニング問題の核心です。 それは巨大なチェーンの中で難しい問題です。

.NET Standardは、.NETCoreと同じ速度では移動しません。 実際にはその近くにはありません。 .NET Standardの動きは、基本的にすべてのプラットフォームを追いつくまで置き去りにします。.NETFrameworkは、動きが最も遅く、最大です。

ポイントトークン、つまり.NET Frameworkの出荷速度がわかりません(たとえば、新しいECDSA APIがCoreFXからNetFXに1年以内に移植されました。これは、このような機密性の高い暗号コンポーネントにとって妥当な時間枠のようです。 )。

クロスコンパイルはオーバーヘッドであり、顧客や製品のニーズとバランスを取る必要があります。

少し時間があれば、クロスコンパイルによって引き起こされるオーバーヘッドの正確な性質についてもっと知りたいと思います。 ありがとう。

皆さんから必要なのは、net461+で実行するためにASP.NETCore2.0が必要であると考える理由の明確なリスト/理解です。 これらのギャップを埋め、すべての人が成功できるように、具体的に説明してください。

現時点では、フルフレームワークバージョンのWCFクライアントライブラリが必要ですnetstandard / netcoreバージョン(https://github.com/dotnet/wcf)はまだ完成していないためです。

少し時間があれば、クロスコンパイルによって引き起こされるオーバーヘッドの正確な性質についてもっと知りたいと思います。 ありがとう。

非常に近い将来、SSLStreamのALPNサポートのような機能を文字通りポリフィルできない時期が来るでしょう。 また、足を伸ばしてAPIを.NET Coreに追加することすら始めていません。これまでのところ、.NETStandardと.NETCore 2.0(.NET Standard 2.0の目的全体)に移植することに悩まされてきました。 。 新しいAPIを追加し、最終的に1日目にASP.NETCoreでそれらを使用します。

現時点では、WCFクライアントライブラリのフルフレームワークバージョンが必要です。netstandard/ netcoreバージョン(https://github.com/dotnet/wcf)はまだ完成に近づいていないためです。

@ctolkienこれは問題であり、そもそもWCFクライアントを移植した理由です。 何があなたをブロックしているのか知っていますか? これは、優先順位を付けるのに役立つ良い機会です。

@davidfowl https://github.com/dotnet/wcf/issues/8

もっとあるかもしれませんが、これは完全なフレームワークwcfに移行する前に私たちが直面した最初のハードルでした。

非常に近い将来、SSLStreamのALPNサポートのような機能を文字通りポリフィルできない時期が来るでしょう。

それはどのように問題ですか? AFAICT、ASP.NETCoreの.NETデスクトップと.NETCoreフレーバーがまったく同じ機能セットをサポートする必要があると言ったことはありません。 APIがないために.NETデスクトップで機能が利用できない場合(HTTP 2/0など)、それを.NET Coreのみにし、 PlatformNotSupportedExceptionをスローして、開発者に探している機能が利用不可?
ほとんどのASP.NETCoreパッケージで新しいBCLAPIを使用する可能性は低いですが、すべてのASP.NETCoreパッケージを.NETCoreのみにするよりもはるかに優れています。

@davidfowl 1つの大きな懸念は、たとえばnetcoreapp2.3で修正されないことであり、 netcoreapp2.4で修正されることだと思います。 ASP.NET Coreが最速の列車に焦点を合わせている場合、マイナーバージョンごとにどれくらいの期間愛されますか? 絶えずアップグレードする必要がある場合、すべての消費者は絶えずアップグレードする必要があります。

これは、最新かつ最高のものを入手するのに最適ですが、ほとんどの企業にとっては最適ではありません。 したがって、ASP.NET Coreの各コンシューマー用のライブラリで多くのバージョン(各マイナーバージョン)を維持するか(最新に依存せずに維持するため)、ユーザーを最新バージョンにドラッグして維持する必要があります。 これは、検証済みの環境などには適していません。

抽象化をできるだけ速く回転させる必要がない限り(例?)、抽象化を切断することをお勧めします。 そうすれば、アップグレードのたびにエコシステム全体をドラッグする必要がなくなります。 netcoreappになるのではなく、継続的に更新され、すべてが緊密に結合されているのではないかと心配しています。

抽象化によって各マイナーバージョンが維持され、(率直に言って)苦痛があなたの側に移るのであれば、私はそれほど心配していません。 ここで修正を加えて意図を詳しく説明できますか?

@PinpointTownes

.NET Coreのみにし、PlatformNotSupportedExceptionをスローして、開発者が探している機能が利用できないことを通知してみませんか?
ほとんどのASP.NETCoreパッケージで新しいBCLAPIを使用する可能性は低いですが、すべてのASP.NETCoreパッケージを.NETCoreのみにするよりもはるかに優れています。

Noooooooo、いいえ。 これは実行時の失敗であり、あまり望ましくない動作です。 ライブラリが可能な限り機能することを、コンパイル時にできるだけ多く保証したいと考えています。 これについては多くの議論がありましたが、それは単に良い道ではありません。 PlatformNotSupportedは、人間的に可能な限り避ける必要があります。

これは実行時の失敗であり、あまり望ましくない動作です。

これは、アセンブリがサポートされていないAPIを使用しようとした場合に、「。NETデスクトップアセンブリを.NET Coreに取り込む」アプローチで発生することです。ただし、 PlatformNotSupportedExceptionではなくMissingMemberExceptionが表示されます。 PlatformNotSupportedException

私のアプローチでは、使用しているAPIがサポートされているかどうかをコンパイル時に判断できるRoslynアナライザーなどを使用して、少なくともより優れたツールストーリーを定義できます。

そしてところで、 PlatformNotSupportedを投げることは本当にコーナーケースになるでしょう。 クロスコンパイルでは、サポートされていないAPIをパブリックコントラクトから単純に除外するのが最善のオプションです。

@PinpointTownes私もこのように考えましたが、現実には新しいプラットフォームが出荷されており、それほど単純ではありません。 これについて何度も話し合った後、ここでの互換性の方法について私の考えは大きく変わりました。 netcoreappの方向に進むと、修正をマイナーバージョンで出荷できます。 逆に行くということは、修正を出荷するために.NETデスクトップを待たなければならないことを意味します。それは...幸運です。 これは、解決のための非常に遅い手段です。

AFAICT、ASP.NETCoreの.NETデスクトップと.NETCoreフレーバーがまったく同じ機能セットをサポートする必要があると言ったことはありません。 API(HTTP 2/0など)がないために.NETデスクトップで機能を利用できない場合は、.NETCoreのみにするのはなぜですか。

その前半はnetstandardです。 netcoreappとの差別化は、まさに彼らがここで行っていることです。 意図的な例外なし。 このルートは適切な契約です。

ギャップが関係している場合、その逆ではなく、より速く修正および改善できるものの方向に進みたいと考えています。 「PlatformNotSupported」例外は、プラットフォームが3か月後に改訂されるのを待つ代わりに、明日ライブラリで修正できます。 .NET Coreは、ほとんどの場合、フォワーダーとして個別にではなく、実際のコードが付属しているため、より高速にサポートできます。

[@PinpointTownes] API(HTTP 2/0など)がないために機能が.NETデスクトップで利用できない場合は、.NET Coreのみにして、開発者にその機能を通知するPlatformNotSupportedExceptionをスローしてみませんか。彼が探しているのは利用できませんか?

APIサーフェスのシンプルさと、開発者の生産性のバランスをとる必要があります。 これまで、過去と互換性のあるAPIサーフェスを提供するために、主にPlatformNotSupportedExceptionを使用してきました。 今後、ばらばらの機能セットを提供する方法としてPlatformNotSupportedExceptionを使用するつもりはありません。 代わりに、機能を備えていないバージョンの.NETプラットフォームのサポートを終了するか、機能自体がどこでもサポートされていない独立したNuGetパッケージとして機能を提供します。

netcoreappの方向性を採用することで、修正をマイナーバージョンで出荷できます。

それは1.0のアプローチとどう違うのですか? @davidfowlによると、新しいAPIには新しいTFMが必要です。つまり、新しい.NET Core APIに依存する修正を取得するには、LTSをオプトアウトする必要があります。 本当に理想的な状況ではありません。

netcoreappとの差別化は、まさに彼らがここで行っていることです。

差別化はまったく問題ありません。ASP.NETCoreのターゲットとして.NETCoreを使用することを強くお勧めします。 ただし、これは、特にクロスコンパイルなどの代替手段が存在する場合に、.NETデスクトップを完全に廃止することを意味するものではありません。

APIサーフェスのシンプルさと、開発者の生産性のバランスをとる必要があります。

もちろん。 ただし、.NETデスクトップ用に開発され、.NET Coreでは利用できない機能を使用するレガシーライブラリは、1.0の場合と同様に、ASP.NETCore2.0でも正常に機能するはずです。

代わりに、機能を備えていないバージョンの.NETプラットフォームのサポートを終了するか、機能自体がどこでもサポートされていない独立したNuGetパッケージとして機能を提供します。

理論的にはまったく問題ありません。 しかし、現在重要な機能が不足しているプラ​​ットフォームは、.NETDesktopではなく.NETCoreです。 これはおそらく数年以内に変更されるでしょうが、確かに人々は.NETCore2.0に欠けている機能を見つけるでしょう。

dotnetにforward-portリポジトリを用意して、.NETFrameworkの.NETCoreにない特定のアイテムに対してAPIリクエストを送信できるようにする価値があるでしょうか。

次に、フィードバック、レビュー、およびガイダンスは、コードリポジトリの日常のノイズの外で行うことができますか? または、一般的なAPIレビュー/仕様リポジトリ(csharplangとroslynのような並べ替え)

また、「変換の問題があり、X apiに関連する問題を検索する必要があります」にも役立ちますが、corefxはそのために非常に騒がしいです。

[@benaadams]ドットネットにフォワードポートリポジトリを用意して、.NETFrameworkの.NETCoreにない特定のアイテムのAPIリクエストを送信できるようにする価値があるでしょうか。

これらはCoreFxの単なる問題だと思います。 また、私たちの約束は一般的に次のとおりです。タイプが.NETFrameworkと.NETCoreの間で共有されている場合、新しく追加されたメンバーを.NETFrameworkに移植する予定です。 非常にまれなケースでは、これが不可能な場合もありますが、地面の問題は、それらが自動的に考慮されることです。

[@benaadams]または一般的なAPIレビュー/スペックリポジトリ

それが価値があるかどうかはわかりません。 APIレビューはすでにやや手間がかかります。 それらを別のリポジトリに抽出すると、それが増幅されるようです。 むしろ、CoreFxを合理化して、新しいAPIの追加がASP.NETなどで行うのと同じくらい簡単になるようにしたいと思います。

前に述べたように、彼らは.NET Frameworkをターゲットとするライブラリ/フレームワークを参照し続けることができ、呼び出すAPIがnetstandard2.0のクロージャの一部であると仮定すると、それは問題なく機能します。

@DamianEdwards netstandard2.0のクロージャにないAPIはどうですか? ほとんどのサードパーティライブラリはクローズドソースです。 すべてのエッジケースがnetstandard2.0のクロージャにあることをどのように知ることができますか?
@PinpointTownesがほのめかしたように、これはロシアンルーレットをプレイするようなものです。

@MJomaaツールはここで役立ちますが、確実に知る唯一の方法は実際に実行することです。 これは、実際には、.NETStandardでサポートされているフレームワークで実行されている.NETStandardライブラリと同じです。 APIの既存は、これらのライブラリをテストする必要性に取って代わるものではありません。 これは、netstandardの実装が互換性を目指していないということではありません、エッジです。たとえば、 https ://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

これらは、NS 2.0には存在するが、.NETFramework4.6.1には存在しないAPIです。

私はこの変更について本当に緊張しましたが、スレッドを読んだ後、理論的には問題ないようです。 5つのASP.NETCoreアプリがあり、そのうちの4つは完全なフレームワーク上にありますが、それはほとんどの場合、他の何よりも防御的であり、抵抗が最も少ないパスを取っているだけでした。

.NET Core Portability AnalyzerのようなVSに組み込まれたある種のツールは、Twitter / GitHubの最新情報がなく、この拡張機能が存在することさえ知らない開発者を支援できると思います。 「拡張機能を提案する」ポップアップが思い浮かびますが、それをトリガーするために人がどのような行動を取るかはわかりません。 net46xlibをASP.NETCore2+アプリに追加しようとしていますか?

マイクロソフトがTelerikやSyncfusionなどのサードパーティサポートのように制御できないものは、彼らが何をしているかによっては、潜在的なブロッカーにもなります。

このGitHubスレッドのメッセージは、FAQなどを添えてできるだけ早くブログ投稿に入れる必要があります。 私はすべてを把握しているように感じますが、これがnet46xライブラリを参照できるかどうかを100%確信していませんでした。 それで混乱したのは明らかに私だけではありませんでした。

他の人が言っていることをエコーする。 ASP.NETCoreが完全なフレームワークで実行できることを知らなかった少なくとも10人の開発者と話をしました。 私は@aL3891と同じ経験をしましたが、開発者が本当に満足している場合は、完全なフレームワークでASP.NET Coreを実行でき、内部ライブラリは正常に機能します。 繰り返しになりますが、ユースケースの大部分を占める.NET Core 2.0に関するメッセージは、非常に重要です。 少なくともSystem.DirectoryServicesのようなWindowsのみのソリューションを機能させることについての部分も重要になります。 私が話している多くのNET開発者は、.NET Coreがクロスプラットであり、x-plat /perfよりも既存のコードが機能していることを気にかけていると聞いて肩をすくめるように話します。

みんな、これは一種のゴミです:(
ASP.NET Coreをnetfxで使用するオプションがあるため、ASP.NET Coreの上に構築し、最大1年間のサポートではなく、5〜10年間続くことを目的としたものを構築しました。 これがビジネスにおけるASP.NETの名前の意味であり、大規模で動きの遅い組織が月のフレームワークのフレーバーよりもASP.NETの名前を選択する理由です。 具体的なユースケースに移りましょう。

私は、企業の内部で使用し、「エンタープライズ」クライアントに販売するための基幹業務ライブラリとアプリケーションを構築するツールグループで働いています。 私たちの場合は主に政府機関ですが、民間部門からも同じことを聞いていると思います。 ビジネスパターンを一般的な抽象化にエンコードする内部フレームワーク(「IDatabaseConnection」、「IEntityProvider」、「IWizardFlow」、「ICodeGenerator」など)があり、これらのプラグ可能なバックエンドの上にRADフロントエンドを構築します。

スタックでは、ASP.NET Coreは「プラグイン」です。これはHTTP宛先であり、データストアの抽象化やサービスのホスティングなどに使用されます。 これは「フロントエンド」でもあります。明らかに、そこにあるたくさんのLOBアプリにはウェブサイトがあり、ウェブアプリの優れた新しいフレームワークです。 したがって、双方向の相互運用性要件があります。ランダムな他のコンポーネントを参照するAN-Cコードと、AN-Cを参照するランダムな他のコードです。

私たちはCoreCLRと移植性のファンであり、多数のコンポーネントをターゲットまたはマルチターゲットのネットスタンダードに移植しました。 これまでにLinuxでホストされているアプリが1つあり、今後さらに増えることを望んでいます。 ただし、すべてがすぐに移植される方法はありません。 私たちはまだ生きている、活発に開発されたコードを持っています。

  • NTLM認証(トークンとSPNに関する高度なシナリオを含む)
  • System.Drawing上記のように(ここで興味深いしわ:新しいOSSライブラリがサポートしていないTIFFのような古い画像形式が必要です)
  • WCF /SOAPAPIへの接続-まだたくさんあります
  • Windows暗号化API(RSACng、ECDSA、およびCSP for PKIトークンを含む)
  • WPFGUI-クライアントはすぐにWindows10に切り替えることはなく、切り替えたとしてもストアアプリは必要ありません。
  • データのインポートとエクスポートのためのMicrosoftOffice相互運用機能(特にアクセスとExcel)
  • VisualStudioの拡張性
  • OracleADO.NETプロバイダーなどのサードパーティプラグイン

これらのテクノロジの一部は、CoreCLRでサポートされることはありません。 しかし、これら実際のテクノロジーであり、新しいアプリ開発の基礎となっています。このようなものにアクセスできるバージョンの.NETが必要です。 現在、私たちの立場は管理可能です。「レガシー」(実際にはプラットフォーム固有)の依存関係を、net461固有の独自のコンポーネントに分離します。 特定のビジネスアプリは、これらの機能が必要な場合はnetfxに依存し、そうでない場合は依存しません。 これは新しいアプリではめったにない未来を想像していますが、0%になるとは想像しがたいです。

相互運用性が重要であるため、csprojとSDKでこのすべての作業を行いました。 ASP.NET Coreはニンジンであり、相互運用が必要な理由です。 私はそれを取り除くことは意味がないと思います。 いいえ、「参照を一方向にロードできますが、実行時に失敗する可能性があります」は相互運用性ではありません。

@gulbanana ASP.NET Coreを使用するシステムの部分について、.NETFrameworkと同じプロセスにする必要がある理由を説明してください。 リスト(Visual Studioのプラグイン、オフィスの相互運用など)に感謝しますが、今日、これらすべての場所にASP.NET Coreを埋め込んでいますか(上記の説明からはわかりません)?

また、ASP.NET Coreが存在する前は何を使用していましたか? それとも、これはASP.NETを使用したことはないが、.NETFramework上のASP.NETCoreに5〜10年の賭けをした新しい試みですか? 刀を見ましたか?

OK、ここにいくつかの特定のケーススタディがあります。 これらの多くは、デスクトップ固有の作業を別のプロセスで実行することで処理できると確信していますが、基本的に一連のインターフェイス実装をRPCに変換するのは非常に面倒なようです。 コアCLRとデスクトップCLRの間でリモーティングやバイナリシリアル化を使用できるわけではありません。

NTLM / AD

シングルサインオンの目的で、Windowsログイン資格情報をIISに渡すブラウザーに依存するアプリがあります。IISはそれらをASP.NETCoreWebサイトに渡します。 認証プロセスの一部は、ユーザーが特定のADグループに属しているかどうかなどの情報を検索することです。 「Windowsサポートパック」について、そしてそれがこのようなことをカバーすることを意図しているかどうかについてもっと知りたいです。

System.Drawing

これは、サムネイルと基本的な画像編集(回転、透かしオーバーレイ)を作成するWebアプリで使用されます。 使用されている画像の多くは恐竜の時代にさかのぼりますので、そこにはTIFFのようなものがあります。 これらは、特定の物件リストと土地管理に関連して政府部門によって維持されているデータです。 この場合、アプリケーションは最初はASP.NET MVCでしたが、MVC 2、4、5、そして現在はCoreを介してアップグレード/書き換えられました。

VSIX

これは、その逆ではなく、netfxにAN-Cを埋め込む場合です。 さまざまなRADシナリオの「テンプレート」を実行するコード生成用のVisualStudio拡張機能があります。 これらのテンプレートの一部は、Web開発用に作成され、設計時にAN-Cタイプを参照します(プリプロセッサー/ランタイムT4を使用して作成されます)。

暗号

これは実際にインプロセスである必要があると思います-コードが非常にセキュリティに敏感なライセンスシナリオがあります。 大まかに言えば、コードが実行されている環境に関してライセンスファイルを復号化および検証します。これは、デスクトップアプリだけでなくWebアプリのバックエンドで使用される一般的なライブラリです。 最終的に、.NET Coreは、これを移植できるほど十分な暗号サポートを取得する可能性がありますが、今日はそうではありません。 たとえば、今日私たちが持っているオプションの1つは、フォーティネット/ ePass2003 PKIトークンのサポートです。ミドルウェアはコアを確実にサポートしていません(サポートする時間枠はありません)。

Oracle ADO.NET

OracleバックエンドでEntityFramework6を使用することは、進行中である必要はありません、データベースにアクセスするためだけにWebサイトに層を追加するのは不便です。

WPF相互運用

最近では、すべてのデスクトップアプリケーションでMicrosoft.Extensions.Loggingを使用しています。実装が行われていない場合でも、ロギングの抽象化自体をインプロセスにする必要があります。

ASP.NETCoreの前に使用したものについては-ASP.NETMVC! 戻ることはできますが、すべてのメリットを放棄することは非常に残念です。

アーキテクトとして、「ASP.NETCoreが完全なフレームワークで実行される」が最初のバージョンを超えて存続するかどうかを調べなかったのは私の失敗です。 正直なところ、そうなるとは思いもしませんでした。 2018年には、Officeドキュメントをロードできるサポートされているバージョンがない可能性があるとは想像もしていませんでした...

私がはっきりしていないことの1つは、言及した各シナリオでASP.NETCoreがどこで使用されているかということです。

NTLM / AD

これは理にかなっているので、最終的にどのAPIにマッピングされるのかを理解したいと思います。 これは単なるSystem.DirectoryServicesですか? それは積極的に取り組んでいます(corefxで見ることができます)。

System.Drawing

これは、私たちが対処しようとしている既知のギャップです。 ここにはまだ答えがありません。ImageSharpを使用して書き直すことはお勧めしません(これはオプションですが)。 これに対処する必要があります。

VSIX

ASP.NET Coreはここにありますか? Visual Studio拡張機能の内部で実行されていますか?

暗号

これにはcorefxの問題がありますか? なぜ移植されないのですか? .NET Frameworkとは異なり、.NET CoreリリースはOSから切り離されているため、重要であると見なされた場合、これは後でではなく早く発生する可能性があります。 (免責事項:このクロスプラットフォームを実行することの意味を理解するのに十分な暗号については知りません)。

Oracle ADO.NET

ASP.NET Coreはどこにありますか? Oracleプロバイダーがまだ.NETCoreに移植されていないと言っているだけですか?

最近では、すべてのデスクトップアプリケーションでMicrosoft.Extensions.Loggingを使用しています。実装が行われていない場合でも、ロギングの抽象化自体をインプロセスにする必要があります。

Microsoft.Extensions。*はnetstandardのままなので、そこでカバーされます。

なぜ発表/議論がないのですか?
aspnet / .netコアチームの機能は気に入っていますが、@jhurdlowと同じ恐れがあります。

他の点でMELについて聞いてうれしい-

NTLM

これが、ほとんどのアプリケーションで使用されている1つのクラスです。 これは、APIを非常に簡単に使用します。これは、理論的には移植できると期待されているものです(ただし、移植されていません)。
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

asp.netコアに固有のcodegenテンプレートは、アクション/ルーティングシステム(IFileProviderなど)を使用して、コントローラーやビューなどを検出し、足場を埋めます。 VisualStudio内でASP.NETWebホストをホストしているのではなく、ASP.NETアプリケーションを内省しているだけです。

暗号

私たちが使用するアルゴリズムは移植されると思いますが、まだ移植されていません。 前提が、asp.net-core-on-netfxのサポートを終了する長期計画の発表と、それがいつ可能になるかについての議論のように、これはすべて大きく異なるように見えます。

オラクル

はい、これはOracleポートが発生した場合に解決されます(フル機能であると仮定した場合など)。

もう1つのユースケース:
アプリケーションの1つは、Accessアプリケーションからレガシーデータをインポートします。 現在、インポートプロセスはasp.netコアWebサイトのサーバーで実行されています。 COM相互運用機能を使用して、再配布可能なaccdb / jetエンジンからacedao.dllをロードし、テーブルをエンティティ抽象化に読み込んでから、より新しいSQLデータベースに保存します。

これは、「procから外れる可能性がありますが、なぜそうである必要があるのか​​」の別のケースです。 基本的に、AN-CをWebAPI 2 Webサイトなどのフロントエンドとして使用していました。その場合、過去への依存関係に戻りました:(

全体として、私たちの目標は、私たちが行うことの大部分を.NETCoreに移行することです。 物事を移動する、可能な限り多くの相互運用を望んでいます...

WTF !!! 😨
ASP.NETCore2は完全な.NETFramework4.xをターゲットにしないと言っていますか!!!
1か月前にASP.NETCore1.1でプロジェクトを開始しましたが、完全な.NET Libを参照しているため、.NET4.6をターゲットにしました。 そして、ASP.NET Core 2にアップグレードする予定でした。しかし、この投稿から聞いていることは...😞
ほら、ASP.NET Coreを選んだのは、その利点(DI、統合されたAPIとMVC、...強力)のためです。ですから、変更として与えてください。

1か月前にASP.NETCore1.1でプロジェクトを開始しましたが、完全な.NET Libを参照しているため、.NET4.6をターゲットにしました。

それらのライブラリは何をしますか? @shanselmanの最初の返信https://github.com/aspnet/Home/issues/2022#issuecomment-299536123を読みましたか? .NET Core2.0の一部の.NETFrameworkライブラリを参照することができます(APIのサブセット内にあると想定しています)。

それらのライブラリは何をしますか? @shanselmanの最初の返信#2022(コメント)を読みましたか? .NET Core2.0の一部の.NETFrameworkライブラリを参照することができます(APIのサブセット内にあると想定しています)。

@davidfowlはい@shanselmanのコメントを読みました。会社が作成したLibを使用しています。これらのlibの一部はWCFを使用しており、すべてのLibは安定しており、.NET 3.5を対象としているため、触れることができません。

これは非常に一般的な状況になります。 これまでに.NETCoreと.NETFrameworkを使用しているASP.NETCoreのユーザー数に関する情報(テレメトリ?)が収集されているかどうかを知りたいです。

私は個人的にこれについて感情的ではありませんが、いくつかの観察:

  • 私が今日持っているほとんどの顧客は、新しいものにオールインするのが怖いので、asp.netコア1.x/フルフレームワークの組み合わせを使用しています
  • nugetパッケージのダウンロード数からわかるように、asp.netコアの採用は素晴らしいものではありません。 その動きで、今はうまく売れないものを売るのはさらに少し難しくなるでしょう。
  • LDAPのものがギャップであると特定したことは素晴らしいことです(過去10年間、これらのライブラリを使用している人を見たことがないと思いますが、それは私だけかもしれません)。 より大きな問題はサードパーティのライブラリになります。 これらは、人々が.netコアに移行しない本当の理由になります

この全体的な状況は、MSが何の注意も払わずに決定を下したことのもう1つの良い例です。 一部の人がチェックインをフォローしているという理由だけで、このスレッドはここに存在します。

私は間違っているかもしれませんが、.NET Coreは現在DNFの管理下にあると思っていたので、これらの決定はもはや純粋にMS内部ではありません。

LDAP / ADのものは、私が今net462を常に把握している必要がある理由です。 完全に行きたいのですが、BAM-> NetCoreですが、これは欠点です。

また、プロジェクトの1つでXML-RPC.netを使用しています。 深刻なReflection.Emitを使用していますが、NetCore2が完全にサポートするかどうかはわかりません。 ただし、PortabilityAnalyzerを試して確実に確認する必要があります。

この状況全体は、.NETの将来に影響を与えるこのような重要な決定が、最後の最後に、透明性なしに、どれほど迅速かつ簡単に発生する可能性があるかについて、少しがっかりします。 .NET Standard 2.0は互換性に重点を置き、.NETとのギャップを埋めるリリースになるというメッセージ(私の理解から)を使用して、ASP.NETCoreへの移行時に既存の.NETエコシステムを販売するために多くのエネルギーが投資されましたv4.xは、エコシステムが最終的に依存できる堅固で安定した.NETプラットフォームを最終的に生成します。 個人的には、.NET Coreが実際に普及するのは、.NET Standard 2.0がリリースされるまでは信じられません。これは、私たちが待ち望んでいる「約束された安定した土地」であると予想していたからです。 2.0 "とは、正確に何をカバーするのか、どのライブラリが.NETCoreのみになるように計画されているのかを意味します。

事前の公式発表、フィードバックの要求、ポーリング、または理論的根拠が与えられていないため、この決定は、コミュニティの関与や既存の.NETエコシステムへの影響分析なしで行われたように見え、多くのエコシステム全体を断片化する可能性があります今後数年。 .NET v4.xサポートを削除すると、多くの企業が既存のコードベースをASP.NETの新しい開発モデルに移行できるようにするためのスムーズな移行パスが削除されます。 これは、彼らが.NET Coreに速くジャンプすることを奨励しません。それは、彼らが試みさえすることを効果的に防ぎ、.NETエコシステムを2つに破壊する大規模な断片化を引き起こします。 これが、10年近くも回復できていない断片化によって取り返しのつかないほどの被害を受けたPython2/3とどのように異なるかはわかりません。

ほとんどの既存の.NETコードベースは、「暗黒物質」.NET開発者によって舞台裏で開発されているブラウンフィールドであり、.NET Core1.1が.NETv4.xをサポートしているため、この決定が行われたことをほとんど知らないでしょう。 .NET Standard 2.0のメッセージングは​​、互換性の向上を約束しました。 この決定のニュースと影響がようやく家に帰ったら、私は大規模な反発を期待しています。 組織内で.NETCoreの採用を販売している多くの開発者は、行き止まりのプラットフォームに効果的に移行していることを考えると、裏切られたと感じるでしょう(何らかの理由で.NETCoreに完全に移行できない場合) )組織内の利害関係者に現在の移行に必要なリソースを承認するよう説得するという記念碑的な決定に成功した直後に直面する必要のある厳しい現実。

ほとんどの組織は、既存のコードベースを「実行中」に移行する必要があります。既存のシステムを継続的に展開する必要がある一方で、最初に.NET v4.xに展開するコードベースを「並行して」移行し、次にすべてが安定し、すべての問題が解決されたら、そこから.NETCoreへの完全な移行を計画できます。

この決定は、.NETが組織が信頼できる安定したプラットフォームであるという信頼をIMOが侵食したASP.NETへの長年の重大な変更のコンテキストでも行われます。 私は.NETCoreの新しい開発モデルが大好きですが、私たちが最も必要としているIMOは、エコシステムの残りの部分が追いつくことができる信頼できる安定したプラットフォームです。 .NET Coreはまだ不気味の谷にあり、ツールが未成熟で、依存関係に互換性がなく、実行時の問題があり、ドキュメントが古くなっています。.NETが最初にリリースされた当初から、これほど不安定なものは見ていません。

.NET開発者がもっと欲しいものについて投票を実行してみませんか? つまり、堅固で安定した洗練されたプラットフォームですか、それとも新しい機能をより速く提供する「動きの速い」プラットフォームですか? .NET v4.xへのバックポート機能について心配する必要がないので、はるかに少ない労力で済むことは理解していますが、主に安定した互換性のあるプラットフォームを長期間提供することに重点を置いたバージョンのASP.NETCoreを用意することは非常に貴重です。 .NETv4.xまたは.NETCoreのいずれかで実行できるタームサポート。

この船は出航しましたか、それともASP.NET Core 2.0をそのまま維持するオプションはありますか? つまり、ほとんどのライブラリと抽象化が.NET Standard 2.0でカバーされており、次のASP.NET Core 3.0リリースで、次のプラットフォームが.NET Coreのみになることを発表しますか? これにより、組織は前進を続け、ASP.NET Core 2.0を採用し、.NET Coreのみのプラットフォーム/から完全に分割しながら、安定した十分にサポートされたツールとライブラリを使用して、エコシステムの残りの部分に追いつくことができます。機能が開始されます。

.NET Core2.0の一部の.NETFrameworkライブラリを参照することができます(APIのサブセット内にあると想定しています)。

これは不確実性を吹き込みます。信頼性とシステムの健全性と安定性を危険にさらし、どの依存関係で実行できるか、実行できないかについて不確実性が存在する場合、.NETCoreへの完全な移行を試みる人はほとんどいません。 .NET Core。これは、当面の間、より多くの人々が.NETv4.xにとどまることを意味します。

これが最終的にどのように機能し、この決定が.NETエコシステム全体にどのような影響を与えるかはわかりませんが、外部のコミュニティの関与なしに、このような幅広い影響を与える重要な決定が行われる可能性があるという事実が懸念されます。

私はあなたたちがあなたのユーザーベースを二分することに少し地獄に屈していないことを望みます。

ライブラリを作成するときの私の視点は、できるだけ多くの人が、できるだけ多くの場所で、できるだけ使いやすくすることです。 これは首の痛みです(Newtonsoft.Jsonで#ifコンパイラディレクティブを検索すると、1300以上の結果が得られます)が、「それだけで機能する」というのは強力なセールスポイントです。

.NET開発者がもっと欲しいものについて投票を実行してみませんか? つまり、堅固で安定した洗練されたプラットフォームですか、それとも新しい機能をより速く提供する「動きの速い」プラットフォームですか? .NET v4.xへのバックポート機能について心配する必要がないので、はるかに少ない労力で済むことは理解していますが、主に安定した互換性のあるプラットフォームを長期間提供することに重点を置いたバージョンのASP.NETCoreを用意することは非常に貴重です。 .NETv4.xまたは.NETCoreのいずれかで実行できるタームサポート。

本物の質問ですが、ASP.NET Core 1.xは現在、.NETFrameworkと.NETCoreをサポートしています。 上記の安定したプラットフォームであったとしましょう。両方のランタイムでバグ修正とサポートを行いましたが、それ以上の機能はありませんでした。 それで十分でしょうか?

ASP.NETCoreと.NETCoreは、現時点で.NET用の動きの速い機能豊富なプラットフォームです。 これは、オペレーティングシステムに関連付けられていないバージョンの.NETであり、迅速な革新とより迅速なリリースに必要な俊敏性を提供します。

この船は出航しましたか、それともASP.NET Core 2.0をそのまま維持するオプションはありますか? つまり、ほとんどのライブラリと抽象化が.NET Standard 2.0でカバーされており、次のASP.NET Core 3.0リリースで、次のプラットフォームが.NET Coreのみになることを発表しますか? これにより、組織は前進を続け、ASP.NET Core 2.0を採用し、.NET Coreのみのプラットフォーム/から完全に分割しながら、安定した十分にサポートされたツールとライブラリを使用して、エコシステムの残りの部分に追いつくことができます。機能が開始されます。

フィードバックはいつでも受け付けており、ASP.NETCore2.0はまだ出荷されていません。 ASP.NET Core 3.0が.NETFrameworkを削除したリリースだった場合、それは状況を改善しますか? @gulbanana@ikourfalnからのフィードバックの一部を見ると、移植される可能性が低く、したがって.NET Coreで動作しない可能性が高いテクノロジがあります。これは、.NETFrameworkをほぼ永久にサポートすることを意味しますか? 1年後も同じ議論をしませんか? それまでに、.NET Coreをサポートするエコシステムやライブラリが大きくなり、影響が少なくなるのではないでしょうか。 決して更新されない(またはソースコードが失われた)エンタープライズライブラリはどうですか? それらは1年で変わるのでしょうか?

ライブラリを作成するときの私の視点は、できるだけ多くの人が、できるだけ多くの場所で、できるだけ使いやすくすることです。 これは首の痛みです(Newtonsoft.Jsonで#ifコンパイラディレクティブを検索すると、1300以上の結果が得られます)が、「それだけで機能する」というのは強力なセールスポイントです。

@JamesNKに違反することはありませんが、JSON.NETはJSONパーサーであり、ほとんどの場合、単一のパッケージです(さらにいくつかあることはわかっています)。 ASP.NETCoreには200を超えるパッケージがあります。

不快感はありませんが、私はパートタイムで働いている一人の男です。 あなたの問題はより困難ですが、あなたは指数関数的に多くのリソースを持っています。

これを読み、私たちが持っている依存関係を調べた後、私はこれが良い考えであるとははるかに確信していません。

計画では、 System.DirectoryServicesが利用可能になるまで、どのアプリもnetstandard / netcoreappに移植できません( CoreFXの問題#2089はこちら)。 したがって、ASP.NET Core 1.xに移植することはできますが、2.0に移行することはできません。 ここでアプリケーションを見てください:Opserver、Stack Overflow自体、内部アプリ...この時点で2.0が提案されているため、何も準備ができていません。 今週のスタンドアップによると、DirectoryServicesのような重要なものは2.x以降のリリースでも引き続き続くでしょう。

つまり、1.0から2.0の間で、移動する準備をしていたものから、移動できないものに変更されました。 そうそう、私はそれが準備ができていないと言うでしょう。 ASP.NETは、HTTPを介して必要なビットを公開する方法です。 ASP.NET自体は必要なものではありません。 私は.NETをWebビットだけに使用しているのではなく、プラットフォームに使用しています...非常に多くの人がそうです。 プラットフォームは、ユーザーが要求するさまざまなユースケースに対応する準備ができていないため、ユーザーをそのプラットフォームに強制することは、苦痛と妨害を引き起こします。

肝心なのは、AD認証(プラットフォームの部分)が必要な場合、1.xラインで放棄されたということです。 それが私が私たちのアプリに向かったところです...しかし、これが方向性であるならば、私が必要とするビットが目的地で利用可能になるまで、ここで努力する意味はありません。

System.DirectoryServicesSystem.Drawingのようなこれらの重要なこと、そして人々が必要とする他のトップアイテムASP.NET Core 2.0で準備できると言えば、私の意見は大きく変わります。 (現在のスケジュールが示すように)後から考えた場合は、そうなるまで.NETFrameworkのサポートを継続してください。

速く動くのは素晴らしいです。 大好きです。 現在、本番環境でアルファ版を実行しています。 しかし、そもそもユースケースで機能しない場合は、それは問題ではありません。

私が個人的に苦労していることの1つは、「安定したプラットフォーム」と「新機能」の違いです。 プラットフォームが安定していて信頼性が高く、互換性があることを望んでいる一方で、2.xの機能がないため、1.xを使い続けたいと思う人は誰もいません。 ASP.NET Core 2.xには、人々をその方向に引き寄せる非常に魅力的な機能がありますか、それとも1.xよりも多くの機能があるという事実だけですか(新しくて光沢があるため)?

後者の場合、それらの人々は安定性を気にしますか? 答えが「はい」の場合、ASP.NET Core 1.xでは不十分なのはなぜですか?

私は.NETをWebビットだけに使用しているのではなく、プラットフォームに使用しています...非常に多くの人がそうです。 プラットフォームは、ユーザーが要求するさまざまなユースケースに対応する準備ができていないため、ユーザーをそのプラットフォームに強制することは、苦痛と妨害を引き起こします。

同意しましたが、あなたの意見では、それはASP.NET Core2.xが.NETFrameworkのサポートを削除することにどのように関係していますか? より多くの依存関係がオンラインになると、ある意味でどこでも機能します。プラットフォームが前進するにつれて、幅広いランタイムセットがメリットを享受します。 ASP.NET Coreアプリケーションのすべてのバージョンは、突然これらの機能を利用できるようになります。

後者の場合、それらの人々は安定性を気にしますか? 答えが「はい」の場合、ASP.NET Core 1.xでは不十分なのはなぜですか?

誰もが常に新機能、新機能の可能性、または少なくとも後でもっと多くのグッズを手に入れるオプションがあることを知っていることを望んでいます。 プラットフォームを閉じて「安定」/「メンテナンスモード」にすると、人々はそれがもはや注目されていないように見えます。

ASP.NET Core 2.xには、人々をその方向に引き寄せる非常に魅力的な機能がありますか、それとも1.xよりも多くの機能があるという事実だけですか(新しくて光沢があるため)?

サポート-それが私たちが支払っているものです。

答えが「はい」の場合、ASP.NET Core 1.xでは不十分なのはなぜですか?

(上記のScottによると)サポートはリリースから約1年後に終了するためです。 そして、私はそれまでにStackOverflowの移植をほとんど終えていないかもしれません。

これは、ASP.NET Core2.xが.NETFrameworkサポートを削除することとどのように関連していますか?

が持っていなければならない図書館がそこにないからです。 そして、いつになるかわかりません。 だから私は1.xで立ち往生し、サポートが終了するまで時限爆弾を持っています。 サポートが終了する前に、1.0から2.x(または3.x)に移植するのに十分な時間がありますか? おそらくそうではありません。

大規模なコードベースは、停止して移植するだけでなく、時間が必要であり、段階的に実行する必要があります。 ASP.NETCoreに.NET4.6.xポートを実行することは、中間ステップとして実行可能でした。 一度にコアに移行することは、はるかに困難で、はるかに時間がかかり、より長寿命のブランチとより多くの苦痛を必要とします。 これを段階的に実行できない場合、正直なところ、現在は廃止されているASP.NET5ラインから移行することはできません。 時間、コスト、開発への影響を正当化する方法はありません。

多くのOSS作者も私と同じだと思います。これは、私たちの日常業務の延長です。 プラットフォームを使用していないか、ドッグフーディングを行っていない場合、ライブラリははるかに悪くなるか、作成されません。 そして、今日私たちが費やしている会社の時間でそれらを維持する時間を正当化することはできません。 そして、私たちが作成するすべてのライブラリは、本番環境でヒットしたニーズから生まれます。 エコシステムドロップのユースケースは、突然ではありませんが、それでも合計される多くのダウンストリームの影響を及ぼします。

現在の私の見解は次のとおりです。2018年7月頃まで機能する新しいプラットフォームがあります。その後:私は何も知りません。必要なものがそれまでにnetstandard / netcoreappで利用できることを願っています。 そして、サポートが終了する前に移植するのに十分な時間があればいいのですが。 ただし、希望する報酬はありません。会社のプラットフォームに関する決定を行うために報酬が支払われます。ASP.NETCoreは、この変更と機能するバージョンの日付がないため、(私たちにとって)悪い賭けです。

1行の要約を提供します。.NETフルフレームワークのサポートがない場合、ASP.NET Coreは、今後2年間のユースケースでサポートされるプラットフォームを提供しません。

短いバージョンとして、それはこれです:

優先度1:これはnet461で機能する必要があり、ifdefsに関係なく、パフォーマンスがあります。
優先度2。.NETCore2.0で10倍高速化できるのであれば、それはすばらしいことです。 人々がプラットフォームを選択したり、可能な場合は移行したりする大きな理由です。

ここで重要なことは、長期的なサポートのために、たとえそれがそこで遅くても、それはまだ完全なフレームワークで動作しなければならないということです。

優先度1:これはnet461で機能する必要があります

そして、.NET Coreがnet461と完全に互換性がある場合(理由の範囲内)。 したがって、net461用に作成されたものはすべてCoreで機能しました。 それなら大丈夫でしょうか?

基本的に、その時点では、net4xよりも安定したプラットフォームがあります。これは、並列で自己完結型で実行できるためです(x-platのタッチも)。 net461ではマシン全体が4.6.1、4.6.2、4.7などに変更されています

明らかに、何かが機能することはありません。 部分的な信頼のように-しかし、それはとにかくうまくいきませんでした。

本物の質問ですが、ASP.NET Core 1.xは現在、.NETFrameworkと.NETCoreをサポートしています。 上記の安定したプラットフォームであったとしましょう。両方のランタイムでバグ修正とサポートを行いましたが、それ以上の機能はありませんでした。 それで十分でしょうか?

Ubuntu/Redhatが5年以上サポートしているLTSリリースで行うようなASP.NETCore2.0のLTSリリースを見てみたいと思います。 それは、エコシステムの残りの部分が採用にコミットする自信を持つことができる、堅実な互換性のあるターゲットを提供します。

個人的には、将来の.NET Coreのみの機能よりも、安定した.NET Standard 2.0に興味があります。すべてが正常に機能し、ツールが壊れていない、人気のある.NET開発に戻りたいからです。 NETパッケージはすべてサポートを提供し、周囲の展開およびホスティングソリューションは洗練されており、ソリューションの構築を開始できる安定したASP.NET Coreで利用できるドキュメント、投稿、ビデオ、およびナレッジベースが豊富にあります。

1年後も同じ議論をしませんか? それまでに、.NET Coreをサポートするエコシステムやライブラリが大きくなり、影響が少なくなるのではないでしょうか。 決して更新されない(またはソースコードが失われた)エンタープライズライブラリはどうですか? それらは1年で変わるのでしょうか?

理想的な世界では、.NETv4.xと.NETCoreはどちらも近い将来ASP.NETCoreをサポートし、.NETCoreのみのパッケージでのみ利用できる新しい.NETCoreのみの機能です。 しかし、MSが.NET 4.xを残す運命にある場合は、正式に別れる前にASP.NET2.0LTSをリリースするのが次善の策です。 定義上、まだ存在しない新機能に依存している人はいないため、.NETCoreのみのv3.0へのアップグレードを強制されることはありません。

1つのプラットフォームをサポートするだけの自由で、開発者が継続的に新しい機能のストリームを備えた次の最新かつ最高のバージョンを採用するように誘うような新しい機能を提供できる可能性があります。個人的には、ASP.NETの機能に満足しています。常に移動するプラットフォームを追いかけるのではなく、再び生産性を高めてソリューションの開発に集中できるように、すべてが洗練された安定したバージョンに興味があります。

まず、スレッドに飛び込んで立ち上がったり質問したりしてくれた@davidfowlに感謝します。Qの山を尋ねる熱狂的なコミュニティがある場合、介入せずに「ターゲット」になるのを避けるのは簡単です。 建設的に参加していただきありがとうございます。 /meはあなたに敬礼します。


この会話から2つの主要なポイント/スレッドが出てきます:

  1. vnextで.NETデスクトップをサポートするように要求します。 (これは、ここでの返信の99%です)
  2. そのような重要な決定に関するコミュニティ協議の欠如。 (ここに2つまたは3つの返信があります)。

TL; DR;

  • 重要なvnextの大きな変更について、もっとオープンになっていただけませんか。
  • これらのvnextの変更について、コミュニティからのRFCに時間を割り当てます。

@mythzは、(この時点で)彼の冒頭の文でそれをうまく述べています。〜最新〜2番目に最近のコメント:

この状況全体は、.NETの将来に影響を与えるこのような重要な決定が、最後の最後に、透明性なしに、どれほど迅速かつ簡単に発生する可能性があるかについて、少しがっかりします。

これは本当に私を個人的に襲ったものであり、私はこれらの電話をかけるMSの適切な人々からのいくつかの公式の返信/コメントが大好きです。 「私たち」は長い間このコミュニティの周りにいました-なじみのある顔、なじみのある名前、そして言うのはかなり公正です-すべて同じ前向きな目標に従っています。 私はさらに、「私たち」はかなり大規模な拡大家族であり、いぼとすべてであると言います。

ですから、MSが取った新しい方向性(OSS-all-the-thingsなど)と、過去12/18か月の最近のmega-uber-.NET-threads(読んでください:これらのコミュニティディスカッションの経験から学ぶ) )...「私たち」はすべて一緒になっており、これらのReally-Big-Things™️のいくつかは、前もってオープンに議論されるでしょう。

ですから、これらの大きな決定のいくつかについて、事前に公開で話し合っていただけませんか。 積極的なコミュニティの協議と議論を得ますか?

注:私は、このプロジェクトが民主主義ではなく、_決定_がMSによって行われることを認めます。 問題はありません。 私は_それ_を批判していません。 その前の手順について話している。 また、私はRFCなどのために_すべて_を我慢することを求めていません。このスレッドが開始したもののように、奇妙な主要なチケットアイテムだけです。

しかし、MSが.NET 4.xを残す運命にある場合は、正式に別れる前にASP.NET2.0LTSをリリースするのが次善の策です。 定義上、まだ存在しない新機能に依存している人はいないため、.NETCoreのみのv3.0へのアップグレードを強制されることはありません。

わかりません。 ASP.NET 2.0の機能はリリースに存在しないため、まだ誰も依存していません。 では、ASP.NET Core 1.xはそのバージョンではありませんか? フルフレームワーク、コア1.0およびコア2.0で実行され、ASP.NET Core 2.xへの足がかりとして機能できますか?

@onovotny

誰もが常に新機能、新機能の可能性、または少なくとも後でもっと多くのグッズを手に入れるオプションがあることを知っていることを望んでいます。 プラットフォームを閉じて「安定」/「メンテナンスモード」にすると、人々はそれがもはや注目されていないように見えます。

はい。ただし、.NET FrameworkがOSコンポーネントに関連付けられてサポートされている大きな安定版である場合、同じレベルの品質を保証することは非常に困難です。 @terrajobstが言ったように、ある時点で確実に移植されるものもあれば、理解する必要があるものもあります。 実際、ASP.NET Coreは、スタック全体を一度に回転させる機能があるため、.NETCoreで最適に動作します。 これまでのところ、2つのランタイムの間には大きなパフォーマンスの違いがあり、.NET Frameworkがサポートされているため、新しいAPIへの依存関係はまだありません。 今後、.NET Frameworkに表示される場合と表示されない場合がある新しいAPIを追加する予定であり、最も安定して移動が遅いランタイム(.NET Framework)のペースで回転させたくありません。

@NickCraver

(上記のScottによると)サポートはリリースから約1年後に終了するためです。 そして、私はそれまでにStackOverflowの移植をほとんど終えていないかもしれません。

それが完全に正確かどうかはわかりません。 2.0が利用可能な場合でも、1.1は引き続きサポートされます。 それで、あなたが話しているこの「サポート」とは何ですか? 有料サポートという意味ですか、それとも問題が発生したときに修正するという意味ですか?

私が持っていなければならない図書館がそこにないからです。 そして、いつになるかわかりません。 だから私は1.xで立ち往生し、サポートが終了するまで時限爆弾を持っています。 サポートが終了する前に、1.0から2.x(または3.x)に移植するのに十分な時間がありますか? おそらくそうではありません。

私が言ったように、それらのライブラリは.NETCoreのバージョンに関係なく点灯します。 あなたが言っていることは、最新バージョンのASP.NET Core(それが何であれ)を使用し、.NET Coreに十分なライブラリがあり、移植ができるようになるまで、.NETFrameworkでサポートされることを望んでいると思います。特定のシナリオでは簡単です。

大規模なコードベースは、停止して移植するだけでなく、時間が必要であり、段階的に実行する必要があります。 ASP.NETCoreに.NET4.6.xポートを実行することは、中間ステップとして実行可能でした。 一度にコアに移行することは、はるかに困難で、はるかに時間がかかり、より長寿命のブランチとより多くの苦痛を必要とします。 これを段階的に実行できない場合、正直なところ、現在は廃止されているASP.NET5ラインから移行することはできません。 時間、コスト、開発への影響を正当化する方法はありません。

ASP.NET Coreの回転バージョンはそれにどのように影響しますか? 3.0で.NETFrameworkのサポートを終了した場合(このスレッドでは人々が理解しにくいようです)、関係なく同じ行き止まりになりませんか? 移植されたASP.NETCore2.0アプリケーションをフレームワークで1年間実行し、3.0がリリースされると、アップグレードできなくなります。 とにかく、これは.NETFrameworkで実行されASP.NETCore2.0がリリースされている場合でもサポートされているASP.NETCore1.1.xで実行できます。

現在の私の見解は次のとおりです。2018年7月頃まで機能する新しいプラットフォームがあります。その後:私は何も知りません。必要なものがそれまでにnetstandard/netcoreappで利用できることを願っています。 そして、サポートが終了する前に移植するのに十分な時間があればいいのですが。 ただし、希望する報酬はありません。会社のプラットフォームに関する決定を行うために報酬が支払われます。ASP.NETCoreは、この変更と機能するバージョンの日付がないため、(私たちにとって)悪い賭けです。

それで、もう一年は皆にとって十分な時間ですか? それは私がこのスレッドから得ている感覚ではありません。

優先度1:これは、ifdefsに関係なく、net461で機能する必要があります。
優先度2。.NETCore2.0で10倍高速化できるのであれば、それはすばらしいことです。 人々がプラットフォームを選択したり、可能な場合は移行したりする大きな理由です。

ここで重要なことは、長期的なサポートのために、たとえそれがそこで遅くても、それはまだ完全なフレームワークで動作しなければならないということです。

.NET Frameworkが現在のように機能する唯一の理由は、それをサポートすることを意図していたためです。 無料ではありませんでした。「コアで高速」ではありません。.NETFrameworkで動作するように、意図的にシステムを設計する必要がありました。 まだ表示されていませんが、.NET Frameworkにまだ存在しないAPIに依存することを決定すると(そして決定すると)、機能のギャップは2つの間に拡大します。 @PinpointTownesの言うことを実行して、これらの機能のギャップが表示されたときにNotSupportedExceptionをスローし始めることができますが、IMOはかなり悪い経験です。

ASP.net MVC5アプリをASP.netコアフルフレームワークに移植して、Azure Service Fabricで適切に機能させるために、多大な開発予算を費やしました。 プロジェクト全体は数か月で、Webアプリケーションの移植に数週間費やされました(そして率直に言って、厄介なVS2015ツールと格闘しました)。

動作した唯一の理由は、現在ASP.netコアでSignalRを実行しているため( @davidfowlの落胆のため)、完全なフレームワークがサポートされていたためです。 私の知る限り、SignalRはまだAsp.net Coreでサポートされていませんか?

その後、1週間ほどかけて新しいVS2017ツールに移行しました。 罰金。

_この時点まで、製品にまったく改善はなく、Microsoftのプラットフォームとツールの要件に合うようにコードの形状を調整しているだけであることに注意してください。_

今、あなたは私に、12か月以内にもっと機能のない開発努力をしなければならないと言っていますが、手を振っている束によってはそれができるという保証はありません。 結構です。

まず、人々が現在ASP.netコアフルフレームワークで使用しているMicrosoftブランドのすべてを、ASP.netコアのみで動作させます。 次に、エコシステムが必要に応じてASP.netコアを採用するのを妨げている他の要因(ある場合)を見つけます。 それから、そしてその時だけ、議論されているようにNetfxのサポートをやめます。

@PinpointTownesが言うことを実行し、それらの機能のギャップが表示されたときにNotSupportedExceptionをスローし始めることができますが、IMOはかなり悪い経験です。

それは私が言ったこととは異なります。クロスコンパイルを使用する場合、特定のプラットフォームで使用できないAPIを除外するには、 ifdefsを使用することをお勧めしますが、何らかの理由でこのAPI署名を公開する必要があります。契約すれば、 NotSupportedExceptionで行くことができます。

わかりません。 ASP.NET2.0の機能に依存している人はいません

ほとんどの開発者は、ASP.NET Coreへの移行をコミットする前に、依存関係がサポートしている安定した互換性の高い.NETStandard2.0を待っていると思います。 .NET Core 1.1がEOL化されており、MSには古いDNX / .NET Coreバージョンの長期サポートを提供してきた歴史がないことを知っているので、彼らは.NETCore1.1を採用するつもりはありません。 エコシステムの残りの部分が安全に採用できる互換性の高い安定したLTSリリースがあった場合、企業はシステムを実行するために必要なすべてのものを備えている必要があり、.NETCorevNextにアップグレードする必要はありません。 v2.0が必要であり、時が来れば、ASP.NET Core 2.0 /.NETv4.6から将来の.NETCoreのみのバージョンへの移行を計画するのがはるかに簡単になります。

@mythz

個人的には、将来の.NET Coreのみの機能よりも、安定した.NET Standard 2.0に興味があります。すべてが正常に機能し、ツールが壊れていない、人気のある.NET開発に戻りたいからです。 NETパッケージはすべてサポートを提供し、周囲の展開およびホスティングソリューションは洗練されており、ソリューションの構築を開始できる安定したASP.NET Coreで利用できるドキュメント、投稿、ビデオ、およびナレッジベースが豊富にあります。

そこにあるすべてに同意しましたが、この決定があなたの言ったことにどのように影響するかわかりません。 私はそれらの同じものすべてが欲しいです👍。

1つのプラットフォームをサポートするだけの自由で、開発者が継続的に新しい機能のストリームを備えた次の最新かつ最高のバージョンを採用するように誘うような新しい機能を提供できる可能性があります。個人的には、ASP.NETの機能に満足しています。常に移動するプラットフォームを追いかけるのではなく、再び生産性を高めてソリューションの開発に集中できるように、すべてが洗練された安定したバージョンに興味があります。

そうです、そのASP.NET Core 1.xではありませんか? 1.xでサポートが拡張された場合、それで十分ではないでしょうか。 netstandard1.xであるASP.NETCore1.が.NETCore2.0(すでに実行されている)で実行されていることを確認し、それをさらに1年ほどサポートすることができます。

それは私が言ったこととは異なります。クロスコンパイルを使用する場合、特定のプラットフォームで使用できないAPIを除外するには、ifdefsを使用することをお勧めしますが、何らかの理由でパブリックコントラクトにこのAPI署名が必要な場合は、次のことができます。 NotSupportedExceptionを使用します。

パブリックAPIの公開についても話していません。 ネットスタンダードには存在しない、呼び出す必要のあるAPIについて話しています。 #ifdefsはここでは役に立ちません。 ギャップが大きくなるにつれて、私たちはただ投げるでしょう。

@davidfowl完全に有効な質問-回答:

有料サポートという意味ですか、それとも問題が発生したときに修正するという意味ですか?

問題のアクティブな修正-1.xは、私たちが壊したすべてのものの修正を受け取りますか、それとも場合によっては修正のためにアップグレードするように言われますか? (注:これは、DirectoryServicesなどのライブラリが存在するまで実行できないアップグレードです...無料または安価に近い場合でも、少なくとも数か月かかる可能性があります)。 私たちは大きく、速く、フレームワークにブレークがあります。 何年もの間、メジャーリリースとマイナーリリースごとに用意しています。 サポートは私たちにとって非常に重要です。

あなたが言っていることは、ASP.NETCoreの最新バージョンを使用したいということだと思います

いいえ、機能するバージョンと今後のパスが必要です。 1.xでは、前半しかありません。 この問題が発生するまでは、2番目の問題が想定されていました。

ASP.NET Coreの回転バージョンはそれにどのように影響しますか?

完全なフレームワークのサポートを終了する場合、サポートを維持するために大きな変更を加える必要があるためです。

3.0で.NETFrameworkのサポートを終了した場合(このスレッドでは人々が理解しにくいようです)、関係なく同じ行き止まりになりませんか?

多分? 重要なのは、ダイビングを行う前にユースケースで同等性を保つことです。 それは私のキャリアです。反対側が私たちをサポートしていない可能性があるときに、私は私たちの会社にジャンプするように言うことはできません。 それは私の側では無責任だろう。 ユースケースが2.xの時間枠でサポートされていれば、明確な道筋があり、ASP.NETCoreに賭ける方がはるかに安全です。

それで、もう一年は皆にとって十分な時間ですか?

時間の絶対的な長さは実際には重要ではありません。ユースケースの互換性+時間(IMO)である必要があります。 私たちのユースケースが今日機能した場合(たとえば、AD認証)、2年で十分です。 しかし、現在はそうではないので、これからの任意の時点で大丈夫であることに同意することは、せいぜい時期尚早です。

無料ではありませんでした。「コアで高速」ではありません。.NETFrameworkで動作するように、意図的にシステムを設計する必要がありました。 まだ表示されていませんが、.NET Frameworkにまだ存在しないAPIに依存することを決定すると(そして決定すると)、機能のギャップは2つの間に拡大します。

それなら不快感はありませんが、それを言って問題を解決してみませんか? その声明はこれ以上議論することはないようであり、私たちの時間は他の場所で過ごすほうがよいでしょう。 そうでない場合は、明確にしてください。

主な問題は、ワークロードを今日、または現在提案されているように、起動時にnetstandardに移植できないことです。 すでに持っているものが機能しない場合、なぜ新しい機能を気にするのでしょうか。 チームはパフォーマンスについて話し続けています(そしてそれは本当に素晴らしいです)が、私が速く走ることができないものは本当に重要ではありません。

アーキテクチャ/プラットフォームのリーダーとして、私はどのような賭けをするかを決定する必要があります。 現在、これは悪い賭けです。 バージョン1があなたをサポートしているが、バージョン2はサポートしていないが、いつかはそうなることを願っています。それは他の人の時間とお金で作るのは本当に悪い賭けです。 少なくとも私たちにとっては、機能、エコシステム、サポートに.NETを選択しました。 現在、新しい単語では、これら3つすべてから1つに変更されています。エコシステムはまだ存在せず(APIサーフェス、ライブラリ)、サポートは以前よりもはるかに短く、アップグレードパスが保証されていません。そうするための未知の時間。

@jahmai

動作した唯一の理由は、現在ASP.netコアでSignalRを実行しているため( @davidfowlの落胆のため)、完全なフレームワークがサポートされていたためです。 私の知る限り、SignalRはまだAsp.net Coreでサポートされていませんか?

SignalR 2でさえASP.NETCoreではサポートされていません(ただし、人々はそれを機能させるためにハックしています)。 SignalRはまだ開発中であり、ASP.NETCore2.0ではリリースされません。後でリリースされる予定です。

今、あなたは私に、12か月以内にもっと機能のない開発努力をしなければならないと言っていますが、手を振っている束によってはそれができるという保証はありません。 結構です。

ASP.NET Core 2.0に必要な機能はありますか? または、最終的に次のASP.NET Coreにアップグレードする必要があり、その時点で.NET Frameworkでは機能しないと推測しているだけですか?

まず、人々が現在ASP.netコアフルフレームワークで使用しているMicrosoftブランドのすべてを、ASP.netコアのみで動作させます。 次に、エコシステムが必要に応じてASP.netコアを採用するのを妨げている他の要因(ある場合)を見つけます。 それから、そしてその時だけ、議論されているようにNetfxのサポートをやめます。

netstandard 2.0の一環として、.NET Frameworkを対象とするライブラリの大部分がバイナリ互換になるように、戻すべき重要なAPIを特定するために多くの作業が行われました。 もちろん、WCF、WPFなどのように機能しない領域もありますが、いくつかの調査を行ったので役立ちます。ライブラリの約60%はnetstandard 2.0とAPI互換です(その数が間違っている場合は修正してください) @terrajobst)、. NETCore2.0で動作する可能性があります。

そうです、そのASP.NET Core 1.xではありませんか? 1.xでサポートが拡張された場合、それで十分ではないでしょうか。

.NET Standard 2.0は、.NET 4.xとの互換性を橋渡しする安定したプラットフォームになると予想していたので、LTSサポートがその周りにある方が理にかなっています。 1.1 / .NET v4.xがリリースの途中でEOLされることを誰も期待していないので、リリース前に.NET 4.xのサポートを取得するのではなく、リリース時に最新バージョンでLTSを発表することを尊重します。そのような古いバージョンを遡及してLTSを実行します。

.NET Coreパッケージを別の*.Coreパッケージで維持しているので、メインのNuGetパッケージにマージした瞬間に、最新の.NETCoreバージョンに続く別のリリースケイデンスを維持できます。正式にサポートする予定の安定したリリースを約束しているため、現在の.NET Standardではなく、.NETStandard2.0から期待した近い将来にサポートできるバージョンがあることを確信する必要があります。 1.1 / 1.3/1.6ミックス。 安定したプラットフォームのシグナルではない.NET標準バージョンの期待を破る2.0と互換性がなくなる1.7/8ストップギャップリリースがあった時期もあったことを覚えています。

私は、.NET Standard 2.0が、非常に求められている高い互換性のある表面積と、非常に必要とされる安定性を提供する運命にあることを切望してきました。

SignalR 2でさえASP.NETCoreではサポートされていません(ただし、人々はそれを機能させるためにハックしています)。 SignalRはまだ開発中であり、ASP.NETCore2.0ではリリースされません。後でリリースされる予定です。

あなたがその声明をどのように意図したかはわかりませんが、それは私の懸念を補強するだけだと思います。

ASP.NET Core 2.0に必要な機能はありますか? または、最終的に次のASP.NET Coreにアップグレードする必要があり、その時点で.NET Frameworkでは機能しないと推測しているだけですか?

何らかの理由で、いつかnetstandard2に移行したいと思います。 そのためには、Webアプリをasp.netCore2に移動するために移動する必要があります。

netstandard 2.0の一環として、.NET Frameworkを対象とするライブラリの大部分がバイナリ互換になるように、戻すべき重要なAPIを特定するために多くの作業が行われました。 <...>

確かに、私はnetstandardで行われていることを気に入っていますが、netstandardに何かが欠けている場合は、それを必要とするアプリケーションで完全なフレームワークをターゲットにできるため、回避できます。 Xamarin.iOS、Xamarin.Android、net46、Asp.net core 1.1で共有されている純粋なnetstandard1.3ライブラリ(ソース)がいくつかあります-net46のものを含む特定のフレームワークターゲティングライブラリを使用して、netstandardで欠落している機能を補うことができるためですasp.netコアWebアプリで。

これらのnetstandardライブラリがある唯一の理由は、巨大なWebアプリケーションを移植する必要があったためです(前述のとおり)。 他のプラットフォーム用にプラットフォーム固有のコードベースを拡張する必要はなく、代わりにネット標準チェーンを上に移動し続ける必要があります。 asp.net core 2に移行する方法がないため、netstandard1.3に固執したくありません。

問題のアクティブな修正-1.xは、私たちが壊したすべてのものの修正を受け取りますか、それとも場合によっては修正のためにアップグレードするように言われますか? (注:これは、DirectoryServicesなどのライブラリが存在するまで実行できないアップグレードです...無料または安価に近い場合でも、少なくとも数か月かかる可能性があります)。 私たちは大きく、速く、フレームワークにブレークがあります。 何年もの間、メジャーリリースとマイナーリリースごとに用意しています。 サポートは私たちにとって非常に重要です。

サポートに問題はないと思います。 私は実際、これが大きな問題になるとは思いません。それによって人々が賭けに自信を持てるようになった場合は、1.xのサポートをより長い期間に延長する価値があるかもしれません。

いいえ、機能するバージョンと今後のパスが必要です。 1.xでは、前半しかありません。 この問題が発生するまでは、2番目の問題が想定されていました。

これは、すべての依存関係が移植されるまで1.xにとどまる必要があることを意味しますか?

@NickCraverすべての苦情は、ASP.NETCoreではなく.NETCoreに欠けているものについて話している。 .NETCore1.xおよびASP.NETCore1.xでは、これら2つのエンティティは一緒に出荷されますが、完全に分離されています。 特にv1が何かをサポートしていることとv2がそれをサポートしていないことについての正当な懸念以外に、ASP.NETCore2.0を使用したい理由は1つも聞いていません。 .NET Coreのみに移植できなかった別の理由があった場合(フルフレームワークでのASP.NET Coreの開発中に、いくつかの新しい依存関係を取得した可能性があります)、1年以内にまったく同じ議論が行われると思います。例として移植されることはありません)。

それなら不快感はありませんが、それを言って問題を解決してみませんか? その声明はこれ以上議論することはないようであり、私たちの時間は他の場所で過ごすほうがよいでしょう。 そうでない場合は、明確にしてください。

なぜ.NETFrameworkをサポートする必要があるのか​​、どのくらいの期間サポートする必要があるのか​​を理解しようとしているので、ここで回答と返信を行っています。 私はまだこれらの時間枠についてこのスレッドで混合された雰囲気を得ています。 また、「ASP.NET Core 1.xに追いやられている」ことについて私が理解できる一般的な恐れがありますが、2.xで必要とされる特定の機能に関して具体的なことは何もありません。

.NETCoreとASP.NETCoreを結合することについて私が気に入っている主な点の1つは、バージョン管理と名前付けの狂気の一部を解決することです。 多くの人は、ASP.NETCoreが.NETFrameworkで実行されていることすら知りません(スタックへの新規参入者を混乱させることさえあります)。 とはいえ、私たちにはさまざまなニーズを持つ多くの顧客がいて、彼らのフィードバックに耳を傾けています。

@mythz

私は、.NET Standard 2.0が、非常に求められている高い互換性のある表面積と、非常に必要とされる安定性を提供する運命にあることを切望してきました。

もちろんですが、私が言ったように、1.xのASP.NET Core、.NET Core、および.NETStandardは完全に分離されています。 .NET Standardライブラリは、それをサポートする.NETCoreの任意のバージョンで使用できます。 したがって、.NET Core 2.0が新しいLTSである場合でも、ASP.NETCore1.xがサポートされていることを宣言できます。

@jahmai

何らかの理由で、いつかnetstandard2に移行したいと思います。 そのためには、Webアプリをasp.netCore2に移動するために移動する必要があります。

いいえ、そうではありません。 WebアプリをASP.NETCore2.0に移動しなくても、いつでもnetstandard2に移行できます。

これらのnetstandardライブラリがある唯一の理由は、巨大なWebアプリケーションを移植する必要があるためです(前述のとおり)。 プラットフォーム固有のコードベースを他のプラットフォーム用に拡張する必要はなく、代わりにネット標準チェーンを上に移動し続けたいと思います。 asp.net core 2に移行する方法がないため、netstandard1.3に固執したくありません。

netstandard1.3に固執する必要はありません。 2つのことは無関係です。

バージョン1はサポートしているが、バージョン2はサポートしていないが、_いつかはそうなることを願っています_場合、それは本当に悪いギャンブルです...。

これが問題の核心だと思います。 ギャップの_一部_( DirectoryServiceなど)は既知であり、対処されるとのコメントがあります。 それよりも具体的なものが必要です。

ASP.NETCoreが.NETCoreをターゲットにしていることは問題ありませんが、ロードマップが明確であれば、これらのギャップ(およびどのギャップ)が解決されると予想できるか(ここでも、以前に移植するのに十分な時間があると仮定して)、2.0ボートを見逃しています。 1.Xはサポートされなくなります)。

現在のところ、WCFでブロックされている問題は、2015年5月以降停滞しており、解決されない可能性があります。

@davidfowl

いいえ、そうではありません。 WebアプリをASP.NETCore2.0に移動しなくても、いつでもnetstandard2に移行できます。

優れた。 その場合、Microsoftが1.xがサポートされていること(あらゆる種類のバグ修正と運用サポート)が顧客に適切な2.x移行パス(SignalRなど)を提供するまで保証している限り、私は私たちがasp.netコア2が必要です。

これは、すべての依存関係が移植されるまで1.xにとどまる必要があることを意味しますか?

正解ですが、それは既知の時間枠である必要があります。 日付はありません。これまでに言われたことは「2.0ではない」ということだけです...それは良くありません。 たとえば、 System.DirectoryServicesは2015年半ばからリクエストされており、まだ不足していますが、ユーザーが最も望んでいるものとして繰り返されることがよくあります(その後にSystem.Drawingが続きます)。 .NET Standard 2.0を最大60%のAPIパリティにするが、ユーザーが要求したビットが欠落していると、重要なことについて混合信号を送信することは間違いありません。

すべての苦情は、ASP.NETCoreではなく.NETCoreに欠けているものについて話している。

それは正しくありません。 サポートされているプラ​​ットフォームで実行する必要のあるビット(AD認証など)が必要です。 欠けているのは後者からのサポートです。 1.xのサポートは確かに私の主な関心事です。 サポートされているパスフォワードや、期待できるタイムラインはありません。

1年でまったく同じ議論ができると思います

そうではないと思います。 問題は、今日は移植できなかったことです。 APIはありません。 私たちが移植することさえできた単一の時点がない限り、将来についての議論は少し議論の余地があります。 ASP.NET Coreでの.NETの完全なフレームワークのサポートは、パリティが確立され、ほとんどのユーザーが移行できるようになると、非推奨になると思います。 そして、私はそのリリースが人々が移動するための長いサポート期間を持っていることを期待しています。

DirectoryServices、Drawingなどが2.xで提供される場合は、すばらしいです。 そのリリースは.NETFrameworkをサポートし、LTSリリースである必要があります。 そして、3.xは完全なフレームワークサポートを削除する必要があります。

.NETCoreとASP.NETCoreを結合することについて私が気に入っている主な点の1つは、バージョン管理と名前付けの狂気の一部を解決することです。 多くの人は、ASP.NETCoreが.NETFrameworkで実行されていることすら知りません(スタックへの新規参入者を混乱させることさえあります)。 とはいえ、私たちにはさまざまなニーズを持つ多くの顧客がいて、彼らのフィードバックに耳を傾けています。

十分に公平ですが、そこにあるすべての狂気は「それは機能しますか?」に次ぐものです。 現在、それは会社の番号です。 ASP.NETと.NETCore/ Standard /何でもMicrosoft内の2セットである可能性があります(そして私は完全にそれを理解しています)が、開発者にとってはそれでも1つのプラットフォームです。 ASP.NET Sideは、多くの人に役立つAPIを必要としていますが、まだ存在していません。 この動きにより、利用可能なAPIがさらに削減されます。 ASP.NETチームは必要なものを入手できますが、必要なものは犠牲になります。

@ctolkien @NickCraver

これが問題の核心だと思います。 いくつかのギャップ(DirectoryServiceなど)は既知であり、対処されるとのコメントがあります。 それよりも具体的なものが必要です。

正解ですが、それは既知の時間枠である必要があります。 日付はありません。これまでに言われたことは「2.0ではない」ということだけです...それは良くありません。 たとえば、System.DirectoryServicesは2015年半ばから要求されていますが、まだ欠落していますが、ユーザーが最も望んでいるものとして繰り返されることがよくあります(System.Drawingが続きます)。

ただし、これらのギャップは.NET Core自体に関連しており、これらの依存関係がいつ利用可能になるかわからないという不安を理解できます。そのため、これらの優先順位付けを支援することをお勧めします。 幸いなことに、netstandard 2.0とnetcoreapp2.0は、他のライブラリの移植を容易にするためのグループワークをもたらしました。 2.0を出荷した後は、互換性の高いベースの上に一連のコードを移植することで、他の依存関係を簡単に立ち上げることができると思います。

CSOMはnetcore2で実行されますか? それは私たちにとって大きな障害となり、私が何も聞いていない領域の1つになります。

@davidfowl私もそうなることを心から願っていますが、私はそれに私たちの会社を賭けていません。 それが起こる前に、そしてその後ではなく、サポートをやめることは、私は強く反対します。 多くの消費者向けの重要なAPIが導入された、3.xの時間枠でこれが発生することは完全に有効だと思います。 準備が整う前にそうすることは、私たちの採用を止めるだけです。

2.x(または積極的に開発/修正されたもの)がそれらの重要なAPIの準備が整うまで完全なフレームワークをサポートすると仮定して1.0を採用する道を進んでいました(私は真剣です-あなたは私がすでにライブラリにどれだけの作業を行ったか知っています)。 しかし、現時点では、Stackではそれを行うことができません...それは悪い仮定でした。 どのポートの将来も非常に不透明なのに、良心的に.NETCoreを使用するようにチームに指示することはできません。 本当にできればいいのですが、現時点ではリスクと苦痛の価値はありません。

@NickCraver

ASP.NET Coreでの.NETの完全なフレームワークのサポートは、パリティが確立され、ほとんどのユーザーが移行できるようになると、非推奨になると思います。 そして、私はそのリリースが人々が移動するための長いサポート期間を持っていることを期待しています。

ここでの「ほとんどのユーザー」の尺度は何ですか? サポートを終了するまでカバーする必要がある依存関係のリストは何ですか? あなたのリストは、このリストの他のユーザーとは異なります。 また、何人かの人々が永遠に、または.NETCoreが.NETFrameworkのパリティに達するまで(これは非現実的です)と言うことを期待しています。 ASP.NET Core 1.xはその目的には十分であり、そのサポートをその時点まで拡張することを検討する必要があります。

それは正しくありません。 サポートされているプラ​​ットフォームで実行する必要のあるビット(AD認証など)が必要です。 欠けているのは後者からのサポートです。 1.xのサポートは確かに私の主な関心事です。 サポートされているパスフォワードや、期待できるタイムラインはありません。

このシナリオで欠落しているASP.NETコンポーネントは何ですか? 1.xと2.xを言うときは、ASP.NETCoreと.NETCoreについて言及すると便利です。

DirectoryServices、Drawingなどが2.xで提供される場合は、すばらしいです。 そのリリースは.NETFrameworkをサポートし、LTSリリースである必要があります。 そして、3.xは完全なフレームワークサポートを削除する必要があります。

これについては前に説明しましたが、ASP.NET Core 1.xでは不十分であるために必要なASP.NETCoreの機能は何ですか?

ASP.NETと.NETCore/ Standard / Microsoft内の2つのセットである可能性があります(そして私は完全にそれを理解しています)が、開発者にとってはそれでも1つのプラットフォームです

同意しましたが、影響を適切に評価できるように、この議論についてFUDを明確にする必要があります。 ASP.NET Core 1.xは、.NET Standard 1.x(1.0-1.6)および.NETFramework4.5.1を対象としています。 これは、これらのバージョンのnetstandardおよび.NETFrameworkをサポートする任意のプラットフォームで実行できることを意味します。 これは、ASP.NETCore1.xが.NETCore2.0で実行されることを意味します。

@smbecker

CSOMはnetcore2で実行されますか? それは私たちにとって大きな障害となり、私が何も聞いていない領域の1つになります。

それが何なのかわかりません。 これはhttps://msdn.microsoft.com/en-us/library/ff798388.aspxですか? もしそうなら、それを明示的にサポートするために行われた作業はありませんでした。 .NET Core2.0の.NETFrameworkとの互換性に基づいて機能する可能性がありますが、.NET Coreに移植されることはないと思います(5分間の確認に基づく)が、間違っている可能性があります。

ここでの「ほとんどのユーザー」の尺度は何ですか? サポートを終了するまでカバーする必要がある依存関係のリストは何ですか? あなたのリストは、このリストの他のユーザーとは異なります。 また、何人かの人々が永遠に、または.NETCoreが.NETFrameworkのパリティに達するまで(これは非現実的です)と言うことを期待しています。 ASP.NET Core 1.xはその目的には十分であり、そのサポートをその時点まで拡張することを検討する必要があります。

不足している上位のAPIから始めましょう-これらはほとんどの人にとってブロックの原因です。 私たちにとって、それは1番のDiretoryServicesです。それがそこにさえなければ、それはコミュニティにとって本当に悪い兆候です。 リストが異なることに同意しますが、 1番を含めない場合は...

このシナリオで欠落しているASP.NETコンポーネントは何ですか? 1.xと2.xを言うときは、ASP.NETCoreと.NETCoreについて言及すると便利です。

これについては前に説明しましたが、ASP.NET Core 1.xでは不十分であるために必要なASP.NETCoreの機能は何ですか?

つまり、フルフレームワーク(したがって必要なライブラリ)をサポートする最新のASP.NETCoreのサポートです。 モジュールやかみそりのページなどが必要なので、これが2.xであることを願っています。2.xの多くの機能を使用しています。 しかし、現時点での唯一の選択肢は1.xのようです。 ASP.NET5からASP.NETCoreに、そしてすべての作業ライブラリを含む完全なフレームワークからnetcoreappに1回の移動でジャンプすることはできません。 多すぎます。 コストがかかりすぎます。 リスクが高すぎます。 そして今、私たちはサポートウィンドウ内でその高価で危険な動きをすることができるかどうか確信がありません。 それは悪い状況です-非常に悪いので、動かない方が良いです(今日の状況では)。 それは本当に残念なことだと思います。

このシナリオで欠落しているASP.NETコンポーネントは何ですか? 1.xと2.xを言うときは、ASP.NETCoreと.NETCoreについて言及すると便利です。

  • Microsoft.Authentication。*NuGetパッケージを介してAD認証/クエリを処理する方法がない限り、それは1つの大きなことです。 私は現在同じボートに乗っていますが、.NET462の上で.NETCore 1.1を実行しているので、それをやってのけることができます。 それ以外では、サポートされている方法でADグループ、メタデータをクエリするにはどうすればよいですか? 私はcorefxリポジトリで、 System.DirectoryServicesで多くの作業が行われていることを確認しましたが、少なくともそれについては満足しています。

  • System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter 。 現在、完全な.NETFramework上で.NETCoreで実行している場合にのみアクセスできます。 DbDataReader / SqlDataReaderをまだ使用できるので、もっと便利なことだと思います。

基本的に、完全な.NET Frameworkを必要とせずに、ASP.NETCore2.xの使用中にAD認証を処理するためのサポートされた方法がいくつか保証されることを知っておく必要があります。

私は今日これについてよく考えていて、私の懸念はここにあるほとんどの懸念とは異なっていることに気づいています(これらの懸念はそれほど重要ではないにしても、それほど重要ではないというわけではありません)。

私はまだnetstandardでASP.NETCoreパッケージを使用するユースケースに固執しています。 この問題が発生するまで、私は(おそらく間違って) netstandardがライブラリの事実上のターゲットであると想定していました。 言い換えれば、図書館の作者が意図する行動は、必要で説得力のある理由がない限り、 netstandardをターゲットにすることです。 これにより、Frameworkとの互換性だけでなく、XamarinやUWPなどの他のプラットフォームとの互換性が保証されます。 .NET Standard 2.0での作業は、さまざまなランタイムのAPI表面積を、それについて考える必要のない共通のターゲットに統合しようとすることで、これをサポートしているように見えました。

私にとって、この変化は何か違うことを示しています。 確かに、結局のところ、ASP.NET Coreは単なるライブラリであり、おそらく、一般的なnetstandardの表面積をサポートしない「必要かつ説得力のある理由」があります。 しかし、これはMicrosoftが開発した最も目に見える.NETライブラリの1つでもあり、「最新かつ最高のものが欲しいので、 netstandardのサポートを停止する」と言うことで、他のすべてのライブラリ開発者(または少なくとも私にとってはそうです)おそらく、彼らはnetstandardをサポートするために一生懸命努力するのをやめ、コアランタイムをターゲットにし始める必要があります。 Microsoftがそれほど気にしないのに、なぜ互換性の問題に悩まされるのでしょうか。 .NET Core4lyfe。 そして、おそらくそれが最善です-それは、私たちが複数のランタイムとほとんど統一されたAPI表面積で行っていたと思っていた場所とは確かに異なります。

ASP.NET Coreには、ASP.NETのコンテキスト外で直接役立つ多くのライブラリが含まれていることを考えると、この懸念はさらに深くなります。 それらが単独で使用されることを意図していたと考えるのは間違っていたかもしれませんが、それらを失うことはひどい恥です。 それらを使用したいライブラリ作成者は、自分のターゲティングを.NET Coreに切り替えるか、 netstandardのままにしてアクセスを緩めるかを決定する必要があります。 多くの人が前者を選択し、代替プラットフォーム用のライブラリサポートをさらに分割することになると思います。 少なくとも、サポートするライブラリのさまざまなプラットフォームをターゲットにするのは難しいというコメントを理解していれば。

最後に、ASP.NETと組み合わせてrevするために、可能な限りすぐに新しいAPIがCoreに追加されるという、ここでのコメントについて少し心配しています。 特に、これらの新しいAPIがnetstandardまたは.NETFrameworkに組み込まれない可能性があることに注意してください。 レガシーと互換性の懸念が解消または緩和された場合に実行できるいくつかのエキサイティングなことがあるかもしれないことを私は確かに理解しています。 しかし、率直に言って、ASP.NETCoreチームが前もって課金していることがよくあるという印象を受けました。 それは必ずしも悪いことではありませんが、それはまた、後退しなければならなかった多くのより広い決定につながりました。 これと、それに続くCoreランタイムの急速な進化によって、一連のランタイムが時間の経過とともに大幅に破壊される結果になるのではないかと思わずにはいられません(繰り返しになりますが、取り残されるのはWindows/フレームワークだけではありません。 Xamarin、Mono、UWPなどもあります)。

このスレッド全体により、 netstandardではなく.NETCoreを中心とした.NETの将来についての理解を深めることができました。 多分私は極端で、これから数週間でそれは和らぐでしょう、あるいはそれは意図された位置でさえあり、それはすべて最善です-いずれにせよ、私は現在、外に出て自分自身のために.NETCoreをターゲットにしたいと思っています私がここで読んだすべてのものから、これから先に焦点を当てるだけです。

@NickCraver

つまり、フルフレームワーク(したがって必要なライブラリ)をサポートする最新のASP.NETCoreのサポートです。 モジュールやかみそりのページなどが必要なので、これが2.xであることを願っています。2.xの多くの機能を使用しています。

現在は1.1.1(2.0にはモジュールがありません)です。RazorPagesは優れたもので、もう1つはSignalRです。 これらは、私がこれの一部として最も苦痛であると思う2つのことです。

ASP.NET5からASP.NETCoreに、そしてすべての作業ライブラリを含む完全なフレームワークからnetcoreappに1回の移動でジャンプすることはできません。 多すぎます。 コストがかかりすぎます。 リスクが高すぎます。 そして今、私たちはサポートウィンドウ内でその高価で危険な動きをすることができるかどうか確信がありません。 それは悪い状況です-非常に悪いので、動かない方が良いです(今日の状況では)。 それは本当に残念なことだと思います。

でも? 依存関係が移植されていると仮定して、ASP.NETCore1.xから2.xまたは3.xに移行するのは簡単です。 一般的にASP.NETCoreに移行することを計画している場合、1.1に移行することは良い最初のステップであり、それを回避するための作業を節約することはできません。

@snickler

基本的に、完全な.NET Frameworkを必要とせずに、ASP.NETCore2.xの使用中にAD認証を処理するためのサポートされた方法がいくつか保証されることを知っておく必要があります。

System.DirectoryServicesが.NETCoreでサポートされるまで、.NETFrameworkでASP.NETCore 1.xを使用できない理由はありますか?

System.DirectoryServicesが.NETCoreでサポートされるまで、.NETFrameworkでASP.NETCore 1.xを使用できない理由はありますか?

それが私が現在していることです。 必要がなければ、.NETFrameworkについて心配する必要がないことを願っています。 現在、MonoにはSystem.DirectoryServices.AccountManagement名前空間が存在しないため、Windowsマシンに制限されています。 それらの同じ点で、Windowsの制約の外で利用可能なSystem.DirectoryServices.AccountManagementはありますか? その1つの小さな部分により、MVCプロジェクトとXamarin.iOSアプリをローカルでデバッグしているときにマシン間をジャンプする必要があります。

一般的にASP.NETCoreに移行することを計画している場合、1.1に移行することは良い最初のステップであり、それを回避するための作業を節約することはできません。

動作する別のプラットフォームにアップグレードするまでサポートがあったことを知っていれば、私は完全に同意します。 現時点では、必要なビットが.NET Coreの世界でいつ利用可能になるかわからないため、今すぐタイムキャップを設定し、それらのビットがいつ来るかわからないことは、私が約束すること賭けています。 それが中心的な問題です。 移植を可能にするサポートされた重複するリリースがあれば、私はすべて準備ができており、投資することができます。 APIが導入される前にサポートが終了した場合、滑走路の量が不明なため、信頼のギャップが大きくなります。

今日netcoreapp2.0で機能しないことがわかっているので、DirectoryServicesを参照し続けます。 もちろん、同じボートに落ちるものは他にもあります。 一部のプラットフォームでは、ASP.NETCore+完全なフレームワーク+数年間のサポートが必要です。 1.xでは、多くの利益は得られませんが、実際にはほとんど得られません。 すでにページを約18ミリ秒でレンダリングしており、転送時間によって小さくなっているため、パフォーマンスは素晴らしい議論ではありません。 ただし、2.0にはかなりの数の優れたアイテムがあります。 Razorページとプラグインの見通しにより、移植するのは非常に魅力的です。 正当化できるほど。

現在、サポート付きの唯一のバージョン(より長いサポート付きの1.1.xは、このスレッドを読んだ後に期待するものです)は、移行する価値がありません。 私たちが今日いる場所にたどり着くには、基本的に多くの時間と労力が必要です。 2.xは、少なくとも、私たちが利用したいいくつかのまともな改善とビットを提供します。 彼らは引っ越しの費用を正当化するのに役立ちます。

すでに18ミリ秒でページをレンダリングしているので、パフォーマンスは素晴らしい議論ではありません

マイナーなOT暴言で、私はあなたが〜18ms @NickCraverでページをレンダリングすることができる方法を知りたいです。 それは素晴らしいです

@daveaglick

私はまだnetstandardでASP.NETCoreパッケージを使用するユースケースに固執しています。 この問題が発生するまで、私は(おそらく間違って)netstandardがライブラリの事実上のターゲットであると想定していました。 言い換えれば、図書館の作者が意図する行動は、必要で説得力のある理由がない限り、ネットスタンダードをターゲットにすることです。 これにより、Frameworkとの互換性だけでなく、XamarinやUWPなどの他のプラットフォームとの互換性が保証されます。 .NET Standard 2.0での作業は、さまざまなランタイムのAPI表面積を、それについて考える必要のない共通のターゲットに統合しようとすることで、これをサポートしているように見えました。

ここでは何も変わっていません。 実際、他のプラットフォームで実行したいライブラリの多くは、依然としてネットスタンダードです。 上記のいくつかを読み直した場合:

  • Microsoft.Extensions。*(ロギング、DI、構成、ファイルプロバイダーなど)
  • EntityFramework
  • SignalRクライアント(.NET Framework、Xamarin、UWPなどで実行する必要があります)。

.NET Standardは、どこでも実行できるライブラリを作成するための事実上の方法です。 ライブラリの作成者は、可能な限りネットスタンダードをターゲットにして、プラットフォームのリーチを最大限に広げることを目指す必要があります。 図書館の著者は、リーチを希望するかどうかを決定する必要があります。 そのため、JSON.NETなどのライブラリはnetstandard1.xおよび.NETFramework2.0をサポートしています。 @JamesNKが前述したように、彼らは物事を「うまく機能させる」ためにさらに努力します。

ASP.NET Coreが一部の場所でnetstandardから離れているということは、これらのAPIがUWPアプリケーション向けではなく、(例として)そこでテストしていないことを示しています。 また、.NETCoreとASP.NETCoreが一緒にバージョン管理される単一の製品であることを固めようとします(名前にCoreが含まれているため)。 ASP.NET Core1.xが.NETCoreと.NETFrameworkの両方をサポートしているため、そのメッセージは少しぼやけており、多くの人(特に新しい開発者)に混乱を引き起こし、ライブラリギャップの問題を緩和するためにそれを行いました。

ASP.NET Coreには、ASP.NETのコンテキスト外で直接役立つ多くのライブラリが含まれていることを考えると、この懸念はさらに深くなります。 それらが単独で使用されることを意図していたと考えるのは間違っていたかもしれませんが、それらを失うことはひどい恥です。 それらを使用したいライブラリの作成者は、独自のターゲティングを.NET Coreに切り替えるか、netstandardを使用してそれらへのアクセスを失うことを決定する必要があります。 多くの人が前者を選択し、代替プラットフォーム用のライブラリサポートをさらに分割することになると思います。 少なくとも、サポートするライブラリのさまざまなプラットフォームをターゲットにするのは難しいというコメントを理解していれば。

それらはまだネットスタンダードだと思います。 どれがそうではありませんか?

これと、それに続くCoreランタイムの急速な進化によって、一連のランタイムが時間の経過とともに大幅に破壊される結果になるのではないかと思わずにはいられません(繰り返しになりますが、取り残されるのはWindows/フレームワークだけではありません。 Xamarin、Mono、UWPなどもあります)。

netstandard進化すると思いますが、.NET Frameworkは常に新しいAPIを取得する最後のものになります(XamarinとMonoは非常に高速に追加できます)。

@snickler

それが私が現在していることです。 必要がなければ、.NETFrameworkについて心配する必要がないことを願っています。 現在、System.DirectoryServices.AccountManagement名前空間がMonoに存在しないため、Windowsマシンに制限されています。 同じ点で、Windowsの制約の外でSystem.DirectoryServices.AccountManagementを使用できますか? その1つの小さな部分により、MVCプロジェクトとXamarin.iOSアプリをローカルでデバッグしているときにマシン間をジャンプする必要があります。

dotnet/corefxでそのような問題を提出するようにしてください。 依存関係が移植されると仮定すると(非常に人気がない限り)、それは間違ったことです。

@davidfowl質問:[ファイル]-> [ASP.NET Core 2.0を使用した新しいプロジェクト]を作成し、ADに対して認証します。 これは可能ですか? これを実行する機能がなければ、Microsoftプラットフォームの出荷を想像することはできません。

そこにあるすべてに同意しましたが、この決定があなたの言ったことにどのように影響するかわかりません。 私はそれらの同じものすべてが欲しい

.NET v4.xのサポートを終了することで、人気のある移行パスが削除され、.NETエコシステムがさらに断片化され、多くの開発者や組織がそれを採用できなくなり、ASPへの知識と投資のコミュニティプールが減少します。多くの.NET開発者は既存のASP.NETv4.xコードベースを無期限にサポートする必要があるため(フルタイムで作業するために報酬が支払われます)、NETCore。

.NET Coreの市場シェアが小さいほど、ライブラリメンテナがサポートする優先度は低くなります。また、ASP.NET Coreへの移行を検討できなくなった組織で働く場合は、サポートしない可能性があります。これは、パッケージに応じて他の人に影響を及ぼします。 これらはすべて、安定したプラットフォームがなく、長期的なサポートが保証され、人気のある移行パスがなくなることにより、ASP.NETCoreを採用する際の負担が増えることによる副作用です。

ここの誰もが.NETエコシステムの繁栄を望んでいると思いますが、既知の量の、互換性の高い、安定したLTSリリースが利用可能になるのは間違いであり、今後何年にもわたって悪影響を及ぼします。

@davidfowlありがとう-あなたのコメントは大いに役立ちます。 私は(明らかに間違って)、この変更の一環として、ほとんど/すべてのサポートライブラリがnetstandardから移動していることを収集しました。 私はかなりの数を使用しており、他の人も同様に使用していることを知っているので、そうでないことを聞くことは歓迎すべきニュースです。

@NickCraver今日、ADに対してどのような認証を使用していますか? OpenIdConnect、WsFed、NTLM、その他?

@Tratcher AD auth、DirectoryServices経由(グループメンバーシップなどを照会する必要があります-標準ビット)

@mythzこれは合理的だと思います。ほとんどの場合、ASP.NETCore1.xのサポート期間を延長するだけで十分だと思います。

ある時点でこの決定を下さなければならない理由はわかりますが、それは時期尚早であり、次の点で最も幸せになると私も信じています。

  • ASP.NET Core 2.xはLTSであり、最後にフルフレームワークをサポートします(すでにプレビューを行っていたので、それほど遠くはありません)。また、SignalRもサポートしているため、ジャンプを行うためのターゲットフレームワークになります。 ASP.NETからASP.NETCoreへ
  • 3.xフルフレームワークのサポートを終了し、上位の依存関係が移行されたときにリリースされます

私の見解では、ASP.NET Core 1.1のサポートを拡張するだけでは十分ではありません。そのプラットフォームは、多くのASP.NET移行(私の場合はSignalRがブロッカー)のターゲットになるほど成熟していない/採用されていないためです。

lulzのためだけに、私が取り組んだASP.NET Core1.0アプリで大規模に使用されているEntityFramework6を、最新のpreview2.NETCoreナイトリービルドで使用してみました。 何だと思う...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

image

完全なフレームワーク用に設計およびコンパイルされたアセンブリのふりをやめると、.NET Coreで問題なく機能します。些細なケース(hello worldアプリを読む)はおそらく機能しますが、多くの場合、不足しているAPIまたは機能しないAPIによってブロックされることになります。 。

絶対にひどいのは、実行時に機能しないことに気付くだけだということです。 場合によっては、それがまったく明らかではないことさえあります。 たとえば、.NET CoreのSqlClientは、アンビエントトランザクションの参加やTransactionScopeを使用した分散トランザクションをサポートしていません。EF6を機能させる方法を見つけたとしても、 TransactionScopeはまったく効果がなく、DB呼び出しは必要な分離レベルを使用しません。

この動きに関する私の懸念については、ここに2セントを追加する必要があると感じています。 WPFで開発された新しい領域のいくつかを備えた主にWindowsフォームであるデスクトップアプリケーションがあります。 そのアプリケーションには15年以上の努力があり、WinFormsから完全に離れるには何年もかかります。 そうでないことを望みますが、そうです。 新しいWebインターフェイスと既存のWinFormsアプリケーション全体でビジネス層とデータアクセス層を利用できるように、コードベースにモジュール性を組み込むために取り組んできました。 新しいWebアプリケーション用にASP.NETCoreにすぐに移行するつもりでしたが、先ほど述べたように、.NETv4.6.xを対象とする既存のコードベースの大部分を消費する必要があります。 System.DrawingとSystem.Security.Cryptographyを使用していることは確かです。 また、上記の方法でTransactionScopeを多用します。

MEFに依存せずに、Webアプリケーションの領域を個別のアセンブリにカプセル化できるなど、ASP.NETCoreの利点のいくつかを得るのを非常に楽しみにしています。 他にも多くの理由がありますが、それが本当に素晴らしい理由です。 ただし、アプリケーションをASP.NET Coreに移行すると、WinFormsを使用してバックエンドコードの移植性を維持する必要があるため、当面は1.xのままになる可能性があります。 私は主にWeb製品に焦点を当てているため、WMIなどのどこに接続しているのか、移植性の問題に影響を与えるのかどうかはわかりませんが、コードベース内にあることはわかっています。 私たちは今本当に興味深い段階にあり、私がしなければならない最後のことは、すべてのWebバージョンの機能をASP.NET MVC 5に開発し、いくつかで移植する必要がある新しいレガシーコードの束を蓄積することです将来の努力。

WinFormsを使用しなくなった場合でも、.NET Standardをターゲットにしないようにするために、多くの使用法があると確信しています。 私たちはマイクロソフトパートナーであり、いくつかの方法でマイクロソフトと直接連携しているため、ここで何をするかについてはあまり詳しく説明したくありませんが、 @ともっとプライベートな話し合いができれば幸いです。私たちが行っていることの詳細が必要な場合は、 @davidfowl 。 私もMSBuildに参加し、出席する場合はそこでどちらかと会って話をすることができます。

このような課題でスタックを使用している企業を検討したことはないと思います。 ただし、完全な免責事項:コードベース内で移植性を維持する必要があるため、前述の移植性アナライザーを実行して、実際にどこに行き詰まっているかを確認するつもりです。 そのチェックに失敗した.NETFrameworkAPIのリストを喜んで提供します。

ムーアハハ。 笑うべきか泣くべきかわからない...

これは、動作しない私の些細な23行EF6アプリのApiPort分析ツールによって生成されたレポートです。

image

クロスコンパイルはオーバーヘッドであり、顧客や製品のニーズとバランスを取る必要があります。 これが、このフィードバックを取得したい理由です。これにより、ASP.NET Coreを進化させながら、お客様と私たちの両方の状況をより具体的に定義できるようになります。

この問題が開かれる前に、フィードバックプロセスはありましたか?

私たちは皆、1.1の時間枠とサポートについて話し合っていますが、ASP.NET Coreが完全なフレームワークを完全に廃止するという事実は、私にとって大きな驚きです。

私の理解では、コアフレームワークはクロスプラットフォームプレイであり、Windowsに結合されていない完全なフレームワークのサブセットで構成された新しいフレームワークです。 2.0リリースは、APIのほとんどを取り戻すために私たち全員が待ち望んでいたリリースでした。

ASP.NET Coreは、この新しいフレームワークのドッグフードでした。新しいWebフレームワークは、フレームワークAPIの非常に小さな表面積に依存していたため、どこでも実行できました。

コアフレームワークが完全なフレームワークとほぼ同等になると、すべての新しいAPIがnetstandardに追加され、最終的には両方のフレームワークになると期待していました。 私たちは皆、netstandardをターゲットにし始め、すべてが虹とユニコーンになります。

ASP.NETを見つけることは、ドッグフードのネットスタンダードでさえなく、フレームワーク固有のeh:/

@rohatsu

私の見解では、ASP.NET Core 1.1のサポートを拡張するだけでは十分ではありません。そのプラットフォームは、多くのASP.NET移行(私の場合はSignalRがブロッカー)のターゲットになるほど成熟していない/採用されていないためです。

SignalRがASP.NETCore1.xで動作した場合はどうなりますか? あなたが必要とするプラットフォームについて他に何が未熟ですか?

@millman82それを共有してくれてありがとう。 .NET Frameworkのサポートがしばらくの間廃止される前に、バージョンに固執するように聞こえます。 したがって、2.xとの互換性を維持し、3.xがドロップするというここでの提案のいくつかは、うまくいかない可能性があります。 ASP.NET Core 1.xにとどまらないのはなぜですか? ポートに必要なものが何が欠けていますか? それとも、 @ NickCraverと同じ懸念事項ですか(2.xがそれをサポートしていないと、それに賭けることに神経質になります)。

@jkells

コアフレームワークが完全なフレームワークとほぼ同等になると、すべての新しいAPIがnetstandardに追加され、最終的には両方のフレームワークになると期待していました。 私たちは皆、netstandardをターゲットにし始め、すべてが虹とユニコーンになります。

それはそれほどフェッチされていません、それは時間の要素が欠けているだけです。 最終的には、それぞれが独自のスケジュールで出荷するすべてのフレームワークになります。

ASP.NETを見つけることは、ドッグフードのネットスタンダードでさえなく、フレームワーク固有のeh:/

このスレッドで何度か言及されているように、その一部は依然としてネットスタンダードを対象としています。

ASP.NET Core 1.xにとどまらないのはなぜですか?

できません-2.0がドロップしてから1年はサポートされていません(2.0が次のLTSであると仮定します)。

@davidfowlそれは間違いなくその大部分です。 また、現在のWebアプリケーションではODataとSignalRを使用しており、次に進む前にASP.NETCoreに含める必要があります。 ただし、ASP.NET Core 1.xのサポートが終了し、現在サポートされていないフレームワークパーツを使用した移行パスがない場合、発生したくないことの1つは問題が発生することです。 ASP.NETCoreがASP.NETホールセールに取って代わると予想しています。 それは道のどこかにあるかもしれませんが、それは来ています。 今ASP.NETMVC5でUIを書き直したくないことを知っていて(現在はいくつかありますが、小さいので簡単に移動できます)、数年後にASP.NETCoreで書き直します。 ASP.NETのサポートが終了すると。

現在Core1.xをターゲットにしている場合、暫定的に拡張されたASP.NET Core 1.xのEOLが到着したときに、その移行パスが存在しない場合、ひどく火傷する可能性があります。 マイクロサービスを使用してその一部をナビゲートすることもできますが、もちろんそれ自体に懸念があります。

@ctolkien

できません-2.0がドロップしてから1年はサポートされていません(2.0が次のLTSであると仮定します)。

2.0が低下しても、サポートが停止していないと少しの間想定します。 それで十分ではありませんか?

ただし、ASP.NET Core 1.xのサポートが終了し、現在サポートされていないフレームワークパーツを使用した移行パスがない場合、発生したくないことの1つは問題が発生することです。

その文の1.xを2.xに置き換えます。 1年以内にすべての依存関係が移植されると思いますか?

その文の1.xを2.xに置き換えます。 1年以内にすべての依存関係が移植されると思いますか?

ただし、まったくそうではありませんが、.NET Fullをターゲットにできなくなった場合は、ターゲットになると思います。 なぜそれを押し上げたいのかは理解できますが、不足している依存関係が移植されていないため、新しいバージョンに移行する手段がなく、サポートから外れるものを企業が採用することは期待できないと思います。

欠落している依存関係が移植されていないため、新しいバージョンに移行する手段がなくてもサポートから外れるものを企業が採用することは期待できないと思います。

なぜサポートから外れるのでしょうか? 私の架空の世界では、.NETFrameworkでASP.NETCore1.xをより長くサポートすることになります。

なぜサポートから外れるのでしょうか? 私の架空の世界では、.NETFrameworkでASP.NETCore1.xをより長くサポートすることになります。

私の質問はどれくらい長いですか? また、チームは、SignalRやODataなどの必要な依存関係をASP.NET Core 1.xに持ち込み、不足しているすべての依存関係が実際に移植されるまでサポートを維持するのに十分な大きさですか? なぜ今.NETフルサポートをやめたいのかについて以前に行われた議論に反しているようです。 正直な質問...

私の質問はどれくらい長いですか? また、チームは、SignalRやODataなどの必要な依存関係をASP.NET Core 1.xに持ち込み、不足しているすべての依存関係が実際に移植されるまでサポートを維持するのに十分な大きさですか? なぜ今.NETフルサポートをやめたいのかについての早い段階での議論に反しているようです。 正直な質問...

3年の乱数を捨てます。 ASP.NETチームはOdata統合を所有していませんが、odataチームは所有しているため、私はそれらに答えることができません。 SignalRに関しては、ASP.NETCore1.xをターゲットにすることは可能だと思います。

私が見ている問題は、各人が異なる「依存関係の欠如」のセットを持っているため、すべての人の.NETFrameworkサポートを削除しても「大丈夫」であるかどうかを判断できないことです。 また、これらの依存関係の一部は移植されない可能性があります(CSOMなど)。
もちろん、1.xトレインを使用していると、バグ修正とマイナーな機能を利用できますが、作業の大部分はASP.NETCoreの最新のメジャーで引き続き行われます。

また、これにより、ASP.NETCore1.xで.NETCore2.0または.NETStandard2.0を使用できなくなることもありません。 このスレッド定数はASP.NETCoreを.NETCoreと統合するため(これが.NET Coreのみを対象とする理由の1つです)、すべての人がそのことを認識していることを確認したいと思います。

私が見ている問題は、各人が異なる「依存関係の欠如」のセットを持っているため、すべての人の.NETFrameworkサポートを削除しても「大丈夫」であるかどうかを判断できないことです。

エコシステムを利用して、リストが何であるかを調べます(いいえ、この問題はそれを行う場所ではありません)。 Microsoftが所有する依存関係の場合は、移植します。 そうでない場合は、所有者に連絡して計画を通知し、移行ガイドを支援します(何もしない場合は、Microsoftの責任ではありません)。 このプロセスを実行するのにかかる時間内に、ASP.netコア1.xをサポートします。 多くの人々を動揺させずにあなたの目標を達成する他の方法を私は見ることができません。 これは提案されている大きなことであり、正しく行うには高度な注意と注意が必要です。

個人的には、.NETFrameworkと.NETStandardと.NETCoreの方がはるかに混乱していると思います。 .NET Frameworkをターゲットにできることを知ったとき、「しかし、これはASP.NET Coreなので、なぜ.NETFrameworkを使用できるのか」とは言いませんでした。 上記の違いは、ほとんどの顧客ベースにとってはるかに混乱を招きます。 ASP.NETCoreが行っているすべてのことが大好きです。 また、プラットフォームの独立性に関する.NETの方向性も気に入っています。 混乱の領域が間違って述べられていると思います。 あなたのユーザーベースの大部分は、それが行っていることの性質とフレームワーク内でターゲットにしているAPIのために、移植性のないコードをいくらか持っていると思います。

私の好みは、.NETCoreと.NETStandardおよび.NETFramework内のAPIパリティに向けて作業することです。 また、人々がターゲットにしようと努力すべきものを見つけます。 先に述べたように、おそらく少し異なる方法で、.NETStandardはバンドエイドのように感じます。 最終的には、.NET Coreが唯一の「フレームワーク」オプションになると思います。その場合、.NETFrameworkと.NETStandardは道に迷います。 私自身、そして発表以来発言してきたほとんどの人と一緒に、ASP.NET Core側で行っている作業の恩恵を受け続け、コードを実行する自由を持たないようにしたいと思います。削除されます。

私がWMIのようなものに依存している私のように、例外的と見なされているケースは、チームが考えるほど例外的ではないと思います。 繰り返しになりますが、私は調査を行い、何が欠けているかを確認します(ただし、以前に誤った移植性の結果を示した投稿では、精度について少し心配しています)。それをよりプライベートな媒体で喜んで報告します。

結論として、私たちはこれを使いたいので、これに情熱を注いでいます。

個人的には、.NETFrameworkと.NETStandardと.NETCoreの方がはるかに混乱していると思います。 .NET Frameworkをターゲットにできることを知ったとき、「しかし、これはASP.NET Coreなので、なぜ.NETFrameworkを使用できるのか」とは言いませんでした。 上記の違いは、ほとんどの顧客ベースにとってはるかに混乱を招きます。 ASP.NETCoreが行っているすべてのことが大好きです。 また、プラットフォームの独立性に関する.NETの方向性も気に入っています。 混乱の領域が間違って述べられていると思います。 あなたのユーザーベースの大部分は、それが行っていることの性質とフレームワーク内でターゲットにしているAPIのために、移植性のないコードをいくらか持っていると思います。

私たちにはたくさんの顧客がいて、人生で.NETを見たことがない新しい開発者がいます。 マイクロソフトとしてやろうとしていることなので、すべての人に対応する必要があります。 .NET Frameworkを実行している人々は、それが機能することを知っており、愛し、理解しているので、ASP.NETCoreが.NETFrameworkで実行されていることを理解してください。ただし、プラットフォームにアプローチする新しい開発者として、 gonodeのようなもの(この時点ではほとんどレガシーがありません)。

私の好みは、.NETCoreと.NETStandardおよび.NETFramework内のAPIパリティに向けて作業することです。 また、人々がターゲットにしようと努力すべきものを見つけます。 先に述べたように、おそらく少し異なる方法で、.NETStandardはバンドエイドのように感じます。 最終的には、.NET Coreが唯一の「フレームワーク」オプションになると思います。その場合、.NETFrameworkと.NETStandardは道に迷います。 私自身、そして発表以来発言してきたほとんどの人と一緒に、ASP.NET Core側で行っている作業の恩恵を受け続け、コードを実行する自由を持たないようにしたいと思います。削除されます。

これらはすべて並行して発生します。 ASP.NET Coreは、「すべて」が.NETFrameworkから.NETCoreに移植されるまで、機能の動作を停止しません。 ASP.NETは、同じボックスの一部として出荷されるため、.NETCoreで利用可能なAPIの革新と活用を継続します。

私はこのスレッドでいくつかのトレンドのアイデアを以下から見ています:

  • .NETFrameworkを永遠にサポートしてほしい。
  • アプリケーションに必要な依存関係が移植されるまで、.NETFrameworkをサポートしてほしい。
  • あと1年必要です。それで、.NET Frameworkサポート(ASP.NET Core 3.x)を削除するのに十分な時間になります。

私たちが発表を書かなかったという事実もありますが(これは私たちのせいです)、発表が来ています(私は約束します、私は週末を非難します)。

また、ここのほとんどの人にとってAPIパリティがどのように見えるかはわかりません。おそらく、人によって異なると思います。 .NET Frameworkは、Windowsに関連付けられた15年以上前の堅固で信頼性の高いエンタープライズテクノロジです。
.NET Coreは、最新の軽量クロスプラットフォームマイクロサービスを作成するために作成されましたが、ライブラリの移植が容易になるように、互換性が向上するように徐々に進化してきました。 とはいえ、互換性の観点から.NET Frameworkにアプローチすることの意味や、それが目標であるかどうかはわかりません(元々はそうではありませんでした)。 ある時点で、.NETFramework上でASP.NETCoreを使用できなくなり、.NETCoreと互換性のない書き換えできない依存関係が存在するようになります。 アプリケーションは、ASP.NET Coreを念頭に置いて設計する場合(近い将来)、それを考慮する必要があります。

私が取り組んでいるプロジェクトに関しては、1.1のサポート期間がはるかに長いほど、適切な緩和策になります。 1年でnetfxの依存関係を削除できる可能性は低いですが、ストローマンとして提案した+3年ではるかに可能性が高くなります。 ただし、最初にすべてが2.0レベルでまとめられるリリースがあると、本当に便利です。これが、すべての移植が容易になるはずだったポイントです。 私が話しているのは1つの組織だけですが、「2.0はLTSリリースになり、3.0はnetfxを削除します」は、FUDの原因ではなく、基本的に通常どおりのビジネスになります。

また、 @ PureKromeがこのエンゲージメントを評価することについて言ったことをエコーし​​たいと思います。これは、非常に有益な議論でした。

パリティのトピックについて-私は以前、.netコアが.netフレームワークレベルの互換性に近づくことはないと想定していましたが、 asp .netコアは引き続き両方をサポートするため、これは問題ありませんでした。

コミュニティとして、私たちは基本的にasp.netコアを使用するために.netコアを使用していると思いますが、それ自体のメリットではありません。 あなたが言ったように、それらは1つの製品であり、コアclrは、選択した場合に利点と欠点を備えたその製品のオプション部分と考えていました。

一晩寝た後-

個人的には、古い.netフレームワークを残して、最新のランタイムに最適なWeb​​フレームワークを作成することをお勧めします。

しかし、それは間違いなく危険であり、途中で顧客の一部を失う可能性があることを知っています(私はそうしないことを望んでいます-しかし私は多くのコンサルティングを行います-そして.NETCoreは現在手の届かない多くの企業のためのものです-2.0を期待しましょうそれを変更します)。

..そしてそうです-これに関するコミュニケーションは(いつものように)あなたが改善できる何かでした(ドイツ語のためのこの文の最も丁寧なバージョン);)

+1

個人的には、古い.netフレームワークを残して、最新のランタイムに最適なWeb​​フレームワークを作成することをお勧めします。

私は強く同意します。 私の望みは、これが段階的な変更であったことです。たとえば、Kestrelが最初にperfのサポートを終了し(http.sysベースのホスティングが残っています)、次にmvc / *が続き、APIと機能の改善が行われ、netstandard2.0の移植/互換性テストの取り組みが始まります。

優れた。 その場合、Microsoftが1.xがサポートされていること(あらゆる種類のバグ修正と運用サポート)が顧客に適切な2.x移行パス(SignalRなど)を提供するまで保証している限り、私は時間を快適に入札できますasp.netコア2が必要になるまで。

+1

.NET Coreにのみ移植できます(フルフレームワークでのASP.NET Coreの開発中に、例として移植されることのないいくつかの新しい依存関係を取得した可能性があります)。

完全に同意する。
今のところ、それは良い決断だと思います。 理想的なシナリオでは、コミュニティの信頼のために、1年以上のサポート、おそらく2〜3年のサポート、および移植されるものに関する情報が必要だと思います。
.net461はサポートされていません。

@dasMulli

私は強く同意します。 私の望みは、これが段階的な変更であったことです。たとえば、Kestrelが最初にperfのサポートを終了し(http.sysベースのホスティングが残っています)、次にmvc / *が続き、APIと機能の改善が行われ、netstandard2.0の移植/互換性テストの取り組みが始まります。

.NETFrameworkでパフォーマンステストを実行することすらありません...移植テストと.NETCoreおよび.NETStandardの改善はとにかく行われ、IMOは.NETFrameworkのサポートが廃止されるかどうかには関係ありません。 どちらかといえば、それ唯一のターゲットであるため、これらのシナリオにレーザーで焦点を合わせることができます。

@gulbanana

ただし、最初にすべてが2.0レベルでまとめられるリリースがあると、本当に便利です。これが、すべての移植が容易になるはずだったポイントです。 私が話しているのは1つの組織だけですが、「2.0はLTSリリースになり、3.0はnetfxを削除します」は、FUDの原因ではなく、基本的に通常どおりのビジネスになります。

なぜASP.NETCore2.0が必要なのですか(.NETStandardと.NETCore 2.0を忘れてください)?

asp.netコア2.0の機能は特に必要ありません。 2.0ウェーブに付属するよりシンプルなビルドプロセスと相互運用機能が必要です。netcoreapp2.0で実行している場合、asp.netコア1.1はnetstandard2.0ライブラリを使用できますか? それは、誰もテストしたり注意を払ったりするものではなく、「標準」でサポートされているシナリオと見なされますか?

基本的に、1.1がLTSになった場合、18か月後に「まあ、2.0apiを使用してこれを行うことができます」という問題が解決されるのではないかと心配しています。

asp.netコア2.0の機能は特に必要ありません。 2.0ウェーブに付属するよりシンプルなビルドプロセスと相互運用機能が必要です。netcoreapp2.0で実行している場合、asp.netコア1.1はnetstandard2.0ライブラリを使用できますか? それは、誰もテストしたり注意を払ったりするものではなく、「標準」でサポートされているシナリオと見なされますか?

もちろん、それはうまくいくでしょう。 私がずっと言ってきたように、3つのことは今日完全に切り離されています。 .NET Standard2.0パッケージに移植されたバージョンのSystem.ConfigurationAPIを使用して、.NETCore2.0上でASP.NETCore1.1を実行しているサンプルプロジェクトを次に示します。

https://github.com/davidfowl/AspNetCore1OnNetCore2

.NETCoreと.NETFrameworkの間に自動相互運用レイヤー(実行時に例外をスローできる現在のレイヤーではなく、自作の内部WebAPI呼び出しではない)があれば、これを受け入れるほうが幸せです-ある種のラッパー("WowNET"?)これにより、4.6に依存するコードを別々の.dllに保持する必要がありますが、パフォーマンスを犠牲にしてレガシーを実行できます(LOBアプリの場合は主な関心事ではありません)。 これは技術的に可能だと思いますか?

また、この変更は、完全なフレームワーク自体がサポート終了に近づいており、ほとんどのAPIが.NET Standardに移行された後は、レガシーコンポーネントである以外の重要な役割を果たさないことを意味するのではないかと思います。

基本的に、1.1がLTSになった場合、18か月後に「まあ、2.0apiを使用してこれを行うことができます」という問題が解決されるのではないかと心配しています。

それは常に懸念事項です。 答えは常に「状況によって異なります」です。 それに応じてバグ修正が検討され、大きな機能がそのバケットに分類されることがよくあります。

@rohatsu

.NETCoreと.NETFrameworkの間に自動相互運用レイヤー(実行時に例外をスローできる現在のレイヤーではなく、自作の内部WebAPI呼び出しではない)があれば、これを受け入れるほうが幸せです-ある種のラッパー("WowNET"?)これにより、4.6に依存するコードを別々の.dllに保持する必要がありますが、パフォーマンスを犠牲にしてレガシーを実行できます(LOBアプリの場合は主な関心事ではありません)。 これは技術的に可能だと思いますか?

このようなhttps://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-rootですが、.NETCoreと.NETFramework用です。 ASP.NETがHeliosをサポートしたとき、私たちは非常に似たようなことをしました。Heliosは、IISでcoreclrをブーストラップするために使用された.NETFrameworkシムです。 それを機能させるためのハックは、COMとstring [] argsを介してMainメソッドに構造を渡すことの組み合わせでしたが、かなり醜いものでした。 ただし、すべて技術的に実現可能です。 それらは同じランタイムではなく、オブジェクトを前後に渡すことができないため、どのような忠実度を期待できるかわかりません。 また、同じプロセスで2つのGC、2 Jitsトン以上のdllを実行していることになりますが、procから何かを実行することで何が得られるのかわかりません。

また、この変更は、完全なフレームワーク自体がサポート終了に近づいており、ほとんどのAPIが.NET Standardに移行された後は、レガシーコンポーネントである以外の重要な役割を果たさないことを意味するのではないかと思います。

から遠い。 .NET Frameworkは、Windowsコンポーネントであるため、Windowsのペースで進化し、出荷されます。 .NET Framework 4.7(https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/)と、多数の新機能をリリースしました。 実際のところ、.NET Coreは他に何も関連付けられていないため、出荷が速くなり、出荷も速くなります。そのため、API、ランタイム機能などが最初に表示されます。 物事が最終的に.NETStandardおよび.NETFrameworkに移行しないという意味ではありません。 そこにたどり着くまでにもっと時間がかかります。 .NET Frameworkがインプレースで更新されるという事実が、変更を移植する際に非常に注意を払っている理由です。 更新が10億台のマシンに自動的にプッシュされると、変更によってアプリケーションが破損する可能性があります😉。 .NET Coreでは、フレームワークが並んでいるため、アプリケーションは新しい機能や修正を取得するために新しいバージョンにオプトインする必要があります。 そこにはもっとたくさんの自由があります。

現在ASP.NETCore1.xで使用しているnet4xライブラリを比較検討すると、2.0では機能しません。EntityFramework6。EFCoreには、不足している多くの機能(たとえば、インターセプト/ライフサイクルフック)があります。 そのため、しばらくの間EF6で立ち往生しています。

また、@ PinpointTownesの投稿によると、 EF6は現在の(開発中の)バージョンのASP.NETCore2.xでは動作しません。

@nphmullerの場合、依存関係が移動するまでASP.NET Core 1.xを使用し続けます(EF Coreに必要なものの数と、ステータスはわかりません)。

@davidfowl確かに、ASP.NETCore1.xからのサポートウィンドウがその時間内に通過しない場合。
主な機能はインターセプト(ライフサイクルフック)です。 その他の不足している機能は、より簡単に回避できます。 インターセプトはバックログにありますが、リリースに結び付けられていません。 そして、私の腸は、それがしばらくの間実装されないだろうと私に言います。

@gulbanana :コミュニティとして、私たちは基本的にasp.netコアを使用するために.netコアを使用していると思いますが、それ自体のメリットではありません。

自分で話してください。 .NET Coreの主な利点は、サーバー上のWindowsから離れることです。

そして、私はあなたがマックを所有しているヒッピーを汚していると思います。 😝

@bradwilsonそして、私は、あなたがマックを所有しているヒッピーを汚していると思います。

自分で話してください、私たちの何人かはヒッピーではありません; P

しかし、はい、Windows(または実際にはIISとhttp.sys)をエスケープすることは、xcopyの展開やパフォーマンスなどと一緒に.NETCoreが必要なことです。

古いコードを別のサービスに分離したり、ASP.NET Coreに移植したりすることは、新しくて輝かしい以外の理由で報われます。

@PinpointTownesは参照エラーです。https: //github.com/aspnet/Home/issues/2022#issuecomment -299810945に従ってSystem.Configurationを参照するとどうなりますか? EF6は、すべてが古いGAC /フルフレームワークバンドルに含まれているため、依存関係がないと述べています

@benaadams@PinpointTownesが失敗する理由は、System.Configuration.ConfigurationManagerが.NETFrameworkが期待するDLL名ではないためです。 System.Configurationのポートが有効かどうかわかりません。

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

はい、Windows以外のサーバーを実行できることは素晴らしいことであり、大きな魅力です。しかし、asp.netコアがなければ、それらのサーバーで何を実行ますか? Nancy for .netコアでさえ、kestrel、UseOwin()などを介してasp.netコアに依存しています。

ASP.NETCoreを使用しないマイクロサービスをいくつか作成しました。 それらは、キューをポーリングして作業を行うワーカープロセスのようなものです。

これは公平ではありません、私たちはロードマップに従います、そしてあなたはそれについて前に何も言わなかった!!
以前に言った場合、.NET 4.x Libが必要なため、プロジェクトではASP.NETCoreを使用しません。
新しい機能が必要なため、計画にはプロジェクトをASP.NETCore2に更新することが含まれます。
.NET4.xもターゲットにするためにASP.NETCore2が必要です。 不可能な場合は、ASP.NET Core 1.xのサポートについて、すべての新機能を追加する予定ですか、それともバグを修正するだけですか。

新しい機能が必要なため、計画にはプロジェクトをASP.NETCore2に更新することが含まれます。

どれ?

@PinpointTownesは参照エラーですが、#2022(コメント)に従ってSystem.Configurationを参照するとどうなりますか?

<Reference Include="System.Configuration" />を追加しても効果はありません(つまり、同じ例外がスローされます)。GACからは解決できないようです(本当に驚くべきことかどうかはわかりませんが)。

image

System.Configurationのポートが有効かどうかわかりません。

したがって、公式の結論は... System.Configurationを使用している場合、.NETCoreで.NETFramework 4.x用に作成されたライブラリを使用することはできませんか?

@PinpointTownes System.Configurationのバージョン(パッケージに含まれているもの)が出荷されているかどうかさえわかりません。 多分そうではないかもしれません(それはcorefxで始める議論です)。 私はあなたのサンプルがなぜそれがしたように壊れたのかをあなたに話しているだけです。

追加する GACから解決できないように見えるため、効果はありません(つまり、同じ例外がスローされます)(本当に驚くべきことかどうかはわかりませんが):

AFAIK、SDKプロジェクトでのGAC参照のデフォルトサポートはありません。 有効にする方法については、 https: //github.com/dotnet/sdk/issues/987#issuecomment-286307697を参照してください。

したがって、公式の結論は... System.Configurationを使用している場合、.NETCoreで.NETFramework 4.x用に作成されたライブラリを使用することはできませんか?

私の結論は、上記で提供したサンプルを使用してCoreFXで問題を開く必要があるということです。

@davidfowl返信ありがとうございます
EF Coreで必要ないくつかの機能とヘルパーは、特にマッピングデータ(自己完結型マッピング)のために2.0で計画されています...
とにかく、ASP.NET Core 1.xのロードマップについて明確に理解する必要があります。私たちのチームは混乱し、心配しています。

私が個人的に苦労していることの1つは、「安定したプラットフォーム」と「新機能」の違いです。 プラットフォームが安定していて信頼性が高く、互換性があることを望んでいる一方で、2.xの機能がないため、1.xを使い続けたいと思う人は誰もいません。 ASP.NET Core 2.xには、人々をその方向に引き寄せる非常に魅力的な機能がありますか、それとも1.xよりも多くの機能があるという事実だけですか(新しくて光沢があるため)?

@davidfowl signlarRはそのような機能の1つだと思います。少なくとも、以前のプロジェクトにはあったでしょう。 ただし、コアに切り替える準備ができるまで、つまり潜在的には何年も、そしてまた、人々を少し落ち着かせるパッチもカバーされています。

また、.netコア2.0でのasp.netコア1.1のサポートは、さらに強調する価値があると思います。それは、人々に(私が思うに)良い移行パスを提供します:asp.net 5 on 46> asp.net core 1.x on 46> .netコア2.0上のasp.netコア1.x>.netコア2上のasp.netコア2これは、多くの人が心配するリスクを軽減するパスになります。

私は初日からこれをフォローしていて、これらの議論と説明のすべての後でも( @davidfowlに感謝します)私たちの多くがバスの下に投げ込まれていると感じています。

フル/デスクトップ.N​​ETフレームワークから切り離す理由を理解しています。 地獄、私はそれがASP.NETに力を与える方法であることにさえ同意します、しかし私はこれが最初からではなく今どのように決定されているかを見ることができません。

もちろん、お客様はどちらのシナリオでも真剣に不満を言うでしょうが、私は「新しい光沢のあるものは使用できません」に賭けて、「使用できる、ゆっくりと移行して、可能な場合は交換する」に賭けるよりも、それが間違っていることを見つけてください。

これが最初からではなく、今どのように決定されているのかわかりません。

推測で:

.NET Core 1.xでは、フルフレームワークライブラリを実行できなかったため、完全に中断されていました。

.NET Core 2.xでは、ほとんどの場合、フルフレームワークを実行でき、.NET Standard 1.x-2.0ライブラリを実行できるため、大きな問題にはなりません。

.NET Core 2.0でのフルフレームワークライブラリの実行に関する問題は、おそらくdotnet/corefxに提出する必要があります。

主なシナリオが「クラウド上の最新のWebアプリ」であることは明らかです。これは、多くの場合、サードパーティの依存関係をあまり持たない(または「単なるコード」依存関係です)。

これまでの議論のほとんどはBCLの可用性に焦点を当ててきましたが、私たちの多くはサードパーティのコンポーネント(たとえば、複雑なビデオ、オーディオサブシステムとの低レベルの統合...)に依存しています。おそらくサポートされないであろう低レベルのテクノロジーに依存します。

ASP.NET Core 1を使用して、Libsの.NET標準を対象とし、サービスの依存関係ごとにFull.NETまたは.NETCoreに展開することを選択して最新のサービスを開発しています。

サポートされていない機能/コンポーネントを見つけた場合、Full .NETを簡単にターゲットにできるため、これに賭けることができます。 そして、Full .NETにとどまることが数年以内に避ける決定のように見えるので、賭けは長期的なプラットフォームにありました。

_.NET Core 2.xでは、ほとんどの場合、フルフレームワークを実行でき、.NET Standard 1.x-2.0ライブラリを実行できるため、大きな問題にはなりません。_

@benaadams BCLのほとんどを使用できることと、Full .NET用に構築されたライブラリを使用できること(および.NET Standard 2.0 /型統合でサポートされていない機能を内部的に使用できること)には大きな違いがあります。

この決定は、ASP.NET4からASP.NETCore 2.0への移行を容易にすることに影響を与えないと思いますか?
私が管理しているかなりの数のアプリケーションは、ASP.NET Core 2.0の更新から実際に利益を得ることができますが、ASP.NETCoreのOWIN/ Katanaサポートがないため、手動で移行する必要があり、それは非常に手間がかかります。 @damianhhttps://github.com/aspnet/AspNetKatana/issues/27で同様の提案をしました

EF6(空間用)およびディレクトリサービスが必要であり、SignalRが適切に待機しているため(現在はサポートされていないバージョンを使用していますが、機能します)、完全なフレームワークで実行しています。 私はしばらくの間他のブロッカーをチェックしていませんが、おそらくもっとあります。

私が理解しているように、これでasp.netコア2.0に移行して、出力時にSignalerを取得することがブロックされます。

dnx、RC1からRC2、プロジェクトjsonからcsprojまでずっと乗り続けてきましたが、ついに森の外にいるように感じました...今はそれほど多くはありません。

私はこの変更が最終的に来ることを理解できますが、これはasp.netコアが牽引力を獲得しようとしているときに本当にそれを行う時ですか? また、私の腸は、EFコアはまだ十分に成熟しておらず(そして確かに空間的にはそうではありません)、コアでのサポートに賭けている人は、ライブラリの移植に関してより多くのリスクを負っています....この移行のために別のバージョンを待っているようですこれにより、完全なフレームワークでシグナルrは言うまでもなく、EFCoreやその他のポートが追いつくための安定性とチャンスが得られます。

私は、企業のほとんどが完全なフレームワークでasp.netコア(ちなみに素晴らしい)を実行しており、私たちと同じような立場にある可能性があると思います。

このASP.NETCoreの高速トレーニングへの移行を考えると、LTSと現在のバージョンを導入することを意味しますか?また、このインスタンスでのサポートの長さはどのくらいですか?

私は、netfxで実行する必要のないグリーンフィールドソリューションに取り組んでいる幸運な例にいると思いますが、可能であれば、それは常に素晴らしいことでした。 私にとってブロッカーになるのは、netfxをターゲットにしているWindowsサービスだけですが、そのための計画があります。

この変化は間違った方向に進んでいるように感じます。 netstandardが追いつくまで、一部の機能はコア専用であることを理解しています。 しかし、このコアのみのルートを進むことは、破壊された生態系を作成するための滑りやすい坂道です。

この変更により、私が好きかどうかわからないという声明が出されます。netcoreappのみをターゲットにしても問題ありません。

私も自分の意見を書きたかった。

.netフレームワークを削除するのは時期尚早だと思います。 .netフレームワークと.netコアを一緒にサポートすることの問題はわかりませんが、この決定により、AspNetCoreへの移行が少し難しくなると思います。 一部の企業は次のように考えているためです。「AspNetCoreを.netコアで開始しましょう。深刻な問題が発生した場合(将来的に必要なライブラリがサポートしないなど)、いつでも.netフレームワークに戻ることができます」。 しかし、今ではそれはもはや不可能であり、企業はAspNetCoreから始めることを躊躇します。 また、この決定により、.netstandardの値が低くなる可能性があります。

@hikalkan

一部の企業は次のように考えているためです。「AspNetCoreを.netコアで開始しましょう。深刻な問題が発生した場合(将来的に必要なライブラリがサポートしないなど)、いつでも.netフレームワークに戻ることができます」。

ASP.NET Core 1.1はいつでも使用できますよね?

また、この決定により、.netstandardの値が低くなる可能性があります。

なぜそうなるのかわかりません。 前に述べたように、私たちのクロスカッティングライブラリは、すべての.NET実装で機能する必要のあるAPIだけでなく、.NET標準も対象としています。

もちろん、asp.netコア1.1を使用できます。 ただし、「ASP.NET Coreの最新バージョンは2.xですが、.net Frameworkをターゲットにする場合は、ASP.NETCore1.xを使用する必要があります」と言うのは良いことではありません。 これは、「MVC5.xを使用する」と言うのと大差ありません:)

.netコアは未来だと思いますが(未来ではなく、今でも!)、.netフレームワークを削除するのは簡単です(この決定は、.netフレームワークが廃止されているようにコミュニティによって理解されます)。

ASP.NET Core 1.1はいつでも使用できますよね?

明確なメリットはありません。 まず、まだ成熟していないので、賭けです。
第二に、ASP.Net Coreの開発者は、古いツールを作成して遅れをとることを望まないでしょう。
私はいくつかのことに興味があります。

  1. 私たちはすでにASP.NetCore、Dapperなどのグリーンフィールドプロジェクトで完全に取り組んでいます。
    しかし、他のプロジェクトでは、ビジネスロジックは4.6アセンブリにあります。 上で読んだように、それらを参照するのに問題はないはずです。 私はよく理解したと思います。
  2. SignalR。 DirectoryServices、MS Orleans、Azure。
  3. 上記の会話とは無関係かもしれませんが、UWPデスクトップアプリケーションまたはUWPのデスクトップブリッジとして、Kestrelまたはその他のHttpListenerを使用してASP.NetCoreをローカルでホストしたいと考えています。

お奨めは、私がこれに関するコミュニケーションにかなり失望していると言います。 私たちはその決定を受け入れることができると思いますが、それはどこからともなく生まれました。

7月に、私のチームは、ASP.NET Core 2.0で実行されるグリーンフィールド12〜18か月のプロジェクトの作業を開始し、.NETCoreで何年にもわたって読んできたすべての優れた機能を備えています。

ただし、当面の間は、ASP.NET MVC Core 1.0アプリを入手しました。これは、基本的に.NETFrameworkライブラリを呼び出すためのラッパーとして機能するレガシー製品の中心です。

チームに、アプリをASP.NET MVC Core 2.0にアップグレードし、.NETFrameworkコンポーネントを交換するときに新しいアプリの一部にする計画であることを確認しました。 現在、プロジェクトを完了する前にEOLされるASP.NET MVCCore1.0で立ち往生しています。

私が意見を述べる直前に、私はある部分を明確にしたいと思います。
ASP.NET Coreを引き続き使用したい場合は、
.Net 4.5以降を対象とするdllを参照して、現在のように機能させることはできませんか?

@ louislewis2いいえ、それは正しくありません。 netstandard2.0のサポートされているAPIスペース内にある限り、 net45 - net461ライブラリを使用できます。 これらのライブラリを再コンパイルする必要はありません。

@bradwilson説明してくれてありがとう。 それはきっと今夜私をよりよく眠らせるでしょう。
ライブラリの多くは私たちの管理下にないので、それは大きな問題でした。

今とても安心しました:)

@shanselman @DamianEdwards @davidfowlまだ移植されていない、私たちが使用するアイテムのリストについては、system.managementdllのアイテムになります。 特にハードウェア識別子を使用します。これは、AzureServiceBusおよびライセンスサーバーとクライアントパッケージ全体の自動リンク生成に使用されます。 現在APIではないので、深刻な問題が発生するのではないかと思います。

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

これは、完全なフレームワークでいくつかのアプリを実行し続ける最大のホールドアップです。

これは私たちを厄介な状況に置きます。

私は、マイクロサービスをKestrel上でインプロセスのASP.Net 4.5(レガシー互換性の理由)から完全な自己ホスト型ASP.NetCore1.xに移植している最中です。 ただし、今のところ、これらを完全なフレームワークで実行する必要があります。 そして、それには正当な理由があります。

すでにインフラストラクチャの一部であり、変更される可能性のない、Windowsのハードな依存関係がいくつかあります。 これには、NTLM認証、イベントログログなどが含まれます。ASP.NetCore2.xがnetstandardサポートから脱却している場合は、まったく実行しない方がよいでしょう。 問題は、積極的に開発された完全なフレームワークの代替手段がないことです。 刀は死んでいて遅い(比較すると)。

誰かが私にKestrelfor.Net Frameworkと同じくらい高速なHTTPサーバーを教えてくれるなら、確かに。 しかし、それは存在しません。 したがって、ASP.Netがこの変更で私のような実際の本番環境の顧客を置き去りにしていることを受け入れる必要があります。

スタックにパイプラインやスパンなどのすべての新しい機能が必要な場合は、それらをnetstandardライブラリとして提供する必要があります。 netstandard2.0にないnetcoreapp2.0にあるASP.NetCore2.xが使用しているAPIは何ですか?また、それらのAPIをその間にnetstandard2.0拡張ライブラリにできないのはなぜですか?

MSは、すべてのフレームワークで(ネット)標準に2年間取り組んで、この標準を使用しないフラッグシップ製品を好転させてリリースしただけだと真剣に言っていますか?

この問題のため、GitHubチームは問題セクションにページネーション機能を追加すると思います。

@mattnischan

私は、マイクロサービスをKestrel上でインプロセスのASP.Net 4.5(レガシー互換性の理由)から完全な自己ホスト型ASP.NetCore1.xに移植している最中です。 ただし、今のところ、これらを完全なフレームワークで実行する必要があります。 そして、それには正当な理由があります。

ASP.NET Core 1.xを使い続けることができますか?

スタックにパイプラインやスパンなどのすべての新しい機能が必要な場合は、それらをnetstandardライブラリとして提供する必要があります。 netstandard2.0にないnetcoreapp2.0にあるASP.NetCore2.xが使用しているAPIは何ですか?また、それらのAPIをその間にnetstandard2.0拡張ライブラリにできないのはなぜですか?

.NETFrameworkにないAPIが.NETStandardに表示される場合、どのように使用しますか?

@ stefan2410

その権利のためにASP.NETCore1.xを使用できますか? どのASP.NETCore2.0機能が必要ですか? SignalRだけですか?

今後2年間はアプリをそのままにしておきますが、完了したら.NETFrameworkライブラリを同等の.NETCoreライブラリと交換します。 これにより、2つのアプリ間でビジネスロジックなどを共有できます。
2018年7月がASP.NETMVCCore 1.0サポートの締め切りであるため、これを行うことはできません。

繰り返しになりますが、私の架空の世界では、1.xの寿命を延ばします

アプリをASP.NETMVCCore 2.0にアップグレードし、.NETFrameworkコンポーネントを交換するときに新しいアプリの一部にします。
Core2.0は.NETFrameworkをサポートしていないため、これも実行できません。そのため、すべてまたはまったくサポートされていません。

実際にASP.NETCore2.0が必要ですか? それとも.NETCore2.0だけですか?

.NETFrameworkにないAPIが.NETStandardに表示される場合、どのように使用しますか?

私たちの計画は、彼らその中に入るまで待つことでした。 先ほどおっしゃいましたが、それは時間の問題ですよね? 安定性のために、最先端を一定量遅らせることは問題ありませんでした。 少なくとも、永久に遅れるよりもはるかに優れています。

@davidfowl
ASP.NetCore2.0に移行します。 他に解決策はありません。 チームに進化の背後にとどまるとは言えません。ASP.NetCoreを長い間待っていました。
ビジネスロジック4.6アセンブリの参照に問題がない限り。
SignalR、DirectoryServicesが必要ですが、Azure / Amazonライブラリ、MSOrleansの問題ではありません。
また、上記の会話とは無関係かもしれませんが、デスクトップアプリで、Kestrel/HttpListenerを使用したASP.NetCoreをUWPデスクトップアプリケーションまたはUWPのデスクトップブリッジとしてローカルでホストする必要があります。
XAMLのコードを書き直すことはできず、Electronを使用したくありません。

ASP.NET Core 1.xを使い続けることができますか?

どのような時間枠で? イベントログのようなものがnetstandardに到達しているのがわかりません。

.NETFrameworkにないAPIが.NETStandardに表示される場合、どのように使用しますか?

これは事ですか? ドキュメントによると、netstandard20はまだnet461で実行されているようです。 netstandard20のAPIは、新しい機能を実装するのに十分なほど完全ではないと言っていますか? または、まだ公表されていないフレームワークを超えてネットスタンダードを移動する計画はありますか?

私たちの計画は、彼らがその中に入るまで待つことでした。 先ほどおっしゃいましたが、それは時間の問題ですよね? 安定性のために、最先端を一定量遅らせることは問題ありませんでした。 少なくとも、永久に遅れるよりもはるかに優れています。

ライブラリは、標準の上に書くことができます。 標準自体を変更する必要がある場合、.NETFrameworkを含むすべての実装で採用されるまでにかなり時間がかかります。 それはいくつかのことを意味する可能性があります:

  • .NET Standardは、最も遅い実装の速度で進化します
  • .NET Standardは他のペースで進化し、.NETFrameworkが最後に追いつくでしょう。

もちろん、ライブラリを作成できないという意味ではありません。サポートする.NET Standardのバージョンを選択する際に、これらの警告を考慮する必要があるということです。

また、上記の会話とは無関係かもしれませんが、デスクトップアプリで、Kestrel/HttpListenerを使用したASP.NetCoreをUWPデスクトップアプリケーションまたはUWPのデスクトップブリッジとしてローカルでホストする必要があります。

UWP上のASP.NETCoreは現在ロードマップに含まれていないため、ここで何が起こるかを実際に言うことはできません。 HttpListenerは.NET Standard 2.0の一部ですが、機能する可能性があります。

ここでのコメントとフィードバックに感謝します。 今後の方向性を理解する間、私たちは本当にそれとあなたの忍耐に感謝します。 この変更がそれほど難しく、遅く、警告なしに行われることを意図していなかったことをご承知おきください。 後知恵は20/20であり、私たちが今知っていることを知っていれば、もっと早く物事を伝えていただろう。 今後も頑張っていきます。

ここで受け取ったフィードバックに基づいて計画を立てており、今週後半に2.0.0-preview1リリースで発表として投稿する前に共有したいと思います。 それが起こったとき、私たちはその計画に関する議論を容易にするために新しい問題を開きますが、今のところ先に進んで、ここであなたの考えとフィードバックを共有し続けてください:

  • .NETFrameworkでのASP.NETCore1.xのサポートは、少なくとももう1年間(2019年7月まで)延長されます。 これを毎年再評価し、ASP.NET Core 1.xのサポートを終了する前に12か月前に通知することを約束します(したがって、2018年7月までに、2020年7月までさらに12か月延長するかどうかを発表します)(補足: 2020年についてすでに話しているという事実に、他の誰かがびっくりしましたか?いいえ?わかりました、私だけです。
  • 新しいSignalRは、ASP.NET Core 1.x(今年後半にリリース予定)を対象とし、完全にサポートされます。
  • System.Webの場合と同様に、ASP.NETCore1.xを引き続き更新して新しい言語バージョンなどをサポートします。
  • .NETCore1.xで実行されているASP.NETCore1.xは、2018年7月までサポートされます(変更なし)
  • .NETFramework上のASP.NETCore1.xがサポートされている限り、.NETCore2+で実行されているASP.NETCore1.xがサポートされます。

    • これは、.NET Frameworkでの実行をサポートしている間、サポートされているASP.NETCoreとサポートされている.NETCoreが常に重複するようにするためです。これにより、お客様は、サポートされているビットを維持しながら、時間をかけて移植できます。

  • .NET Core 1.xのサポート(ランタイムとして)は変更されません。 2018年7月に終了します。ASP.NETCore1.xを実行しているお客様は、その時点で.NET Core 2.0に移行するか、.NET Frameworkを使用する必要があります(または.NETCore2.0のASP.NETCore2.0に移行する必要があります)。
  • 今年System.DirectoryServicesSystem.Drawingを.NET Coreに移植します(完全にサポートされ、クロスプラットフォームで、少なくとも夏のWindowsのプレビュー)
  • その後.NETCoreに移植するもののリストには、現在ServiceBaseが含まれています(.NET Core Windowsサービスをサポートするため)。 次のタイムライン以外のタイムラインはまだありません(リストを下に進むにつれて、タイムラインは明らかに具体的になります)。 お客様のフィードバックに基づいて、このリストに基づいて作成します。
  • 現在、 System.ServiceModel (サーバー側のWCF)を.NETCoreに移植する予定はありません。 WCF for .NET Coreは引き続き拡張され、HTTPメッセージ暗号化などのフィードバックに基づいて機能が追加される可能性があります。

@DamianEdwards @davidfowl問題の大部分は、多くの組織が移行できないASP.NET Coreへの移行にコミットするための莫大な機会費用を犠牲にしながら、計画と開発に数か月かかる可能性があることです。 .NET 4.xは、システムのすべての依存関係を実行できることが保証される唯一のプラットフォームであるためです。

これまで、MSはASP.NETの将来として.NET Coreを積極的にマーケティングしてきましたが、ASP.NET 4.xの開発が停止したかどうか、および将来の開発努力がすべてASP.NETCoreに投資されるかどうかは不明です。システムを最新の状態に保つために、多くの移行が進行中です。 多くの人々は、すべての努力の結果、EOL化されたプラットフォームに効果的に移行した場合、バスに投げ込まれたように感じるでしょう。 これは、組織と、.NETCoreへの移行を開始するための最大のチャンピオンであった開発者/コンサルタントの両方を傷つけます。 彼らは今ASP.NETCore2.0から何も必要としないかもしれませんが、彼らは間違いなく彼らのシステムのためにいくらかのヘッドルームを持ち、すべての努力のためにいくつかの新機能にアクセスできることを望んでいます。

また、IMOが.NETの最大の資産の1つと見なされるべきときに、既存の「レガシー」コードが責任と見なされる理由もわかりません。既存の.NETライブラリを実行できなかった場合、.NETCoreはそれほど魅力的ではありません。 。 Javaは、言語自体に固有の弱点よりも重要なJVMの大規模で安定したエコシステムのため、依然として非常に強力です。

MSが.NET4.xのサポートを終了したことによる反発を感じ始めたとは思いませんが、発表されるまで広く知られることはありません。GitHubでの開発に積極的に取り組んでいるほとんどの開発者は、新しい機能を見ることにもっと興味を持っていると思います。それらは相互運用性があり、既存のコードベースのスムーズな移行パスがあることを保証します。 非常に驚きますが、発表された後、この決定から熱が出なければ、それによって多くの人が傷つくことはないかもしれないので、それは正しいものかもしれません。

ASP.NET Core 2.0の安定した/互換性のあるリリースに焦点を合わせてから、後続のバージョンの.NET Coreのみの将来を発表するのは大変な労力でしょうか? まったく予期していなかったことを考えると、この状況で行うのは公正なことのように思えます。

@DamianEdwardsアップデートと明確な計画に感謝します。 私はそれに同意しませんが、それでもあなたがそれをレイアウトしてくれたことに感謝します。

ここにはまだ大きな根本的なギャップがあります。 1.xへの移植はほぼ完全に横方向の移植であり、私たちにとってはいくつかの機能があります。 2.xはいくつかの価値のあるアップグレードがある場所であり、私たちはまだその動きをすることができるという保証はありません。 フレームワークに完全に依存しているため、1.xに移植するためにかなりの時間、お金、労力を費やして、そこで立ち往生する可能性が高くなります。 私は私たちの会社とそのギャンブルをしません。 ASP.NET4.xよりもサポートが少なくなる可能性があります。

それが変更されない限り、私たちのアプリはASP.NET Coreにアクセスすることはなく、ドッグフーディングが不足しているため、すべてのライブラリがはるかに悪化します。

この決定を再考していただきたいと思います。 いつの日か、StackOverflowが.NETCoreプラットフォームの開発に費やした数千時間の個人的な時間を活用できるようになることを願っています。

@NickCraver

フレームワークに完全に依存しているため、1.xに移植するためにかなりの時間、お金、労力を費やして、そこで立ち往生する可能性が高くなります。

このスレッド全体を通して、コアなものの1つとしてSystem.DirectoryServicesを呼び出しました。 移植されるまでに長い時間がかかると思われる依存関係や、移植されない依存関係があると思います。 2.0がサポートされている.NETFrameworkの場合、これらの依存関係は1年で移動しますか?

2.xはいくつかの価値のあるアップグレードがある場所であり、私たちはまだその動きをすることができるという保証はありません。

どれ? 移行を容易にするために、重要性の高いものをASP.NET Core 1.1にバックポートすることについて話し合っていたので、知っておくとよいでしょう。

それが変更されない限り、私たちのアプリはASP.NET Coreにアクセスすることはなく、ドッグフーディングが不足しているため、すべてのライブラリがはるかに悪化します。

stackoverflow.comについては何も知りませんが、ASP.NET Coreを一部の部分に使用できるように、断片を分割することは可能ですか(「マイクロサービス」とは言いたくない)。

@mythz

これは、組織と、.NETCoreへの移行を開始するための最大のチャンピオンであった開発者/コンサルタントの両方を傷つけます。

ASP.NET Coreのことですか? または.NETCore?

@davidfowl私はASP.NETCoreを意味しましたが、最初にASP.NET Core / .NET 4.xから、後で.NETCoreから段階的に移行することを計画していた開発者にも影響します。

そういえば、ASP.NET Core /.NETCoreにはSAMLを処理するためのライブラリがないことに気づきました。 サードパーティのIdPを介してSSOを処理する必要がありますが、それが可能かどうかはわかりません。

@davidfowl私はASP.NETCoreを意味しましたが、最初にASP.NET Core .NET 4.xから、後で.NETCoreから段階的に移行することを計画している開発者にも影響します。

なぜそうなるのかわかりません。

私の組織がプラットフォームから離れることを避けるには、おそらくその計画で十分だと思います。 主なことは、残りのnetfx depsを書き換えたり、その他の方法で削除したりできるサポート(=セキュリティパッチ)の期間を長くすることです。 しかし、それはまだ一種の危険であり、概念的には奇妙です。 3年後、Excelドキュメントを取り込むことができるWebサイトを構築したり、アプリにWebサーバーを埋め込んだりしたい場合はどうなりますか? netcoreappの代わりに標準の上に構築されているOrleansのような他のフレームワークはどうなりますか?

ASP.NET Coreが実際に使用するのに十分ではないのに、なぜnetstandard2.0でこれほど多くの作業が行われたのか、私は真剣に理解していません。

3年後にExcelドキュメントを取り込むことができるWebサイトを構築したい場合はどうなりますか

言いにくい。 それを所有しているチームについて話すことはできませんが、.NET Coreに移植され、クロスプラットフォームで動作する可能性があります。

または、アプリにWebサーバーを埋め込むには?

HttpListenerはnetstandard2.0の一部です。

netcoreappの代わりに標準の上に構築されているOrleansのような他のフレームワークはどうなりますか?

.NET Framework、UWP、.NET Core、monoなどで実行するかどうかを決定するのはフレームワーク次第です。それは選択です。 Orleansには.NETCoreは付属していません。 ASP.NETCoreはそうします。 それらの製品は同じものです。

私たち(そして私たちのクライアント)にとって難しい決断は、私が現在持っている図書館ではなく、6か月後に必要かどうかわからない図書館です。 netstandardまだサポートしていないライブラリとフレームワークのロングテールがあります。 たとえば、プロジェクトの1か月後に、EF Coreはもちろん、EF6では近くにないNHibernateの機能がいくつか必要であることに気付きました。 では、そこでの私のオプションは何でしょうか?完全な.NETでASP.NET Core 1.xをターゲットにしますか?

将来的にはApiPortを持っているようです。

では、そこでの私のオプションは何でしょうか?完全な.NETでASP.NET Core 1.xをターゲットにしますか?

はい。

言いにくい。 それを所有しているチームについて話すことはできませんが、.NET Coreに移植され、クロスプラットフォームで動作する可能性があります。

そうですが、移植されていない可能性のあるライブラリのエコシステムへのアクセスを提供する価値があるかどうかを判断するのは、確かにasp.netチームの権限の範囲内です。

そうですが、移植されていない可能性のあるライブラリのエコシステムへのアクセスを提供する価値があるかどうかを判断するのは、確かにasp.netチームの権限の範囲内です。

.NETは古くて大きく、ASP.NETチームが.NETエコシステムに存在するライブラリの息吹に話しかけることを期待できない方法はありません。 それは非現実的です。 このスレッドの一部としてCSOM(https://msdn.microsoft.com/en-us/library/office/jj163123.aspx)が何であるかを知りました。移植されるとは思えませんが、もちろん。

.NETFrameworkでのASP.NET1.1のサポートを拡張すると、これを少し軽減できますが、.NETCore上のASP.NETCoreに適切に移行するには、一部の依存関係を分離する必要があるため、これも役立つと思います(これは将来の予定です)。

その点はすでに詳細に議論されているので、私は図書館を脇に置きます。 私たちの場合(amilia.com、eコマースSaaS)、サードパーティのツールはすでに目を見張るものがあり、現時点では完全なフレームワークでASP.NETCoreを実行することさえできません。 私はこれが正当な理由のように聞こえないことを認めますが、それは私たちが対処しなければならない制約です。

理論的には、これらのツール(つまり、プロファイラー、監視、サーバーの構築など)を.NET Coreをサポートする代替ツールに置き換えることができますが、それは、より差し迫った問題の解決に費やしたい2か月の作業です。 最終的にはASP.NETCore/ .NET Coreに移行しますが、現時点ではかなり動いているターゲットです。

この時点まで、ASP.NET Coreデスクトップフレームワーク上で実行し続けることができ、そのため、さまざまなことなどを話すことができると期待されていました。どのような茶葉を読んで知っておくべきかわかりません。それは非現実的でした:/

たとえば、明確にするために、ASP.NETCoreが.NETCoreでのみ実行される可能性があるという考え自体はおかしなことではありませんが、これまでのぞき見は聞いたことがありません。 すべての公開情報は、.NET Frameworkで正常に動作することであり、これを変更する必要がある可能性があるという兆候はありませんでした。

.NETは古くて大きく、ASP.NETチームが.NETエコシステムに存在するライブラリの息吹に話しかけることを期待する方法はありません。 非現実的です

それが.NET4.xをサポートし続ける正当な理由ではありませんか? 互換性/相互運用性の負担は.NET4.xプラットフォームに抑えることができます。これは、.NET Coreが古いライブラリと相互運用する必要をなくし、既存の人気のある.NETライブラリを.NET Coreに移植する圧力を軽減できる実用的なソリューションです( MSおよび外部の作成者向け)。

@mythz

それが.NET4.xをサポートし続ける正当な理由ではありませんか? 互換性/相互運用性の負担は.NET4.xプラットフォームに抑えることができます。これは、.NET Coreが古いライブラリと相互運用する必要をなくし、既存の人気のある.NETライブラリを.NET Coreに移植する圧力を軽減できる実用的なソリューションです( MSおよび外部の作成者向け)。

これが、1.1のASP.NET Coreの存続期間が延長された理由です(永続的ではありませんが)。 それがASP.NETCore2.0を使用する主な理由の1つとして述べられているため、SignalRが機能することを確認します。 同時に、ASP.NETCoreが長期的に望んでいる場所ではありません。 その意図は、常に統合された.NETCoreプラットフォームの一部として出荷することでした。

@gulbanana

この時点まで、ASP.NET Coreはデスクトップフレームワーク上で実行し続けることができ、そのため、さまざまなことなどを話すことができると期待されていました。どのような茶葉を読んで知っておくべきかわかりません。それは非現実的でした:/

残念ながら、.NETFramework上のASP.NETCoreは、移植を容易にするためのストップギャップソリューションとして伝達されませんでした(これは、私たちが非常に不十分なメッセージでした)。 これは、サポートされるプラットフォームとして永遠に意図されたものではありませんでした。これは、一部の依存関係が移植されないことを想定した場合の論理的な結論です。

これが、1.1のASP.NET Coreの存続期間が延長された理由です(永続的ではありませんが)。

問題は、それで十分かどうかです。互換性のある/安定したリリースが提供される前に、現在のバージョンは基本的にEOL化されています。

既存の投資の価値が考慮されているとは思いませんが、EOLプラットフォームに移行するためにすべての努力をしたいと思うのは誰ですか? 開発者は既存のブラウンフィールドシステムに無期限に取り組んでいます。基本的に、現在のASP.NET v4.xスキルは廃止され、新しいASP.NETCore開発モデルに移行できないと言われています。 NET 4.xのサポートは終了し、行き止まりのプラットフォームへの移行を検討または推奨することは無責任です。

@davidfowl

残念ながら、.NETFramework上のASP.NETCoreは、移植を容易にするためのストップギャップソリューションとして伝達されませんでした(これは、私たちが非常に不十分なメッセージでした)。 これは、サポートされるプラットフォームとして永遠に意図されたものではありませんでした。これは、一部の依存関係が移植されないことを想定した場合の論理的な結論です。

間違いが起こります、それは結構です。 現在の問題は、多くの人がこの仮定を行ったため、論理的ではあるが誤った結論のためにASP.NETCoreのみを使用していることです。 いくつあるかわかりますね:/

asp.net core 2 / .net core 2を長い間待っていましたが、結果は非常に落ち込んでいます。

@mythz

既存の投資の価値が考慮されているとは思いませんが、EOLプラットフォームに移行するためにすべての努力をしたいと思うのは誰ですか?

来年の3.0がリリースされると、ASP.NET Core2.0が.NETFrameworkのEOLになることについて同じ議論をすることはできませんか? ASP.NET Core 1.1で1年では不十分だと言っている場合、ASP.NET Core 2.0で1年は問題ないと提案するのはなぜですか?

開発者は既存のブラウンフィールドシステムに無期限に取り組んでいます。基本的に、現在のASP.NET v4.xスキルは廃止され、新しいASP.NETCore開発モデルに移行できないと言われています。 NET 4.xのサポートは終了し、行き止まりのプラットフォームへの移行を検討または推奨することは無責任です。

ASP.NET 4.xのスキルが廃止されると誰が言われたのですか? どちらかといえば、そうではないことを望んでいます。 特にMVCは、いくつかの新機能とのコンセプトの互換性を売り込んでいます。 ASP.NET CoreはKatanaによく似ています(これは間違いではありません)。 Webフォームについて話している場合、MVCについてはどうでしょうか。

コンサルティングの経験はありませんが、依存関係が利用できない場合は同意します。 これを考慮に入れるには、それまたはアプリケーションを再設計する必要があります。

@xyting明確にできますか?

@davidfowl

来年の3.0がリリースされると、ASP.NET Core2.0が.NETFrameworkのEOLになることについて同じ議論をすることはできませんか? ASP.NET Core 1.1で1年では不十分だと言っている場合、ASP.NET Core 2.0で1年は問題ないと提案するのはなぜですか?

私は長い間、ASP.NETCore1.1はASP.NETCore2.0および.NETStandard2.0の一時的なソリューションであり、互換性に重点を置いた安定したLTSリリースであり、ほとんどの.NET4.xに欠けているコア機能-このスレッドが基本的にその仮定を破壊するまで。 .NET4.xの互換性をASP.NETCore2.0まで維持することは理想的ではありませんが、誰も予想していなかった現在のリリースで終了するよりもはるかに優れています。

ASP.NET 4.xのスキルが廃止されると誰が言われたのですか? どちらかといえば、そうではないことを望んでいます。

MSは、.NET Coreでの積極的なマーケティングをすべて行っており、すべての新しい発表と機能はASP.NETCoreに重点を置いているようです。 古いASP.NETWebForms/ MVCはオープンで開発されていますか? 古いASP.NETWebForms/MVCと.NETCoreに投資されている開発作業の割合はどれくらいですか? 最近見たものすべて、毎週のスタンドアップ、ビデオチュートリアルは、ASP.NETCoreのみに焦点を当てているようです。 古いASP.NETWebFormsまたはMVCテクノロジを使用して、新しいグリーンフィールドプロジェクトを開始するのは間違いなく快適ではないことを私は知っています。

あなたが彼らがそうでないことを望んでいるなら、MSは明確なロードマップでそれをよりよく伝えるべきです。 過去数年間のASP.NETの不安定さを考えると(この問題は完璧な例です)、公式のコミットメントと発表がなければ、将来がどうなるかを知ることは不可能です。

バージョン1が完全なフレームワークで実行されなかったとしたらもっと良かったと思う人はいますか? ネーミングのせいで期待していなかった。 今ではそれができて、私はそれを失うことに失望している味を持っています。

私はあなたがこれでどこから来ているのかわかります、あなたはスタック全体をできるだけ速く繰り返したいです。 あなたは、スタック全体を制御し、ドラッグする荷物がない、たくさんのグリーンフィールドWebフレームワークと競合しています。 System.Webの手荷物を落とすのは、ASP.NETCoreが非常にエキサイティングな主な理由の1つです。

その上で眠ったので、私たちの使用法はうまくいくと言うことができます、私たちが必要とする依存関係はすべて2.0で動作するはずです。

同時に、ASP.NETCoreが長期的に望んでいる場所ではありません。 その意図は、常に統合された.NETCoreプラットフォームの一部として出荷することでした。

.NET Coreが.NETの将来のプラットフォームであることを理解するのは超能力者ではありませんが、最初から(または「常に」)意図がASP.NETCoreを.NETCoreと結合することであった場合。 NET Core、これは私が今まで見たどのメディアでも確実に伝達されませんでした。

私は文字通り、すべてのASP.NETスタンドアップの1分ごとを見てきました(HanselmanとGlennがDockerのトラブルシューティングを3時間行うことを含みます...私には人生がないため)、ブログを読んでいます、私は常にTwitterにいます、私はに行きます年に2回以上の会議、ユーザーグループへの参加などがあり、ASP.NETCoreの意図として伝えられたことは一度も聞いたことがありません。 代わりに、「両方のプラットフォームで動作する」と何度も耳にしましたが、当然のことながら、人々は誰かが椅子を下から引き出したように感じます。 私はASP.NETCoreについて話し、「両方のプラットフォームで動作する」と自分で言ったことがありますが、今ではこの道を進んだ人には罪悪感を覚えています。 ITTの人々は最先端にいる可能性が高く、この種のニュースを最も受け入れていると思います。ここには多くの反発があります。 これは、このニュースが、プラグインされていない開発者とそのマネージャーに伝わり、ITTよりも保守的である可能性が高いため、悪化するだけのようです。

コミュニケーションの欠如といくつかのシナリオのサポートの欠如に加えて、多くの反発はこの発表のタイミングによるものだと思います。 .NET Core 2はまだRTMされておらず、それはすでに唯一の長期的な前進と見なされており、ASP.NETCoreのフルフレームワークには本質的に時限爆弾が置かれています。 ナイトリー以外に何か具体的な遊びができれば、私たちの恐れの多くは解消されると思います。

VSで.NETCore2+からnet461+libsを参照する場合は、「実行して動作するかどうかを確認する」よりも優れたツールエクスペリエンスが必要だと思います。 461以上のアセンブリも!」 死ぬまで売り出されるでしょう。 参照したものの欠落しているAPIを分析し、コンパイル時エラーを提供し、理想的には互換性のあるnupkgが存在する場合はそれを提案することができます(上記のEF6の例のSystem.Configurationのように...そしてそれを:smile:)。 明らかに、コンパイル時にすべてを分析できるわけではありませんが(上記の分散トランザクションのシナリオは、事前に分析するのが難しいものとして思い浮かびます)、それが多ければ多いほどよいでしょう。 ImmoがここでPlatformNotSupportedExceptionに対して行ったことや、netstandard2用のnet461APIが欠落しているようなものがあればいいでしょう。

ちょうど私の2セント。 私はただ過剰反応していることを願っています。 最終的に、私たちの多くはASP.NET Coreが大好きで、それを使用する上で何も邪魔されたくないので、ただがっかりしています。 ❤️

すでにリストされている懸念事項に私の声を加えて、来月新しいASP.NET MVCプロジェクトを開始します。顧客は、Microsoftが次の点に関して正しいことをしていると信頼していないため、ASP.NETMVCを使用したプレーンな.NETFrameworkになります。長期計画。

顧客組織はまだWindows7の展開を使用しており、このプロジェクトは例外です。これは、Webプロジェクトの大部分が実際にはJavaを使用するUNIXで行われ、.NETは主にデスクトップアプリケーションで使用されているためです。

この種の不確実性は、Windows 8 .NETスタックとUWPがあったという壊れた歴史に積み重なっており、.NETの将来に対するより安定した代替案を探す組織のCTOの関心を高めています。

これらのタイプの組織にASP.NETCoreで動作するようにモジュールを最初から作成するように強制する場合は、制御できない問題に直面するのではなく、より安定したロードマップを備えたものを採用するようにお客様にアドバイスすることもできます。

@davidfowlこの変更は、99%のプロジェクトで正常に機能する可能性があります。 ただし、「両方のプラットフォームで動作する」および「必要に応じて完全なフレームワークで使用できる」として販売されました。 asp.netコアのフルフレームワークバージョンが移行できないプロジェクト用であることは誰もが知っていましたが、それは問題ありませんでした。 そして人々はそれを念頭に置いて計画しました。

この変更はコードの観点からは最悪ではないかもしれませんが、より定期的な開発者がニュースを見ると、恐らく大きな嵐を引き起こすでしょう。 そして、それはコードについてではなく、約束されたことについてです。 そして、約束は「ネットまたはコアを実行し、それらすべてを組み合わせるためのネットスタンダード」でした。

@DamianEdwards@ davidfowl計画を共有していただきありがとうございます。

1.xのSignalRは、サポートされていないバージョンを置き換える大きな安心です。また、現在使用しているServiceBaseが次のリストにあるというニュースもあります。

ただし、EF6とspatialに大きく依存しているため、必要な機能セットが揃うまで1.xを使用し続けます。

ただし、ややおもしろいことに、これにより、最終的にはより多くのマイクロサービスのデプロイが必要になる可能性があります。 ただし、製品を機能させるためだけに、LOBのお客様がIISにさらにいくつかのAPIをインストールする必要がある理由を説明するのを楽しみにしています。

早すぎるように思われるので、これを抑えることができればと思います。ブログの投稿が削除されると、これにより大きな反発が生じると言われています。

また、最初から感情が完全なフレームワークで実行され、同僚に同じことを説教しているとき、私は少し川が売り切れたと感じていると言わなければなりません。 ただし、asp.netコアのわかりにくい名前の選択について説明します。

@shanselman@ davidfowl私の最大の問題点はNHibernateです。 EF Coreのリリース後も、それは依然として唯一の最も高度なフル機能のO/Rマッパーです。

@shanselman @DamianEdwards私は、サイトをASP.NET MVC 4から最新バージョンにアップグレードすることを検討し始めています(5か1か混乱しています)。 SyncFusionライブラリとTelerikライブラリの両方を参照しているため、完全な.netフレームワークを実行する必要があります。 SyncFusionはPDFファイルを表示し、TelerikはWord.docxファイルを生成します。 他の人が指摘しているように、これに対処するためのマイクロソフトの戦略が「それを試して、それが機能するかどうかを確認する」ことは単に合理的ではありません。 サードパーティのコードの非常に大きなコードベースであるため、本番環境ですべてが機能することを保証することはできません。

SyncFusionのサポートは一般的に非常に優れていますが、Telerikのサポートはそうではなく、.netコアで動作させることができれば驚きます。 .netコアでサポートされていないApiを使用している可能性があるかどうかはわかりません。サードパーティ製品の要点であるエンドユーザーとして、プラグを差し込むだけで、必要な処理を実行できます。

率直に言って、あまり頻繁に処理しない顧客(私は主にWPFを実行します)にとって、これはすべて非常に混乱します。 さまざまな非互換性を伴う、非常に多くの異なるバージョンがあります。 誰かが指摘しているように、これはUWP XAMLに少し似ています。類似していますが、WPFXAMLとは完全に互換性がありません。

開発者にとっては良くなく、開発者がマイクロソフトへの信頼を失う原因となるもう1つのこと(過去数年間の多くの1つ)。 人々がサーバー上で使用する必要があるかもしれないツールの非常に大きなライブラリがあるので、ASP.NETは間違いなく完全な.netフレームワークで実行されるべきであるように私には思えます。 私の場合、新しいASP.net機能の更新が必要な場合に、最新のASP.netのものを使用する必要がある場合は、新しいバージョンの.netフレームワークに簡単に更新できます。

人々が完全に船に飛び乗る前に、開発者にどのようなメッセージを送るかは、はるかに明確である必要があります。

...ステファン

残念ながら、.NETFramework上のASP.NETCoreは、移植を容易にするためのストップギャップソリューションとして伝達されませんでした(これは、私たちが非常に不十分なメッセージでした)。 これは、サポートされるプラットフォームとして永遠に意図されたものではありませんでした。これは、一部の依存関係が移植されないことを想定した場合の論理的な結論です。

私は個人的にこの号に記載されている変更に問題はありません。私はその理由を理解しており、ここで多くの回答を読んだので、それらは理にかなっています。 しかし、あなたが今言ったことは、最終的に問題の核心であるもの、つまりマイクロソフト全体からのコミュニケーション不足を浮き彫りにします(私が感謝しているのは、あなたや特定の個人のせいではありません)。

何かが足りないかもしれませんが、githubにコードを置いて誰もが試してみるだけでなく、「オープンで開発する」ことだけではありません。 この問題は、ある日コードに変更が加えられて人々を驚かせたために発生しましたが、明らかにあなた自身と.netチームの全員がそれを知っていて理解していたので、長い時間がかかりました。 問題は、私たちの残りの人々がそれによって完全に盲目的にされていたということです。

さらに悪いことに、開発者の大多数は知識や情報を得るためにgithubにあまり注意を払っていないのではないかと思います。したがって、この変更は、すでにここでコメントしているよりもはるかに多くの人々を驚かせるでしょう。 この問題は、ハッカーニュースのRSSフィードに表示されたため、自分で発見しただけです。これは、ニュースや情報のトップソースとは言えません。

MSDNのブログ投稿をフォローしている人なら誰でも、2.0が登場することを知っており、それをasp.netコアと以前は「欠けていた」すべてのものとの間のギャップを埋める聖杯と見なすでしょうが、彼らは完全に気づいていません。特定のワークフローにとって本質的に重大な変更は何ですか。 asp.netコア2.0の設計で実際に何が起こっているかについての詳細はほとんどありません。 詳細は今週後半にビルドで発表されると思いますか? 希望することしかできません。

.net slackは情報のもう1つのリソースですが、実際に何が起こっているかを最新の状態に保つのは少しうるさいです。 開発者の関与や質問をするのに最適ですが、ニュースソースにはなりません。

Twitterやソーシャルメディアも別の情報源ですが、このgithubの問題が表示されるまでには少し似ていますが、これは通常、誰かがすでに行われた決定に懸念を表明し、人々を驚かせたためです。

私たちがこの正確な問題を抱えたのもこれが初めてではありません。 csprojに戻すことによって引き起こされた大失敗を覚えていますか? 私はその変化について議論したくありませんが、それは人々の驚きに起こった変化の別の例であり、それはあまりにも伝えられていなかったので、今日まで多くの人々はそれが同じcsprojではないことに気づいていません「古き良き時代」から。

ここで何を提案しようとしているのか完全にはわかりませんが、.netのオープンな開発には間違いなく「欠けている」ものがあります。 マイクロソフトは、開発者向けのリソースとドキュメントを提供するという素晴らしい仕事をしていますが、完成品と出荷されたものに対してのみです。 ロードマップ、計画会議、フレームワークの設計と方向性を決定するために必要なすべては、「選択されたパートナー」などについて時折言及されて、密室で行われているようです。 すべての会議を世界中にストリーミングして放送する必要があると言っているわけではありませんが、決定とその背後にある論理的根拠をできるだけ早くコミュニティに簡単に伝えることができる、より良い中間点が確実に存在する可能性があります。消化して上を維持するために本当にフォローしたい私たちの人たちのために。 おそらく、MSDN(または他の場所)の専用ブログで、これらの決定が行われると定期的に更新されます。

これに関する私の最大の問題の1つは、昨年ASP.NET Coreが発表されたほぼすべての会議で、.netFrameworkと.netCoreの両方で実行されているasp.netCoreを示すスライドを提示したことです。これを見てください:昨年のIgniteのMicrosoft ASP.NETCore1.0を使用したWeb開発を調べてください。 約7.50で、スライドが表示されます。

私にとって最大の目玉は、System.DirectoryServices、ServiceBase、EF6(EF Coreの準備ができていません)、ClosedXML(Excelシートを作成するため)です。

.NETFrameworkでのASP.NETCore1.xのサポートは、少なくとももう1年間(2019年7月まで)延長されます。 これを毎年再評価し、ASP.NET Core 1.xのサポートを終了する前に12か月前に通知することを約束します(したがって、2018年7月までに、2020年7月までさらに12か月延長するかどうかを発表します)(補足: 2020年についてすでに話しているという事実に、他の誰かがびっくりしましたか?いいえ?わかりました、私だけです。)

@DamianEdwards発表ありがとうございます。

現在、当社は.NETFramework4.6.2でASP.NETCore1.1を使用して複数のクライアント向けのエンタープライズアプリケーションを開発しています。 そのフレームワークコンボのサポートが少なくとも2019年まで、そしておそらく2020年まで延長されるまでサポートされていると聞いて、大きな安心を得ることができます。

今年はSystem.DirectoryServicesとSystem.Drawingを.NETCoreに移植します(完全にサポートされ、クロスプラットフォームで、夏には少なくともWindowsのプレビュー)

これらが、現在.NETFrameworkをターゲットにしている2つの理由です。 これらが.NETCore2に完全に移植されれば、来年はアプリケーションをASP.NETCore2に安全に移植できると確信しています。

多くのpplがMS開発者であるという基本的なルールを破ったようです-少なくともV2までは製品/フォークにコミットしないでください。

しかし、ええ、あなたの企業クライアントを疎外することについて話してください! 彼らがMSを使用する理由はすべて、下位互換性のためです。

ASP.NETを実行するpplの大多数は、Linuxで実行する場合は気にしません。 また、ASPNET Coreとの速度を比較したブログ投稿を見た場合、レガシー.NETをサポートしていないことを確認した場合でも、クロスプラットフォームを超えて読むことはありません。

lolcats。

多くの人々に新しい世界へのスムーズな移行パスを提供するために、ASP.NETCore2.0をnet46xで完全に実行することには価値があると思います。 ASP.NETCore2.0と.NETCore2.0が今日のギャップの多くを埋め、移行を可能にすることを期待して、多くの人々がASP.NETCore2.0と.NETCore2.0を待っていたと思います。 ASP.NET Core 2.0ですべてをnetcoreapp2.0に移植する必要がある場合、チームの速度が大幅に低下し、実現可能性が損なわれる可能性があります。

ただし、それは、ASP.NET Core 3.0がすぐに存在できないという意味ではありません。その直後に、すべての新しい光沢のあるグリーンフィールドに取り組み、ファーストトラックになりたいすべての人々を対象とするnetcoreapp2.0のみがターゲットになります。

ASP.NET Coreの2つのバージョン(2.0と3.0)を並べて使用することは、(少なくともしばらくの間は)本当に良いことかもしれません。 これにより、MSFTは現在のMVC 5スタックをより迅速に段階的に廃止できます。これは、MVCの新しいバージョンが本質的にASP.NET Core MVC 2.0であり、完全な.NETでも実行されるためです。

多くの人々に新しい世界へのスムーズな移行パスを提供するために、ASP.NETCore2.0をnet46xで完全に実行することには価値があると思います

ASP.NET Core 1.xからの移植よりもスムーズになる理由は何ですか?

ASP.NETCore2.0と.NETCore2.0が今日のギャップの多くを埋め、移行を可能にすることを期待して、多くの人々がASP.NETCore2.0と.NETCore2.0を待っていたと思います。

互換性を持たせるために行われた作業の大部分は、.NETCore2.0および.NETStandard2.0で行われました。 ASP.NET Core 2.0には、正直なところ、それほど多くの新機能はありません。 SignalRをASP.NETCore1.x(とにかく2.0以降)にバックポートすると言われています。 それは単なる知覚のことですか?

ASP.NET Coreの2つのバージョン(2.0と3.0)を並べて使用することは本当に良いことです。

これは、1.1と2.0で行っていることです(数字を反転するだけです)。

これにより、MSFTは現在のMVC 5スタックをより迅速に段階的に廃止できます。これは、MVCの新しいバージョンが本質的にASP.NET Core MVC 2.0であり、完全な.NETでも実行されるためです。

MVC 5がなくなることはなく、非推奨になることはありません。 .NETFrameworkが存在する限りサポートされます。 (System.Web上の)IIS統合パイプライン内でASP.NET Coreプロジェクトを実行することはできません。また、System.Web上のMVC 5と同じことをすべて実行するわけではないため、特定のシナリオに代わるものではありません。 。

@davidfowl完全な.NETとnetcoreapp2.0を対象とするASP.NETCore1.xアプリを作成できるので、現在のレガシーアプリを最初にASP.NET Coreに移行し、すべての依存関係をnet46xにしてゆっくりと移行できますか?すべてがnetstandard2.0に移行するまで、次々とnetstandard2.0をターゲットにする依存関係があります。これにより、ASP.NET Core 1.xアプリを2.xにアップグレードできます(その一部としてnet46xのターゲットを削除できます)。

もしそうなら、私はスレッドを誤解したと思います。 私はこれが本当にほとんどの人がここに求めているものだと思います。

@dustinmorisはい、できます。 人々が抱えている主な懸念は、ASP.NET Core 1.xでのサポートが終了する前に、ASP.NET Core 2.xに移行しない場合、移行が可能である場合にどうなるかということです。

@alexwieseああ、それは素晴らしいことです。では、実際にここで何について話し合っているのでしょうか。 ターゲットとするフレームワークについて説明するのではなく、ASP.NET Core 1.xのサポート期間について説明する必要があります。これは、MSFTが必要に応じて簡単に変更できるものです:)

編集:
@DamianEdwardsは、これをスレッドの少し上に書きました。

.NETFrameworkでのASP.NETCore1.xのサポートは、少なくとももう1年間(2019年7月まで)延長されます。 これを毎年再評価し、ASP.NET Core 1.xのサポートを終了する前に12か月前に通知することを約束します(したがって、2018年7月までに、2020年7月までさらに12か月延長するかどうかを発表します)(補足: 2020年についてすでに話しているという事実に、他の誰かがびっくりしましたか?いいえ?わかりました、私だけです。)

私にはいいですね。 もう1年間のサポートを約束し、定期的に再評価します。 私には完全に理にかなっています。

このスレッドのすべての投稿を読みました。 まだ1つの質問が答えられていません:なぜこの決定がなされたのですか? 技術的な問題のために必要だったと結論付けることしかできません。 名前の「混乱」が問題である場合、Microsoftはより優れた広報担当者を雇い、チームがこのスレッドで行っているようにたわごとをかき混ぜるのをやめるべきです。

では、netstandard2.0でASP.NET Core 2.0をブロックした技術的な問題は何ですか? ソフトウェアの世界では不可能なことは何もないので、.NETフルで実行できない(したがってnetstandard20に含めることができない)ソリューションを思い付くことができなかったということはあり得ません。 はい、それは時間と労力を要しますが、ユーザーにとってこの決定の副作用、これのために彼らが投資しなければならない時間/労力の量を皆さんは本当に理解していなかったと思います。

この決定には別の欠点があります。ASP.NETCoreはnetstandardの消費者ではないため、その推進力ではありません。 これにより、netstandardがフォロワーになり、ASP.NETコアはそれに依存しないため、ほとんど意味のないフォロワーになります。.netcore 2.0+のAPIはターゲットとするサーフェスであり、ASP.NETコアはそのサーフェスをターゲットにします。 netstandard2.0。

そして、申し訳ありませんが@davidfowl 、私はあなたがよく意味していることを知っていますが、ASP.NETコア1.xを人々に何度も提案することは、あなたが提案する人々の状況が本当に何であるかについての手がかりがないことを示しています:人々は移行できませんASP.NET Core 1.xに移行するのは、期限が定められていないとスムーズなパスがないかどうかわからないためです。現在考えているよりも長くそのプラットフォームにとどまる必要がある可能性があります(依存関係を移植する必要があります)。等。)。 それだけで、Microsoftからの「約束」に基づいてASP.NETCore1.xaに移行することを決定します。 これは、インターネット向けのコード用のAPIです。 マイクロソフトがセキュリティ上の欠陥を修正するため(例を挙げると)、今日作成されたアプリを3年以内に実行できるかどうかを知る必要があります。

率直に言って、.NETエコシステム内でさらに別のカオスクラスターを開始する衝動はありません。安定性、信頼性、信頼性が必要です。「今日書かれたコードは、5年後にそのまま実行されます」。 はい、それは一部の人にはばかげているように聞こえますが、それは現実です。この惑星には、それらを維持する開発者よりもすでに多くのソフトウェアパッケージがあり、ギャップは拡大しているだけです。 組織がASP.NETCoreをWebスタックとして使用することを決定し、それを使用して記述されたコードが5年以内に実行されることを期待することはできません。組織は、それを実行しなくなります。信頼性が高く、次のことを提供します。彼らは、その時間枠内にアプリ全体を書き直すことができない可能性があることを知っているため、その保証が必要です。

マイクロソフトはこのスレッドで示しており、申し訳ありませんが、この問題に関する彼らのひどいPRは、その保証を与えることはできません。 そして、今後数日間に\ buildでどれだけスピンを加えようとしても、フェンスの向こう側にいる私たちは、Microsoft Marketing!=保証が明日機能することを学びました。

@FransBouma技術的な問題があったとは思いませんが、netcoreapp2.0のみをターゲットにする動機は、MSFTが好きなだけ速く移動できる唯一のトラックであるためです。これは、ASP.NETCore2.xが以前の.NETの世界の他のどのWebスタックよりもはるかに高速に移動できることを意味します。 この高速トレインにコミットできない場合は、ASP.NET Core 1.xをより長く使用できます(現在、2019年までサポートされています)

@davidfowlおよび@shanselmanとしての@FransBoumaは、.NET Coreに高速で追加される新しいAPIがあり、ASP.NET Core 2.xはそれらの一部を使用するため、netcoreapp20をターゲットにする必要があると述べました。 これらのAPIをnetstandard2xに追加する場合、.NET Frameworkやその他のプラットフォームは追いつく必要があり、動きが遅いことで有名です。

これは議論の良いことです。 理由は次のとおりです。

  • チームはそれの地獄のためにこれをしているだけではありません。 最新のWebアプリケーション、API、マイクロサービスを構築し、それらの機能が完全なWindows .NET Frameworkに組み込まれるのを待つ人々にとって非常に便利な、.NET Coreに組み込まれる準備ができている(またはほぼ準備ができている)多数の新機能と最適化があります。リリースを何ヶ月も遅らせるでしょう。
  • このスレッドで目にする不満の多くは、ライターが実際に意味するのが「.NETCore2.0でXを実行する方法を変更する必要がある」場合の「.NETCore2.0でXを実行できない」のバリエーションです。 _。 はい、変更する必要があります。 いいえ、それは悪いことではありません。 ASP.NET MVCアプリケーションにPDFまたはDOCXファイルで何かを行う小さな個別の機能があり、それを実行するためのより良い方法を_本当に_見つけることができない場合(試したことはありますか?)、それを破ります機能をWindowsServer上の完全な.NETで実行されているマイクロサービスに組み込み、.NETCoreアプリケーションからHTTPAPIとして呼び出します。 アプリケーションを分解し、特定の機能を小さな自己完結型のサービスに移動することは、回避策でさえありません。_これは汎用のベストプラクティスです。_

    • 注意私が知る限り、OpenXMLパッケージは現在.NET Standardをサポートしているため、Word /Excel/その他の操作は不可能ではありません。

  • .NET Core 2.0はまだ適切な公開プレビューに含まれていないため、LDAPや時期尚早と思われるものがサポートされていないと不満を漏らしています。 RTMが第3四半期に登場し、ADやKerberosなどと対話する方法がまだない場合は、不平を言います(ただし、2008年ではなくなったため、最新のトークンベースの認証システムへの移行も検討してください)。
  • ASP.NETMVC4.5からASP.NETCore2.0へのスムーズな移行があります。 これはASP.NETCore1.0と呼ばれます(この状況では、1.0の長期サポートが約束されているはずです)。 1.0を使用してアプリを構築し、Windows Server2012R2のIIS8.5で統合パイプラインのFull.NETで実行できます。

    • 完全な.NETが追いつき、ASP.NET Core 2.xを実行するか、または

    • 依存しているサードパーティの技術が何であれ、.NET Coreをサポートします(または、.NET Coreをサポートする同等の技術に置き換えることができます)。

  • チームが外部の依存関係、内部の企業ポリシー、政治、または単なる慣性に悩まされている可能性がある一方で、最新のアプリケーション、サービス、APIを構築しようとしている開発者は、数百万とまではいかなくても数十万人いることを忘れないでください。 ASP.NET Core 2.0が最適なアーキテクチャパターンと新しいテクノロジプラットフォーム(クラウド/エッジ/ IoTなど)。 彼らはそれが高速でスケーラブルでクロスプラットフォームであることを望んでいます。 それらは多くの人にとって重要です。 サードパーティのコントロールサプライヤまたはオープンソースプロジェクトがまだコードを移植していないという理由だけで、急速に拡大している市場を無視するようにMicrosoftに依頼するのはばかげています。

@dustinmorisは、netstandardに高速Webスタックを作成するためのAPIがないことを示唆しています。 もしそうなら、私たちは皆、より大きな問題を抱えています。

私が言ったように@alexwiese 、私は完全なスレッドを読んだので、あなたが参照している投稿も読んだ。 私は彼らが何を言っているかを知っており、彼らの主張を理解することができますが、下された決定は、彼らが彼らのユーザーが彼らのもので何をしているのか見当がつかないことを示しています。 私は何年も前から自分で製品を作っていますが、しばらくすると、時代遅れの古いがらくたを使わずに、物事を切り取ってより速く移動したいポイントに到達することを知っています。 しかし、それを行うと結果が生じます。過去14年間に私が学んだことのひとつは、下位互換性はソフトウェア製品が持つことができる最大の機能の1つであるということです。それを使用でき、「正しく機能する」ことが重要なポイントです。多くの人々があなたのプラットフォームを決定します。 それほど重要だとは思わないかもしれませんが、それは問題ありませんが、現実が異なるためにそのように見ることができない人はたくさんいます。

asp.netコアチームが速く動くべきではないということではありません、それは彼らがasp.netコア1.xに移ったときに多くの人々の仮定を破る方法でそれをするということです。

@FransBoumaなぜ、マイクロソフトのユーザーがマイクロソフトよりもマイクロソフトのものを使って何をしているのかについて、より良い考えを持っていると思いますか?

@markrendle

チームはそれの地獄のためにこれをしているだけではありません。 最新のWebアプリケーション、API、マイクロサービスを構築し、それらの機能が完全なWindows .NET Frameworkに組み込まれるのを待つ人々にとって非常に便利な、.NET Coreに組み込まれる準備ができている(またはほぼ準備ができている)多数の新機能と最適化があります。リリースを何ヶ月も遅らせるでしょう。

では、これらのスーパーデュパーAPIを.net標準2.0パッケージとして作成し、nugetに投稿してみませんか?

なぜあなたは、マイクロソフトのユーザーがマイクロソフトよりもマイクロソフトのものを使って何をしているのかについてより良い考えを持っていると思いますか?

このスレッドの投稿を読んで、わかりませんか?

@FransBouma

これは、netstandardに高速Webスタックを作成するためのAPIがないことを示唆しています。 もしそうなら、私たちは皆、より大きな問題を抱えています。

netstandardは、その標準をサポートしたいプラットフォームによって実装される必要のある機能のリストにすぎないため、netstandardには何も欠けているとは思いません。 理論的には、netstandardを好きなだけ速く移動でき、仕様にさらに追加するだけですが、現実的には、すべてのプラットフォームがこれらの新しい仕様に追いつくことは現実的ではありません。

したがって、問題は、ASP.NET Core 2.xがnetstandard2.0(現在最高)にコミットして、そこで定義されているすべてのものでスタックしていることを知りたいのか、それともASP.NETCore2.xのみを実行するのかということです。 netcoreapp2.xにコミットします。これは、netstandard2.0だけではありません。 しばらくすると、netcoreappからの新しい光沢のあるものに追いつく新しいnetstandard(3.x?)が再び存在すると確信していますが、それにははるかに時間がかかり、すべてのasp.netフレームワークが機能不全に陥って進行が遅くなるのはなぜですか? 。 ネットスタンダードに準拠したより長期的なサポートを提供する秒もある限り、非常に高速で移動するASP.NETCoreスタックが1つあるのはいいことです。

@FransBoumaああ、すみません、あなたのサンプルサイズがそれほど大きいことに気づいていませんでした。 決定を嫌う人々に強い偏見を持った257のコメント? それについて議論するのは難しい。

免責事項:私はビッグデータの専門家ではありません。

@davidfowl

このスレッド全体を通して、コアなものの1つとしてSystem.DirectoryServicesを呼び出しました。 移植されるまでに長い時間がかかると思われる依存関係や、移植されない依存関係があると思います。 2.0がサポートされている.NETFrameworkの場合、これらの依存関係は1年で移動しますか?

はい、他にもあります。 System.Directoryサービスは、要求された上位の名前空間でさえ準備ができていないため、私が指摘しているものです。 他のすべては悪化しています。 APIポータビリティアナライザーは、実行可能なVS2017用に更新されていません。 移植できるかどうかを確認するアナライザーはまだ投資されておらず、すでにサポートを終了しています。

どれ?

かみそりのページは巨大なものです、私はそれを何度か言及しました。

stackoverflow.comについては何も知りませんが、ASP.NET Coreを一部の部分に使用できるように、断片を分割することは可能ですか(「マイクロサービス」とは言いたくない)。

いいえ、これは実際には不可能です。 API呼び出しを行い、物事の間にオーバーヘッドを追加することによって、18ミリ秒でレンダリングすることはありません。 私はいつでもアーキテクチャを調べてうれしいです、あなたはそれが本当に合理的なルートではないのを見るでしょう。

これについては前に説明したと思いましたが、ここでも次のようになります。

進化する必要のあるnetstandardの一部であるAPIは、ゆっくりと進化します。 物事はnetstandardの上に構築でき、どこでも実行できます。それは問題ありません。 たとえば、httpクライアント、SSLストリーム、Int、文字列、配列、LINQ、またはNET Standardに存在するプリミティブのいずれかで新しいAPIが必要になった瞬間に、新しい.NETStandardバージョンを作成して実装する必要があります。彼らがそれを実装することに同意する。 モノラル、.NET Core、.NET Framework、UWPなど、ほとんどを所有しているため、これで世界の終わりではありませんが、Unity(およびおそらく他の製品)のようなものもあります。 各.NET業種には独自の時間枠と出荷サイクルがあり、それぞれ独自の製品であり、無視することはできません。

しかし、今、あなたはその考えを理解しました。新しいAPIがオンラインになると、新しいnetstandardバージョンが作成されます。 ライブラリがこれらの新しいAPIを使用したい場合は、すぐにすべてのプラットフォームのサポートが失われます。 クロスコンパイルしてポリフィルを試すことはできますが、すべての変更に対応できるわけではありません。

うまくいけば、APIをnetstandardに移行するプロセスがどのように見えるかがわかります。 @terrajobstは、計画が何であるかについてより良い考えを持っているでしょう。

@DamianEdwards@shanselmanサービスファブリックとユニットテストはどうですか?

私たちの場合、コアプロジェクトであるが.Net Framework 4.5から4.6までを使用するSFアプリケーションがたくさんある大きなマイクロサービスプロジェクトがあります(何か)。 SFは現在netcoreappをサポートしていないため、.Net Frameworkを使用する必要がありましたが、遅れを取りたくなかったため、.NetCoreプロジェクトを使用しました。

(別の問題は)私たちのサービスは.Net Frameworkであり、MS Fakesはnetcoreappで利用できないため、すべての単体テストは通常​​の(またはレガシーと言えば).NetFrameworkプロジェクトです。 ほとんどすべてのライブラリはnetstandard1.0から1.6にあります。

ここでも、クライアントアプリはXamarin Forms + UWPを使用しており、ライブラリに互換性があるようにnetstandardを使用することができました。

これは、スタックしていて、.Net Core 2.0、netcoreapp2.0、およびnetstandard 2.0にアップグレードできないことを意味しますか?

@NickCraver

かみそりのページは巨大なものです、私はそれを何度か言及しました。

私はこれを理解していますが、スタックオーバーフローのすべてをかみそりのページのみに変換することになるとは信じられません。 今日すでにMVCを使用している場合は、通常のビューに移植するだけでなく、より多くの依存関係がオンラインになったときに、かみそりのページに移植してください。 かみそりのページの設計方法により、コントローラーのアクションからかみそりのページに移動するのは簡単です。

はい、他にもあります。 System.Directoryサービスは、要求された上位の名前空間でさえ準備ができていないため、私が指摘しているものです。 他のすべては悪化しています。 APIポータビリティアナライザーは、実行可能なVS2017用に更新されていません。 移植できるかどうかを確認するアナライザーはまだ投資されておらず、すでにサポートを終了しています。

依存関係のリストをエスカレーションして、何が重要かを確認してください。

@aboo

これは、スタックしていて、.Net Core 2.0、netcoreapp2.0、およびnetstandard 2.0にアップグレードできないことを意味しますか?

ASP.NET Core 2.0とは? .NETCore2.0および.NETStandard2.0は、ここでは実際には適用されません。

はい、ASP.NETCore1.xを使用する必要があります。

互換性を持たせるために行われた作業の大部分は、.NETCore2.0および.NETStandard2.0で行われました。 ASP.NET Core 2.0には、正直なところ、それほど多くの新機能はありません。 SignalRをASP.NETCore1.x(とにかく2.0以降)にバックポートすると言われています。 それは単なる知覚のことですか?

@davidfowl物事を移行する必要があると言われたときに、Windows開発者の心を打つ恐れを大幅に過小評価していると思います。 _特に_新しいスタックが古いスタックと同等の機能に達していない場合、それがいつ発生するかは不明です。 これは基本的に、完全な.NETFrameworkでのASP.NETCoreのEOL化を発表しています。 そして、それは長期的な計画ではなかったかもしれませんが、それは機能として発表され、人々はそれがしばらく続くかもしれないと考えました。 私たちが話すように、ロードマップは変化しています。 ミーティングが行われます。

名目上維持されているデータベースコネクタとSDKのために、サポートしなければならない嫌なほど古いものがいくつかあります。 これらのベンダーの中には、既存の製品を維持するよりも、30%の既存の機能、HTML5インターフェース、および一連の新しいバグを備えた、新しい、肉付きの良いAPIをリリースする可能性がはるかに高いものがあります。 または、競合他社を買収して製品をリリースし、すぐにEOLする場合もあります。 これらのベンダーの中には、認識できるほどの規模のものもあります。 すばらしいコードがたくさんありますが、そのコードの一部は、常に制御できるとは限らないため、最善を尽くしてもウィンドウスラムに存在します。 古い技術はただ優雅に引退するだけではありません。 それはあなたのベッドの下、私たちのクローゼットの中、そしてあなたのキーボードの下に潜んでいます。

私は、この動きが.NET Standardのサイドラインの可能性を示していることを、他の部分よりも懸念しています。 .NET Standardは当初、消費者が進化し成長するプラットフォームに移行できるようにしながら、さまざまな実装を機能の同等性にますます近づけるもののように見えました。 今では、.NETCore機能のマイルストーンに過ぎないように聞こえます。 実行可能ファイルを.NETStandardのターゲットにすることはできません(またはターゲットにすることはできません)。ライブラリのみです。 また、.NET Standardに関連する計画は大幅に少なくなるようです。代わりに、変更するには遅すぎるため、ASP.NETで使用されたものにラバースタンプが付けられます。 結局のところ、それはすでに生産されているでしょう。

他の開発者は、コードにコンパイラ指令を振りかけ、コードをプラットフォーム固有のライブラリに分割し、複数のターゲットでコンパイルする必要があります。 私の失礼な部分は、ASP.NET Coreチームにドッグフードを提供してもらいたいので、マルチターゲティングおよびマルチプラットフォームシナリオのランタイムとツールのサポートの向上に関心があります。 そして、あなたのチームがそれを望むなら、私たちはそれを手に入れるかもしれません。 私の実際的な部分では、少なくとも、.NETStandardを対象としたASP.NETCoreの定期的なリリースが必要であると述べています。 とにかく実際の_stable_リリースを作成する必要があります。 マスターブランチをgitからコンパイルして本番環境にデプロイするだけではありません。 .NET標準の小さなイテレーションを実行し、タグ付けされたASP.NETリリースと一致させてみませんか?

また、デスクトップ用の新しいASP.NETはありますか? すべてのファンファーレにより、ASP.NETCoreが唯一のASP.NETであるように聞こえました。 これで、.NET Coreを使用していない限り、ASP.NETでは何も新しいものが得られないように聞こえます。 そして、それは多くのビジネス戦略を変えるでしょう。 ロードマップには多くの混乱があります。

MVC 5がなくなることはなく、非推奨になることはありません。 .NETFrameworkが存在する限りサポートされます。

はい、私たちは古いものがそこにとどまるであろうことをかなり知っています。 通常はそうですが、感謝しています。 しかし、新しいものが「完全な」フレームワークに組み込まれるかどうかは非常に重要です。 私たちは物事がどこに向かっているのかを知る必要があります。 電車に最後まで乗りたくないので、どうやって前に進むかを考えます。 乗客も心配する必要があります。 また、.NETCoreと.NETFrameworkの違いにより、多くの人が将来について不安を抱いています。 1年半前に、機能の特定の部分が.NETCoreでサポートされる時期について質問しました。 個人的に取り組んでもいいのかと聞いてみました。 コミュニケーションはまばらです。 どうなるかまだわかりません。 サポートされているシナリオとタイムラインに関するこの種の不確実性は、私たちが作成するコードに大きな違いをもたらします。 デスクトップフレームワークのどのセクションが優先度が低いかを知っていても、ステータスの更新を待つのではなく、移行するための十分な時間を人々に与えることができます。

要するに、私はあなたがしていることとその背後にある目標を支持します。 そして、私たちがここに乗って、あなたが非常に正当な理由で下した決定について不平を言うのは難しいことを私は知っています。 しかし、多くの人はパイオニアトレインに乗れないのでジャンプしませんし、他の人はどこに行くのかわからないのでジャンプしません。

@davidfowlだと思います。 .Net Frameworkを使用したコアプロジェクト(新規)を何と呼びますか? それが何であれ、投稿か​​らの私の理解は、netstandardvNextはそれをサポートしないということです。

@markrendle私たちは本当の顧客です。 私たちは人々に物事がうまくいかないことを伝えています。 私はあなたよりも私のアーキテクチャをよく知っているので、傲慢なコメントは役に立ちません。 あなたのポイントに:

チームはそれの地獄のためにこれをしているだけではありません。 最新のWebアプリケーション、API、マイクロサービスを構築し、それらの機能が完全なWindows .NET Frameworkに組み込まれるのを待つ人々にとって非常に便利な、.NET Coreに組み込まれる準備ができている(またはほぼ準備ができている)多数の新機能と最適化があります。リリースを何ヶ月も遅らせるでしょう。

これらのことを支持することに反対する人は誰いません。 私たちの不満は、新しい機能を条件付きで追加することではなく、一般的にサポートを削除することに関するものです。

このスレッドで目にする不満の多くは、ライターが実際に「.NET Core 2.0でXを実行する方法を変更する必要がある」という意味で、「。NETCore2.0でXを実行できない」のバリエーションです。 はい、変更する必要があります。 いいえ、それは悪いことではありません。 ASP.NET MVCアプリケーションにPDFまたはDOCXファイルで何かを行う小さな個別の機能があり、それを実行するためのより良い方法を本当に見つけることができない場合(試したことはありますか?)、それを破ります機能をWindowsServer上の完全な.NETで実行されているマイクロサービスに組み込み、.NETCoreアプリケーションからHTTPAPIとして呼び出します。 アプリケーションを分解し、特定の機能を小さな自己完結型のサービスに移動することは、回避策でさえありません。これは、汎用のベストプラクティスです。

これはベースからかなり離れているので、どこから始めればよいのかわかりません。 私たちのページは、「マイクロサービス」でははるかに遅く、より高価になります。 このような設定でページレンダリングを行うよりも、GCでかなり多くの時間を費やします。 これはまた、完全なフレームワークの依存関係がすべてのページレンダリングの重要な部分ではないことを前提としています。 悪い仮定。

.NET Core 2.0はまだ適切な公開プレビューに含まれていないため、LDAPや時期尚早と思われるものがサポートされていないと不満を漏らしています。 RTMが第3四半期に登場し、ADやKerberosなどと対話する方法がまだない場合は、不平を言います(ただし、2008年ではなくなったため、最新のトークンベースの認証システムへの移行も検討してください)。

彼らはそこにいないと言われています。 立ち上がるのを見てください。 または、「Future」というラベルの付いたGitHubを見てください。 この悪い決定は第3四半期に出荷されるため、現在不満を述べています。

ASP.NETMVC4.5からASP.NETCore2.0へのスムーズな移行があります。 これはASP.NETCore1.0と呼ばれます(この状況では、1.0の長期サポートが約束されているはずです)。

長期的なサポートは、行き止まりではないという意味ではありません。 1.xが終了しても、簡単に取り残される可能性があります。 その場合、完全なフレームワークのサポートが長くなります。

完全な.NETが追いつき、ASP.NETCore2.xを実行できます

netcoreappをターゲットにしていますが、それは起こりません。

...または依存しているサードパーティのテクノロジが.NETCoreをサポートしている(または.NET Coreをサポートする同等のテクノロジに置き換えることができる)。

これらの図書館は、多くの場合、人々の管理と時間の予算の範囲外です。 Microsoftのライブラリでさえアップグレードされていません。 install.ps1が機能するため、現在SQLチームと戦い、パッケージをアップグレードして新しいプロジェクトシステムで機能するようにしています。 これらの簡単な修正を取得することさえできない場合は、 netstandardポートに悩まされています。

チームが外部の依存関係、内部の企業ポリシー、政治、または単なる慣性に悩まされている可能性がある一方で、最新のアプリケーション、サービス、APIを構築しようとしている開発者は、数百万とまではいかなくても数十万人いることを忘れないでください。 ASP.NET Core 2.0が最適なアーキテクチャパターンと新しいテクノロジプラットフォーム(クラウド/エッジ/ IoTなど)。 彼らはそれが高速でスケーラブルでクロスプラットフォームであることを望んでいます。 それらは多くの人にとって重要です。 サードパーティのコントロールサプライヤまたはオープンソースプロジェクトがまだコードを移植していないという理由だけで、急速に拡大している市場を無視するようにMicrosoftに依頼するのはばかげています。

それをばかげていると呼ぶことは、愚かで、失礼で、求められていないことです。 これが私たちの生活です。 これらは私たちのアプリです。 これらは私たちが何年も何十年もかけて作成してきたものであり、リリース前に突然、見通しが私たちにとって時間制限があることがわかりました。 控えめに言っても、多くの不確実性が導入されています。 それはあなたがあなたのキャリアで本当に望んでいることではありません。

すべての点が理にかなっていますが、この宇宙ではすべてがより少ないエネルギーを必要とする状態になることを忘れないでください。そして、私たちが何らかの方法でそこに行くので、その状態があなたが行きたい場所であることを確認してください。
したがって、特定の状態を達成したい場合は、現在の場所にとどまるために必要なエネルギーよりも必要なエネルギーが少ないことを確認してください。

誰かがこれをIRCの傍白として言及した後、私はこのスレッド全体を読んだばかりです-これについての公式発表はまだ見ていません-そして私は完全に失望しています。

新しいSDKとランタイムの経験を積み、macOSとLinuxでこれらのプロジェクトを実行するために、.NET Coreを監視し、小さなプロジェクトを.NETFrameworkから.NETStandard /.NETCoreに変換しています。 。

私の大きな目標は、.NETCore1.0または1.1では[まだ]利用できないコンポーネントのヒープを使用する大規模なエンタープライズWebサービスです。 これには、頭のてっぺんから次のようなものが含まれます。

  • Active Directory( System.DirectoryServices )、認証とユーザー管理に使用
  • Entity Framework 6( EntityFramework )。EFCoreは、まだ使用している多くの関数をサポートしていないためです。
  • OData( Microsoft.Data.Services / System.Data.Services )v1-3、使用するクライアントJavascriptライブラリはv4を(まだ)サポートしておらず、WebAPIODataのセットアップははるかに複雑です。
  • IIS管理( System.Web.Management )と.NET Remoting( System.Runtime.Remoting )により、Webサービス自体をアップグレードできます。ただし、これはスタンドアロンアプリケーションに抽出できます。
  • SignalR
  • カスタムのIHttpHandlerIHttpModuleは、ASP.NET Coreに相当するもの、おそらくある種のミドルウェアに適合させる必要があります。
  • ASP.NETWebAPIの拡張性を使用したカスタムコンテンツのすべて。
  • サーバーでMicrosoft.TeamFoundationServer.ExtendedClientを使用することもできると思います。このサーバーは、net46のみをサポートし、いくつかのネイティブアセンブリがあり、.NET Core 2.0で動作する可能性は約0%です。

このサービスのサイズと複雑さのために、.NET Coreへの移行は段階的に行う必要があり、おそらくASP.NET-Core-2.0の新しいAPIを使用する必要があるかもしれません。まだ、私たちはそこまで到達していません。

.NETFrameworkでASP.NETCoreを実行する機能を削除すると、ASP.NET Core 1.xが実行可能な足がかりにならない場合、移行はビッグバンスタイルで実行する必要があります。 「新しいランタイムで新しいフレームワークを実行する」前に、「古いランタイムで新しいフレームワークを実行する」という段階を即座に失います。 これは、大規模なシステムにとって恐ろしい変更管理戦略です。

.NETCoreが同等またはそれに近い状態になったら.NETFrameworkのサポートが廃止されてもかまいませんが、十分に高度なアプリケーションにはまだかなり遅れており、2.0がそのようなものにするのに適切な場所ではないと思います。重大な変化。

@davidfowl

私はこれを理解していますが、スタックオーバーフローのすべてをかみそりのページのみに変換することになるとは信じられません。 今日すでにMVCを使用している場合は、通常のビューに移植するだけでなく、より多くの依存関係がオンラインになったときに、かみそりのページに移植してください。 かみそりのページの設計方法により、コントローラーのアクションからかみそりのページに移動するのは簡単です。

ここでは、アプリ間で共有される多くのライブラリなどが使用されています。 Stack Overflowは多くのアプリケーションです(メインのウェブサイトはほぼ完全に単一のアプリですが、会社として:私たちは多くの関連するコミュニケーションのものを持っています。

依存関係のリストをエスカレーションして、何が重要かを確認してください。

ええ、私はそれをやっています。 しかし、それが最後の依存関係ではなく、それなしでは一部のアプリにログインすることさえできないため、最大のブロッカーになります。 ファーストスクリーンブレーカーです。 今週(今朝のリリース後)、アプリ全体で完全なポータビリティアナライザーを試してみますが、もっと気のめいるようになるのではないかと心配しています。 このような動きが検討される前に、アナライザーが現在のツール用に更新されていれば、役に立ちます。

データは役に立ちます。この決定が変わる可能性がゼロでない限り、私はあなたのより多くのデータを取得しようとします。 その場合は、もう時間をかけないように教えてください。

念のために言っておきますが、ODataは、netcoreappをまだサポートしていない別のライブラリです。

実際には、まだSystem.Webに基づいており(ASP.NET CoreのOWINミドルウェアを介して使用する必要があります)、サポートを約束しました(https://github.com/OData/WebApi/issues/939を参照)。

まだ言及する価値があります。 特にそれはマイクロソフトからのものなので。

編集:@ yaakov-hは2分速かったので、ODataについての彼の言及に対して+1

私はまだここにいくつかの理由で返信しています

  • 私は気にします
  • 睡眠は弱い人のためです😆
  • インターネット上の誰かが間違っているので、FUDを呼び出す必要があります

@NickCraver

ここでは、アプリ間で共有される多くのライブラリなどが使用されています。 Stack Overflowは多くのアプリケーションです(メインのウェブサイトはほぼ完全に単一のアプリですが、会社として:私たちは多くの関連するコミュニケーションのものを持っています。

これは、Razorページを使用できないことを意味します。ASP.NETCore2.0には小さな機能がたくさんありますが、1.xにバックポートされていない大きな機能や修正はありません。 EOLのことは非常に現実的であり、個人的には、ASP.NETCore2.0が.NETFrameworkをもう1年間サポートすることは役に立たないと思います。 ここでは、方向の変更について実際に話し合っています。.NETFrameworkを永久にサポートするかどうかにかかわらず、その間には実際にはありません。

@dustinmorisはそれだけではありません。 期待の問題でもあります。 あなたのユースケースは他の人と同じではないかもしれません。

aspnetcore 1. *アプリを開発し、.NETデスクトップをランタイム(エンタープライズ用のLOB)として使用しています。

そして、私は.netコアランタイムとnetstandardなどの違いを理解しています(これがそれについての誤解についてのコメントではないことを確認するためだけに)

フロー/ビジョンなどを統合し、.netコアに移動した後(可能な場合)がaspnetcoreの選択の決定的なシナリオであったため、最初にaspnetコアに移行しました(.netデスクトップをターゲットにしています)。

aspnetcore 1. *は常に「両方のフレームワークで実行」として販売されており、次のバージョン(バージョンまたは年)の削除に関する警告はゼロであるため、この問題は少し予想外です。
私は、少なくとも廃止された->廃止されたサイクル、または単にサポートされていない機能を期待していました(それは問題ありません)。

.net(およびWebスタックの選択肢としてのaspnet)の良いところは、既存のコードベースとライブラリを活用できることです。
一部は内部的なものであり、ターゲット(.net core / netstandard)が流動的すぎる場合、これらを移行するための実際の投資収益率はありません。
一部は外部であり、変更が困難です。これらがnetcoreapp2クロージャーで機能しない場合、これらを使用することはできません。

さらに、私のアイデアはnetcoreapp2 netstandard2に慰められました。
libsのnetstandard2への移行をまだ評価していない場合、どうすれば評価を開始できますか? プレビュービットと約束に基づいて移行を評価することは困難です(そして最近の年は約束の安定性に対する私の信頼を低下させました)

私は完全なグリーンフィールドとは異なるシナリオであることを理解していますが、グリーンフィールドが既存のシステム(excel / pdf / etc)と対話する必要があるため、いくつかのライブラリを再利用したい場合は、すべてをスクラッチから書き直す必要はありません。
または、最新のトレンドであるという理由だけでマイクロサービスをrpcとして追加します。これは、物事をより複雑にするためです(これは、既存のライブラリをラップすることを強制されるのではなく、評価して実行したい、わかりやすい選択です)。 アーキテクチャを変更するだけでなく、価値を提供する必要があります(aspnetcore開発フローは素晴らしく生産的です)。

エコシステムの個人的な評価では、私のユースケースでは、.netコアやnetstandard libの可用性が低すぎます(すべての人が無料のnuget.org oss pkgを使用しているわけではありません)。 したがって、新しいスタックにハードに移行する必要がある場合は、他のスタックも評価する必要があります(コスト/利益/将来/信頼など)

私はTODOWebアプリを作成しているだけでなく、何年もの準備が整っているので.NETを使用しているので、1つ変更できます(この場合はaspnetcoreで、残りはこのイテレーションのままにしておきます)。
私のシナリオでは、すべてを変更するだけで災害のレシピになります。それを行う必要がある場合は、libが存在する別のスタック(java / nodeとして)に移行する方が理にかなっているかどうかを実際に評価し始める必要があります。

スムーズな移行には時間がかかります。将来のaspnetコアのビジョンが気に入っています。 しかし、私が明確な道筋を持っていない場合(またはそれについて疑問がある場合)、社内で販売することは困難です。

とは言うものの、.netデスクトップを残しておくと、aspnetチームの良い賭けになり、より速く移動し、より多くの新しいユーザーを選ぶことができます(または、node / javaへの流れを失わないでください)。
しかし、確かに、遅いリングでの開発者の生活は難しくなります。これはaspnetチームコール(彼らの製品)です。
私のフィードバックは、それを行わず、fwをサポートするために一生懸命働くことです。なぜなら、開発者として、信頼と安定性が必要であり、昨年は.netエコシステム(netcore / project.jsonだけでなく、以前また、マーケティング/エバンジェリストは信頼を下げるのに役立ちませんでした)

@ yaakov-h

ASP.NET Core(1.xまたは2.x)に移植する場合は、別のプロセスが必要になります。 ASP.NET CoreはSystem.Webで実行されないため、同じプロジェクトで段階的な移植を行うことはできません。

.NETCoreが同等またはそれに近い状態になったら.NETFrameworkのサポートが廃止されてもかまいませんが、十分に高度なアプリケーションにはまだかなり遅れており、2.0がそのようなものにするのに適切な場所ではないと思います。重大な変化。

それを落とす適切な時期はありません。 .NET Frameworkと同等になることを意図したものではなく、移植されない依存関係がある可能性があります。 それを考えると、私の質問は、アプリケーションを再設計するのか、それとも現実的に.NETFrameworkを永遠に使い続ける必要があるのか​​ということです。

@davidfowlは、アップストリームの依存関係に完全に依存しています。 この時点で、私たちは.NETFrameworkに永遠にとどまるでしょう。

興味深いことに、ほとんどのサードパーティ製のものには、すでにnetstandardリリースがあります。 .NET Frameworkを維持しているのは主にMicrosoftの依存関係であり、それらの一部は半ば放棄されているようです(ODataなど)。

@NickCraver私は侮辱したり侮辱したりするつもりはありません。 これは最近の変更であり、コミュニティのどのセクションも影響を受けるのはイライラします。影響を受けた場合は、おそらく大騒ぎになるでしょう。 私はそうではありません(私が働いている場所ではまだASP.NET WebAPI 5.2.3を使用しています)ので、状況に対する私の見方はそれほど感情的ではありません。

このように見てください。今日、次のStack Exchange(それが何であれ)を最初から構築する場合、ASP.NET Coreチームが使用したいnetcoreapp20にあるものではないでしょう( UTF8StringsやPipelinesのように、割り当てが少なく、非同期の_fast_プリミティブ(少し推測しています))は、完全な.NETよりも魅力的ですか? .NET Core 2.0は、通常、完全な.NET 4.7.1よりも意味がありませんか? 進化して変化に迅速に適応できるWebスタックと、サポートについて心配する20年近くのレガシーコードを備えた動きの遅い基盤となるテクノロジーに取り返しのつかないほど結びついているWebスタックを選択する場合、どちらを選択しますか?

@ZigMeowNyan

私は、この動きが.NET Standardのサイドラインの可能性を示していることを、他の部分よりも懸念しています。 .NET Standardは当初、消費者が進化し成長するプラットフォームに移行できるようにしながら、さまざまな実装を機能の同等性にますます近づけるもののように見えました。 今では、.NETCore機能のマイルストーンに過ぎないように聞こえます。 実行可能ファイルを.NETStandardのターゲットにすることはできません(またはターゲットにすることはできません)。ライブラリのみです。 また、.NET Standardに関連する計画は大幅に少なくなるようです。代わりに、変更するには遅すぎるため、ASP.NETで使用されたものにラバースタンプが付けられます。 結局のところ、それはすでに生産されているでしょう。

これらは実際には本当に良い点であり、検討する価値のあるものです。 .NET Standardが傍観されていることとは何の関係もなく、単なる物理学であることを理解する必要があります。 各.NETプラットフォームが独自のペースで動く場合、最新の.NET Standardを使用することは、動きの遅いフレームワークが物事を取得する頻度が少なくなることを意味します。 それは誰もが内面化すべきものです。 それはそれをそれほど有用にしません、それはただ獣の性質です。 この負担を取り除く唯一の方法は、.NETが実行できる場所を大幅に狭める単一の実装と単一の出荷スケジュールを持つことです。

他の開発者は、コードにコンパイラ指令を振りかけ、コードをプラットフォーム固有のライブラリに分割し、複数のターゲットでコンパイルする必要があります。 私の失礼な部分は、ASP.NET Coreチームにドッグフードを提供してもらいたいので、マルチターゲティングおよびマルチプラットフォームシナリオのランタイムとツールのサポートの向上に関心があります。 そして、あなたのチームがそれを望むなら、私たちはそれを手に入れるかもしれません。 私の実際的な部分では、少なくとも、.NETStandardを対象としたASP.NETCoreの定期的なリリースが必要であると述べています。 とにかく実際の安定したリリースを作成する必要があります。 マスターブランチをgitからコンパイルして本番環境にデプロイするだけではありません。 .NET標準の小さなイテレーションを実行し、タグ付けされたASP.NETリリースと一致させてみませんか?

私たちは同じことをします、覚えておいてください、私たちはまだたくさんのライブラリのnetstandardをターゲットにしていて、それらはifdefを含んでいます。 ただし、2.xの時間枠で新しいAPIを利用できるように設定するために、netstandardをターゲットにしているものもあります。

要するに、私はあなたがしていることとその背後にある目標を支持します。 そして、私たちがここに乗って、あなたが非常に正当な理由で下した決定について不平を言うのは難しいことを私は知っています。 しかし、多くの人はパイオニアトレインに乗れないのでジャンプしませんし、他の人はどこに行くのかわからないのでジャンプしません。

正直な質問(これはマイクロソフトではなく私に尋ねています)、新機能よりも互換性を優先しますか? はいの場合、なぜASP.NET Coreを選択するのですか?

もう1つの簡単な考え:このようなすべてのスレッドには、「古い」.NETのサポートへの譲歩が行われたために、異なる、しかし同じくらい大きなグループの人々が同じように動揺した、同等であるが反対のスレッドが存在します。

興味深いことに、ほとんどのサードパーティ製リリースには、すでにネットスタンダードリリースがあります。 .NET Frameworkを維持しているのは主にMicrosoftの依存関係であり、それらの一部は半ば放棄されているようです(ODataなど)。

😞

@markrendle

•このスレッドで見られる不満の多くは、ライターが実際に「.NET Core 2.0でXを実行する方法を変更する必要がある」という意味で、「。NETCore2.0でXを実行できない」のバリエーションです。 。 はい、変更する必要があります。 いいえ、それは悪いことではありません。 ASP.NET MVCアプリケーションにPDFまたはDOCXファイルで何かを行う小さな個別の機能があり、それを実行するためのより良い方法を本当に見つけることができない場合(試したことはありますか?)、それを破ります機能をWindowsServer上の完全な.NETで実行されているマイクロサービスに組み込み、.NETCoreアプリケーションからHTTPAPIとして呼び出します。 アプリケーションを分解し、特定の機能を小さな自己完結型のサービスに移動することは、回避策でさえありません。これは、汎用のベストプラクティスです。
注意:私が知る限り、OpenXMLパッケージは現在.NET Standardをサポートしているため、Word /Excel/その他の操作は不可能ではありません。<<

他の人がすでに述べたように、私たちの素晴らしいデザインのアーキテクチャを変更することは良い計画ではありません。 この場合、アプリケーションのWPFテストとサーバー間でコードを共有します。 維持するのがより複雑なものの間で私たちが作成するより多くの違い。

PDF、DocX生成に使用するのに最適なツールの調査に多くの時間を費やしてきましたが、オープンXMLを使用する場合ほど簡単ではありません。 サードパーティのライブラリを使用しているのは、サードパーティが開発したコードが数万行あり、開発/保守/テストする必要がないためです。 それが要点です。

.netのバージョン管理は非常に複雑になっています。 将来、ASP.netを完全な.netフレームワークで使用できるようになるかどうかはわかりません。 サーバーとデスクトップアプリケーション間でコードを共有する必要があるため、最新バージョンのASP.Netを使用できないということですか? これは短期的には問題ではありませんが、長期的にはセキュリティの改善などにより、最新バージョンから離れすぎたくありません。 私のボートには、完全なフレームワークとの何らかの形の互換性が必要な他の多くのものがあると確信しています。

私がしていることを明確にするために、さまざまなWPFアプリとサーバー間で共有される独自のライブラリが3つあるということです。 この時点では、使用しているApiが.netコアで使用できるかどうかはまったくわかりません。 そして、それらのライブラリでは、docxとpdfを生成するためにTelerikとSyncFusionの両方のWPFツールのフルデスクトップバージョンを使用しています。 これらのツールが使用する機能の一部またはすべては、.netコアで使用できる場合とできない場合があります。 に基づいてアプリケーションを開発しようとすることは、非常に困難です。 Microsoftは.netに優れた基本フレームワークを持っており、私は.netコアの背後にある理由を理解しています。 Microsoftは、下位互換性の重要性を忘れているようです。

ステファン

@markrendle

ああ、すみません、あなたのサンプルサイズがそれほど大きいことに気づいていませんでした。 決定を嫌う人々に強い偏見を持った257のコメント? それについて議論するのは難しい。 免責事項:私はビッグデータの専門家ではありません。

私があなたに何をしたかはわかりませんが、このようなスナークや低レベルの泣き言は必要ありません。 このスレッドはほんの一例です。

@stefanolson

.netのバージョン管理は非常に複雑になりました

これは私たち全員が同意できる数少ないことの1つだと思います。

.NetCorexへの移植を検討しています。
私たちの最大の問題は次のとおりです。
NewRelic (.Net Coreプランがないため、代替案を見つける必要があります)
NH (EFコアに機能がない場合)。
ServiceBase (夏に.Net Core 2に登場するようです)

確かに、暫定的にCore 1.0をターゲットにして、NH、EFのアップグレードを待つか、クリエイティブになる必要があるようです。

これは、Razorページを使用できないことを意味します。ASP.NETCore2.0には小さな機能がたくさんありますが、1.xにバックポートされていない大きな機能や修正はありません。 EOLのことは非常に現実的であり、個人的には、ASP.NETCore2.0が.NETFrameworkをもう1年間サポートすることは役に立たないと思います。 ここでは、方向の変更について実際に話し合っています。.NETFrameworkを永久にサポートするかどうかにかかわらず、その間には実際にはありません。

Razorページより少し大きいので、移動する理由はありません。 これらの両方が存在する(現在の)シナリオは存在しません。

  1. ずっとサポートされます
  2. 反対側に実際のアップグレードがあります

事実、ASP.NET Coreは、エコシステムなしではそれほど有用ではありません。 テキストを元に戻すコントローラーがあることは素晴らしいことですが、それほど多くのシナリオでは役に立ちません。 APIが必要です。 ライブラリが必要です。 エコシステムが必要なため、そもそも.NETを選択しました

この変更は、今日のユースケースを完全にサポートするフレームワークから、明らかに準備が整っていないフレームワークに移行します。 準備が整っているとは言えません。 また、準備ができているかどうかをテストするためのプレビューは、一般的には利用できません。 何が準備できるかについての約束を理解するための移行は利用できません。 私たちはたくさんの約束を果たしており、多くは燃やされるでしょう。 これは、これらのものを売り込むための最悪の方法です。つまり、過剰な約束と過剰な配信(全体的なエクスペリエンス)です。

ASP.NETCoreは素晴らしいと思います。 あなたたちは素晴らしいことをやっています。 私は幸運にもそれのいくつかを手伝うことができました。 しかし、この時点でのこのスイッチは悪いです。 移植されると思われるものすべてが実際に2.xの時間枠で移植されるのであれば、すばらしいことです。 次に、3.xで変更を加えます。 代替案の準備が整う前に移植し、EOLライフラインをいつ終了するかの期限を設定するのは悪いことです。 メンテナンスに移植するように人々に指示する->EOLバージョンは悪いです。

今はこの変更を行わないでください。 .NETはこれよりも優れています。 ここにいる全員があなたのことを気にかけているのと同じくらい、ユーザーのことを気にかけていることを示してください。 助けたくなければ、私たちはここにいなかったでしょう。

@FransBoumaマイクロソフトには、テレメトリ、フィードバック、その他のデータの膨大なデータベースがあり、GitHubの問題のスレッドの数よりもはるかに明確な画像を提供していることを、よく知っているはずです。それを指摘することは、

このスレッドの投稿を読んで、わかりませんか?

.netのバージョン管理は非常に複雑になっています。 将来、ASP.netを完全な.netフレームワークで使用できるようになるかどうかはわかりません。 サーバーとデスクトップアプリケーション間でコードを共有する必要があるため、最新バージョンのASP.Netを使用できないということですか? これは短期的には問題ではありませんが、長期的にはセキュリティの改善などにより、最新バージョンから離れすぎたくありません。 私のボートには、完全なフレームワークとの何らかの形の互換性が必要な他の多くのものがあると確信しています。

さまざまな.NETランタイム間でのコード共有ストーリーは.NET標準です。 ライブラリは、.NETCoreと.NETFrameworkで共有されるコードをターゲットにする必要があります。

Microsoftは、下位互換性の重要性を忘れているようです。

問題は、ASP.NETCoreが下位互換性を持つことを意図したものではなかったことです...そのため、ASP.NET4.xからこのような大きなパラダイムシフトがありました。 下位互換性が上位ビットである場合は、.NETFrameworkでASP.NET4.xを使用する方がよいようです。 これ当面の間サポートされており、Windowsが稼働している限りセキュリティパッチが適用されます。

ただし、意図されていなかったとしても、1.0は非常に下位互換性がありました。 それは生態系の広大な遺産全体を支え、私たちはそれを高く評価しました。 当時は、誰もケーキを配ったり、食べたりする必要がなかったようです。

@NickCraver

Razorページより少し大きいので、移動する理由がありません。 これらの両方が存在する(現在の)シナリオは存在しません。

詳細を教えていただけますか?

事実、ASP.NET Coreは、エコシステムなしではそれほど有用ではありません。 テキストを元に戻すコントローラーがあることは素晴らしいことですが、それほど多くのシナリオでは役に立ちません。

それも本当に速くすることができます😉

ASP.NETCoreは素晴らしいと思います。 あなたたちは素晴らしいことをやっています。 私は幸運にもそれのいくつかを手伝うことができました。 しかし、この時点でのこのスイッチは悪いです。 移植されると思われるものすべてが実際に2.xの時間枠で移植されるのであれば、すばらしいことです。 次に、3.xで変更を加えます。 代替案の準備が整う前に移植し、EOLライフラインをいつ終了するかの期限を設定するのは悪いことです。 メンテナンスに移植するように人々に指示する->EOLバージョンは悪いです。

2.x(サポート)と3.x(ドロップ)が1.x(サポート)と2.x(ドロップ)よりも優れている理由がわかりません。 それを説明してもらえますか? それはどのように違いを生むのでしょうか?

ASP.NETバリエーションの長期サポートについて懸念している人のための//BUILD2017セッションの推奨事項のカップル:

  • T6009ASP.NETWebフォームの更新

    • つまり、彼らはまだ完全な.NETWebプラットフォームを開発しています

  • T6072 ASP.NET Coreのサポート:LTSとは何ですか?

    • 私は今、必死に更新されていると思います:grimacing:

@davidfowl

それはどのように違いを生むのでしょうか?

2.0以降に出荷される最も重要な欠落しているAPIのいくつかを約束したのでしょうか?

@ yaakov-h

2.0以降に出荷される最も重要な欠落しているAPIのいくつかを約束したのでしょうか?

ASP.NETCoreのどれを教えてください。

@davidfowl System.DirectoryServices、System.Drawingは上記のとおりです。

正直な質問(これはマイクロソフトではなく私に尋ねています)、新機能よりも安定性と互換性を優先しますか? はいの場合、なぜASP.NET Coreを選択するのですか?

これはとても良い質問だと思います。 完全な.NETFrameworkが今日必要なものすべてを提供するのであれば、完全に異なるスタックへの移行に熱心なのはなぜですか? .NETCoreとASP.NETCoreの名前が異なっていて、.NET intがなければ、移行の問題について議論する人ははるかに少ないと思います。 より高速に移動するGoまたはNode.jsWebスタックに移行できないことについて不満を言う人は誰もいません。

@davidfowlがASP.NETMVC5.xと下位互換性があることと、.netFrameworkとの下位互換性があることは別のことです。 .netフレームワークを削除することは大きなことです...

2.x(サポート)と3.x(ドロップ)が1.x(サポート)と2.x(ドロップ)よりも優れている理由がわかりません。

私たちが理解しているように、2.xはすぐに来るからです。

@davidfowl System.DirectoryServices、System.Drawingは上記のとおりです。

これらはASP.NETCore1.xまたは2.xとは関係がなく、オンラインになると両方で実行されます。

私が言ったように、私はFUDとその一部を呼び出すためにここにいます。 このスレッドは非常に大きくなっているため、一部の返信で事実を確認することはできません。

@FransBoumaマイクロソフトには、テレメトリ、フィードバック、その他のデータの膨大なデータベースがあり、GitHubの問題のスレッドの数よりもはるかに明確な画像を提供していることを、よく知っているはずです。それを指摘することは、

@markrendleテレメトリは魔法ではありません。 ppl / devが切り替えられない理由、他のスタックを切り替えた理由、プロジェクトの重要性、スタックがどれだけ好きか(そして、コンサルティングやossで他の人を助ける)、または彼らが何をしているかを測定することはできません。

このスレッドはまさにそれ、フィードバックです。

2.x(サポート)と3.x(ドロップ)が1.x(サポート)と2.x(ドロップ)よりも優れている理由がわかりません。 それを説明してもらえますか? それはどのように違いを生むのでしょうか?

@davidfowl時間。
少し落ち着く時間。 物事を評価する時間。 一度に一つのことを変える時間。 rtmのものでnetstandard2パッケージを使用する時間。 ライブラリをnetstandard1(より難しい)ではなくnetstandard2(より簡単)に移動する時間です。 私にとっては、ほとんどの場合、一度に1つのものを変更する時間です。
あなたはaspnetを実行しますが、私の製品はaspnetだけでなく、多くのライブラリとトレードオフ、およびエコシステムの組み合わせです。

私たちが理解しているように、2.xはすぐに来るからです。

それはそれと何の関係がありますか? 2.0が年末または1月に登場した場合はどうなりますか? それは違いを生むでしょうか? 1.xを価値のないものにしているのは2.0の何ですか?

@ yaakov-h @shanselmanが言ったところにここで言及されました(私の強調)

AD –全体として、LDAPを直接呼び出したい場合、これはギャップです。 あなたは確かに今すぐWindows認証に対して認証することができます。 特に夏の時間枠の前後にCore2.0のDirectoryServices名前空間を使用する予定です。
描画–全体として、これはギャップです。 これは、夏の時間枠の前後にCore2.0で使用する予定です。 これまで、これらのnetstandardオプションには、ImageSharp、ImageResizer、Monoオプションなどもあります。

@davidfowlそれはバージョンではなく、.netコアの日付と成熟度、そしてそれはエコシステムです。

@hikalkan

申し訳ありませんが、非常に高レベルのPOVからではありますが、技術的なPOVからではないことを理解しています。 多分これは技術的な議論ではありませんか?

@enricosada

少し落ち着く時間。 物事を評価する時間。 一度に一つのことを変える時間。 rtmのものでnetstandard2パッケージを使用する時間。 ライブラリをnetstandard1(より難しい)ではなくnetstandard2(より簡単)に移動する時間です。 私にとっては、ほとんどの場合、一度に1つのものを変更する時間です。
あなたはaspnetを実行しますが、私の製品はaspnetだけでなく、多くのライブラリとトレードオフ、およびエコシステムの組み合わせです。

特にASP.NETCore2.0に違いがあるのはなぜですか? ASP.NET Coreが何を選択したかに関係なく、プラットフォームからそのメリットを得ることができます。

@markrendle誰かが私にカレンダーを取得します。これは、季節が四半期全体にまたがり(同じ四半期の他の何かから3か月離れている可能性がある)、特に南半球の人々を混乱させるためです。

@enricosadaテレメトリやその他のデータソース(Web分析、検索データ、顧客からの直接フィードバック)から非常に多くの有用な情報を取得できます。 GitHubの怒っている暴徒から得られるよりもはるかに多くのことを(ただし、各個人の怒りは正当化される可能性があります)。

@ yaakov-hええと、現在予測されている.NET Core 2.0(およびASP.NET Core 2.0)のRTMはカレンダーQ3(7月/8月/9月)であり、北半球の夏は主に7月/8月/9月です。 、基本的に同じことです。

テレメトリやその他のデータソース(Web分析、検索データ、顧客からの直接フィードバック)から非常に多くの有用な情報を取得できます。

ただし、このテレメトリ(少なくとも自動化された部分)は、企業の展開に対してどれほど信頼できるのだろうか。 (そこから反発の大部分が発生しているようです。)

2.x(サポート)と3.x(ドロップ)が1.x(サポート)と2.x(ドロップ)よりも優れている理由がわかりません。 それを説明してもらえますか? それはどのように違いを生むのでしょうか?

@davidfowl時間。 そして適切な発表。 メッセージがより明確であれば、人々はそれほど驚かないでしょう。

@davidfowl時間。 そして適切な発表。 メッセージがより明確であれば、人々はそれほど驚かないでしょう。

私は理解していますが、それが実際に何かを移植する能力に違いをもたらすとは思いません。 同じEOLポリシーがまだ存在します。

さて、この問題を理解するのに苦労した後、私は私のように苦労している人々のためにいくつかの洞察をもたらしたいと思いました、そしてまたいくつかの質問があります。

したがって、正しく理解すれば、最終的にはネットフレームワークをネットスタンダードに置き換えることができます。

したがって、netcoreが存在せず、aspnetcoreがnetstandardに基づいていると仮定します。 つまり、機能が遅くなります。

例:
2017asp.netは機能Aを望んでいます。
2018netstandardは機能Aを実装します。nsで機能Aを取得します。

チームが言っているのは、netstandardに基づいていないnetcoreを使用することです。
2017asp.netは機能Aを望んでいます
2017aspnetチームは機能Aを実装します。Asp.NetCoreはnetcoreで機能Aを取得します。
2018netstandardは機能Aを実装しています。nsで機能Aを取得します。

したがって、この決定により、実際には方程式により多くの「柔軟性と速度」がもたらされます。 誰がそれらを使用できるか、フィードバックなどのためのより速いリリース。それはネットフレームワークの遅い平和への素晴らしい追加だと思います。 NSに到達すると、機能は本当に成熟します。

netstandard 2に基づくnetcoreを使用するということは、機能が1年後(または任意の時間枠)にリリースされることを意味する場合でも、人々はこれが必要だと主張しますか? これは、 NET Frameworkで慣れているシナリオです。

これはaspnetチームにとって天国であり、他の誰かに依存することなく荷物を発送することができます。また、それらの速い荷物を手に入れることができる顧客にとっても素晴らしいニュースです。 あなたが速いもので行くことができないならば、前のバージョンに固執することは合理的なトレードオフです(そしてあなた/依存関係がアップグレードする動機)。

ライブラリの作成者は、netstandardをターゲットにするようにAIMを実行する必要があります。そうすれば、まったく心配する必要はありません。
netstandardにないもの(おそらくレイザーページ(?))が必要な場合は、ネットコアをターゲットにする必要があります。シナリオ1では、レイザーページが存在しない可能性があります。 これがどのように悪いのかわかりません、私はそれが公正だと思います。

ですから、問題は、NETFrameworkからNetCoreへの移行を制限する現在の依存関係はどれかということです。
ここにいるのは私だけかもしれませんが、aspnetコアがNET Frameworkで永遠に機能するとは思っていませんでした。これが、「移行」ステップであることは明らかでした。 現在NETFrameworkを必要としている私の開発はすべてsplitedです。 (いいえ、これはマイクロサービスではありません。それよりもはるかに簡単です)。

2.xサポートおよび3.xドロップは、1.xサポートおよび2.xドロップと同じです。 ここで推測して、人々はシナリオを明確に理解していないと言うので、これが少なくともいくつかを明確にすることを願っています。

@NickCraverは、マイクロソフトにこの決定を元に戻してほしいと言っていました。 分離されたネットコアを持たず、機能のリリースが遅いというあなたの提案は何ですか? (正直な質問)

@davidfowl現在の提案には、開発者を悩ませている微妙な隠れた問題があるかもしれないと思います。
asp.net(netcoreを使用)の機能Aを使用している場合は、マーケティングと出荷(および管理/午後のチェックボックスのチェック)を行い、netstandardに実装するために「怠惰」になることができます。間違いがなければ、これが「賭け」です。不確かな点については、こちらを参照してください。
したがって、前の例では、netstandardは機能Aを2019年、2020年、または2018年の代わりに実装しない可能性があります。<-これは考えられる問題のように見えます(?)私は正しいですか? マイクロソフトはここで何かにコミットできますか?

議論に時間を費やしてくれた@davidfowl@ DamianEdwards@shanselmanのおかげで、発表が好きかどうかは私たち全員で異なります。 これは、エンゲージメントとオープン性が向上したことのさらなる証拠です。

タイミングなどについて議論する人もいると思いますが、それは進歩です。

例:
2017asp.netは機能Aを望んでいます。
2018netstandardは機能Aを実装します。nsで機能Aを取得します。

チームが言っているのは、netstandardに基づいていないnetcoreを使用することです。
2017asp.netは機能Aを望んでいます
2017aspnetチームは機能Aを実装します。Asp.NetCoreはnetcoreで機能Aを取得します。
2018netstandardは機能Aを実装しています。nsで機能Aを取得します。

彼らがすべきことは次のとおりです。
2017 aspnetチームは、netstandard2.0をサポートするlibXに必要な機能を構築します。 このように、aspnetは.netstandardが実行されるすべてのもので機能し、libXは.NETfullでも使用できるため、ユーザーは.net fullで実行できます(nugetをインストールするだけです)。

代わりに、これを行わず、lib Xを.NETコアのみにするように強制します(そうでない場合は、そもそもなぜこのスレッド/決定を行うのですか)。 lib Xが非常に高度で、CoreCLR機能が必要な場合、Microsoftは、これらの高度な機能が.NETフルCLRに移植されない理由を自問する必要があります。

全体として、MSがAzureの顧客にAzureのコンテナーで使用できるスタックを提供してAWSまたはGoogleクラウドのJVM / NodeJSベースのコンテナーと競合するために、動きの速い.NETコア/aspnetコアを必要とする政治のように感じます。 彼らのビジネスの観点から、私はそれさえ理解することができます。 しかし、それが示しているのは、MSは.NETコアに追いつくのに十分なリソースを.NETフルに配置していないため、.NETフルに関して優先順位がなくてより速く前進することです。 過去2年間に.NETに追加されたAPIの量を確認してください。 それは、大規模なチームがそれに取り組んでいることを示していますか?

いいえ。

Microsoftは、大規模なデータベースシステムであるSQLServerEnterpriseを販売しています。 それは派手な暗号化機能が付属しています。 .NETコアではサポートされていません。 その高価なデータベースシステムの潜在的な顧客である企業に.NETコア2.0を販売することを楽しんでください。

「速く」移動したい場合もありますが、移動先を完全に理解していない限り、最初にそれを決定するのに1、2分かかると役立ちます。

考えれば考えるほど、ほとんどの人が抱えている問題は、.netとasp.netの間のコードを切断していると感じていることだと思います。
現在、asp.net、asp.netコア(.net)、およびasp.netコア(コア)があります。 したがって、コアを使用しないか、ほとんど使用しないか、完全に使用するかを選択できます。

バージョン管理が十分に伝達されていないため、人々は、asp.netとasp.netコア(.net)が行き詰まっている間、それが革新と前進をしている最後の部分にすぎないと感じています。
libがnetstandard2.0で動作するかどうかを試さずに検証する方法がないため、新しいプロジェクトでフルコアを使用することは非常に危険です。 したがって、最終的にはasp.net(古い)またはasp.netコア(これも古い)になります。
また、どちらも古いため、system.webと古いasp.netを使用するのが理にかなっています。 彼らはそれを知っているので、そしてasp.netコアはとにかくEOLなので、なぜわざわざ。

したがって、最終的には勇敢な選択コアのみになり、残りは古いが安定したsystem.webになります。 そして、私たちは永遠にさらに破壊された生態系で立ち往生するでしょう。

PS:私はこれを現在の気持ちと同じように言います。 そのasp.netコア1.xは2.xに対して「古くて時代遅れ」です。 それは事実ではありませんが、それは人々が考えていることです。

@davidfowl

各.NETプラットフォームが独自のペースで動く場合、最新の.NET Standardを使用することは、動きの遅いフレームワークが物事を取得する頻度が少なくなることを意味します。

これはすでに起こっており、私たちはそれで大丈夫です。 バージョンドキュメントは通常、_vNext_で埋められます。 そして、それは大丈夫です。 標準をインクリメントする前にすべてのプラットフォームが同等になるまで待つのではなく、標準が数バージョン先に定義されていることを確認し、プラットフォームが追いつくのを監視したいと思います。 人々は定義と実装のために売り込むことさえできます。 また、ASP.NET Coreがそのリリースの標準を対象としている場合、プラットフォームとアーキテクチャがその新しい標準を実装した瞬間に、パッケージが利用可能になります。 新しい標準バージョンは、VSアップデートまたはパッケージを通じて提供される可能性があります。

.NET Standardは、コミュニティが計画した取り組みのようには思えませんが、その提示方法。 これは、レビューに合格した実装済みの契約のスナップショットのようなものです。 そして、主要なプロジェクトがそれを対象としていない場合、そのリリースに向けた計画はほとんどありません。

私たちは同じことをします

ああ、いいね。 共有された惨めさは最高の惨めさです。 platform / configのものを含むCsprojファイルとslnファイルは、ビルドの組み合わせが常に宣言されているとは限らないため、非常に煩わしいものです。これらは推測されます。 したがって、VSは、考えられるすべての組み合わせが重要であると想定しているため、実際に存在するよりも多くのビルドの組み合わせがあると考える可能性があります。 また、プラットフォームと構成の組み合わせを宣言できれば不要なセクションをファイルに追加する必要があります。 csproj PropertyGroup要素でSubstringのような関数を使用してカスタムプロパティを単純化する方法と同様ですが、これらの条件はビルド構成の決定に使用されるため、完全な文字列値をそこに含める必要があります。 この種のものは、それほど面倒なものであってはなりません。

正直な質問(これはマイクロソフトではなく私に尋ねています)、新機能よりも互換性を優先しますか? はいの場合、なぜASP.NET Coreを選択するのですか?

個人的にはありません。 私がしなければならないことをする方法がある限り、それがほとんど利益のない大きな努力やテストするPITAでない限り、コードを書き直してもかまいません。 だから私は最も勢いと可能性があるものを選びます。 ただし、Win32、COM、CORBA、ADO.NET、いくつかのレポートエンジン、さまざまなWeb API、CEF / Firefox / IEなどの組み込みブラウザー(もちろん、サポートされていないため、エッジはありません)などの複数のテクノロジにわたるプロジェクトで作業する必要があります。恥ずかしくない複数のベンダー固有のもの。 私はプラグインとしてできることを実装していますが、ほとんどの場合、ホスト実行可能ファイルで最小公分母と結婚しています。 その多くのテクノロジーに対処するのは面倒ですが、静的です。 それがデスクトップ/サーバーのものの多くです。 相互運用するためのツールが与えられている限り、私はそれを行うことができます。 しかし、私が覚えている非推奨のフレームワークは少ないほど良いです。

ただし、ASP.NETはWebスタックの一部であり、Webスタックは最新の状態に保つ必要があると私が感じているものです。 ユースケースは異なります。残念ながら、そうしない正当な理由がない限り、または重大な互換性のないコードベースがない限り、Web作業に新しいプラットフォームを使用することが期待されます。 Web標準は迅速かつ大幅に変更されるため、私はそれを最新の状態に保つようにしています。 Webのペースを維持している人のほとんどは、新しいテクノロジーに固執しており、古いスタックに新しいものを実装するのはかなり苦痛です。 特にASP.NETがPHPやNodeと競合する状況では、才能と興味を引くために、より最新のスタックを維持する必要があります。 Web作業を減らしたいのですが、残念ながら、それは新しいUIの期待です。 標準に固執することで両方の長所を活かせることを望んでいましたが、それは期間限定のオファーのようです。

したがって、正しく理解すれば、最終的にはネットフレームワークをネットスタンダードに置き換えることができます。

そうではありません。 あなたがその結論をどのように引き出したかはわかりません。 .NET Standardは、それをサポートする各ランタイムのサブセットになります。

何度か言及されているので、ここにいくつかのクレイジーなものを投げたいと思います。 私がこれから言おうとしていることは、何が起こるかには関係ありません。現時点ではすべて推測です。 何人かの人々は、なぜ.NETStandardではなく.NETCoreをターゲットにしたいのかと尋ねました。

  • 文字列を.NETCoreで取り組みたい主要なものの1つとして特定しました。アイデアはたくさんありますが、そのうちの1つは、文字列をデフォルトでutf8にすることです(互換性の問題がたくさんありますが、ここでフォローしてください)。
  • 修正したいもう1つの点は、配列/文字列の安価なスライス、隣接するメモリの任意の部分を取得する機能です。 Span<T>を追加し、これを表すためにBuffer<T>を検討しています。 これは、StringとArrayが、0の割り当てを必要とするスライスを取得できるようにする新しいインターフェイスを実装していることを意味する場合があります。
  • これにより、毎回配列を割り当てない分割を可能にするStringの新しいメソッドが作成されます。
  • これにより、Int、UIntなど(TryParse)がオーバーロードされ、 Span<char>Span<byte>が必要になります。
  • これにより、 Span<byte>を使用する新しいエンコーディングルーチンが作成されます。
  • Buffer<T>Span<T>を使用すると、メモリを統一された方法で表すことができます。ネットワークスタックをアップグレードして、 Span<T>またはBuffer<T>を使用する事前に固定されたバッファを渡すことができるようにします。
  • Kestrelは2.xタイムフレーム(現在2.1を目指しています)でHTTP2を実装し、ALPN(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)を実行するにはSSLストリームに新しいAPIが必要です。
  • .NET Core上のHttpクライアントは、二重ストリーミングをサポートします。これにより、単一の非WebSocket http要求を介して、Signalのhttpを介してストリーミングエンドポイントを実装できるようになります。
  • ヘッダーパーサーの実装をHttpClientとSystem.Net.Httpからフォークし、名前を変更して(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers)、それらを改善できるようにしました。 .NETFrameworkと.NETCoreの両方をサポートするようにします。 .NET Coreには、これらの改善のコピーがありますが、改善する必要がないため(消費できませんでした)、元に戻されていません。
  • 新しいAPIを必要とする新しいスレッドプリミティブがたくさんあり、それらを使用できる場合は新しいシナリオを照らします(https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl + label%3Aarea-System.Threading)、これらは私が個人的に提出したもののほんの一部です。

コアプリミティブを回転させる機能がない場合は、それらをフォークして、それらに似ているがそうではないものを作成することをお勧めします。 これが、ASP.NETCorehttps://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives内に独自の小さなBCLがある理由です。

これは、.NETの非常に基本的な部分に影響を与える、短期的に私たちが行っていることをランダムにダンプしたものです。

@FransBouma

.NETコアに追いつくのに十分なリソースが.NETフルに配置されていないため、NETフルでより速く前進できます。 過去2年間に.NETに追加されたAPIの量を確認してください。 それは、大規模なチームがそれに取り組んでいることを示していますか?

それは真実ではありません。 物事は継続的に.NETFrameworkに移植されますが、ご存知のとおり、リスクは.NETCoreで同じ変更を加えるよりもかなり高くなります。 .NET Frameworkへの更新によってアプリケーションが破損した場合、皆さんはそれを嫌いではありませんか? 私たちもそうしているので、それを軽減するためにあらゆる種類のプロセスを発明しています。それを維持するためにエンジニアリングにかかる​​苦痛を信じられないでしょう。 それにもかかわらず、私たちはまだ機能を実行することができます。 とは言うものの、.NET Coreほど速く移動することはなく、Windowsのスケジュールに従って出荷されるWindowsコンポーネントです。

私は理解していますが、それが実際に何かを移植する能力に違いをもたらすとは思いません。 同じEOLポリシーがまだ存在します。

@davidfowl正解です。 しかし、それをどのように組み立てるかは何かを意味します。 いつ伝達されるかは言うまでもありません。 それは必ずしも人々に実際の仕事をするためのより多くの時間を与えるわけではありませんが、それは彼らに(彼らのために)考えそして正しい決定をするためのより多くの時間を与えるでしょう。

現在、.NETFrameworkでASP.NETCoreへの移植/使用を開始した場合、次の3つの選択肢があるようです。

  1. すべてのコードと依存関係を.NETCoreに移植し、ASP.NETCore2.xに移行します。

    • これは最適なソリューションですが、大量の作業が必要になる可能性があり、サードパーティのライブラリが原因で制御できない場合もあります。

  2. ASP.NET Core1.xと.NETFrameworkを使い続けて、サポートされなくなる前に1.できることを願っています。

    • これはかなり危険です。 1年以内(または2、3?誰が知っていますか?)、サポートされていないプラットフォームで実行するリスクがあります。

  3. ASP.NET4.xに戻ります

    • この代替手段はサポートされたままですが、「戻って」、すでに開始した作業を元に戻すことができます。 そしてまた、それに直面しましょう。 このプラットフォームは、今後あまり愛されることはありません。

あなたが事前に知っていて、それを計画することができれば、私は1.と2.の両方がまともな選択肢だと思います。 問題は、両方の選択肢にかなりの数の未知数があることです。 ライブラリAはどうですか? ライブラリBはどうですか? ライブラリAは移植されますか?

今のところ、多くの人は、選択が実際に何を伴うのかを明確に把握することなく、選択を余儀なくされていると感じていると思います。

@khellang (仮想ソリューション内)

  1. .NETFramework上のASP.NETCore2.0に移行します

    • これはかなり危険です。 1年以内に、サポートされていないプラットフォームで実行するリスクが生じる可能性があります。

@davidfowl

正直な質問(これはマイクロソフトではなく私に尋ねています)、新機能よりも安定性と互換性を優先しますか? はいの場合、なぜASP.NET Coreを選択するのですか?

正直な答え:
好意:安定性と互換性が最も重要です。 新しい機能は素晴らしいですが、それらが着陸したとき、それらは単に既存のエコシステムを壊してはなりません
ASP.NET Coreが選ばれる理由:OSXとLinuxで実行されているからです。

.NET(古いおよび/またはコア)またはJavaのようなエコシステムは企業によって選択されます。 そして、彼らが決定を下すとき、彼らはそのプラットフォーム/エコシステムのためのコードを開発することに多大な努力を払います。

現在、たとえば、お客様の1人はすでにASP.NETCoreに多額の投資を行っています。 以前の発表と.NETCoreの販売されたアイデアに基づいて、コードが作成されました。 この新しい(ASP。)NET Coreコードは、(ASP).NET Coreの初期開発の過程でチームと一緒に(痛々しいほど)作成しました。最初から、サーバーとクライアントライブラリのセットであり、かなりの数があります。ビジネスロジックの。
そして、このコードは、Linuxサーバーで実行され、サービスを提供するだけでなく、現在、これらのサービスと通信する非常に古いアプリケーションのセットでも使用されています。これらは、WPF/Windowsフォーム/C++/CLIと通常のアプリケーションの組み合わせの地獄です。 C ++(DirectXのものを含む)。

そして今、実際のアプリケーションで新しい.NET Coreコードを再利用することは不可能であるため、既存のアプリケーションの.NETCoreコードへのかなりの数人年の努力でクライアントの投資を削減しているだけです。 (新しいサーバーとビジネスロジックライブラリはのために構築されました)。

質問に戻ると、企業は.NET Coreを「.NET、現在はXPlatにも」として選択しますが、過去17年間に.NETが提供してくれたのとまったく同じ互換性と安定性を期待しています。 そして、率直に言って、これが.NETCoreの唯一の理由です。 それを望まない場合は、Node.jsまたはJavaを使用します。 どちらも、現在.NETCoreよりもはるかに成熟していてXPlatです。

そして、もう少し詳しく説明します。.NETCoreは、project.jsonやその他すべてを使用して、初期の段階ではクールでペースが速かったです。 そして、「。NETとの互換性」の理由から、project.jsonは、Msbuildと.csprojを再び支持して私たちから取得されました。 そして今、まさにこの「.NETとの互換性」の利点も取り除かれ、..正確には何ですか?

@gingters

まず第一に、素晴らしい返事!

ASP.NET Coreが選ばれる理由:OSXとLinuxで実行されているからです。

それに基づいて、モノラルのMVC 5はあなたが本当に望んでいたもののようですよね?

質問に戻ると、企業は.NET Coreを「.NET、現在はXPlatにも」として選択しますが、過去17年間に.NETが提供してくれたのとまったく同じ互換性と安定性を期待しています。 そして、率直に言って、これが.NETCoreの唯一の理由です。 それを望まない場合は、Node.jsまたはJavaを使用します。 どちらも、現在.NETCoreよりもはるかに成熟していてXPlatです。

そして、もう少し詳しく説明します。.NETCoreは、project.jsonやその他すべてを使用して、初期の段階ではクールでペースが速かったです。 そして、「。NETとの互換性」の理由から、project.jsonは、Msbuildと.csprojを再び支持して私たちから取得されました。 そして今、まさにこの「.NETとの互換性」の利点も取り除かれ、..正確には何ですか?

これが基本的に問題の核心です。 あなたの評価に基づく:

この新しい(ASP。)NET Coreコードは、(ASP).NET Coreの初期開発の過程で、チームと(痛々しいほど)作成しました。

古き良きASP.NET4.xと互換性のあるLinux上の既存の.NETFrameworkが本当に必要でした。 それは公正な要約ですか?

好意:安定性と互換性が最も重要です。 新しい機能は素晴らしいですが、それらが着陸したとき、それらは単に既存のエコシステムを壊してはなりません。

.NET Coreは、デスクトップでは不可能な場合にサイドバイサイド実行を可能にするため、実際にはデスクトップよりも安定したプラットフォームです。

デスクトップの次のバージョンで新しい機能を使用する場合は、マシン全体をその新しいバージョンにアップグレードする必要があります。これは、新しい機能を使用するアプリだけでなく、そのマシンのすべてに影響します。 単一の目的のための専用サーバーがある場合、これは問題ありません。 ただし、同じサーバー上でさまざまな速度でアップグレードする(またはまったくアップグレードしない)アプリが多数実行されている場合はそうではありません。

@davidfowlは書いた:

.NET Framework、UWP、.NET Core、monoなどで実行するかどうかを決定するのはフレームワーク次第です。それは選択です。 Orleansには.NETCoreは付属していません。 ASP.NETCoreはそうします。 それらの製品は同じものです。

Orleansの場合、「2.0TechnicalPreview」ビルドで.NETStandard 1.5をサポートしていますが、安定したリリースを作成できるように.NETStandard2.0を待っていました。 現在、私たちにとってブロッカーは見当たりません。私の懸念は、将来の分岐についてのみです。 ただし、その相違はある時点で発生する必要があります。

👍みんなの質問に答えるために頑張ってくれてありがとう、 @ davidfowl &co!

.NETコアに追いつくのに十分なリソースが.NETフルに配置されていないため、NETフルでより速く前進できます。 過去2年間に.NETに追加されたAPIの量を確認してください。 それは、大規模なチームがそれに取り組んでいることを示していますか?

それは真実ではありません。 物事は継続的に.NETFrameworkに移植されますが、ご存知のとおり、リスクは.NETCoreで同じ変更を加えるよりもかなり高くなります。 .NET Frameworkへの更新によってアプリケーションが破損した場合、皆さんはそれを嫌いではありませんか? 私たちもそうしているので、それを軽減するためにあらゆる種類のプロセスを発明しています。それを維持するためにエンジニアリングにかかる​​苦痛を信じられないでしょう。 それにもかかわらず、私たちはまだ機能を実行することができます。 とは言うものの、.NET Coreほど速く移動することはなく、Windowsのスケジュールに従って出荷されるWindowsコンポーネントです。

これは、依存しているライブラリをnetstandard2.0パッケージとしてリリースできるという事実を無視しているため、aspnetは.netでも完全に実行できます。 さらに、.NETを完全に変更することにはリスクが伴いますが、1回の変更ですべてが崩壊する可能性がある、ひどく整理されたコードの山のように聞こえないようにしてください。

それにもかかわらず、私たちはまだ機能を実行することができます。

ええ、他のすべての.NET開発者もそうです;)何かをリリースすると、そのAPIに固執し、私たち全員がこれを手に入れます。 ただし、ショートカットを使用して(ASPNETチームがこれまでに何度も行ったように!)、その負担をかけずに移動したいと考えています。 しかし、それは最終的には飛ぶことはありません。

とは言うものの、.NET Coreほど速く移動することはなく、Windowsのスケジュールに従って出荷されるWindowsコンポーネントです。

ここに問題の核心があると思いますよね? .NETコアチームは、巨大な「WinDiv」と通信することなく、やりたいことを実行できます。 なぜマイクロソフトはこの内部政治のがらくたを社内で解決せず、.NETフル+ .NETコアがWindowsの政治なしで適切にバージョン管理/移動されていることを確認しないのですか?

ところで、SQLServerEnterpriseの暗号化APIを.NETコア2.0ユーザーに販売する方法にまだ興味があります。

また、追加する必要があります。 非常に多くの人々が関わっていながら、まだ市民でありながら、このスレッドがどれだけ長く続いているかにかなり感銘を受けました❤️それはインターネットで毎日見られるものではありません👏おそらく.NET OSSエコシステムは結局成長していますか? 😉

これは、依存しているライブラリをnetstandard2.0パッケージとしてリリースできるという事実を無視しているため、aspnetは.netフルでも実行できます。

さらに、.NETを完全に変更することにはリスクが伴いますが、1回の変更ですべてが崩壊する可能性がある、ひどく整理されたコードの山のように聞こえないようにしてください。

それは大きく、長い間存在してきました。 他のレガシーシステムと同様に、一部の部分は他の部分よりも優れています。 コードの信頼性が低下することはありませんが、一部の部分を変更することは事実上不可能になります。 ベテランが、ある領域のバグ修正が他の部分のアプリケーションのあいまいなシナリオをどのように壊したかについて、非常に多くの楽しい話があります。 それは絡み合っています、それは依存関係の境界がうまく定義されていないときに起こることです。 私がreferencesource.microsoft.comにアクセスして閲覧するだけだと信じる必要はありません。 インプレース更新は、.NETFrameworkへの単一の潜在的に破壊的な変更のために構成スイッチを追加する必要がある理由です。 それは物理学です、それはただ速く動くことができません。

ええ、他のすべての.NET開発者もそうです;)何かをリリースすると、そのAPIに固執し、私たち全員がこれを手に入れます。 ただし、ショートカットを使用して(ASPNETチームがこれまでに何度も行ったように!)、その負担をかけずに移動したいと考えています。 しかし、それは最終的には飛ぶことはありません。

ショートカットが大好きです! 開発者は怠惰です😄。 また、.NET Frameworkが表すものを中断することなく、.NETCoreを真に改善したいと考えています。 たぶん、Sparkle😄のような別の名前に変更する必要がありました。

ここに問題の核心があると思いますよね? .NETコアチームは、巨大な「WinDiv」と通信することなく、やりたいことを実行できます。 なぜマイクロソフトはこの内部政治のがらくたを社内で解決せず、.NETフル+ .NETコアがWindowsの政治なしで適切にバージョン管理/移動されていることを確認しないのですか?

物理学についての他の答えを読んでください。

ところで、SQLServerEnterpriseの暗号化APIを.NETコア2.0ユーザーに販売する方法にまだ興味があります。

それは私の専門分野ではありません。他の誰かに答えさせます。

@khellang lolは、GitHubの問題がまだトロルを嫌うMSを引き付けていないためです。 現在、Twitterは、まだ反対票が出ていないメディアです:)

@davidfowl

古き良きASP.NET4.xと互換性のあるLinux上の既存の.NETFrameworkが本当に必要でした。 それは公正な要約ですか?

いいえ、そうではありません。 私たちのクライアントは、既存の.NET 4.x(私たちが始めたときは3.5でした)Windowsデスクトップアプリケーションを補完するために、完全に新しい/光沢のある(マイクロ)サービスを必要としていました。

光沢のあるCoreのすべてをベータ版にしたとき、ASP.NET Coreの上に、付随するDTO、ビジネスロジック、クライアントライブラリとともに、まったく新しいMVCの新しいサーバーコードを書き始めました。既存の4.6デスクトップアプリケーションで並行して使用され、まったく新しいサーバーと通信します。

また、まったく新しいASP.NET Coreサーバーの一部は、Linuxでのみ実行されるのではなく、Topshelfを使用したWindowsサービスとしても実行されます(完全な4.6フレームワークに加えて)。

つまり、多くの投資が行われ、現在は.NET Core 1に固執しているようです。これは、2に移行する(そしてnetstandardを失う)ことも意味するため、アセンブリを再利用できないことを意味します。既存のデスクトップアプリケーション(サービスと付随するライブラリが作成された)はもうありません。

したがって、私たちにとって最も重要なことは、サポートされている状態を維持しながら、.NET 4.6デスクトップアプリケーションで作成した新しい(ASP).NET Coreライブラリを引き続き使用できることです(そのためにビルドされたため)。コードを実行できるデスクトップ.N​​ETバージョンがサポートされている限り、.NETCoreバージョン。

したがって、.NET Core1.が.NET4.6のようにサポートされ、.NET5がリリースされたときに.NETCore xへの線形アップグレードパスがあり、.NETCorexコードがで実行できる限り。 NET 5なら、問題ありません。

@gingters asp.netサービスのnetstandard2.0にない.net機能を使用していますか?

そうでない場合は、ライブラリは正常に機能するはずです。 しかし、あなたはnetstandard2.0にないものについて話していると思います。

@davidfowl c ++ / clidllはnetcoreapp2.0で動作しますか? 古いサードパーティのC++/ CLIアセンブリがありますが、これはすぐには置き換えられません。

@davidfowlは書いた:

ASP.NET Core 2.0には、正直なところ、それほど多くの新機能はありません。

どちらの場合、なぜこの非常に破壊的な変化が今起こっているのでしょうか?

@qrli C ++/CLIはCoreCLRでは機能しません。 サポートされない理由の背景は次のとおりです: https ://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

1xに4年間のサポートを提供し(2xから可能な限り移植)、2xで高速に進みます。 遅い都市交通のためのシティカーと高速道路のためのフェラーリ。 .netの世界以外でも多くの競争があります。
ASP.Net Coreが成功した場合、MSは1xを4年間サポートするためのリソースを提供すると確信しています。 ほとんどの場合、文化は変わります。

@idg10実際にはそうではありません。 2.xはほぼ1.xであり、コアでのみ使用可能なパフォーマンス機能を備えています。 主な機能はRazorPagesだけだと思います。

したがって、バージョン1.xを使用しているからといって、古いバージョンを使用しているとは限りません。 しかし、これはあまりうまく伝えられていません。

どちらの場合、なぜこの非常に破壊的な変化が今起こっているのでしょうか?

これはそれをかなり要約していると思いますhttps://github.com/aspnet/Home/issues/2022#issuecomment-300141134

@hallatore
私はそれが_今_そうであるように、それが機能することを知っています。 今のところ1のままです。 問題は今後も続くでしょう。 (ASP).NET Core 2ライブラリにアップグレードする必要がある場合(つまり、1がサービスを停止し、重大なセキュリティホールが修正された場合)、アップグレードできないという問題に直面します。 .NETデスクトップアプリでアップグレードされたパッケージを必要とするライブラリを使用できなくなります。

編集/追加:既存のレガシーデスクトップアプリの線形アップグレードパス上にある、新しい固定の.NETCorelibを実行できる新しい完全な.NETFrameworkがない限り。

@gingtersわかりません。

デスクトップライブラリがnetstandard2.0で動作する場合は、コアでも実行する必要があります。 (彼らがwpfのものなどを呼び出す場合、もちろん彼らはしません)
この場合、asp.netcore2.0を使用できるはずです。

デスクトップライブラリがnetstandard2.0にないものを使用しているために、コアでクラッシュした場合。 次に、1.xにとどまる必要がある理由がわかります。 そして、なぜ短いEOLが問題になるのかがわかります。

2.xには主にコアパフォーマンスのものしか含まれていないことがわかっている場合、1.xの方が簡単/より良い選択になります(1.xは2.xに対して古くないことを意味します)。 そして、その1.xはパッチを取得し、*年間サポートされますか?

@hallatoreそれは逆です。 古いアプリケーション:Windowsフォーム、WPF、C ++ / CLI、通常のC ++、DirectX、数百万行のコードなどの組み合わせ。pp、4.6フルフレームワークで実行。

.NET Coreの場合:新しいビジネスロジックライブラリ(他のライブラリ、つまり.NET CoreバージョンのSerilogも使用)、抽象化ライブラリ+サービス+これらのサービスのクライアントライブラリ。 サービスはLinux上でWindowsサービスとして実行する必要があります(現在、Windowsサービスサポートが変更される可能性のあるCoreに到達するとすぐに、完全な.NET 4.6フレームワーク上のTopshelf)。

現在、新しいビジネスロジックと抽象化、およびサービスクライアントライブラリも.NET4.6アプリケーションから使用されています。 これは、デスクトップアプリが実行する限り、完全な.netフレームワークで実行する必要があるため、アップグレードできないことを意味します(完全なフレームワークでない限り、デスクトップが存続できる限り、ほとんどの場合、アップグレードできると想定できます)。一般的に消えます)。

@gingters引き続きnetstandard_min(usable)_を対象とするソリューションに共有ライブラリプロジェクトを含め、ASP.NET Core 2.0コードからそれらのライブラリを使用し、WPF、Xamarin、UWPなどから使用できるようにパッケージ化することができます。

あなたのMSの人たちがまだポイントを得られないのは本当に悲しいことです。 あなたはまだそれがAPIギャップの問題だけだと思います。 あなたはまだ人々が彼らのコードを修正することができると思います、そしてそれはnetcoreappで働くでしょう...私はあなたがグーグルよりはるかに企業をよく理解していると思いました。

それに基づいて、モノラルのMVC 5はあなたが本当に望んでいたもののようですよね?

@davidfowlつまり、さあ。 それは否定的で率直に侮辱的な答えです。 MSの誰かが、単一の開発者がFramework ASPに割り当てられていることを確認できますか? 私はここで急いでいるつもりはありませんが、時々コミュニティが話しかけられているようです。

.NetCoreとASP.NetCoreを同じ製品と見なす必要がある理由はありません。 それをサポートするメッセージはまったくありません。 特に、Monoが.NetCoreの発表の_後_にMicrosoftの翼の下にあったことを考えると。 これは常に、.Netのより小さくて機敏なxplatバージョンとしてメッセージが送信されてきました。 それだけでなく、ASP.NetCoreが実際にはASP.Net5であり、どこでも機能するようになった時代を私たちは皆覚えています。 ちなみに、その変化は1年半ほど前のことです。

netstandard20の自己ホスト型HTTPストーリーは、効果的に「Kestrel 1.xを使用」していますか? ナンシーの人々がそれを大いに気にかけてくれるかどうかはわかりませんし、私もそうは思いません。ASP.Net2.xは機能的には段階的かもしれませんが、Kestrel 2には、その日に真剣に使用できる重大なパフォーマンス上の利点があります。出てくる。

@davidfowl

それは大きく、長い間存在してきました。 他のレガシーシステムと同様に、一部の部分は他の部分よりも優れています。 コードの信頼性が低下することはありませんが、一部の部分を変更することは事実上不可能になります。 ベテランが、ある領域のバグ修正が他の部分のアプリケーションのあいまいなシナリオをどのように壊したかについて、非常に多くの楽しい話があります。 それは絡み合っています、それは依存関係の境界がうまく定義されていないときに起こることです。

これは面白いコメントだと思います。 @davidfowl@DamianEdwardsがASP.NET4のレガシーの断片を取り除いて、本当に残したいと思っていた古いNDC会議セッションの記録を見たのを覚えています。コードのブラックボックスの内部を覗くのは本当に魅力的でした。

しかし、このコメントは、私たちの多くが私たち自身のコードベースに対して抱いている懸念も反映していると思います。 私たちは大規模なレガシーシステムを維持していますが、依存関係の境界が不十分なため、うまく設計されていないことがよくあります。 これらのシステムの一部を.NETCore用に書き直すことは事実上不可能です。 ビジネスは、それほど多くの変化のリスクを単純に許しません。

正解はわかりません。 しかし、私たち自身のアプリケーションでは、近い将来、完全なフレームワークとASP.NET4 / MVC5を使用することを知っています(WebFormのチャンクはまだしばらくの間書き直されません!)。 MVC5がGitHubに_最終的に_移動されたので、MVC5が愛されることを願っています。私は、MVC5を改善するために自分の時間と労力を寄付するつもりです(たとえば、非同期サポートの改善、パフォーマンスの改善など)。

@qrli Enterprisesには、Windows Server 2008 R2 IIS7.5Webファームで実行するための完全な.NET4.5がまだあります。 誰もそれを彼らから奪っていません。

@mattnischan

netstandard20の自己ホスト型HTTPストーリーは、効果的に「Kestrel 1.xを使用」していますか? ナンシーの人々がそれを大いに気にかけてくれるかどうかはわかりませんし、私もそうしません。

HttpListenerはnetstandard20の一部であるため、netcore20もnetcore20に移行することでその前線で何も取り除かれていません。

HttpListenerはnetstandard20の一部であるため、netcore20でもあります。

そして、私はHttpListenerから毎秒同じリクエストを期待できると思いますか?

@markrendleTrue 。 今のところ。

しかし、私たちの共有コンテンツ(つまり、serilog、newtonsoft、autofacなど)で使用される他の1つのライブラリが、netstandard_min(usable)のサポートを終了した場合(おそらく、両方の世界をサポートするための努力が多すぎると感じたため)、何を提案しますか?まだ完全なフレームワークをサポートしている最新バージョンで検出された重大なセキュリティ問題がありますか?

@mattnischan

HttpListenerはnetstandard20の一部であるため、netcore20でもあります。

そして、HttpListenerからの1秒あたりの同じリクエストを期待できると思いますか?

では、ナンシーは.NETStandard 1.6なので、Core2.0で使用してKestrel2.0を使用できます。 より良い?

@gingtersあなたがそれに来たら、その橋を渡ることをお勧めします。

未来があなたを邪魔させないでください。 あなたがしなければならないなら、あなたは今日あなたを現在に対して武装させるのと同じ理由の武器でそれに会うでしょう。
_〜マーカスアウレリウス_

これは、メンテナンス予算がなく、今後何年もほとんど変更せずに使用する必要があるソフトウェアを提供する場合のマントラとしてはあまり役に立ちません。

それが今後何年にもわたってほとんど変わらなければならないのなら、なぜそれが今後何年にもわたって依存している図書館に何が起こるかが重要なのでしょうか?

@markrendleここで、アプリケーションのバージョンが出荷される前に、法律によって(少なくとも一部の国では)緊急プロトコルを提供する必要があると仮定します。これは、人々の命が危険にさらされる可能性のある環境で使用される可能性があるためです。 。

それで、Kestrelと同じくらい高速なWebサーバーが必要であり、唯一の特定の要件は、Kestrelではないということですか?

では、ナンシーは.NETStandard 1.6なので、Core2.0で使用してKestrel2.0を使用できます。 より良い?

@markrendle @benaadamsいいえ、誤解していると思います。繰り返しになりますが、ASP.Net Coreには、すべてではない他の顧客がいることを指摘するだけです。 Kestrel 2.0がリリースされたら、本番プラットフォームをホストしたいと思います。本番プラットフォームはしばらくの間Framework上にある可能性があります。 netcoreapp20をターゲットにできません。

ナンシーはnetstandard16かもしれませんが、Core2.0以外ではKestrel2.0を使用できないため、問題ではありません。 これは具体的なことだと思います。おそらく答えは、「Kestrel2と同じくらい高速なフレームワークで動作する独自のWebサーバーを作成することです。KestrelはASP.Net専用です」。 しかし、それがメッセージになるのは嫌だ。

@gingters @gulbananaオープンソースプロジェクトが、将来のある推定日に、基盤となるフレームワークの任意のバージョンのサポートを停止するため、依存関係のセットが固定された出荷済みアプリケーションがどのように機能しなくなるのかわかりません。

@mattnischanはい、私はあなたが何を意味するのか理解し、そのコメントを削除しました:)

@stefanolson

サーバーとデスクトップアプリケーション間でコードを共有する必要があるため、最新バージョンのASP.Netを使用できないということですか?

ライブラリで.NETStandardをターゲットにしている場合は、デスクトップとコアの両方で使用できます。 .NET Standardを対象とするライブラリの場合、ユニバーサルプラットフォームをサポートします:デスクトップ、コア、モノ、Unity、UWP、Tizenなど

ASP.NETアプリケーションは実行可能ファイルです。 エンドポイント、それは図書館ではありません。 最終的な出力であるASP.NETアプリケーション/実行可能ファイルは、プラットフォームで実行する必要があります。 最終的に、そのプラットフォームライブラリはいずれもASP.NETアプリケーションによって消費されるため、プラットフォームと同じターゲットではないという利点はありません。

.NET Coreは、クロスプラットフォームを幅広くカバーしているため、優れたプラットフォームです。 デスクトップと並べてインストールでき、アプリごとに個別にアップグレードできます。 マシン全体やすべてのアプリではなく。

一部のアイテムは外部で使用されます。 そのため、 Wyamは静的サイトの生成にRazorを使用しています。 Razorは現在.NETStandard1.3であるため、Coreの外部で使用しても問題はありません。

上記のいくつかのエッジケースがあります:

.NETStandard2.0機能セットをサポートしていないライブラリを使用する。 それらの多くは、うまくいけば埋めることができるギャップです-そしてこの問題の初めに、MSはそれらのギャップが何であるかを尋ねていたので、彼らはそれらに優先順位を付けることができました。

たとえばUWPアプリに埋め込まれたWebAppを実行します。 ただし、デスクトップは引き続きサポートされていてもバージョン4.7.1に変更された場合、UWPが現在4.7.1をサポートしていないのと同じ状況になり、ASP.NETが4.7.2、次に4.7をサポートするまでに必要になります。 3など。他のプラットフォームがそれをキャッチすることは決してないので、それはSisypheanタスクになります。 それで、それはあまり意味のない忙しい仕事でしょうか?

はい、私はあなたが何を意味するのか理解し、そのコメントを削除しました:)

心配ありません、よろしくお願いします。 👍

@davidfowl

ASP.NET Coreの回転バージョンはそれにどのように影響しますか? 3.0で.NETFrameworkのサポートを終了した場合(このスレッドでは人々が理解しにくいようです)、関係なく同じ行き止まりになりませんか? 移植されたASP.NETCore2.0アプリケーションをフレームワークで1年間実行し、3.0がリリースされると、アップグレードできなくなります。 とにかく、これは.NETFrameworkで実行されASP.NETCore2.0がリリースされている場合でもサポートされているASP.NETCore1.1.xで実行できます。

(私が理解しているように)「いつか完全な.netで中断する必要があったのに、今すぐではない」と言うだけでは、重要なポイントが欠けています。 多くの人がコア2.0のリリースを待っていたと思います。 完全な.netとの互換性の多くの改善が公に約束されているからです。 非常に多くのライブラリ作成者も、コアへの移行を開始するのを待っています。 したがって、コア2.0がリリースされた後、コア上でさらに多くのライブラリが移行されると思います。 そのため、asp.netコアをコア3.0にバインドすることで、エコシステムのフラストレーションが大幅に軽減されます。 3.0の時点では、これらはコアへの移行を妨げることが少なくなるはずです。
今は災害です。

以前は、フレームワーク( @benaadamsの説明と非常によく似た話)のcore / asp.netコアへの移行の開始を2つのステップで評価していました:Webパーツ(現在はmvc / webapiにあります)をasp.netコアに移行し、完全に維持します.netを実行し、すべての依存関係に対応するコアの実装がある場合は、コア上の他のすべてのものを移行します。 現在、私たちをブロックしているのは、OracleADOプロバイダーとPostgresADOプロバイダーです(corefxには、まだ掘り下げていない他の非互換性がある可能性があります)。 今、この計画は死んでいます。 したがって、コアの世界ですべての新しいものを放棄する依存関係の移行を待つ必要があります。 そして、これはすべて、MSの誰かが「高速で移動する」プラットフォームが必要であると判断したためです。

@markrendleそれだけでアプリケーションが壊れることはありません。 問題は別のものです:
.NET Core 2は完全なフレームワークのサポートを終了したため(バージョン1で正常に動作し、新しいバージョンに更新するときにそのような基本的な基本機能が削除されるとは思わないMicrosoftからのものです)、依存関係により、このシナリオのサポートがすぐに削除される可能性があります。
使用されているライブラリの1つで重大なセキュリティ問題が見つかったため、スタックしているバージョンの更新は発行されません。新しいバージョンではランタイムがサポートされなくなったためです。 現在、アプリケーションは非常に規制された環境で使用されているため、重大なセキュリティ問題が検出されたときに何をするか、そして人々が怪我をしたり悪化したりするのを防ぐためにその修正をロールアウトする方法を説明する緊急計画を提供する必要があります。 「まあ、私たちは何もできません」は、そのアプリケーションを出荷するためのあなたの許可を取り消すことになります。

@gingtersほら、要点は、現在入手可能な情報とあなたの会社が運営している市場の性質に基づいて技術的な選択をしなければならないということです。 世界で最高の意志を持って、あなたはすべての不測の事態を説明することはできません、しかし世界の官僚と規制当局はあなたができるふりをしたいと思っています。 MicrosoftがAppleによる敵対的買収で買収され、.NETがSwiftを支持して完全に廃止された場合はどうなりますか? 販売先の国の1つで強力な暗号化が違法になり、SHA256を含むすべてのソフトウェアスタックが禁止された場合はどうなりますか? Nicolas、James、または_insert-name-of-Autofac-maintainer-here_が火星に移動して湿気のある農家になることを決定した場合はどうなりますか? 磁極が反転し、デジタル記録されたデータのすべてのビットが消去された場合はどうなりますか?

あなたが会社として何をするかという質問に対する実際の答えとして、JSON.NETで重大なセキュリティ問題が見つかった場合(たとえば)、公式の更新が利用できない場合にのみ、考えられる答えは「JSON.NETをフォークアンドパッチする」です。これは、JamesNewton-Kingが何らかの理由で体調を崩した場合にどうするかという質問に対する答えであると私は推測しています。 この種の市場で働いていた私の以前の経験では、その種の不測の事態に備えて、ソースコードをプロプライエタリパッケージにエスクローする取り決めがありました。 オープンソースパッケージについて何をすべきかは、それに比べれば簡単です。

そして、これはすべて、MSの誰かが「高速で移動する」プラットフォームが必要であると判断したためです。

「速く動く」ことはそれを誇張しているかもしれません。 フルフレームワークの以前のリリーススケジュールに従うと、出荷に「1〜2年の遅延を追加せずに」と表現したほうがよい場合があります。 これは、Webの世界ではクレイジーな時間です。

物事は急速に変化しており、プラットフォームは関連性を維持する必要があります。

@davidfowl@DamianEdwardsこの混乱は、ASP.NETCore1.xが.NETFrameworkで実行できるという事実に起因していると思います。 これにより、ASP.NETCoreがASP.NET4/MVC5の進化形であるという前提が生まれました。 下位互換性を維持しながら、すべての利点(速度と新機能)が得られると考えて、人々をそこに移行させます。

したがって、この問題に対する長期的/永続的な答えは、長期サポートとの下位互換性を求める人々のための答えとしてASP.NET 4 / MVC5を再プロモーションすることです(そしておそらく小さな改善を提供することもできます)。

そうすれば、ASP.NET Coreは、過去から脱却して、ジャンプできる人に大きなメリットを提供する新しいプラットフォームになることに集中できます。

その観点から、(ASP).NET(フレームワーク)と(ASP).NET Coreは、顧客が選択できる2つの並列で同等に有効な道路になります。 そして、これが最初から物事があったはずの方法だと思います。

@markrendleはい、これは架空のものですが、残念ながら官僚主義は本物です。 そして、はい、すべての不測の事態を説明することはできません(そして説明する必要はありません)。 あなたが期待できるもののためだけに。

そして今、a).NET Core 1で問題なくサポートされていた完全なプラットフォーム(.NETフルフレームワーク)の削除は、予想できない状況になっています。 ただし、これが発生したため、b)他の依存関係でのv1のサポートの低下をかなり確実に予測できます。「はい、それはかなり早く発生することがわかります」。

はい、フォークとバックポートの修正は可能な解決策の1つですが、これはできるだけ避けたいものです。 .NET Coreチームが「ねえ、見て、完全なフレームワークで実行するつもりはない、それに依存しない」などと言った場合、またはそもそもそれを可能にしたことがなかった場合は、このディスカッション全体そもそも顧客が.NETCoreに加えて新しいものに投資することを選択しなかったので、必要ありません。

@gingters .NETCore2.x以降でASP.NETCoreWebビットを実行し、CoreとFull /UWP/その他の間でライブラリを共有するために.NETStandard2.xを使用することに満足していると思いました。 。 これらのライブラリが.NETCore2.xだけを優先して.NETStandard2.xのサポートを廃止した場合、完全な.NETのサポートも廃止されることになり、どちらの方法でも問題が発生します。

@markrendle 1xがサポートされなくなった後、共有コンテンツで使用する必要のあるASP.NETCoreビットの1つに重大な問題が発生するまで。

@gingtersは幸運にもオープンソースであり、必要に応じて自分自身をサポートする(またはサードパーティに支払う)ことができます!

@markrendleいいえ。 純粋なレガシープロジェクトは死んだものです。 エンタープライズプロジェクトは通常、数十年前から新しいものまでのコード/ライブラリを含む大きな組み合わせのコードベースです。 netcoreappであるということは、ミックスする機能を削除したことを意味するだけです。 そのため、新しいバージョンに移行することはできなくなりますが、古いバージョンにロックダウンされます。 そして、反msの同僚は私に「私はあなたに言った...」と喜んで言い、それから私たちにグーグルソリューションへの移行を促します。

私はnetfxを永遠にサポートすることを主張しているわけではありません。 しかし、私はnetfxが少なくとも2年間はasp.netコアによってサポートされるべきだと強く感じています。 1.xだけでなく2.xも。

@qrliこれらの「エンタープライズプロジェクト...数十年前から新しいものまでのコード/ライブラリを含むビッグミックスコードベース」。 エンタープライズプロジェクトで間違っているすべてのものであり、停止する必要があります。 新しいテクノロジーが、シム、梱包ワイヤー、拒否と一緒に保持された絶望の大きなボールに泥の塊を投げ込むのを防ぐと不平を言うのは、新しい産業用レーザー切断機に身を乗り出して切断するのを防ぐ安全機能が付いていると不平を言うようなものですあなた自身の重要な部分。

@benaadams

「速く動く」ことはそれを誇張しているかもしれません。 フルフレームワークの以前のリリーススケジュールに従うと、出荷に「1〜2年の遅延を追加せずに」と表現したほうがよい場合があります。 これは、Webの世界ではクレイジーな時間です。

物事は急速に変化しており、プラットフォームは関連性を維持する必要があります。

これは政治的/組織的な制限であり、技術的な制限ではありません。 JVM/Javaがどのように動いているかを見てください。 彼らがまったく動いているのなら。 まだ関連性がありますが、今日の.NETよりもはるかに多くのものがあります。 したがって、「高速移動」は、人々がJava/JVMを選択する理由ではありません。 それどころか。 彼らはJava/JVMを選択します。これは、「高速移動」に関連するすべての欠点がないためです。Java/ JVMは安定した信頼できるプラットフォームであり、投資が1〜2年で無駄になることはありません。

MSが.netを完全に高速で移動したい場合は、高速で移動します。 彼らはそれを所有し、彼らは何をすべきかを決めることができます。 しかし、実際にはそれについて多くを与えていない力:.net fullは、現在の場所には「十分」です。

MSは何年にもわたって眠っていましたが、パフォーマンスやメモリの負荷などの突然の問題はすべて重要です(間違いなく重要です)が、JVMでは、ランタイムの特定の側面への土地投資が多くの人に行われています。年とそれは報われる。

解決策が短期的にはわかりませんが、長期的には、.NETを2つの主要な部門(Windowsでいっぱいの.net、devdivでいっぱいの.net)に分割し、同じ以外の共通の根拠/目標はありません雇用主は私たちの部外者にとって良い前兆ではありません。

ここでは多くのポイントが指摘されており、誰もが他の視点を確実に理解しようとしていますが、「大企業はそのようにすべきではない」などのソリューションは役に立ちません。 たとえあなたが彼らにそれを納得させることができたとしても、彼らは大企業であるため、彼らがそのようになるのをやめるのに20年かかるでしょう。

@kolectivそれは本当ですが、企業が突然企業でなくなることはないということを受け入れることは、そのような行動を積極的に奨励/有効化する必要があるという意味ではありません。

また、_my_アプリケーションの実行速度が遅くなり、ホストにコストがかかることを意味するものではありません。

ASP.NET Core1.x上の.NET4.x(EF6、NHibernate、NServiceBus)とmanをターゲットとする、頻繁に使用されるライブラリで移植性分析を実行すると、これらのライブラリはnetstandard20をターゲットにできるほどではありません。 netstandard20

Lib | パーセント
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

そして、不足しているAPIにはまだ大きなギャップがあります。 EF CoreにはまだEF6との大きなギャップがあり、EF6には存在しない主要な機能がある場合はNHibernateを使用します。 メッセージングを行うすべてのプロジェクトで使用するNServiceBus。

ふぅ。

@markrendle

それらの「エンタープライズプロジェクト...数十年前から新しいものまでのコード/ライブラリを含むビッグミックスコードベース」。 エンタープライズプロジェクトで間違っているすべてのものであり、停止する必要があります。 新しいテクノロジーが、シム、梱包ワイヤー、拒否と一緒に保持された絶望の大きなボールに泥の塊を投げ込むのを防ぐと不平を言うのは、新しい産業用レーザー切断機に身を乗り出して切断するのを防ぐ安全機能が付いていると不平を言うようなものですあなた自身の重要な部分。

ええ、それらの厄介な企業や大規模な組織に、別の方法で物事を行うように伝えましょう。 泥の洪水を止めろ! それは彼らを目覚めさせ、耳を傾けさせるでしょう。 彼らはすでにそれを知っているので、待ってください、それは助けにはなりませんが、あなたが気にしないか、あなた自身の議論のために無視する多くのことで働かなければなりません。

ほら、誰も「新しい技術:悪い!」とは言いません。 それは、それがもたらす結果に気付かずに新しい技術を追求することです。 私たちは皆、最新のビットで作業するのが好きで、古いくだらないことを心配する必要はありません。誰がそれを望んでいますか? しかし、現実は別の話をします。 あなたが最新のビットで作業する必要があり、古いたわごとを気にする必要がないなら、あなたにとって良いことです! 悲しいことに、塹壕にいるドローンは別の現実で生きなければなりません。 多くの人々にとって現実はそれだけであり、彼らはそれを変えることはできず、彼らは別の未来を作ることはできず、それは彼らが協力しなければならないことであるということを少なくとも認めるなら、それはあなたに適しています。

@markrendle何を提案しているのかよくわかりませんか? 1,500万行の動作するC#コードを放棄して、すべてを新たに記述しますか? 私たちは(ゆっくりと)netstandard 2.0に移行し、うまくいけばSpanなどにアクセスできるようになることを検討していましたが、このような問題は賢明なことではないかと思います。

Linuxのサポートが必要ですが、これは分岐のように感じます。 私は、netstandardが最も高度な実装で前進し、フレームワークのようなものが追いつくだろうと思っていましたが、少なくとも私たちはそれがそうなることを知っていました。

@FransBoumaでは、企業は愚かなことをしたいので、私たちは皆苦しむべきですか? 数百万ドルの公共部門のプロジェクトはまだ準備ができていないので、私は良いものを手に入れるべきではありませんか? それはどのように機能しますか?

@markrendleコードを機能させ続けたいと思うのは何が愚かですか?

彼らはJava/JVMを選択します。これは、「高速移動」に関連するすべての欠点がないためです。Java/ JVMは安定した信頼できるプラットフォームであり、投資が1〜2年で無駄になることはありません。

そして、System.Webは基本的に永久に使用できます。 Windowsに焼き付けられているため、消えることはないでしょう。 それ以上に安定して信頼できるものはありません。

ASP.NET Core 1.x-> ASP.NET Core 2.x; すべてのAPIはほとんど同じですが、主な変更点は.NETFrameworkのサポートを終了することです。 それは休憩のためにsemverを変更します😱

ASP.NET Core1.xは.NETCore2.xおよび.NETFrameworkで実行され、.NET Standard 2.x(.NET Core 2.x経由)をサポートします。 ASP.NET Core 2.xと同じAPIを使用しているため、これが踏み台のリリースです。

ASP.NETCore2.xはブレークリリースです。 引き続き.NETStandard2.x(.NET Core 2.x経由)をサポートしており、ASP.NETCore1.xとASP.NETCore2.xの間でAPIに関する変更はあまりありません。 ただし、.NETFrameworkは削除されます。

代替案は次のとおりです。

  • ASP.NET Coreは先に進み、 netstandard3.0 (2.xの場合もあります)のようなものに取り組み、netstandardのバージョンをより高速にします。 四半期に一度のように。
  • NetFxの次のリリースは、次のリリースがいつでもnetstandard3.xをサポートするために再びジャンプする可能性があります。 最新の規格である必要はありません。

使用されるすべてのものがnetstandardの一部である必要はないかもしれないので、これは悪い考えかもしれませんが、少なくともASP.NET Core 2.xは、他のフレームワークが最終的に使用する標準をターゲットにします。

ただ唾を吐きます。 私はこれが提起されたと確信しています。

@bencyoung私は、全世界が1500万行の動作するC#コード(動作を停止することはありません)を中心に展開する必要があると主張するのは少し利己的だと言っているだけです。 したがって、ASP.NETCore2.0は使用できません。 ブライトンスルーロックのようにレガシーサポートが実行されている完全なWindows専用フレームワークASP.NETがまだあります。 そのため、コードを移植してアプリケーションをリファクタリング/再構築するのは経済的に実行可能ではないため、遊ぶことができない新しいおもちゃがあります。 それはひどいですが、たくさんのことをします。 しかし、Microsoftが既存の20年前のレガシーコードベースで機能しないものをすべて回避すれば、おそらくVB 6.0で記述されたCOMコンポーネントがまだ含まれているので、さらに20年後にはMicroFocusになります。

@adamhathcockこれが、netstandardの目的であると私が想定したものです。最小公分母ではなく、統一アプローチです。 好きなだけ速く移動できますが、.NETFrameworkが最終的に追いつくというコミットメントになります。 最終的には、基本的に.NETフレームワークからプラットフォーム固有のものを差し引いたネットスタンダードがあり、それが統合されます。

NetFxの次のリリースは、次のリリースがいつでも、netstandard3.xをサポートするために再びジャンプする可能性があります。

.NET Frameworkの更新は、(ほとんどの場合)Windowsを実行している地球上のすべてのマシン強制更新です。

.NET Coreアップデートは、個々のアプリケーションが選択したアップデートです。

彼らは非常に異なる獣です。

簡単な方法の1つは、ASP.NETCoreドキュメントの最初のページからこのページへのリンクを停止することです。

(または、「ASP.NET Coreを引き続き使用する場合は、.NET Frameworkを選択しないでください!」という行を追加するだけです。)

それらは、.NETFrameworkが最終的に追いつくというコミットメントになるでしょう。

https://github.com/aspnet/Home/issues/2022#issuecomment-299609207があります

一般的に、私たちの約束は次のとおりです。タイプが.NETFrameworkと.NETCoreの間で共有されている場合、新しく追加されたメンバーを.NETFrameworkに移植する予定です。 非常にまれなケースでは、これが不可能な場合もありますが、地面の問題は、それらが自動的に考慮されることです。

しかし、追いつくまでに、ASP.NETは次の.NET Standardバージョンに移行し、ASP.NET用の.NETFrameworkの正しいバージョンになることはありません。 それは常に遅れているでしょう。

@markrendleいいえ、大きな泥だんごではありません。 大きなミックスは、彼らが悪い設計であるという意味ではありません。 それらはモジュール式です。 それは、多くのモジュールが、本当に賢い人々によってずっと前に書かれた、またはサードパーティから購入された、戦闘でテストされたコードであるということです。 移行または書き換えするには、cによるもの、fortranによるもの、c ++ / cliによるものなどがあります。それらを理解し、論文を読み、より実際のテストデータを収集し、新しいバージョンを再テストする必要があります。 それは努力を要しますが、そのようなタスクは決して予算が組まれることはありませんが、私たち自身次第です。 ビジネスマンは、.netコアを使用するかどうかは気にしませんが、機能を実行することを望んでいます。 サードパーティの場合は、それらを促すか、交換を求める必要があります。
そのため、実際には数年かかる場合があります。

@benaadams

そして、System.Webは基本的に永久に使用できます。 Windowsに焼き付けられているため、消えることはないでしょう。 それ以上に安定して信頼できるものはありません。

ASP.NET Core 1.x-> ASP.NET Core 2.x; すべてのAPIはほとんど同じですが、主な変更点は.NETFrameworkのサポートを終了することです。 それは休憩のためにsemverを変更します😱
ASP.NET Core1.xは.NETCore2.xおよび.NETFrameworkで実行され、.NET Standard 2.x(.NET Core 2.x経由)をサポートします。 ASP.NET Core 2.xと同じAPIを使用しているため、これが踏み台のリリースです。
ASP.NETCore2.xはブレークリリースです。 引き続き.NETStandard2.x(.NET Core 2.x経由)をサポートしており、ASP.NETCore1.xとASP.NETCore2.xの間でAPIに関する変更はあまりありません。 ただし、.NETFrameworkは削除されます。

はい、そしてオプションが実際に何であるかを見てみましょう:) ASPNET Core 1.xは行き止まりです:それに移植することはできますが、今日.netがいっぱいのライブラリに依存している場合はコードを.netコアに移動できませんサポートが終了すると、.net core/standardに移植されない場合があります。 ASP.NETコア1.xを選択するのは、依存関係がすでにnetstandard2.0 / .netcoreにある場合にのみ賢明です。その後、行き止まりに陥っていないことを確認して、問題なくasp.netコア2.xに移行できます。

安定性を確保したい場合は、nginxとJVMスタックの代わりにsystem.webを選択するという提案は少し弱いと思いませんか? :)それは、大規模な組織がプラットフォームとして何を選択するかについてのオプションです。 彼らが完全に新しく、外部の依存関係(まれ)で動作する必要がないアプリを作成していない限り、彼らはおそらく安全な賭けをするでしょう、そしてなぜ彼らはそうしないのですか? それがsystem.webまたはJVM/nginxに帰着する場合、選択は非常に簡単です。

それはささいなことです。 私は前にそれを打ち負かしました:SQLサーバー企業の暗号化機能。 これらは.netコアにないため、.netコアでは使用しません。 オラクル? いいえ。 したがって、asp.netコアとこれらの機能を使用する場合は、.netfullとasp.netcore1.xを使用する必要があります。 しかし、asp.net core 1.xのサポートが終了したときに、これらの機能が移植/利用できない場合はどうなりますか? (そして、すでに「QFEモード」になっているプラ​​ットフォームにファームを賭けたいのは誰ですか?)system.webに戻りますか?

問題の一部は、ASP.NETが.NETCoreの進化を直接推進していることだと私には思えます。 これはMicrosoftの内部的なことだと思いますが、実際には、プラットフォームと特定のライブラリをそれほど緊密に結合するべきではありません。

.NETのバージョンに何か新しいものを追加する必要がある場合は、netstandardバンプ(vNextを使用)を介してすべてのユーザーが利用できるようにし、リリース時にASP.NETを更新して使用できるようにする必要があります。 この問題の原因はASP.NETの特権的な位置だと思います。 Microsoft内の開発者のグループが同じであるため、これは避けられないかもしれません...

.NETを多用するHPCソフトウェアのライターとして、基盤となるプラットフォームを変更することなく、独自のゼロ割り当て解析なども実装しました。 スパンなどの恩恵を受けますか? 絶対! .NET Coreに切り替えることはできますか? 長い間ではありません。 Spanなどが.NETFrameworkに追加されますか? それが正味の標準的なコミットメントでなければ、今言うのは難しいようです...

@markrendleもちろんですが、移行計画はどうなっていますか? サポートされていないパスにヒットしないものが表示されません。 変更がnetstandardにあり、ASP.NET Coreがそれらを使用した場合、少なくとも最終的にはパスがあったことがわかります。

@markrendleasp.netコアの対象ユーザーが誰であるかわかりません。 しかし、私が見たのは、ほとんどの場合、.netと大きなレガシー(悪くない)コードベースに多額の投資をしている.netユーザーです。 私たちが意図したユーザーでない場合、.netがどれほど優れていると思っても、node.js / python/goの人たちが.netにsh*tを与えるのを見ることはありません。
会社用ではなく自分のプロジェクト用の場合は、aspを使用せず、代わりにnancyを使用します。 企業は安定した保証とサポートを必要としています。 そして彼ら/私たちはそれに多額のお金を払います。

この問題の簡単な解決策は、Microsoftが.NETFrameworkライブラリの全範囲をサポートするCoreCLRのWindowsのみのディストリビューションを作成する場合です。

私の個人的な側面は、ubuntuのPIで.NET Coreを使用するのはクールですが、.NET Frameworkは必要なすべてを実行し、.NET Coreは比較すると問題があるだけなので、ビジネス側は.NETCoreを考慮しませんでした。 この問題のほとんどは、ツールを使用して全員をセットアップすることでした。そのため、これらの問題はようやく解消されましたが、それでも多くの機能が不足しています... EF Coreは、EF6やNHibernateに代わるほどまろやかではなく、勝ちました。 .NETCore2でも実行されません。 SOAPサービス用のWCF(ホスト)の欠如は、ビジネスコミュニケーションで一日中行っていることから、かなりの負担になりますが、巧妙な設計と、複数のアプリでの.NETCoreおよび.NETFrameworkの使用によって軽減できる可能性があります。 AppDomainsも簡単には置き換えられませんが、それは私の問題の中で最も少ないものです。 ASP.NET MVC5からMVCCoreへの飛躍は、書き直しが予想外に簡単でしたが、.NET Coreに移行すると、VSの連携が停止し、すべてのエラーが表示されます。

WPF内でASP.NETCoreをホストするような楽しいことも不可能です。

現在の.NETFrameworkとそれほど変わらないため、WindowsCoreCLRディストリビューションがクローズドソースであるかどうかは問題ではありません。

ASP.NET Coreに移行された実験用ブランチを静かに泣きながら削除している間、すみません。

安定性を確保したい場合は、nginxとJVMスタックの代わりにsystem.webを選択するという提案は少し弱いと思いませんか?

その極端な終わり;)

それがsystem.webまたはJVM/nginxに帰着する場合、選択は非常に簡単です。

ええ、JVMに移行できる場合は、ブロッカーがなく、相互運用性とp/invokingが優れているASP.NETCore2を使用します:)

APIが「ほぼ同じ」である場合は、1つのバージョン番号をすべて2倍にして、「netstandard」または「netcore」を選択するオプションを用意してみませんか?

内部が変化しているからです。 ランタイム、jit、および標準ライブラリへの変更を利用します。 ユーザーには、ASP.NET1.xと2.xの互換性がある場合とほとんど同じように見えます。 内部ではなく、公開されたAPIサーフェスで「これがどのように行われるか」です。

問題の一部は、ASP.NETが.NETCoreの進化を直接推進していることだと私には思えます。

他の人もそうです。 たとえばValueTaskの場合と同じように、 dotnet/corefxでAPIリクエストを行うことができます。 その後、タスクのようなものに進化し、現在はC#7の一部になっています。

APIが.NETCoreに含まれるとすぐに、それを使い始めることができます(夜間に行き、APIが正しいことを確認したい場合)。 または、6か月間ハングしたい場合は、coreclr/corefxの次のリリースで。

その後、ASP.NETは、リリース時に使用するように更新されました。

今、あなたは2年待たなければなりません。 それは実際には実用的ではありません。 APIは使用を通じて改良する必要があるため。 使用することで、より多くの発見が起こります。 これは、開発サイクルに2年間のコンパイルステップを追加するようなものです。

.NETを多用するHPCソフトウェアのライターとして、基盤となるプラットフォームを変更することなく、独自のゼロ割り当て解析なども実装しました。 スパンなどの恩恵を受けますか? 絶対! .NET Coreに切り替えることはできますか? 長い間ではありません。

HPCソフトウェアはWebリクエストに直接ぶら下がっていますか? 推測では、Webリクエストによって駆動されるキューがあるかもしれませんが、別のプロセスで実行されるため、この変更の影響を受けないはずですか?

Spanなどが.NETFrameworkに追加されますか?

はい

@benaadams

しかし、追いつくまでに、ASP.NETは次の.NET Standardバージョンに移行し、ASP.NET用の.NETFrameworkの正しいバージョンになることはありません。 それは常に遅れているでしょう。

少なくとも1つのバージョンの重複がある場合、これは完全に問題なく受け入れられます(つまり、最新の完全なフレームワークを使用している場合でも、公式にサポートされている(ASP).NET Coreバージョンが少なくとも1つあります)。

Microsoftは、すべての.NETFrameworkライブラリをサポートするCoreCLRのWindowsのみのディストリビューションを作成します。

または、.NETStandard2.0ライブラリのセット。 .NET Coreで実行できますが、APIギャップをカバーするWindowsでのみ実行できますか?

@benaadamsええ、それはアイデアですが、PlatformNotSupportedExceptionをスローするものには機能しません

@qrliモジュール式の場合は、今すぐアップグレードできるモジュールをアップグレードし、残りは後でまで残すことができます。

「モジュラー」とは、「PInvokeとCOMを介して相互運用する数十の異なるライブラリで構成される大規模なモノリシックSystem.Web ASP.NET IISアプリケーション」を意味する場合を除き、大きな泥だんごです。

影響を受けるアセンブリと影響を受けないアセンブリの最終的なリストはありますか? Microsoft.Extensions.*は安全であり、 Microsoft.AspNetCore.Razor.Runtime (想定)もあると言われています。そのおかげで、 Microsoft.AspNetCore.Html.Abstractions netstandardに留まる必要があります。 netstandardにとどまっているMicrosoft.AspNetCore.*に他に何かありますか?

@bencyoung推奨される移行計画は、さまざまなコンポーネントを.NET Core 2.x(またはその特定のコンポーネントの開発ツールの全世界から最もよく機能するもの)を対象とするスタンドアロンサービスに移行し、レガシーコードからそれらのサービスを消費することです。適切な分散システムアーキテクチャが得られるまで、HTTPまたはメッセージバスを使用する標準のAPI境界。

@markrendleただし、すべてが分散システムに属しているわけではありません。 具体的な例として、Stack Overflowがページを非常に高速にレンダリングする理由の大部分は、ページが分散されないことです。 ネットワーク遅延は0.017msですが、これにより、アプリケーションにかなりのネットワーク、シリアル化、逆シリアル化、およびGCのコストが追加されます。 システムを多くのサービスに分割することは、普遍的な答えではありません。 これは複雑なものであり、コストがかかるものであり、多くのシナリオでも正味のネガティブです。 それは良いことかもしれませんが、複雑すぎる悪いことでもあります。

@markrendle私の問題はサービスへの移行の問題ではありません。基本的なサービスインフラストラクチャの構成要素の一部が、 netstandard20またはnetstandardbananaのロードマップにないAPIを使用していることです。 私たちにとっての.NETCoreは、グリーンフィールドアプリケーションではなく、グリーンフィールドシステム全体に関するものです。 System.DirectoryServicesは1つの例ですが、他の人にとってはWCFであり、他の人にとってSystem.DataとSqlClientのものであり、私たちにとってはSystem.Messagingです。

できる限り.NETCoreを使用することに専念しています。 これまでのところ、グリーンフィールドであろうとなかろうと、ゼロクライアントプロジェクトが含まれていますが、それらはすべて何かでブロックされています。

@NickCraver私はファセットか何かを意味するわけではありません、そして私はSOページがとても速くレンダリングされる本当の理由はあなたとそれを構築する他の人々が素晴らしいことであることを知っています、しかしあなたのページへのリンクを含むGoogle検索結果あなたのページと同じくらい速くレンダリングします、そしてあなたはそれらが大きくて複雑な分散システムから来ていることを_知っています_。 アマゾンページはかなり速く、同じ取引をレンダリングします。 ASP.NET Coreは、システムの構築と同じ方法で同じパフォーマンスでシステムを構築できる未来に向かって進んでいると楽観視しています。ASP.NETCoreが解放されれば、そこに到達する可能性が高くなると思います。完全な.NETの小さな島への転換サイクル。

@jbogard似ているように見えますが、.NETCore2.0がリリースされたときは大きく異なります。

はぁ。

@jbogard

netstandardbanana

スレッドの引用

これに関する主な問題は、私と私のチームにとって、この道が意図された未来であったという兆候がなかったことです。 将来は誰にもわかりませんが、完全な.netフレームワーク(コンポーネントベンダーのdll、支払いサービスsdk、HSM sdk)に依存するものをすべて独自のサービスに分解し、その新しいホップSTINGSを導入する必要があると聞いています。 これはこのサイトに必要なものではないため、開発オペレーションをさらに複雑にするか、Webアプリの部分をMVC5に再実行する必要があります。

ケストレルの速度と新しいAPIのために、asp.netコアを使用しました。 依存関係を考えると、簡単なアップグレードパスがないことに対して、オプションをより正確に比較できればよかったと思います。

@jabrown85に追加
ASP.NET Coreは、これまでのところ感情のジェットコースターでした。
csprojが着陸した後、私はついに「今すぐ準備ができました」と考え、新しいことを始めて何をアップグレードできるかを確認するのは簡単だと考えました。 この発表の後、「。NET Coreはシナリオを確実にサポートしますか、それとも安全に移動してMVC5を使用する必要がありますか?」

これまでのところ、犠牲者は少なく、プライマリMVC5アプリの管理タスクを管理するASP.NETCoreで記述されたアプリケーションは1つだけですが、メインアプリはNHibernateを使用しているため、1.xで永久に停止します。

@markrendleコンピュータはノーと言います

完全な.NET->netstandardのロードマップがあればいいのにと思います。 基本的な部分のいくつかは、ApiPortから「サポートされていません」とだけ言っています。 ASP.NET Core 1.xでクライアントプロジェクトの詳細な分析を実行して、不足しているものを確認します。

ただし、メインアプリはNHibernateを使用しているため、1.xで永久にスタックします。

すべきではありません、NHibernateは死んでいませんか?

@benaadamsは驚くほどありません。 EF6には実際には同等のものがないということを行うことがいくつかあります。 デフォルトはEF6ですが、NHルートを使用しなければならない場合があります。

@benaadamsは公式にはありません。ほとんど死んでいるように見える一時停止がありますが、通常は数日ごとに1つのコミットがあります。 ApiPortは.NETStandardの72.26%のカバレッジを報告していますが、(少なくとも近い将来に)移植されるとは本当に確信していません。

コメントを読んで、私はこのプロジェクトが向かっている一般的な方向性について心配しています。 長い間、ASP.NETは安定した堅実なテクノロジに適していました。 しかし、今は同じ気持ちにはなりません。 「速く動き、物事を壊す」テクノロジーはたくさんありますが、それはまったく別のカテゴリーです。
マイクロソフトがこれらの懸念に対処し、すべての人の期待に応えることができるようになることを願っています。

エンタープライズソフトウェアと非エンタープライズソフトウェアの違いではありません。 今日使用されているPython2.xアプリケーションはたくさんあり、それらすべてが「エンタープライズ」であるとは限りません。 さらに、すべての新しいプロジェクトがPython 3を使用しているわけではありません(Python 3.0のリリースからほぼ9年後です!)。

誰かがブログ投稿でスレッド全体を要約できますか?

通勤/昼食時に300以上のコメントをすべて読みましたが、まだ完全に「理解」していないようです。

私が得るものは:

  • 完全な.NETFrameworkは、.NETCore2ではサポートされません。
  • すべての依存関係は、 netstandard2.0 #$ではなくnetcoreapp2.0に依存します
  • DirectoryServicesやDrawingのようなものが必要な場合は、FullFrameworkを削除して2.0にジャンプする必要があります

私はちょっと残りを逃しました...忙しいスケジュールとすべて。

@MaximRouiller

DirectoryServicesやDrawingのようなものが必要な場合は、FullFrameworkを削除して2.0にジャンプする必要があります

いいえ、.netコアをサポートしていないライブラリが必要な場合は、AspNetCore2.0以降をまったく使用できません。

@MaximRouiller 、彼らがやったことは、Asp.Netコアプロジェクトが完全なフレームワークアセンブリを参照できず、ほとんどではないにしても多くの人にとって役に立たないということです、彼らはsystem.drawingやDirectoryservicesのようなアセンブリが新しいnetstandarに移植されると言いますまたは、私にはわかりませんが、それでも、古いアセンブリは誰かが移植しない限り機能しません。したがって、一部のアセンブリはレガシーであり、移植されないため、多くの人にとってはほとんど役に立ちません。 結論として、.NET Frameworkのフルバージョンで.netコアを使用していた人はだれでもがっかりし、MVC5に戻る必要があります。

@davidfowlちなみにこのリストをありがとう。 それは非常に重要なことです「それで、私たちはこれから何を得ているのでしょうか?」 人々が心の中で費用便益のバランスを取るために必要な部分。

まだ読んでいない場合は、リストを読んで、両側に通知してください。 私はまだ2.xを移行リリース(実際に移動を正当化するためにビジネスに正当な利益をもたらす)にし、3.xが勝利の場所であることを望んでいます。 2日後に出てきても。 私は本当にあらゆる面での洞察に感謝しています。

あなたが言った@davidfowl

ライブラリは、標準の上に書くことができます。 標準自体を変更する必要がある場合、.NETFrameworkを含むすべての実装で採用されるまでにかなり時間がかかります。 それはいくつかのことを意味する可能性があります:
.NET Standardは、最も遅い実装の速度で進化します
.NET Standardは他のペースで進化し、.NETFrameworkが最後に追いつくでしょう。

しかし、なぜそうなのですか? .NET Standard vNextをリリースして、しばらくしてから(数か月から1年後).NETに追いつくことはできませんか? つまり、最先端で最新のASP.NETCoreが必要なユーザーは.NETCoreでホストでき、レガシーコードに.NETが必要なユーザーは、.NETが追いつくと、最終的にそのバージョンのASP.NETCoreを使用できるようになります。使用する.NETStandardバージョンに変更します。 なぜ.NETStandardを最低の実装と同じくらい速く改訂しなければならないのか理解できません。
また、ここでは標準の公式実装について話しますが、標準と並行して更新されない他の実装もあります。
そうすれば、人を置き去りにすることはありません。 確かに、.NETにある場合、最新の機能の恩恵を受けるには少し時間がかかりますが、永遠に行き詰まるわけではありません。

@jdomは、.NET Frameworkが変更される速度と、それを遅くする必要がある理由を知っているためです。 これは別のディストリビューションであり、おそらくそれに対する十分な評価がありません。 変更はすべて、数十億台のマシンにプッシュされます。 レイヤリングも完全に異なるため、理由を説明するのは簡単なことではありません。

なぜ.NETStandardを最低の実装と同じくらい速く改訂しなければならないのか理解できません。

ASP.NET Coreで.net標準の最低水準点を上げ続けると、目的が果たせなくなり、同じ状況に陥ります。 いつかこれらのAPIが.NETFrameworkに登場するという約束があるので、取り残されているとは感じませんが、どのようなタイムラインでしょうか。 .NET 4.7は、まだ.NETStandard2.0と同等の機能を備えていません。

@davidfowlですが、これはPCLの場合と同じ問題を引き起こします。これは最小公分母になり、使用するのが面倒になります。ASP.NETがそれを使用しないことは、すでにそれを示しています。

@davidfowlですが、これによりPCLの場合と同じ問題が発生し、最小公分母になり、使用するのが面倒になります。

@Suchimanそれはどうですか? PCLの唯一の問題は、PCLが動的に計算され、NuGetで表される方法でした。これにより、何を取得するかを予測することが困難になりました。 異なる実装で実装できるAPIセットでなければ、netstandardは他にどのように機能しますか?

PCLを使用するのが面倒だったのは、APIの表面積が非常に小さいことでした。 .NET Standard 1.3-1.4は、APIに関してほとんどの基本的なライブラリを実装するのに十分です。

.NET Standardは、常に幅広さを重視していました。

ASP.NETCoreと.NETCoreは、軽量のマイクロサービスを構築するための競争力のあるクロスプラットフォームサーバースタックに関するものでした。 この意味での息吹は、より広範なプラットフォームサポート(Linux、osx、tizen、piなどで実行)でした。

@davidfowl

文字列を.NETCoreで取り組みたい主要なものの1つとして特定しました。アイデアはたくさんありますが、そのうちの1つは、文字列をデフォルトでutf8にすることです(互換性の問題がたくさんありますが、ここでフォローしてください)。

修正したいもう1つの点は、配列/文字列の安価なスライス、隣接するメモリの任意の部分を取得する機能です。 Spanを追加しましたとバッファを見ていますこれを表すために。 これは、StringとArrayが、0の割り当てを必要とするスライスを取得できるようにする新しいインターフェイスを実装していることを意味する場合があります。

これは、ライブラリでこれらの新しいビットを使用する場合、ライブラリもnetstandard2.0 #$ではなくnetcoreapp2.0をターゲットにする必要があることを意味しているようです。 あれは正しいですか?

古い4.xフレームワークをサポートしないのは本当に悪い考えです。 それが多くの仕事を引き起こすならば、人々はアップグレードしません。 2002年から約15年で廃止された超古いクラシックASPをご覧ください。 また、従来のASPにはまだ存在する古いアプリケーションがあります。 マイクロソフトはもう一度似たようなものを見たいですか? 古い4.xサポートを削除することは必須である必要がありますが、長期的には! 今はやめろ。 .NETコアが事実上の標準であり、古いアプリケーションのみがnet 4.xを使用している場合、これは数年後にはオプションになる可能性があります。

(ASP).NET Coreの背後にある考え方は本当に素晴らしいものであり、.NETのリリース以来Microsoftが行った最高のことです。 しかし、そのような混乱はこの素晴らしい概念を鈍くします。 また、Microsoftがコミュニティで議論することなく、このような大規模な変更を独自に決定することは非常に悲しいことです。 この会社はまだオープンソースプロジェクトの扱い方を完全には学んでいないようです。

@davidfowl

.NET Standardは、常に幅広さを重視していました。

APIまたはプラットフォームの幅は?

.netcoreappと同じペースで.netstandardを進化させることの問題は何ですか?
他のフレームワークには実装されないため、BCLチューニングターゲットのいずれかが.netcoreappに固有ですか?

.netcoreapp2.1と同時に.netstandard2.1をリリースしても、最初と1年後に.netstandard2.1 .netcoreapp2.1 $ .net50と同時にリリースしても違いはありません。 .netstandard2.1を対象とするパッケージは、 .net50ですぐに機能を開始しますが、 .netcoreapp2.1を対象とする場合はブロックされます。

ASP.NET Coreは、.NET Core上に構築された高レベルのWebアプリケーションフレームワークであり、将来的には.NET Coreをターゲットにしますが、代わりに.NET Standard上に構築された高レベルのWebアプリケーションフレームワークにすることもできるため、ターゲットになります。特定の実装ではなく、参照APIインターフェイス。

.NET Standardの一般的な位置付けは、実装の詳細を脇に置いて構築するのが簡単なターゲットです。ほとんどのユースケースをカバーするために、Microsoftから直接提供された2つの公式フレームワークがあります。

なぜ今その話を変えるのですか? .NET Frameworkが追いつかない場合、それは重要ではないようです。 少なくとも、そうなる可能性があるか、別のサードパーティフレームワークがそうする可能性があります。 では、現実的にペースを維持する実装が1つしかない場合はどうなるでしょうか。 これが、具体的な実装が1つしかない場合でも、アプリケーションにインターフェイスがある理由です。そのため、柔軟性と利点がもたらされます。

おそらく、ASP.NET Core2.0のスコープを.NETStandard2.0とインラインでダウンさせてから、新しい機能に.NET Standard 2.1を使用しますか? いくつかのまともなサポートタイムラインを追加すると、このジレンマ全体が解決されませんか? Microsoftは.NETStandardと両方のフレームワークを所有しているため、バージョンを増やすことに対するこの恐れは完全に根拠がないようです...

ASP.NETからASP.NETCoreへの移行パスはすべての人にとっての移行パスではないことを考慮する必要があると思います。

フルフレームワーク上のASP.NETはそのまま残り、機能を取得しますが、Coreとは異なります。

移行は時間の経過とともに簡単になりますが、100%一致することはありません。

人々は今でも古典的なASPを実行しています。 それは彼らにとっても問題ありません。

@davidfowl私はチーム全体とあなたが成し遂げている進歩に大きな敬意を払っています。 ですから、これを何が起こっているのかを理解していると見なさないでください。 あなたたちはパイオニアであり、私たちは皆、物事を正しく行う方法の例としてあなたに目を向けています。 しかし、私はこれらの点の多くを、特にそれが伝達されていない場合、当面の目標変更の問題とは見なしていません。 たぶん私は間違っています。

何度か言及されているので、ここにいくつかのクレイジーなものを投げたいと思います。 私がこれから言おうとしていることは、何が起こるかには関係ありません。現時点ではすべて推測です。 何人かの人々は、なぜ.NETStandardではなく.NETCoreをターゲットにしたいのかと尋ねました。

  • 文字列を.NETCoreで取り組みたい主要なものの1つとして特定しました。アイデアはたくさんありますが、そのうちの1つは、文字列をデフォルトでutf8にすることです(互換性の問題がたくさんありますが、ここでフォローしてください)。

ここでのこの点は間違いなくゲームチェンジャーですが、IMOは、フレームワークをターゲットにしないことを絶対に必要とする唯一のポイントであり、とにかくnetcoreapp20用ではありません。

  • 修正したいもう1つの点は、配列/文字列の安価なスライス、隣接するメモリの任意の部分を取得する機能です。 Spanを追加しましたとバッファを見ていますこれを表すために。 これは、StringとArrayが、0の割り当てを必要とするスライスを取得できるようにする新しいインターフェイスを実装していることを意味する場合があります。
  • これにより、毎回配列を割り当てない分割を可能にするStringの新しいメソッドが作成されます。
  • これにより、Spanを使用するInt、UIntなど(TryParse)へのオーバーロードが発生しますとスパン
  • これにより、Spanを使用する新しいエンコーディングルーチンが作成されます
  • バッファとスパン均一な方法でメモリを表すことができます。ネットワークスタックをアップグレードして、Spanを使用する事前に固定されたバッファを渡すことができるようにします。またはバッファ

これらはすべて、現在のネットスタンダードに加えてパッケージとして実装できます。 これにはnetstandard20も必要ありません。 この荷物を持ち歩きたくないことは理解していますが、MS以外の世界にいる私たちの残りの部分は、ユースケースやパフォーマンスが合わない場合は常にカスタムBCL風のimplを作成する必要があります。 言うまでもなく、Span APIは2.0も対象としていません(再度変更されない限り)。

Kestrelは2.xタイムフレーム(現在2.1を目指しています)でHTTP2を実装し、ALPN(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)を実行するにはSSLストリームに新しいAPIが必要です。
.NET Core上のHttpクライアントは、二重ストリーミングをサポートします。これにより、単一の非WebSocket http要求を介して、Signalのhttpを介してストリーミングエンドポイントを実装できるようになります。

これは少しトリッキーな気がしますが、libuvを持ち歩くKestrelとそれほど違いはありません。 .Net CoreからのCURL実装は、誰もが追いつくまで、netstandard拡張パッケージに簡単に取り込むことができます。

  • ヘッダーパーサーの実装をHttpClientとSystem.Net.Httpからフォークし、名前を変更して(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers)、それらを改善できるようにしました。 .NETFrameworkと.NETCoreの両方をサポートするようにします。 .NET Coreには、これらの改善のコピーがありますが、改善する必要がないため(消費できませんでした)、元に戻されていません。

そうですが、この場合、これは間違いなく正しい方法です。 待って実装を続けるのはイライラしますが、フレームワークやライブラリを作成するときに他の人が行うこととこれがどのように違うのかわかりません。

  • コアプリミティブを回転させる機能がない場合は、それらをフォークして、それらに似ているがそうではないものを作成することをお勧めします。 これが、ASP.NETCorehttps://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives内に独自の小さなBCLがある理由です。

繰り返しますが、私たちの他の人と同じように。

ASP.NETCoreと.NETCoreは、軽量のマイクロサービスを構築するための競争力のあるクロスプラットフォームサーバースタックに関するものでした。

ASP.Net Coreには、そのようなメッセージがいくつかありました。 .Net Coreは、完全に機能するxplatサーバー側の.Netフレームワークサブセットとして初日からメッセージが送信されています。 .NetCoreはマイクロサービス専用であると誰かが言うのを聞いたことがありません。 必要に応じてASP.NetCoreで使用できると聞きましたが、コンソールアプリ、データ分析、DBサービスなども使用できます。.NetCoreの方向性は、事実上「ASP.NetCoreチームが最も望んでいるものは何でも」ですか。

フルフレームワーク上のASP.NETはそのまま残り、機能を取得しますが、Coreとは異なります。

それでしょうか? 私はまだMSの誰もそれがまだ取り組んでいることを確認するのを見ていません。 私の腸はそうではないと言っています。 わかった。 チームが自由になるには、「動かすか失う」タイプの瞬間が必要です。 まだその瞬間ではないと思います。

Oracle.Netドライバー、NHibernate、およびRabbitMQ(すべて4.6)を使用するビジネスロジック4.6アセンブリがあると仮定します。 ASP.Netとのインターフェイスは、ビジネスオブジェクト、要求、および応答を介してのみ行われます。 再コンパイルせずに、ASP.Net Core 2でこのアセンブリを参照できますか?

私の簡単な要約
aspnetcore

@ stefan2410短い答え、いいえ、完全なフレームワークを参照することはできません。これらのアセンブリは、netstandar2.0用に作成されている場合にのみ参照できます。

@mattnischan

これらはすべて、現在のネットスタンダードに加えてパッケージとして実装できます。 これにはnetstandard20も必要ありません。 この荷物を持ち歩きたくないことは理解していますが、MS以外の世界にいる私たちの残りの部分は、ユースケースやパフォーマンスが合わない場合は常にカスタムBCL風のimplを作成する必要があります。

申し訳ありませんが、実際にはそうではありません。 パッチタイプをモンキーパッチすることはできません。 あなたが提案していない限り、新しいタイプを追加し、既存のタイプを変更しないでください。

言うまでもなく、Span APIは2.0も対象としていません(再度変更されない限り)。

Spanは2.0に実装として存在しますが、パブリックAPIには存在しません。 新しいメジャーで重大な変更を加え、マイナーバージョンでより多くの機能を実行できるようにします。 ASP.NETCore2.1が.NETStandard2.1を対象としている場合、.NETFrameworkのサポートは再び削除されます。

これは少しトリッキーな気がしますが、libuvを持ち歩くKestrelとそれほど違いはありません。 .Net CoreからのCURL実装は、誰もが追いつくまで、netstandard拡張パッケージに簡単に取り込むことができます。

つまり、両方の.NET Standardで使用できるように、BCL内のすべてのクラスの名前を変更する必要があります。

.NetCoreはマイクロサービス専用であると誰かが言うのを聞いたことがありません。 必要に応じてASP.NetCoreで使用できると聞きましたが、コンソールアプリ、データ分析、DBサービスなども使用できます。.NetCoreの方向性は、事実上「ASP.NetCoreチームが最も望んでいるものは何でも」ですか。

いいえ、.NET Coreは汎用フレームワークであり、元々はそのコアに業種がありませんでした。 ASP.NET Coreは、.NET Coreの上にあるライブラリではなく、垂直方向である必要があった可能性があります。これにより、この混乱の一部を回避できた可能性があります。

それでしょうか? 私はまだMSの誰もそれがまだ取り組んでいることを確認するのを見ていません。 私の腸はそうではないと言っています。 わかった。 チームが自由になるには、「動かすか失う」タイプの瞬間が必要です。 まだその瞬間ではないと思います。

はい、HTTP/2サポートは前回のリリースで追加されました。 ASP.NETとIISに取り組んでいる別のチームあり、それらは改善を行っています。 ただし、ASP.NETCoreが実行しているものと同じ規模ではありません。

疫病のような完全なフレームワークでASP.NETCoreサービスを実行することを避けたので、これについてはあまり強い気持ちはありません。 そうは言っても、 netstandard2.0を待っているか、単に望んでいないという理由で.NET Standardをサポートしていなかったため、いくつかの優れた成熟したライブラリの使用を避けなければなりませんでした。

私の恐れは、フルフレームワークでASP.NET Coreを実行する機能を削除すると、ユーザーが現在のMVC 5 / Web API2アプリをASP.NETCoreに移植することを思いとどまらせ、ライブラリ作成者が.NETへの移植を回避するもう1つの理由を提供することです。標準。 どのユーザーにもメリットがないのに、なぜわざわざアップグレード作業を行うのでしょうか。 それは鶏が先か卵が先かという問題になり、それがある程度の牽引力を獲得し始めたのと同じように、これが生態系全体を傷つけるのではないかと心配しています。 まず、ASP.NET Coreユーザーが必要ですが、私たち全員が望むほど多くのユーザーがいるとは思いません。 うまくいけば、私は間違っています。

ASP.NETCore2.1が.NETStandard2.1を対象としている場合、.NETFrameworkのサポートは再び削除されます。

いいえ、それは、NetFrameworkが.NETStandard 2.1をサポートするとすぐに、たとえ1、2年かかる場合でも、ASP.NETCore2.1を自動的にサポートすることを意味します。

他のすべての.NETStandard準拠プラットフォーム(Xamarin / Unity / ...)についても同じです。

.NET Standardに基づいて構築すると、他のプラットフォームが_最終的に_点灯し、.NET Coreに基づいて構築すると、__決して__点灯しなくなります。

たとえ長い遅延があっても、full-fxがnetstandardに追いつくという計画はまだあると思いますか?
(そして、NETCore以外の他のプラットフォームが.NETStandard 2.1を実装することが期待されていないのなら、なぜ.NET Standardを持っているのでしょうか?)

申し訳ありませんが、実際にはそうではありません。 パッチタイプをモンキーパッチすることはできません。 あなたが提案していない限り、新しいタイプを追加し、既存のタイプを変更しないでください。

後者は、ほとんどの場合、1.xですでに行われていることですよね? それは突然、もはや耐えられなくなりますか?

Spanは2.0に実装として存在しますが、パブリックAPIには存在しません。 新しいメジャーで重大な変更を加え、マイナーバージョンでより多くの機能を実行できるようにします。 ASP.NETCore2.1が.NETStandard2.1を対象としている場合、.NETFrameworkのサポートは再び削除されます。

なぜそれが落とされるのでしょうか? SpanはFrameworkに存在しないと言っていますか?

つまり、両方の.NET Standardで使用できるように、BCL内のすべてのクラスの名前を変更する必要があります。

うわー、いや。 別のAPIを使用した辞書が必要な場合は、Microsoft.Net。*で既に行ったように、他の何かを作成する必要があり、System.Collections.Generic.Dictionaryとは呼ばないでください。

はい、HTTP/2サポートは前回のリリースで追加されました。 ASP.NETとIISに取り組んでいる別のチームがあり、それらは改善を行っています。 ただし、ASP.NETCoreが実行しているものと同じ規模ではありません。

それは公正です。 私はそのことに気づいていませんでした。

後者は、ほとんどの場合、1.xですでに行われていることですよね? それは突然、もはや耐えられなくなりますか?

それは混乱を引き起こします。 彼らはそれをできるだけ少なくしようとしました。 APIの設計とデプロイは、ほとんどの人が理解しているよりもはるかに複雑だと思います。 そして、それをそのようにしているのはマイクロソフトの人たちではなく、多くのプラットフォームとタイムラインをサポートするという現実です。 何度かその真っ只中にいて、すべてを話し合うまで、私はこれに感謝しませんでした。 ただし、タイプ転送がメソッドレベルで行われることを本当に望んでいます。 これまでのところかなりの数のケースを解決しているでしょう:(

なぜそれが落とされるのでしょうか? SpanはFrameworkに存在しないと言っていますか?

完全なフレームワークにはまだタイムラインがないため、タイムラインが調整されなくなるため、 ASP.NETCore2.0から削除する必要があります。

完全なフレームワークにはまだタイムラインがないため、タイムラインが調整されなくなるため、ASP.NETCore2.0から削除する必要があります。

AFAIK、スパンは.NETデスクトップで使用できるnetstandard1.xパッケージの一部です(これはポータブルな実装であるため、CLRにバックアップされた場合と同じパフォーマンスブーストはありませんが、可能性があります十分に良い)。

編集: System.Memoryパッケージにはnetstandard1.0 TFMがあるため、.NET4.5でも使用できます。

image

後者は、ほとんどの場合、1.xですでに行われていることですよね? それは突然、もはや耐えられなくなりますか?

そのため、本日、特定の方向で機能の作業を停止します。 これは意図的なものであり、.NET Frameworkが機能できるように、.NET Standardの外部でコピーして再実装することにより、新しいAPIの使用を控えて拒否します。 これがすべてではありませんが、今後触れたい基本的な部分がいくつかあります。結局のところ、私たち(Microsoft)は双方を管理しています。

なぜそれが落とされるのでしょうか? SpanはFrameworkに存在しないと言っていますか?

Span自体には、どこでも実行できるポータブルバージョンがあります。高速な実装が、.NETFrameworkで行われるかどうかはわかりません。 Spanを利用する.NETFrameworkに追加されるAPIは、Span自体よりもはるかに長い時間がかかる可能性があります。 .NET Frameworkで文字列と配列を最後に変更したのはいつですか?

うわー、いや。 別のAPIを使用した辞書が必要な場合は、Microsoft.Net。*で既に行ったように、他の何かを作成する必要があり、System.Collections.Generic.Dictionaryとは呼ばないでください。

それはまさにあなたが提案していることです。 Microsoft.Extensions.Collections.Genericは必要ありません。 これを回避するために最善を尽くし、可能な場合は古いAPIとポリフィルを使用します(https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs)。 これは持続可能ではなく、.NET Coreの使用を積極的に回避しているため、.NETCoreがメリットを享受できないことを意味します。

スパンを持つ@PinpointTownesは十分ではなく、既存のタイプへのメソッド呼び出しでそれらを使用する必要があります。 そのとき、クラスレベルの型転送が機能し、多くの問題が発生します。

@ 0x53A

それは公正です。 NuGetで人気のあるライブラリが、明らかにサポートされていない古い.NETFrameworkバージョンのサポートを終了しない理由を教えてください。 最も人気のあるライブラリは、net20、net35、net40などを対象としています。ASP.NETCoreを使い続けるために、最高バージョンの.NETFrameworkが突然必要になったのはなぜですか。 それは合理的だと思いますか?

これはショーストッパーです。 ASP.NET MVC 5 / WebApi2からCoreへの移行をキャンセルすることを検討する必要があります。 多くの安定したフレームワークはまだコアで利用できません。 EFコアは十分に成熟していないため、引き続きEF6.xを使用しています。機能の比較

スパンを持つ@PinpointTownesは十分ではなく、既存のタイプへのメソッド呼び出しでそれらを使用する必要があります。

「必要性」はおそらく少し過剰です。 スパンは主にパフォーマンスのために使用されるため、.NETデスクトップがスパンのネイティブサポートを取得するまで、ifdefを使用して.NETデスクトップで既存の超パフォーマンスではないオーバーロードを使用することを妨げるものはありません。

@davidfowl大きな問題は感情的なものだと思います。 netstandardをターゲットにしている場合は、最終的に1.xから2.xにアップグレードできることを知っています(遅延がある場合でも)。 ほとんどの場合、netfxの更新は、アプリケーションにとってそれほど大きな問題ではありません(libでは異なります)。

ただし、一部のアプリはジャンプnetfx-> netcoreを作成できないため、netcoreをターゲットにすると、1.xで行き止まりになっていることがわかります。

その点で、Asp.netコアがnetfxで実行されていなかったとしたら、それはもっと良かったでしょう。現状では、彼らは継続することを期待し、今では(当然のことながら、IMOは)裏切られたと感じています。 結局のところ、彼らはすでにこれに多くの時間を投資している可能性があります。

私はこれに個人的に投資していません。私はasp.netユーザーではないので、私の大きな質問は実際には

たとえ長い遅延があっても、full-fxがnetstandardに追いつくという計画はまだあると思いますか?
(そして、NETCore以外の他のプラットフォームが.NETStandard 2.1を実装することが期待されていないのなら、なぜ.NET Standardを持っているのでしょうか?)


net20、net35などをターゲットとする他のライブラリに関しては、私の経験では、ほとんどの作成者は可能な限り低いバージョンをターゲットにしようとし、他に選択肢がないプラットフォームのみをカットします。

そして__はい、まだ明確な移行パスが利用可能であるため、古いバージョンの.NETFramework__のサポートを終了することは合理的だと思います。 バージョンを更新するだけです。 ほとんどの場合、何も変更する必要はなく、「ただ」再コンパイルしてテストします。


ネットコアをターゲットにできないアプリの数を真剣に過小評価していると思います。これをブロックするには、単一のクローズドソースのサードパーティ依存関係で十分です。

Span自体には、どこでも実行できるポータブルバージョンがあります。高速な実装が、.NETFrameworkで行われるかどうかはわかりません。 Spanを利用する.NETFrameworkに追加されるAPIは、Span自体よりもはるかに長い時間がかかる可能性があります。 .NET Frameworkで文字列と配列を最後に変更したのはいつですか?

@davidfowlこれはおそらく問題の一部だと思います。 .Net Coreが登場する直前に開始されたグリーンフィールドアプリとして途中で立ち往生しているため、私は正直に悪魔の代弁者を少し演じてきました。

私たちの考えは常に、可能な限り新しいライブラリ(Kestrelなど)を使用することですが、 .Net Coreが安定するのを待ちます(ツールの変更のみの場合は、そうしてよかったです)。フレームワークに戻すためのクールなコアビット。 ほとんどの人の想定は、corefxが行ってきた進歩のすべてではないにしても、ほとんどがFrameworkvNextまたはvNext+1になるというものだったと思います。 しかし、この変更やその他の変更から、Frameworkは将来のプラットフォームではないように見えます(30kフィートのビューから)。

そうだとしたら、そういうことだと思います。 私たちのプロジェクトは大規模なので、BCLタイプやifdefスパゲッティに近いが、完全ではないもののカスタムimplをたくさん持つことの苦痛を理解していると言ったら、私を信じてください。 だから、私は合併症の無知から物事を提案しているのではありません。 確かにトレードオフがあります。

確かに良い質問です。.netコア機能の.NETフルへのバックポートの残りは何ですか? 私がここで読んだように、.NET fullは非常に脆弱であり、コードをそこに移動するには時間がかかり(非常にゆっくりと移動します)、いつでも壊れることがあります(おそらく、それがどのように絡み合っているかはわかりません)。よく。

両方にすることはできません。.NETフルへのバックポートは問題ありません。リリースの頻度が少ない(たとえば、6か月から1年ごと)か、非常に複雑でエラーが発生しやすいです。 前者の場合は、ペースを上げて、ユーザーに請求書の支払いをさせず、後者を言い訳として使用するのをやめさせないでください。 後者の場合、正しい結論ではありません。将来的に重要なのは.netcoreのAPIだけなので、netstandardは誤謬です。

.NETの今後の方向性を真剣に考えています。 私の会社は、.NETfullおよび.NETstandard1.6用のツールを構築しています。 私たちが最後に望んでいるのは、.NETの方向性の原動力(すべての月の前に.NETコアの発表で述べられているように、.NETに完全にバックポートされようとしている新機能)が物事とエコシステムを効果的に分割することです断片化が殺しているので、半分に分割されます。

このスレッドには、 _all_ .NETの将来と、それを存続させるために必要なエコシステムに問題がないことを私に安心させるものはありません。2つのグループしか表示されません。

  • オプションが複雑になり、先に困難な問題を抱えていることを懸念している人々
  • マイクロソフトは、1つの道を先取りしています。それは.netコアロードです。

現在、これら2つは一致していません。 マイクロソフトの誰かが首尾一貫したストーリーを出して、実際の取引が何であるか、実際にどのようになっているのかを確認できますか? (sqlserverのもの、いくつか例を挙げるとトランザクションスコープ)そしてMicrosoftは、この新しい方向性を将来に向けて堅固で信頼性が高く信頼できるプラットフォームとして販売できると考えているため、企業や大規模なチームは心配することなくそれを選択できます。

これらすべてが長期的には良いことであることに同意しますが、2.0で完全なフレームワークのサポートを終了するのは時期尚早だと思います。

できるだけ早く.NETCoreに移行したいと考えていますが、残念ながら、現時点で最大のブロッカーはほぼ独占的にMicrosoftライブラリです(たとえば、Entity Framework Coreはまだ十分ではなく、Azure Service Busには非常に初期のプレビューしかありません)。

Azureライブラリが今後数週間/数か月で準備が整うことを願っていますが、EFCoreに十分な機能がすぐに備わっているとは思えません。

EF6の内部については何も知りませんが、合理的な努力でネットスタンダードをターゲットにすることは可能ではないでしょうか。 これは巨大なブロッカーを取り除くでしょう...

「1.xにとどまるだけ」は、気にしない(または両方をサポートするためのリソース/知識がない)ライブラリがたくさんあり、依存関係をにアップグレードするだけなので、良い選択肢とは思えません。 2.0

PS:ここ数年で.NETエコシステムがどれほど複雑になったかに非常に不満を感じています。 私はすべての新しいことを理解するために多くの時間を費やさなければなりませんでした、そして私は新しい開発者がこれのどれを理解するべきかわかりません。 これらの非常に極端な重大な変更のすべてのために、インターネット上には非常に多くの古い情報があります。
また、すべての異なる製品バージョン(.netコア、sdk、.net標準など)は非常に混乱します。 20分の説明を必要とせずに.NET標準テーブルを理解している人を見たことがありません。 😞

フルバージョンの.NETFrameworkで.netコアを使用していた人はだれでもがっかりし、MVC5に戻る必要があります。

うん。 私はその理由を理解しており、これが来るのを見るべきだったと言えると思いますが、事前の警告なしにこれを私たちに落としたのは非常に苛立たしいことです。

他の多くのアプリケーションと同様に、10年以上前にさかのぼる共有ライブラリ、複数のMVC 3、4、5アプリ、コンソールアプリ、Windowsサービス、数十万行のコードを備えたアプリケーションエコシステムがあります。 いくつかの状況と比較して、アップグレードするのにそれほど悪い状況ではありません。

最近、ASP.Net Core 1.1を使用して、必然的に完全な4.6.2フレームワークを対象としたいくつかの新しいWebアプリを立ち上げました。 これらのアプリは、既存の共有ライブラリの大規模なスワスを使用します。 project.json、次に新しい.csprojを処理するために、恥ずかしい量の開発時間を費やしました。同じソリューションで古い.csprojと新しい.csprojを混合しようとし、VS15に戻って、古い.csprojタイプで処理を実行しました。システム。 依存関係、およびアセンブリバインディングの問題、ビルドと公開の問題の連なり..リストはどんどん増えていきます。

そして今、私たちは行き止まりで高くぶら下がっていて乾いたままになっています。 数人月の開発を捨てるか、何回も費やして、最初に何がうまくいくか、何がうまくいかないかを確認し、次にアップグレードする方法を考え出し、それが可能かどうかを考えますか?

その方向性や必要性に異議を唱えることはできませんが、早めのコミュニケーションをいただければ幸いです。

もちろん、AzureServiceFabricライブラリは.NETコアでも実行されません。これは私たちにとってもう1つのブロッカーです。

Microsoft(特にAzure)内で適切な.NETコアストーリーを提供できるようになるまで、完全な.NETFrameworkをサポートする必要があると思います。

@ cwe1ssこの変更により、.NETエコシステムの複雑さが軽減されます。 2つの異なる形式(ASP.NET Core +.NETFullとASP.NET+.NET Core)がないためです。 古い情報については完全に同意しますが、Microsoftが現在行っているように、オープンで開発する場合は避けられないと思います。

@davidfowl

さまざまな.NETランタイム間でのコード共有ストーリーは.NET標準です。 ライブラリは、.NETCoreと.NETFrameworkで共有されるコードをターゲットにする必要があります。<

しかし、私が理解しているように、完全なフレームワークはsupport.net標準すらサポートしていないため、実際には有用な標準ではありません。

Microsoftは下位互換性の重要性を忘れているようです。<<

問題は、ASP.NETCoreが下位互換性を持つことを意図したものではなかったことです...そのため、ASP.NET4.xからこのような大きなパラダイムシフトがありました。 下位互換性が上位ビットである場合は、.NETFrameworkでASP.NET4.xを使用する方がよいようです。 これは当面の間サポートされており、Windowsが稼働している限りセキュリティパッチが適用されます。<

セキュリティパッチは問題の一部にすぎません。 Web標準は急速に変化するため、最新の標準を使用できるものが必要です。 たとえば、HTTPSv2について何かより上のところを見ました。 それが実際に何を意味するのかはわかりませんが、重要なのは、フレームワークがこれらのことをサポートできるようにしたいということです。 フレームワークがv4であろうとv1であろうと、古いバージョンのフレームワークを使用せざるを得ない場合、必要なものはサポートされません。

ASP .net Coreは、常に.netCoreとフレームワークの両方で実行されるものとして販売されていました。 他の人が言っているように、フレームワークが追いつくまで6か月または1年待たなければならないのは気になりません。 とにかく私は通常約6ヶ月以上遅れています。 しかし、起こっているように見えるのは、私たちの多くが時間を費やしてきた他の多くのマイクロソフトテクノロジと同様に、既存の投資が完全に放棄されているということです。

ステファン

@Rutixは「オープンで開発」したため、この大きな重大な変更は、発表も調査も行わずに驚くほど静かに行われました(結局、この問題はプルリクエストを監視しているコミュニティメンバーによって作成されました)。

物事を黙って行うことは過去にマイクロソフトを噛んだことがあり、彼らは学んでいないようです。 また、完全なフレームワークサポートを削除すると、コミュニティが混乱し、プラットフォームへの信頼と投資が損なわれることを彼らが理解できなかったと私に言わないでください。

前回のインシデントはhttps://github.com/dotnet/roslyn/issues/17054でしたが、すぐに修正されました。これがどのように解決されるのか疑問に思います。

しかし、私が理解しているように、完全なフレームワークはsupport.net標準すらサポートしていないため、実際には有用な標準ではありません。

@stefanolsonそれは正しくありません。 .Net Standard 1.xを対象とするライブラリは、現在、さまざまなフルフレームワークバージョンで実行できます。 .Net Standard 2.0を対象とするライブラリは、私が最後に調べた4.6.1で実行できるようになる予定です。

@Suchiman私はそこであなたに完全に同意します。 彼らがコミュニティに爆弾を投下する方法を学んでいないようであることに少しがっかりしています。 彼らが最初にそれを発表し、コミュニティの議論をしていれば、彼らはこの方法をよりうまく処理できただろう。

しかし、私が理解しているように、完全なフレームワークはsupport.net標準すらサポートしていないため、実際には有用な標準ではありません。

@stefanolsonそうです。 異なる(既存の)バージョンの.NET Frameworkは、異なるバージョンの.NET標準を実装します。 https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/を参照してください

このスレッドに少し遅れていることはわかっていますが、WindowsのNetFXでASP.NETCoreを使用するための2つのユースケースを次に示します。

ASP.NETを使用してアプリケーションのRESTAPIをホストする

私たちのアプリケーションは、「。NETAPIからRESTAPIに変換された」種類のアプリケーションです。 最初は.NETAPIとして出荷され、あらゆる種類のWindowsに依存関係があります。

REST APIを追加したとき、それをホストするためにASP.NETWebAPIを選択します。 WebAPIがASP.NETvNext/ 5 / Coreで統合されていることが明らかになったとき、__ and____ASP.NETCoreはNetFX__で実行されることがわかりました。ASP.NETvNext/5/Coreを使用するのは理にかなっています。

.NET Coreを利用してアプリケーション(の一部)をLinuxおよびmacOSに移植しますが、.NET Coreでは実行されないWindows依存関係がまだあります(移植した依存関係のリストを取得するには、 CoreCompat.* NuGetパッケージ)。

非常に長い話ですが、ASP.NET Core 1.xにロックされていることに気付きました。これは、約限られた期間だけサポートされます。 そして、何? ASP.NET 4に戻りますか?

私はあなたが行っているすべてのパフォーマンス作業を理解し、.NET Coreの他の領域で限界を押し広げていますが、私のユースケースでは、大量のインターネットに公開されたWebサイトをホストしておらず、RESTAPIをホストしています。最大10〜20 RPSのようになりますか?

VisualStudioのサポート

実際、NET4.xでのVisualStudio 2017のエクスペリエンスは、.NETCoreよりもはるかに優れています。テストプロジェクトを再コンパイルして新しいテストをテストウィンドウに表示するのに時間がかかる良い例です。 。 NetFXでははるかに高速です。

今日、NetFXと.NETCoreプロジェクトが本質的に同じコードベースを並べてコンパイルしている状況になります。 この二重のメンテナンスについていく唯一の理由は、.NET Coreプロジェクト(特に単体テストとデバッガー)でのVisualStudioのパフォーマンスのためです。

後付けとして、私が本当に驚いたのは、この変更がプレビューリリースの数日前に行われたことです。 まだ技術的な理由がないことを示しているようです。ASP.NETCorev3で変更を加えてみませんか?

@mattnischan

@stefanolsonそれは正しくありません。 .Net Standard 1.xを対象とするライブラリは、現在、さまざまなフルフレームワークバージョンで実行できます。 .Net Standard 2.0を対象とするライブラリは、私が最後に調べた4.6.1で実行できるようになる予定です。<

asp.netコアが.net標準ではなく.netコアを実行するように見えますか? そのため、.net標準のポイントが何であるかはまだわかりません。作成されるとすぐに、事実上放棄されるかどうかです。

現時点ではフレームワークにないものが必要なため、asp.netコアに.net標準2.1が必要な場合は完全に理にかなっています。 そのため、最新バージョンのAsp.netコアを使用するには、完全な.netフレームワークがこれらの追加機能をサポートするまで待つ必要がありました。 それはうまくいき、理にかなっています。

しかし、代わりに、標準を放棄して標準を役に立たなくしているだけです(この紛らわしい状況を正しく理解している場合)

だから...そのビルド2017は明日から始まります。 チームは準備にとても忙しいと思います。 多分いくつかの発表、多分そうではありません。 おそらく、彼らに少し呼吸の余地を与えて、1週間で再び召集しますか?

たぶん、ショーhttps://build.microsoft.com/をキャッチします(水曜日8:00 PST、15:00 GMT、木曜日も同様ですか?)

私たちはもっと知っているかもしれません。 ではないかもしれない。 物事はより明確かもしれませんが、そうではないかもしれません。 ただし、ASP.NETチームは、もう少し適切に対応し、すべての人の懸念にもっと集中できるようになるでしょう。 @davidfowlは勇敢にやっていますが!

@stefanolsonしかし、代わりに、標準を放棄して標準を役に立たなくしているだけです(この紛らわしい状況を正しく理解している場合)

.NETStandardのポイントは互換性だと思います。 ライブラリの作成者は.NETStandardをターゲットにでき、.NET Framework、.NET Core、または.NET Standardをサポートするその他のものを使用している場合でも、誰でもそれを使用できます。

.NET Coreのポイントは、.NETFrameworkを再考することだと思います。 .NET Coreは、クロスプラットフォーム、高性能、オープンソースであり、急速に進化しています。

文字列の実装をデフォルトでutf8に変更することは大規模であり、.NETFrameworkで期待されることではありません。

このスレッドを読んだ後、私は感じます:
.NET Core-> .NET Frameworkは、ASP.NETMVC->WebFormsに似ています。

ツーリングの側面も2番目にしたいと思います。 現在の復元/ビルド/テストなどのパフォーマンスは非常に悪く、非常に苦痛です。 「1.0にとどまる」必要がある場合でも、(うまくいけば)より優れたパフォーマンスで新しいSDKを使用できるでしょうか、それとも1.x SDKで立ち往生するでしょうか?

.NET Coreストーリーは、浮き沈みに満ちた素晴らしいツアーです。 以前のすべての「ファックアップ」(バージョン管理、命名、project.json-.csproj遷移)のために、最近ASP.NET Coreの作業を開始しました。私は、.netstandard 2.0を楽しみにしていました(そして私はそう思っています)。これは最初の「実際の」リリースになります。

ASP.NET Core 1.1は引き続きサポートされており、今後10年間は​​実行されると思いますが、皆さんは__that__を高速に移動し、ASP.NETCoreの以前のセールスポイントの1つを削減することに非常に勇気を持っています。

私たちの側から(ディレクトリサービス以外の)ブロッカーとは何かを知りたい場合:私たちはまだEF6を使用しており、netstandardwhateverをターゲットとする公式のOpen XMLSDKNuGetパッケージを待っています。
コードの移行には非常に長い時間がかかる場合があります...

Asp.Net Coreライブラリリリースのメンテナンスフェーズの一部としてコアをターゲットにすることを含む、コアで発生する変更に基づいて、 netstandardXXを進めるためのある種のプロセスを形式化することは可能でしょうか?

現状では、ANC Web APIをSPA(および最終的にはWebFormsレガシーアプリ)に公開して呼び出すときにトリガーを引くWebForms / MVCアプリがありますが、CoreCLRで開発することはできません。 Sybase(現在はSAP)Ase ADO.NETドライバーへの依存(これを読んでいる人がSAPのどこかのボタンを押す可能性がある場合...悲しいことに、これや私が知っているバグについてはまったく聞けないようです9年になります)。

この問題を読んで、私は私の道がどうあるべきかもうよくわかりません。 私が計画できると確信している唯一のことは、デスクトップフレームワーク用のバグのあるドライバーが引き続き存在することです。 過去数年間のASP.NETへの変更は時間の無駄になり、WebApi2のみをターゲットにする必要があるため、無視することになっていましたか? 移行することはないだろうという知識の下でANC1.xを進めて、今後10〜15年間ここでサポートされると信じているアプリケーションで2.xの利点を確認することになっていますか(WebFormsアプリは1.1フレームワークがリリースされてから移行および保守されています)?

@davidfowl

Span自体には、どこでも実行できるポータブルバージョンがありますが、高速な実装が実現するかどうかはわかりません。
.NETFrameworkで。 Spanを利用する.NETFrameworkに追加されるAPIは、Span自体よりもはるかに長い時間がかかる可能性があります。 .NETで文字列と配列を最後に変更したのはいつですか
フレームワーク?

待って、何?

私たち全員がWeb開発者というわけではありません。 私たちは何年にもわたってより良い文字列処理のサポートを待ち望んでいましたが、突然あなたは私たちがSOLだと言っていますか? .NET Frameworkとその上に構築された無数の非Webアプリケーションが、Spanに基づく文字列処理ライブラリにアクセスすることは決してないということですか?

これはもはや単なるASP.NETの問題ではありません。 これは、.NETFrameworkとその基本クラスライブラリに対するMicrosoftの長期的な取り組みの中心にあります。

ご存知のように、私は@davidfowlのような人々に、この議論に貢献してくれたすべての人とすべての人に応答し続けるためにそれを本当に与えなければなりません。 今日の初めから追いつくことがたくさんありますが、誰もが.NETを使用している、または使用したいと思っていることに関して、コメントごとに多くのことを学んでいるように感じます。

みんなの助けを借りて、最終的にはいくつかの道がまっすぐになると思います。すべての側面が考慮されることを願っています。

公式発表を心待ちにしています

私が正しく理解していれば、net coreapp 2.0は、ASP.NET Core 2.0プロジェクトが従来のNetFxクラスライブラリ(net461など)に依存できるようにする互換性シムを提供します。
そのような互換性のあるシムの現在計画されている機能/制限に関する詳細情報はどこにありますか?

@dgasparこれは正確ではありませんが、その仕組みは次のとおりです。 netcoreapp2.0は、 net461ほとんどのAPIをサポートしています。 ライブラリがnet461用に構築されており、 netcoreapp2.0がサポートするサブセット内に存在するAPIのみを呼び出す場合は、とにかくライブラリをインポートできます(オーバーライドとして考えてください。よく知っています)。呼び出すすべてのクラスとメソッドがそこにあるはずなので、実行させます。

ここで、欠点もあります。メソッドが存在しないか、何らかの方法で完全にサポートされていない場合、メソッドが欠落しているなどの実行時エラーが発生します。したがって、コンパイル時のチェックは十分な保証ではありません。 知っておくべきは少し両刃の剣ですが、まだ更新されないライブラリの中には、呼び出すAPIのセットで問題がないものもあります。

@NickCraver誰もが覚えています...

"imports": [ "dnxcore50", "portable-net45+win8" ]

私が12月に行った関連コメント。 11の親指を立てて繰り越します:

ここで何かが軌道に乗っていない。 私は15年間C#アプリを出荷しています。 皮肉なことに、より高いレベルの抽象化がMicrosoftによって出荷されているので、以前は心配する必要がなかった内部を深く掘り下げることにますます多くの時間を費やしています。 あなたはそれを間違っています。

実行時に、コンパイラがキャッチしなかったランダムなライブラリとパッケージ管理によって引き起こされたエラーに驚かされたい場合は、Rubyでアプリを作成します。

node.jsでさえ、すべてのnetfxライブラリを簡単に呼び出すことができます。

mvcコードは本当に簡単な部分です。 node.jsまたはnancyで書き直すには数週間かかる場合がありますが、ビジネスコードとアルゴリズムコードを移植するのにはるかに長い時間がかかり、古いものと同じように機能することが証明されます。 ソースがない場合は言うまでもありません。

RyuJitの例を見てみましょう。リリース後も、主要なバグのブロックが見つかり、完全に解決するにはさらに1年かかりました。 ペットショップではなく、1日数百万ドルを稼ぐのに役立つ産業用ツールである私たちのソフトウェアについても同じです。

UIフレームワークは、winformからWebに急速に変化します。 しかし、コアビジネスロジック/アルゴリズムははるかに安定しており、長寿命です。 したがって、新しい光沢のあるUIフレームワークを使用するには、ビジネス/アルゴリズムコードを書き直す/再テストするか、放棄する必要がありますか? いいえ、新しい光沢のあるものは5年以内にもっとトレンディなものに置き換えられることはわかっていましたが、ビジネス/アルゴリズムコードは引き続き使用されます。

@qmfrederik

後付けとして、私が本当に驚いたのは、この変更がプレビューリリースの数日前に行われたことです。 まだ技術的な理由がないことを示しているようです。ASP.NETCorev3で変更を加えてみませんか?

次にHTTP2サポートを行っており、新しいAPIが必要です。

ツーリングの側面も2番目にしたいと思います。 現在の復元/ビルド/テストなどのパフォーマンスは非常に悪く、非常に苦痛です。 「1.0にとどまる」必要がある場合でも、(うまくいけば)より優れたパフォーマンスで新しいSDKを使用できるでしょうか、それとも1.x SDKで立ち往生するでしょうか?

うん、それはうまくいくでしょう。

@davidfowl

次にHTTP2サポートを行っており、新しいAPIが必要です。<

では、asp.net Core 2.0で利用できるようなHTTP2サポートは、1.xでは利用できないのでしょうか。 これは、なんらかの理由で完全な.netフレームワークにバインドされているため、最新のテクノロジにアクセスできない場所について私が心配している種類の問題です。 上で述べたように、そのフィルターが私が使用しているものに到達するのに6か月から1年かかるかどうかは関係ありませんが、最終的にはそれほど遅れたくないのです。 この段階ではコードシェアとサードパーティのライブラリを使用しているため、完全な.netフレームワークが必要です。

最後に、私はいくつかのことを明確にします:

  • レガシーモジュールと言えば、netfxまたはc ++ / cli dllに依存するdllであり、ネイティブdllをピンボークする可能性があります。 それらはビジネス/アルゴリズム用であり、COM、asp.netはありません。 彼らは悪くない。 主に.netコアがそれらを実行しないため、それらはレガシーになります。
  • 長期的にはネットコアに移行することは可能であり、私たちはそれを本当に望んでいます。 しかし、それを実現するのは本当に難しいです。私たちとサードパーティがすべてそこにいるまでには数年かかるでしょう。
  • ドメイン固有のライブラリは、技術スタックの変更に関して主流のライブラリよりもはるかに低速です。 私たちは皆、Python3の例を知っています。 これらのドメイン固有のライブラリは実際のビジネスです。

@danielcrabtree

.NET Coreのポイントは、.NETFrameworkを再考することだと思います。 .NET Coreは、クロスプラットフォーム、高性能、オープンソースであり、急速に進化しています。<

これは素晴らしいです。 課題は、既存のコードベースをどのように処理し、それらを.netコアでどのように使用できるようにするかです。 WPFが.netコア上に構築されて利用可能であれば、どこでも.netコアを使用できます。 しかし、そうではなく、私のコードはWPFとASP.netの間で共有されているので、それらを共有する方法が必要です。 しかし、私は最新のWebテクノロジーとセキュリティ技術に大きく遅れをとることを望んでいません。そのほとんど(すべて?)は2.x以降にのみ存在するように聞こえます。

このスレッドや他の場所のドキュメントでは、.NETCoreはクロスプラットフォームとして説明されています。 これは、プラットフォームに移行するための主要なセールスポイントの1つとして宣伝されました。

しかし、Twitterでのこの会話で明らかにされているように、これは当てはまらないようです。

https://twitter.com/James_M_South/status/861595907782987776

そして上記のコメント; 強調鉱山。

.NET Core 2に欠けている残りの大きなギャップは、System.DirectoryServicesとSystem.Drawingです。 この夏、Windows上の.NETCoreで両方を有効にするWindows互換パックの作成に取り組んでいます。

私は、 ImageSharpSystem.Drawingによって残されたギャップを埋めようとして非常に早い段階から、.NET Coreで非常に熱心に取り組んできましたが、今では非常に混乱し、少し不満を抱き、次のように尋ねています。

今の.NETCoreとは何ですか?

これがMSDocsからの説明です。

.NET Coreは、MicrosoftとGitHubの.NETコミュニティによって維持されている汎用開発プラットフォームです。 クロスプラットフォームであり、Windows、macOS、Linuxをサポートしており、デバイス、クラウド、組み込み/IoTのシナリオで使用できます。

そのクロスプラットフォームステートメントが再びあります。 それですか、そうではありませんか? これを特定しようとすると、開発コミュニティ全体で多くの混乱が生じると思います。

私が読んだすべての説明は異なっているようです。

していい:

  1. 適切で一貫性のあるメッセージをどこかに書き留めてください。そうすることで、実際に目標を設定し、全体的な理解を深めることができます。
  2. System.DirectoryServicesSystem.Drawingの実際のロードマップで明確な情報を提供します

特にSystem.Drawingは、混乱を招き、懸念を抱いています。 そのAPIを任意のプラットフォームの.NETCoreに移植したいと思う理由を理解することはできません。 作業が難しく、サーバーでサポートされておらず、最新の開発に必要な多くの重要な機能(マルチスレッド、ピクセル形式、ICC、EXIF、量子化、インデックス付きPNGなど)が不足しています。

ここには認識できる名前や顔がたくさんあります。ここにノイズを追加しているだけですが、次のようになります。

  • DirectoryServices
  • 描画(必要なわけではありません)
  • EF

これらは、このような大きな休憩をとる前にスピードを上げるための3つの最も重要なことのように思われます。 個人的に、私が取り組んでいるほとんどすべては、EFCoreのために、EF6のためだけにnet4x上にあります...まあ...:trollface:

@stefanolson
共有コードを.NET標準ライブラリに分離することが期待されていると思います。 その後、.NET Framework上のWPFおよびASP.NETから、および.NETCoreおよびその他の.NETCoreアプリケーション上のASP.NETから使用できるようになります。

@JimBobSquarePants
Windowscompatpackは.NETCoreの一部ではないと思います。 これは、.NETCoreの上にあるWindows固有のライブラリです。 Linuxのみの機能を公開するLinux固有のライブラリがあることを想像できます。

Windows compat packは、既存の.NETFrameworkコードベースの移行を簡単にすることを目的としていると思います。 明らかに、誰かが.NET Coreに切り替えたら、ImageSharpのようなより良いソリューションへの移行を検討する必要があります。

@stefanolson
.NET CoreでWPFアプリケーションを作成できるWindows専用のWPFパックを作成することもできますが、これはWindowsでのみ実行されます。

このGitHubの問題は、ドイツのITニュースサイトで言及されています。
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

互換性パックについて聞いた最初の@danielcrabtreeに感謝します。

@MJomaaのリンクの翻訳: https ://translate.google.com/translate?u = https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert-

System.Xamlが移植されるのを待っています。

@alexwieseは息を止めないでください。

System.Xamlが移植されるのを待っています。

続ける; 噛みます。 WebサイトでXamlをどのように使用していますか?

続ける; 噛みます。 WebサイトでXmalをどのように使用していますか?

クロスプラットフォームUI(「グリーンスクリーン」コンソールアプリケーション、Xamarinアプリ、およびAngular SPA間で共有される画面テンプレート)。ビジネスルールエンジンにも使用されます。

わあ、わかりました。XAMLのXMLを何らかの方法でHTMLとJavascriptに変換していますか? 十分に公平😄

あなたがただトローリングしていたかどうかはわかりませんでした。

私も同じことをしていますが、この時点では実行せずに解析できないことを考えると、実際にはXAMLが移植されていることはわかりません。

わあ、わかりました。XAMLのXMLを何らかの方法でHTMLとJavascriptに変換していますか? 十分に公平😄

もちろん違います; 最初にJSONに変換しています😉

私たちの多くが引用されているこのトピックに関する別のニュース記事: https ://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss作者は@Grauenwolfです

@ alexwiese @yaakov-hそれについてのブログ投稿を読みたいです。 かなり面白そうに聞こえますが、私が慣れているものとは異なる一連の課題が伴う必要があります。

これは本当に悪いです。 ASP.NET Coreは、必要に応じてレガシーライブラリを活用できる場合、妥当な販売でした。 新しいものでそれができる場合は、いくつかのことを微調整して.NETCoreをターゲットにします。 それ以外の場合は、完全なフレームワークをターゲットにします。

この変更により、それはオールオアナッシングジャンプです。 また、すべての依存関係を前もって理解しているとは限らないことを考えると、リスクが大きくなります。

私は、速く動き、とにかく物事が進むはずの場所で進化したいという願望を理解していますが、あなたはユーザーを置き去りにするでしょう。 人々はジャンプするのではなく、移動する傾向があります。 多数の場合、現在の状態から外れることはありません。 そして、そうするとき、彼らは完全に別のプラットフォームに移動するかもしれません。 真剣に、あなたはそのリスクを過小評価しています。

これは最終的に行われるべき動きですが、早くても2019年後半または2020年のようです。 それでも、物事を混ぜることを選択した人々をサポートするための長期的なモデルが必要です。

いいえ、ASP.NETCore1.xはその答えではありません。 移行段階としては未熟であり、移行が容易ですが、長期的な生活には適していません。 このようなプラットフォームを開発する人とそれを使用する人の考え方には大きな違いがあります。 この方向を考え直してください。

@davidfowlネットコアのedge.jsのようなものはどうですか? これにより、APIコンシューマーがプラットフォームのチェックを担当するようになり、ほとんどのシナリオでは、netfxとnetcoreの間の強く型付けされたインターフェイスで十分です。

このテンプレートは削除されますか?

現在、VS2017に組み込まれています。

image

まったく容認できないでたらめですが、これもまた、それがプライムタイムと幅広い採用の準備ができていないおもちゃの技術であることを証明しています。

素晴らしい乗り心地とコーディングの経験を持っている人たちに本当に感謝しています。ブログエントリとツイッター(hoorrray!)で輝いて、LinkedInプロファイルとCVS(hooray ^ 2)を改善し、すべてのリリースパーティー、女の子、飲み物、ものは有望に見えますが、..誰がそれを使用するのですか? 企業をターゲットにして、大規模な採用と強固なユーザーベースを望んでいますか? またはいくつかのスタートアップヒッピーだけ?!?

「フルスパン」が.NETFrameworkに組み込まれない可能性があるというコメントは、私にとって深刻な問題です。 フルスパンが.NETFrameworkにない場合、それを使用するAPIが将来のネット標準になることはないと思います。これにより、高性能の解析を使用または公開するクロスプラットフォームライブラリを作成できなくなります。 つまり、安全でないカスタム実装に永続的に効果的に行き詰まっているということです...

ライブラリをクロスプラットフォームにしたい場合は、netstandardをターゲットにする必要があるとおっしゃっていますが、広く使用されているライブラリでない場合、ASP.NET Coreとは何ですか? 他のライブラリがnetstandardのサポートを終了し、.NET Coreに切り替えることをお勧めしますか? JSON.NETの次のメジャーバージョンまたはその他のネットスタンダードを削除する必要がありますか? それは確かに高速解析で行うことができます!

注Javaは、Netty(https://netty.io/)との下位互換性のある方法で、ゼロコピーなどの高速IOを追加することができました。

最後に、ぶらぶらして答えてくれる人たちに感謝します。 私たちは答えに感謝します...

@shanselman高速で移動することは、特にASP.Netチームのように、互換性に最重要の努力を払い、互換性のある方法で物事を設計するチームにとって、高貴な目標です。 私は彼らが問題の領域をどれだけ単純化したいと思っているかを知っています、そして私はそれを支持します、しかし...

速く移動すると同時に、顧客から「離れる」ことも良いことではありません。 ご存知のとおり、お客様(私を含む)は、レガシーソフトウェアの深刻なセットと、既存のアプリやライブラリへの時間投資を持っています。 あなたは私たちを置き去りにして、私たちがフォローできない/フォローできない場所に行くことはできません。

.Netコアにアクセスできず、少なくともしばらくの間はフルフレームワークを使用する必要がある顧客を検討する必要があります。 フルフレームワークから離れると、多くの人が古いバージョンに取り残され、.Netの世界に大きな分裂が生じます。

@JimBobSquarePants System.Drawingの部分で2番目になります。 System.Drawingを取り戻すことについて、他のリポジトリでいくつかの議論があります。 このスレッドのコメントのいくつかに基づいて、最初にWindowsに「コンパットパック」があり、次にすべてのOSにSystem.Drawingの「コンパットパック」があることを理解しています。

それはどのように見えるのか、そしてそれがMonoのlibgdiplusに基づいているのかどうか疑問に思います(これにより、System.Drawingに関する懸念の一部が取り除かれますが、それは別の話です)

さて、私がそれを見ると、危機に瀕しているいくつかの問題があります:

  1. これはかなり不十分に伝達されました。
  2. 人々は決定に関与していませんでした。 もちろん、Microsoftは好きな方向を自由に選択できますが、この種の大きな変更についてコミュニティと話し合わないことは、オープンソース開発の精神ではないことに注意してください。
  3. コミュニティがこれらのタイプの決定を検討するために使用できる「壮大な計画」はありません。 当初、.NET Coreは、完全なフレームワークのトリミングされたクロスプラットフォームバージョンでした。 次に、.NET Standard 2.0を使用すると、多くの人にとって、.NET Core 2は、当然のことながら(UWPやWinFormsなどがない)完全なフレームワークのドロップイン置換のように見えました。
  4. .NET Core 2は、System.DirectoryServicesなど、完全なフレームワークにあるいくつかの重要な機能を見逃します。 私の知る限り、これは認められていますが、おそらくこれらの機能を.NETCoreに追加するための道のりをより明確にすることができます。
  5. 完全なフレームワークには新しい機能がないため、ASP.NETCore2は完全なフレームワークでは実行されません。 私は実際これで完全に大丈夫です。 不足している機能を完全なフレームワークに追加するのが非常に難しい場合は、そうしないでください。 ASP.NETCore2を.NETCore2でのみ実行することは、実際にはかなり意味がありますが、1つの製品であると言及することは、それらの関係を説明するための最良の方法ではなかったでしょう。

人々が本当に見たいと思うのは、.NETプラットフォームのビジョンの説明です。 物事はどちらの方向に進みますか? 完全なフレームワークはバグ修正などを受け取るだけで、新機能は受け取りませんか? 不足している機能を.NETCoreに追加するために何が行われていますか?また、いつそれらを期待できますか? これを説明することは、人々が今感じている不安を和らげるのに大いに役立つことを願っています。

@davidfowlHTTP2.0だけではないと思います。 それが本当にHTTP2.0に関するものである場合、HTTP2.0サポートを除いてASP.NETCore2.0ターゲットNetFXを使用できませんでしたか? おそらく、コミュニティが本当に必要な場合にNetFXでHTTP 2.0を実行できるようにするための、プラグイン可能なモデルでさえありますか?

@cokkiy @ popcatalin81 @xprzemekw建設的な発言がない場合は、コメントを控えてください。この種のコメントは誰にも役立ちません。

@davidfowlhttps : //github.com/aspnet/Home/issues/2022#issuecomment-300141134で説明されている動きをする正当な理由があります

含めるのを延期する理由(たとえば、asp.net core 3.0):

  • 多くの機能が欠落しているため、EFCoreはまだEF6.0を置き換える準備ができていません
  • 生産準備ができていないSystem.Drawing交換
  • いいえSystem.DirectoryServices
  • office xml sdkについての言及がありましたが、2017-05-01https://www.nuget.org/packages/DocumentFormat.OpenXml/の時点でnetstandardですでに利用可能になっているようです
  • .netコアでは使用できないMSスコープ外の他のパッケージ(nhibernate、さまざまなdbプロバイダー、ikvm)

それをしない理由は次のとおりです。

  • 人々は、.netコアに移行する意図なしに、レガシー依存関​​係を持つasp.netコアにアプリを移植しました。
  • netstandardを置き去りにし、あまり気にしないことを心配します。
  • 一部のサードパーティパッケージが.netコアに移植される可能性はほとんどありません(これにより、おそらくそれらは廃止されますが、それは私の意見かもしれません)

建設的なコメントの例は、これら3つのシナリオのいずれかを見たい理由を追加したり、代替ソリューションを提案したりすることです。 同意/不同意を表明したいだけの場合は、「反応」ボタンを使用してください。

@Kukkimonsuta

人々は、.netコアに移行する意図なしに、レガシー依存関​​係を持つasp.netコアにアプリを移植しました。

完全に同意します。 Microsoftは、ASP.NETCoreが.netコアと.netフレームワークの両方で動作することを発表したためです。 そして今、それらをAspNetCore1.xに残すことは公平ではありません。

最後の要約はかなり良いです。 1つか2つ追加したいのですが。

1.).NET Coreを使用してWindowsサービスを記述できるはずです(* NIXプラットフォームのデーモンの動作が異なることはわかっています)。 したがって、ServiceBaseは引き続き必要であり、これはEFとともに優先度が高くなります。

2.)さらに、 .NET Coreを使用してスタンドアロンサービスを記述し、既存のフルフレームワークベースの.NETアプリケーション(つまり、Windowsフォーム/ WPFアプリからの無料サービス)内でそれらを拡張して拡張することも可能です。

後者は、ハードカットを行ってグリーンフィールドを開始することが不可能な、低速の移行シナリオで実際に必要です。

完全に同意します。 Microsoftは、ASP.NETCoreが.netコアと.netフレームワークの両方で動作することを発表したためです。 そして今、それらをAspNetCore1.xに残すことは公平ではありません。

また、.csprojとmsbuildへの大幅な変更は、既存の(フルフレームワーク).NETプロジェクトから(ASP).NETCoreプロジェクトを参照できないという事実で主に免除されたことを再度強調したいと思います。

この変更により、後者は不可能になります(少なくとも、ASP.NETの最大の部分では)。 では、なぜ当時は互換性が最重要だったのでしょうか(そして多くの苦痛を引き起こしました)、今はそうではありません(そして再び多くの苦痛を引き起こします)?

申し訳ありませんが、私もストレスを感じる必要があります。 しかし、ほぼ500のコメントがあります。この問題についてマイクロソフトの担当者として関わっていれば、2つの選択肢があります。
1:問題をミュートする
2:私の決定について再考する

@gingters csprojの変更は、主に_.net_コアに対するものでしたが、xamarin、asp.net、uwp、およびその他すべてがコードを共有し、ネイティブコードなどの他のプロジェクトタイプも参照するためです。

また、asp.netコア2プロジェクトが、互換性のあるシムを介して完全なフレームワークプロジェクトを参照できるようにします。

@qmfrederik

おそらく、コミュニティが本当に必要な場合にNetFXでHTTP 2.0を実行できるようにするための、プラグイン可能なモデルでさえありますか?

彼らは技術的に可能でした。 しかし、彼らは望んでいないようです。 私には、企業や大企業の本当のニーズや、下位互換性やグリーンフィールド以外のものに対処する必要性について考えたくないと感じています。

率直に言って、これまでの期待値管理は、既存のアプリをゆっくりと拡張/移行できる一方で、クロスプラットフォームにゆっくりと拡張/移行したいビジネスを完全に対象としていました。 したがって、この動きは以前の期待値管理とは完全に一致していません。

@ aL3891

xamarin、asp.net、uwp、およびその他すべてがコードを共有するため

はい。 丁度。 また、.NETCoreライブラリを使用するためのWPF/ Windowsフォームアプリも含まれています。これは、.NETCore2に移行する場合は不可能になりました。

誰かがこれらのライブラリがnetstandard2.0をターゲットにできない理由を正確に説明できますか?

これまで、 netcoreappをクロスプラットフォーム実行可能ファイル(csproj実行可能プロジェクトでのみ使用)のモニカと見なしていましたが、プラットフォームとは見なしていませんでした。今では、実際のプラットフォームと見なす必要がありますか? なぜ、なぜ、そしてどのようにしてこのばかげた選択肢にたどり着いたのでしょうか。

netcoreapp2.0をターゲットにすることの背後にある理由と論理的根拠はわかりますが、この動きは非常に時期尚早だと思います。 エコシステムはまだ準備が整っておらず、非常に広く使用されている依存関係(グリーンフィールド開発で使用される可能性が高い依存関係を含む)のかなりの数がネットスタンダードをターゲットにしておらず、それらがこれまでにそうなるかどうかは不明です。 Azure用のものを含め、netstandardを対象としないMicrosoftパッケージとSDKは言うまでもありません。

何かを投げ出すだけです。Windowsで実行しているときに、.NET Core 2.0を完全なフレームワークでポリフィルすることは可能でしょうか? すでにP/Invokeが存在するため、APIサーフェスを埋めるために、ファサードパッケージの背後にうまくラップされた何らかのNETFX/Invokeが存在する可能性があります。

結局、私たちの誰もがnetstandard2.0 $の代わりにnet461をターゲットにするものを使用したいとは思わない、それは依存関係ができない(APIがない)か勝ったというだけです(放棄された、したくないなど)変更されません。 そして、この問題を解決するには、パッケージ開発者に時間と非常に明確に伝達された計画を提供する必要があります。

@xoofx

誰かがこれらのライブラリがnetstandard2.0をターゲットにできない理由を正確に説明できますか?

私が理解している限り(私が間違っている場合は誰かが私を訂正します)、完全なフレームワーク(少なくとも4.6.1 )はnetstandard 2.0に準拠することになっているので、それを必要とする機能があります近い将来、完全なフレームワークにはなりません

私が興味深いと思うことの1つは、「ビジョンとは何か」についての質問全体に関連しています。 System.Drawingの頻繁な言及です。

クラス(たとえば、System.Drawing.Colorのような構造体とは異なります)System.Drawingは、少なくとも.net Framework 3.5の時代以来、ASP.netで何年もサポートされていなかったため、興味深いと思います。 ドキュメントから:

System.Drawing名前空間内のクラスは、WindowsまたはASP.NETサービス内での使用はサポートされていません。 これらのアプリケーションタイプのいずれかからこれらのクラスを使用しようとすると、サービスパフォーマンスの低下や実行時の例外など、予期しない問題が発生する可能性があります。 サポートされている代替方法については、WindowsImagingComponentsを参照してください。

もちろん、多くの場合、GDI +は機能するため、実際にGDI+を使用しています。 また、サポートされていない動作に依存するのが良いかどうかについては、ここでは説明しません。

しかし、.netCoreとASP.netCoreの現在のビジョンはどうなっているのだろうか。それは、優れたアイデアの再実装と、古くからの残骸(別名「.net-The GoodParts」)の削除ですか? その場合、なぜSystem.Drawingを導入するのでしょうか。

それとも、基本的には完全な.net Frameworkをマルチプラットフォーム、基本的にはより優れたMonoに書き直したものですか?

私はどちらの方法でも議論していません、私はただ知りたいです。 .netと.netCoreチームは、前者として始まり、現在は後者であると感じているため、魂の検索を行う必要があると感じています。

私はWindows上の.netFrameworkにとどまることを気にしません(私は雇用主のためにアーキテクチャを推進していないので、ここで私自身のプロジェクトについて話します)。 .net Frameworkは非常にうまく機能し、WindowsServer2016では少なくとも2027年までサポートされています。

もちろん、.netFrameworkを使用することには妥協が伴います。 たとえば、HTTP / 2サポートは、他のWebスタックよりもはるかに遅れてリリースされ、OSの完全なアップグレードが必要でした。間違っている場合は修正してください。ただし、私の知る限り、WindowsでASP.netを使用してHTTP/2を実行する方法はありません。 Server2012R2。 しかし、これらの妥協は、現状がさらに10年間サポートされるという強力な保証のために価値があります。

しかし、新しい開発のための完全なフレームワークを検討するために、完全なフレームワークでのASP.netのロードマップ(ASP.net MVC 6、Web API 3、SignalR 3などで計画されているもの)を確認したいと思います。基本的には、この世代のVisual Basic 6 / Classic ASP(.net)です。

速いペースで実現できる優れた機能がたくさんあるので、.net Coreに焦点を当てることはASP.netCoreの最大の利益であると感じています。また、.netCoreは永遠に初めてだと感じています。新しい開発のための生産準備ができています。 速く動き、革新し、基本的にNode.jsが成功したことを実行します(そして、彼らには独自の安定性/革新のドラマがあったことを忘れないでください。io.jsを参照してください)。

ここでコメントしているチームの皆さんに感謝します。これは多くの異なる視点を持つ長いスレッドですが、市民的な議論です。 @davidfowlが「では、移植するために実際に何が欠けているのか」と尋ね続けるのはイライラするに違いないことを私は知っています。 そして、このスレッドに役立つ答えを得るだけです。

しかし、現在.net Frameworkを使用している人々にとって、現在のASP.netは基本的に「完成」しており、すべての新しい開発はASP.net Coreで行われることを_感じ_、それは本当に正当な恐れとフラストレーションでもあります。基本的に、「VB.netに移動するか、数年後に立ち往生する」と言われたときにVisualBasic6の人々に何が起こったのか。

.netCore上のASP.netCore2.0を素晴らしいWebスタックにすることで、実際に倍増するのははるかに簡単だと思います。これまで使用できなかった人々が、ASP.netCoreの優れた部分がまだ道を見つけると安心した場合クラシックASP.netスタックに追加します。

とにかく、私のとりとめのないことは十分です。 チームが解決するのは非常に難しい問題であり、私はあなたを羨ましく思いません。 私(そしてここにいる他の多くの人々)が望んでいるのは、エコシステム全体がどこに向かっているのかを明確にすることだけです。

私が理解している限り(私が間違っている場合は誰かが私を訂正します)、完全なフレームワークはnetstandard 2.0に準拠することになっているため、近い将来、完全なフレームワークには含まれない必要な機能があります

ありがとう! どの機能を正確に知りたいですか? @davidfowlは上記のHTTP2が理由の1つであると述べましたか? 分離されたSystem.Http2アセンブリに実装できるプロトコルが、.NETプラットフォーム全体をフォークするのにどのようにつながるのでしょうか。 誰かが完全な推論についてもっと詳しく教えてもらえますか?

@gingtersですが、不可能ではありませんが、ライブラリは.netstandardをターゲットにして、46とコアの両方で使用できます。これは、asp.netコアだけではありません。

埋められてリンクできないため、再投稿します。

したがって、正しく理解すれば、最終的にはネットフレームワークをネットスタンダードに置き換えることができます。

そうではありません。 あなたがその結論をどのように引き出したかはわかりません。 .NET Standardは、それをサポートする各ランタイムのサブセットになります。

何度か言及されているので、ここにいくつかのクレイジーなものを投げたいと思います。 私がこれから言おうとしていることは、何が起こるかには関係ありません。現時点ではすべて推測です。 何人かの人々は、なぜ.NETStandardではなく.NETCoreをターゲットにしたいのかと尋ねました。

  • 文字列を.NETCoreで取り組みたい主要なものの1つとして特定しました。アイデアはたくさんありますが、そのうちの1つは、文字列をデフォルトでutf8にすることです(互換性の問題がたくさんありますが、ここでフォローしてください)。
  • 修正したいもう1つの点は、配列/文字列の安価なスライス、隣接するメモリの任意の部分を取得する機能です。 Span<T>を追加し、これを表すためにBuffer<T>を検討しています。 これは、StringとArrayが、0の割り当てを必要とするスライスを取得できるようにする新しいインターフェイスを実装していることを意味する場合があります。
  • これにより、毎回配列を割り当てない分割を可能にするStringの新しいメソッドが作成されます。
  • これにより、Int、UIntなど(TryParse)がオーバーロードされ、 Span<char>Span<byte>が必要になります。
  • これにより、 Span<byte>を使用する新しいエンコーディングルーチンが作成されます。
  • Buffer<T>Span<T>を使用すると、メモリを統一された方法で表すことができます。ネットワークスタックをアップグレードして、 Span<T>またはBuffer<T>を使用する事前に固定されたバッファを渡すことができるようにします。
  • Kestrelは2.xタイムフレーム(現在2.1を目指しています)でHTTP2を実装し、ALPN(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)を実行するにはSSLストリームに新しいAPIが必要です。
  • .NET Core上のHttpクライアントは、二重ストリーミングをサポートします。これにより、単一の非WebSocket http要求を介して、Signalのhttpを介してストリーミングエンドポイントを実装できるようになります。
  • ヘッダーパーサーの実装をHttpClientとSystem.Net.Httpからフォークし、名前を変更して(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers)、それらを改善できるようにしました。 .NETFrameworkと.NETCoreの両方をサポートするようにします。 .NET Coreには、これらの改善のコピーがありますが、改善する必要がないため(消費できませんでした)、元に戻されていません。
  • 新しいAPIを必要とする新しいスレッドプリミティブがたくさんあり、それらを使用できる場合は新しいシナリオを照らします(https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl + label%3Aarea-System.Threading)、これらは私が個人的に提出したもののほんの一部です。

コアプリミティブを回転させる機能がない場合は、それらをフォークして、それらに似ているがそうではないものを作成することをお勧めします。 これが、ASP.NETCorehttps://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives内に独自の小さなBCLがある理由です。

これは、.NETの非常に基本的な部分に影響を与える、短期的に私たちが行っていることをランダムにダンプしたものです。

みなさん、非常に興味深い議論に感謝します。 このスレッドは臨界量に達しており、同じ質問のいくつかが尋ねられ、再回答されています。 今からお辞儀をします👋。

@ aL3891

これが当てはまらないのは、asp.netコア自体だけです。

これは、たとえば、ASP.NET Core 2をWindowsサービスとしてホストしているものを強制終了します(.NET CoreにはすべてのAPIがなく、TopShelfは完全なフレームワークで実行されているだけです)。 これは実際にはかなり強い制限です。 また、既存のWPF /Windowsフォームアプリ内でホストされている.NETCore2サービス拡張機能をホストすることも禁止されています。これは、レガシーアプリとの統合ユースケースで一般的なシナリオです。

.NETフルで利用できない高速バージョンのSpan<T>は、本当に奇妙です。Microsoftは、Roslynをどのように高速化するのでしょうか。 彼らは速いSpan<T>とそれに付随する技術を持っていますが、地球上のすべてのVisual Studioのインストールでそれを使用するわけではありません。なぜなら...政治? MSのツリーには、言うほど勇敢なマネージャーがいないため、.NETをフルに活用する必要がありますか?

しかし、今日の//buildから広まる予定の虹と色のマーケティングのblablaトークを台無しにさせないでください。 MSは、すべてが順調で、地球の残りの部分がまだ洞窟に住んでいるというバラ色の絵を描くと確信しています。

@davidfowlここでのあなたの努力に感謝します、あなたの洞察と答えは確かに多くの人々を助けました。 👏

@gingters一連のシナリオは完全に制限されていますが、netstandard/csprojの作業全体が無駄にならないというだけです。

@davidfowlこのニュースに出くわしたばかりで、少し怖いです。 これまで、.NETStandard 2.0との同一性をサポートすれば、完全なフレームワークで実行しながら、最終的にアプリケーションでASP.NETCore2.0の使用に切り替えることができると確信していました。 私が完全に要点を見逃していない限り、それはもはや不可能です。

APIアナライザーの最新バージョンを実行したところ、依存している.NETStandard2.0に不足しているAPIがいくつかあります。 それらのいくつか(例えば、System.Configuration)は、それが苦痛であっても取り除くことができます。

その他、まだわかりません。 たとえば、私はランタイムコード生成を使用し、System.Reflection.Emit.ILGenerator、TypeBuilderなどに依存しています。これらを取り除くことはできません。これは製品のコア部分です。

APIアナライザーをさらに掘り下げてみたところ、その一部は.NET Core 2.0 + Extensionsでカバーされているようですが、次のAPIがまだ不足しています。
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName、System.Reflection.Emit.AssemblyBuilderAccess、System.Collections.Generic.IEnumerable {System.Reflection.Emit.CustomAttributeBuilder})
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName、System.Reflection.Emit.AssemblyBuilderAccess、System.String)
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName、System.Reflection.Emit.AssemblyBuilderAccess、System.String、System.Boolean、System.Collections.Generic.IEnumerable {System.Reflection.Emit.CustomAttributeBuilder})
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String、System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String、System.String、System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineVersionInfoResource
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String)
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String、System.Reflection.PortableExecutableKinds、System.Reflection.ImageFileMachine)
M:System.Reflection.Emit.ILGenerator.MarkSequencePoint(System.Diagnostics.SymbolStore.ISymbolDocumentWriter、System.Int32、System.Int32、System.Int32、System.Int32)
M:System.Reflection.Emit.LocalBuilder.SetLocalSymInfo(System.String)
M:System.Reflection.Emit.ModuleBuilder.DefineDocument(System.String、System.Guid、System.Guid、System.Guid)
M:System.Reflection.Emit.TypeBuilder.CreateType

https://apisof.net/catalogを少し調べましたが、そこの情報はAPIアナライザーの出力とは異なるようです。つまり、アナライザーがサポートされていないとマークしたAPIがいくつかリストされています(TypeBuilder.CreateType)。 だから、大丈夫かもしれませんが、やってみるまでわかりません。 その他のもの、それらは間違いなく欠落しています、例えば、AssemblyBuilder.Save(...)

つまり、結論として、ASP.NET Core 2.0を完全なフレームワークスタックにドロップして、古い依存関係を維持することはできません。 また、.NETStandard2.0を使用できなくなります。 代わりに、BigBangをすべてASP.NETCore 2.0に移植する必要があります。これは、必要なほとんどすべてをカバーする唯一のAPIだからです。 また、移行する前に、ASP.NETCore2.0で新しいWebアプリケーションレイヤーを開発することはできません。 つまり、実際にはビッグバンの後に本当にビッグバンが続きます。

@davidfowl詳細をありがとう。

私は完全に.NETCoreに夢中になっていて、実際には.NET Full Frameworkについてはあまり気にしません...しかし、.NET Full Framework APIのほとんどをもたらしたという理由だけで、 netstandard2.0を気にしました。バージョン2.0は、「ジャンクション」バージョンとして、つまり、コードを.NETFullから.NETCoreに移行するのに役立ちます...しかし、私は、コードがゆっくりと進化するパスに結び付けられるとは思っていませんでした。完全なフレームワークは永遠に...しかし、結局netstandard2.0が新しいPCLになるようです...

十分に公平であるため、.NETフルフレームワークには今すぐ退職プランが必要です( System.Drawingあなたを引き止めますか?来てください、 SkiaSharpはより良く待って、クロスプラットフォームです)そして.NETCore2.0を進化させてください独自のフルペース!

@davidfowl当初、APIに関しては、Net Coreはすべてのプラットフォームで実行されるフルフレームワークのサブセットであると想定されていました。Coreに関するAPIの変更は、両方で行われる予定でした。 それは少なくとも最初の約束でした...この新しい(どこからともなく)方向性によって、物事は今では非常に異なって見えます。

あなたが言及したことはすべて素晴らしいです、私は今それらを持っていたいです、しかしそれらが大いに必要とされるフルフレームワークで、私は現在スパンがあるWPFアプリに取り組んでいます関連するAPIは天の恵みであり、現在、日時と期間、および文化を認識する必要があるためサポートの悪夢であるプリミティブ取得インデックス用のカスタムTryParseルーチンがあります。

フレームワークを進化させたいのは完全に理解できますが、理解できないのは、なぜ既存の顧客とこの分割を作成し、現在死にかけているプラ​​ットフォームに立ち往生させているのですか? 完全なフレームワーク?

@ popcatalin81 (物事が話題から外れる前に、しかしマンスプレイニングになるリスクがあります)-スパン割り当てなしでメモリを移動することであり、DateTimeとは何の関係もありません。

@ popcatalin81 with netstandard2.0 WPFSystem.Drawingでさえ.NET Coreで実行されると期待できると確信しています(Windowsのみ、明らかに非Windowsプラットフォーム...)、afaik、これらのライブラリはCLRの特別な機能を使用していません... netstandard2.0で再コンパイルする必要があります...(。NET部分のみ、ネイティブ部分は同じ-wpf構成エンジン、またはSystem.DrawingのWin32関数への直接呼び出し...)

私は「コア」の旅全体をおそらく私が持っているべきほど厳密に追跡していませんでした。そのため、私にとって本当に際立っていることがいくつかあります。

当初、ASP.NETチームは他の誰よりも先に課金していた(または少なくともそのことで非難されていた)ようでしたが、その後再び統治され、すでに述べた理由で再び解放されなければなりません。 それは公正な評価ですか?

もしそうなら、現在直面している多くの困難は予見可能であり、新しい最新のASP.NET/.NETは最初からスタンドアロンのものでなければならなかったように思われます。

このスレッド全体で私が目にしている主な問題は、人々がもはや当てはまらない約束や仮定に基づいて多額の投資を行っていることです。

これの多くは避けられたように感じます。

私は基地から離れていますか?

@davidfowl @DamianEdwards @shanselman

機能を提供し、以下の名前空間を使用するため、 net462をターゲットとするASP.NETCore1.xアプリを本番環境にいくつか用意しています。 netstandard2.0の進行中のAPIリファレンスに名前空間が表示されません。

1. ADFS統合:

•System.IdentityModel.Protocols.WSTrust
•System.IdentityModel.Tokens
•System.ServiceModel
•System.ServiceModel.Security

2. Atom / RSSフィードの生成:

•System.ServiceModel.Syndication

将来的には、これらの既存のアプリをnetcoreapp2.0をターゲットにしたいと思います。 それぞれの場合の私の最善の行動方針は何でしょうか? たとえば、既存のNuGetパッケージを見逃したことがありますか、それとも将来のリリースを待つ必要がありますか?

皮肉なことに、それらのほとんどはMicrosoftテクノロジであり、私をフルスタックにすることを余儀なくされるものはたくさんあります。 CRM Dynamics SDK、Azure SDK、XLST名前空間のサポート、ヘッドレスADALログイン(フルスタックでのみ使用可能)など...

この変更は、.NetCoreを早期に採用するのに十分な勇敢で愚かなすでに小さな開発者ベースをさらに分離するだけです。

@davidfowl

次にHTTP2サポートを行っており、新しいAPIが必要です。

私はその点を部分的にしか理解していません。 HTTP / 2の場合、主なブロッカーはTLSのALPNサポートであるため、現時点ではそれを使用できません。 ただし、CoreFxリポジトリの関連するリクエストに関するコメントによると、これは.NETCore2.0にも間に合いません。 後で(2.2?3.0?)、つまりHTTP / 2の観点からは、ASP.NETCoreがcorefx2.0または.netstandard2.0のどちらに依存しているかは関係ありません。とにかく機能しません。 後で、バージョン番号が再び増加したとき。

それに加えて、HTTP / 2の問題は主にWebサーバー(Kestrel)に影響し、フレームワーク全体には影響しません。 「複数のものを維持するのは醜い」という理由に加えて、.NET標準のHTTP / 2サポートなしでWebサーバーを使用できず、将来の.NETCoreバージョン用のWebサーバーを使用できない理由はわかりません。

@davidfowlこの議論全体で実際にカバーされていないことが1つあります。 私は技術的背景を完全に理解しており、あなたの推論に完全に同意します。 特に、1.xを維持すること(サポート期間が延長される可能性がある)、特にSignalRのような現在不足している問題点が将来1.xサポートで追加される場合は、技術的に実現可能なソリューションになることに同意します。ここで説明するすべてのケースの大部分について。

しかし、問題は技術的な性質のものではなく、心理的なものです。 ここで指摘されているように、ASP.NETCoreの採用はまだ初期段階です。 送信しようとしているメッセージについて考えてみてください。2.xバージョンを間もなくリリースし、その後すぐにバージョン3.xで戦略的計画を開始します。すべて、すべてを公開します(通常はこれは良いことです)。 その結果、ほとんどの人が2.xを使用するための必須要件がなくても、1.xをサポートすることで合理的な技術的ソリューションを提供できたとしても、人々の頭の中で既存のものを積極的に移行するという考えが生まれます。バージョン3ですでに作業が行われている場合の「バージョン1」の解決策は、即座に受け入れられない心理的な障害になります。 これにより、既存のプロジェクトをASP.NET Coreに移行せず、ライブラリの作成者が十分な需要とプレッシャーがないために.NET Coreに移植しないという、鶏が先か卵が先かという問題が発生するという本当の危険があります。非常に長い間、採用率をさらに遅くします。

一部の人も言及しているように、明らかに多くの人々は、この動きがいつか来ることに気付いていたとしても、このカットがすぐに起こるとは思っていませんでした。 さらに、過去数か月の間に、2.x(.NET Core、.NET Standardなど)がどのように物事を安定させ、統一するかについての多くの講演、インタビュー、投稿を聞いて読みました。 したがって、多くの人の心の中で、「2.x」は「成熟した」と同等になりました。この主張がどれほど技術的に十分に根拠があるかどうかは関係ありません。 2.xの興奮を高め、すぐに1.xのコア機能を取り除いた方法は、最も不幸な動きでした。これにより、たとえ議論が技術的な推論から感情的な推論に移った可能性があります。表面的には、まだここで技術的な詳細について話し合っているようです。 この認識を元に戻し、1.xがASP.NET Coreへの確実な移行ターゲットであるという幅広い信頼と信頼を再確立することは、非常に困難になります。

私の個人的な推奨事項は、.NET Frameworkをサポートする最後のメジャーリリースとして2.0をリリースすることですが、そのサポートを終了するのにさらに1年以上かかる代わりに、3.xにはるかに早く移行してください。 下位互換性を念頭に置いて不可能なこれらすべての技術的機能には3.xを使用し、2.0が公開されたらすぐに3.xでの作業を開始します。 これにより、一度に複数のメリットが得られます。1.xの元のサポートプランを維持できます。 人々は2.xで.NETサポートを取得します。これは、過去数か月にわたって「成熟した」バージョンとして構築されてきました。 彼らは自信を持って「最新かつ最高」に移行でき、3.xがそのサポートを終了するという事実と、必要に応じて移行戦略を計画するのに十分な時間を認識しています。 また、新しい機能を追加したり、ASP.NET Coreを必要なだけ急速に進化させたりすることで、速度を落とす必要はありません(または非常に短時間だけ)。

繰り返しになりますが、その提案は、いくつかの異なるバージョンの忍術が適用されているだけで、とにかく現在あなたがやろうとしていることとそれほど変わりません。 この変更が最近適用されたという事実は、技術的には、フルスロットルで再び前進できるようになるまで、これはほんの少し後退するだけであることを意味しますが、これらの心理的問題をうまく回避します。

/ cc @DamianEdwards @shanselman

ビルド時にMicrosoftShrinkを発表します。 (申し訳ありませんが、抵抗できませんでした)
なぜかについてはすべて@MisterGoodcatに同意しますが、私は疑問に思っています。感情的な欠陥やニーズを管理するために、本当にMicrosoftが必要なのでしょうか。

.NET Frameworkは安定していますが、動きが遅いので、ほぼすべての種類の.NETアプリのメンテナーとして、何かをしなければならないことに同意します。マイクロソフトが他のオプションの代わりに.NETCoreに油を注ぐことを選択したので、時間の余裕のあるオプション。 しかし、この問題は、過去の努力がすべて自動的に移植されるわけではないというマイクロソフトの盲目の傾向を示しています。

開発者と開発者ツールに重点を置いていることで有名な会社にとって、Microsoftが独自の依存関係の形でのみブロッカーを要求することは非常に近視眼的です。 DirectoryServicesとDrawingが最も人気のある単一のブロッカーであることは驚きではありませんが、不可能、非現実的、または非常に高価な内部コンポーネント、サードパーティコンポーネント、およびCOM相互運用機能のすべてのロングテールの母が存在しないという意味ではありません(特にアップグレードの形で)乗車のために持って来るために。

MicrosoftがBCLまたは拡張.NETFramework(WCFなど)から独自のものについて質問しているという議論を理解していますが、同じ質問が、正しいものに取り組んでいることを確認するためです。プラットフォーム全体を移動します。 ある段階で.NETFrameworkを完全に廃止する計画がある場合は、それを伝えてみませんか? そして、最近決定が下されたのなら、その時にそれを伝えてみませんか? 私たちと話して相談してみませんか? 私たち全員が適格な分析を行うわけではないことは理解していますが、このスレッドでMVPを見ると、最も熱心なサポーターと最もアクティブなユーザーがこれに目がくらんでいるのを見ると、マイクロソフトが顧客について少しでも気にかけているとは確信していません。 。

また、「マイクロソフト」と言うのは簡単だという議論も理解しています。 無限の能力を持たない個人で構成されていることを私は知っています。 しかし、私は鋼のような一枚岩からの大胆な努力を求めません-私はコミュニケーション、正直、尊敬を求めます。 この製品に取り組んでいて、顧客に影響を与える変更を加えたい場合は、サイコロを振るのではなく、コミュニティに参加してください。 私たちはあなたのために記事を書き、あなたのプラットフォームを選び、あなたが正しいことをしたときにそれを送り出します(たとえば、無給のコミュニティメンバーであるベンアダムスが消えない貢献をした全体的なパフォーマンスの向上について人々に知らせるなど)、私たちはコミュニティのスタンドアップを監視します。 しかし、これは双方向です。 私たちをメガホン以上のものとして使ってください、そして私たちはこのように反応しないかもしれません。

@Bartmaxそれか、コア、asp.netコア、asp.netコア非コア、netstandardbanana、.net、system.webの違いについて全員に2時間の必須コースを提供します。 asp.net 5(つまり6)。
そして、ロードマップと意図をより明確に伝え始めます。

完全なフレームワークを手放すことのできない人にとっては、まだ修正されていません。 どこかで、2つのコミュニティができあがります。

完璧な世界では、asp.netコアはコア上でより高速であり、.netでは利用できないいくつかの排他的な機能を備えている可能性もあります。 しかし、ほとんどのものはネットスタンダードであり、他のすべては少なくとも予見可能な将来のためにクロスコンパイルされるでしょう。 また、レガシープロジェクトで作業する必要がある場合、唯一の違いはasp.net全体ではなく、ブートストラップ部分であるため、コアを学ぶことができます。

誰もが通常のasp.net開発者ショップであることがわからない場合は、この前進に自信を持つことができます。

かなりの数のC++/ CLIライブラリを使用しなければならない人として、この潜在的な変更は私に恐ろしいオプションを残します。

1)新しい機能やセキュリティ修正を利用する機会がなくても、現在の安定したasp.netコアバージョンを永久に使用できます。

2)これらすべてのC ++ / CLIライブラリを置き換えるために大量の時間(そして最終的にはお金)を投資します。これは、顧客が1セントも払うことを望まないでしょう。

3)asp.netコアを完全に放棄します

この変更は将来必要であると理解でき、私はそれですべてです。 私が理解して受け入れることができないのは時間枠です。 この規模の何かは、バージョン3.xまたは4.xでの今後の重大な変更として、1年前のロードマップの目標として発表し、次のバージョンではダンプしないものです。

@davidfowlネットコアのedge.jsのようなものはどうですか? これにより、APIコンシューマーがプラットフォームのチェックを担当するようになり、ほとんどのシナリオでは、netfxとnetcoreの間の強く型付けされたインターフェイスで十分です。

私には、これは理想的な解決策のように見えます。

1)netfxコードがnetcoreで実行されるかどうかの推測はありません-netfxランタイムをインプロセスで使用します
2)コアを抑制しません
3)新しいコアAPIが十分に普及し、開発者がnetstandardの可能な限り低いバージョンのサポートを終了する場合、これはnetfxスペースで起こっていることではなく、反対方向へのブリッジを提供できます。

デュアルプラットフォームのASP.NETCoreを提案している場合は、古い.NETで実行され、新しい文字列とスパンの機能はありません。また、.NET Core 2でこれらの機能を使用している場合は、次のことをお勧めします。コードを確認します。

最も基本的なレベルでは、任意のWebフレームワーク:

  • UTF8でエンコードされた文字列(_BOBTRUES_)を表すバイトのブロックを取得し、それらを解釈して、厳密に型指定されたオブジェクトとしてコードに渡します。
  • コードの結果を取得し、それらを_BOBTRUES_に戻します。

したがって、Webフレームワークを構築する場合に本当に必要なのは、_BOBTRUES_を理解する低レベルのプリミティブであることは理にかなっていますね。

また、作成しているコードのほとんどが_BOBTRUES_に依存しているが、_BOBTRUES_が何であるかを知らない別のランタイムもサポートする必要がある場合は、そのすべてのコードを2回作成し、すべてコンパイラ指令または複雑なビルドファイルが散らばっています。 。 そして、完全な.NETが_BOBTRUES_を理解するのに必要なだけでなく、Webフレームワークを_awesome_にしようとすると同時に、すべてのコードを重複して記述および編集し続ける必要があります。また、Mono、UWP、Xamarin、Unity3D、および_BOBTRUES_要件を追加するNETStandardを実装するその他のものもあります。これらの多くは、そもそも_BOBTRUES_を気にしません。

もちろん、このコードをすべて2回記述しなければならない唯一の理由は、ファーストパーティとサードパーティのパッケージがたくさんあるからです。

  • System.Drawing、System.DirectoryServicesなど、または
  • 1.xに必要なAPIがないため、NETStandard 2.0を待っている、または
  • NETStandardに移行する時間やインセンティブがない人々によって維持されている
  • 放棄された、または
  • 上記のいずれかであるアップストリームパッケージに依存

System。*ビットは別として、他の多くのパッケージについては、ASP.NET Coreユーザーが完全な.NETで実行できることを知っていると、NETStandardへの移植を少し簡単に正当化できますか? _ "はい、ASP.NET Coreをサポートしていますが、現時点では完全な.NETでのみサポートしています..." _Linuxコンテナーで.NETCoreアプリを実行する必要がある場合、またはMacで開発したい場合は、同じようにイライラします。 、そして「今のところバージョンXにとどまる」回避策はありません。 NHibernate、OData、EF6などはありません。

したがって、これがマイクロソフトの内外のチームがパッケージをNETStandard 2.0に適切に移行して、Windowsサーバーで完全に実行されている開発者だけでなくすべてのASP.NET開発者*が使用できるようにするために必要な準備です。 .NETの場合、それは_良いこと_です。

* .NETCore2.0で実行されているASP.NETCore2.0は、NETStandardパッケージを_公開_する必要はありません。

パーサーだけを書くように@JamesNKに向けられたコメントは、特にあなたが彼のためにあなた自身のパーサーを落としたことを考えると、本当に上品です。 それは彼があなたのプラットフォームを前進させるために彼自身の時間に書いたものです。

はい、フルスタックの移動は遅くなりますが、それはフレームワークを理解する時間があることも意味します。 通常のフレームワークではまだやるべきことがたくさんあるので、正直に言うと、なぜ.Netコアのようなものが必要なのかよくわかりません。 クロスプラットフォームが懸念される場合は、Xamarinを購入したばかりで、ほとんどすべてのもので.Netを実行します。 おかしな時計を含みます。

たぶんロードマップ?

私たちは祖父のソースコードを読むことができず、彼らのアルゴリズムを理解することができず、一夜にして無知でした! 。
Asp.net Coreが登場した場合、兄弟のKılıçdaroğluにはリーダーシップの資質がありません。

したがって、これがマイクロソフトの内外のチームがパッケージをNETStandard 2.0に適切に移行して、Windowsサーバーで完全に実行されている開発者だけでなくすべてのASP.NET開発者*が使用できるようにするために必要な準備です。 .NET、それは良いことです。

@markrendleライブラリの作成者がASP.NETCoreロジックに従っている場合、netstandardではなくnetcoreappにジャンプするだけではないでしょうか。 結局のところ、彼らも新しいAPIの恩恵を受けることができますか? なぜnetstandardをまったく気にしないのですか? ASP.NETは、結局のところ、単なる別のライブラリです(ただし、大きなライブラリです)

私のケースは、このスレッドで他の多くの人が述べているのとまったく同じです。私の会社には、おそらく.NETCoreで利用できるようになることのない多数の内部ライブラリとサードパーティライブラリに依存する大規模なSaaSアプリケーションがあります。 今後の計画は、常に完全な.NETFramework上のASP.NETCoreに移行し、その後5年以上かけて、これらのサードパーティコンポーネントの代替品を見つけることでした。 この(非)発表は、これらの計画を完全に混乱させました。

ASP.NETCoreが.NETDesktopフレームワークで実行されていないという印象を受けました。 編集します。 ドキュメントページには、ASP.NETCoreは完全な.NETFrameworkで実行されると記載されているため、サポートを明確に示しています。

誰もこれをまだ提案していない場合に備えて、別のオプションがあるようです。

結局のところ、ASP.NETCoreはオープンソースです。 これは、ASP.NETCoreの2つの異なるバージョンが存在する可能性があることを意味します。

ASP.NET Core:既存のビルドである.NET Core(netcoreapp2.0)をターゲットにします
「ASP.NETCoreStandard」 :.NET Standard(netstandard1。*およびnet4 *)を対象とし、必要に応じて.NETDesktopFrameworkおよびその他の標準プラットフォームで実行される別のビルド。

Coreビルドは.NETCoreにリンクされますが、 Core Standardビルドは、netstandard1。*およびnet4 *、およびそれ以降の.NET標準2.0以降で使用可能なものによって制約されます。 動きは遅くなりますが、互換性が高くなります。 .NET Coreはグリーンフィールドや新興企業に適している可能性があり、Standardはブラウンフィールド、移行、企業に最適です。

マイクロソフトチームがたどった道は、メインラインオプションとして理にかなっています。コアはフレームワークの未来です。 一方、netstandardの追加目標を維持することは、最小限の労力で達成できるはずです。 オープンソースプロジェクトにすることができます。 おそらく、互換性の精神で、Microsoftも実際にそれを行うことができます。

これは、「ASP.NET Core Standard」がすべての新機能を取得できない可能性があることを意味しますが、このブランチは互換性のためであるため、これを使用するユーザーは、標準フレームワークでサポートされているすべての機能を使用できること、および標準ブランチはGithubで無期限に利用可能になり、ボランティアは修正と更新をCoreブランチから標準ブランチに移植できます。

ASP.NETCoreで.NETDesktopフレームワークの互換性を長期間維持できれば、別のビルドを維持することはそれほど大きなハードルにはなりません。 他の多くの.NETプロジェクトは、protobuf-netのように、いくつかの条件付きコンパイルステートメントを使用して、マルチターゲットに対して同じことを行います。

基本的に、Active DirectoryとSystem.Drawingを必要とするユーザーは、ASP.NET Core Standardを使用できますが、Windowsの使用に制限されます。 ただし、ライブラリが利用可能になると、コードは.NET Coreに簡単に移植できるようになり、将来サポートが不足するリスクはありません。

チームがそのようなブランチを提供できるかどうかが問題になると思います。 ASP.NETのような基本的なライブラリの場合、これが必要になる場合があります。 .NETFrameworkから.NETCoreへのパスを提供する必要があると、いずれにせよ、これらのタイプのストップギャップソリューションが必要になると思います。 ソフトウェアは柔軟性があり、この種のソリューションにより、必要な移行をスムーズに行うことができます。

これを行うための余分な努力は、コミュニティ全体に提供される大幅に大きな採用とより良い移行と比較すると、小さな投資と見なされるべきだと思います。 何千人ものユーザーがいることは、2つのターゲットを維持する作業を相殺するために、プロジェクトへのより多くの貢献を生み出すのに確かに役立ちます。

@bencyoung

ライブラリの作成者がASP.NETCoreロジックに従っている場合、netstandardではなくnetcoreappにジャンプするだけではないでしょうか。 結局のところ、彼らも新しいAPIの恩恵を受けることができますか? なぜnetstandardをまったく気にしないのですか? ASP.NETは、結局のところ、単なる別のライブラリです(ただし、大きなライブラリです)

ええと、ライブラリの作者が_BOBTRUES_の新しいプリミティブとフレームワークレベルのサポートから多大な恩恵を受ける何かを書いているなら、それはおそらく理にかなっていると思います(そして私はそれらをサポートするJSONまたは他のシリアライザーライブラリの良いケースを完全に見ることができます、ところで)。 しかし、パッケージ内のコードが_BOBTRUES_やそのようなものを本当に気にしない場合は、 netstandard20が同じように機能するときに$ netcoreapp20を書くことに特に気を配る必要があります_ 。

@markrendleでは、Newtonsoft.JSONが次のバージョンでそれを実行し、1年のタイムスケールを持つ既存のバージョンのサポートを終了することを嬉しく思いますか? 解析、IO、および高性能ライブラリがnetstandardおよび.NET Frameworkのサポートを終了し始めたことに満足していますか?

これを修正する方法に関する提案:

  1. asp.net core 2.xを.netで実行し、コアのみのものをバージョン3.xに移動します(2.0のユーザー向け機能を1.xにバックポートし、2.0と呼びます)
  2. asp.net core 2.xが.netで動作する最後のバージョンになることを最初から明確にしますが、寿命は長くなります。
  3. libがnetstandard2.xでより良く機能するかどうかを検証するためのツールを作成することに焦点を当てます。 現在の推測作業は、人々を驚かせているものです。
  4. 多くの人が使用するライブラリがnetstandard2.x/coreのサポートを受けるのを支援することに焦点を当てます。 (Windowsのみの場合でも)
  5. Microsoftとコミュニティ間のコミュニケーションを調整します。 はい、速度/機能などが必要ですが、多くの場合、信頼性/レガシーも必要です。 これよりも良い中間点を見つける必要があります。

@vectorix :そうだった。 ASP.NETCoreドキュメントの最初のページであるASP.NETCoreの概要には次のように書かれています。

次のステップ

..。
ASP.NET Coreアプリは、.NETCoreまたは.NETFrameworkランタイムを使用できます。 詳細については、「。 NETCoreと.NETFrameworkのどちらを選択するか」を参照してください。
..。

.NET Framework(完全版)を使用できることを明確に示しているページにリンクしています。

性交のために、その比較ページはこれさえ言っています:

.NET Frameworkは、多くの既存のシナリオで引き続き自然な選択であるため、すべてのサーバーアプリケーションで.NETCoreに置き換えられることはありません。

個人的に私を幸せにするために必要なのは、BOBTRUESがnetstandard xにあり、xを定義する必要さえないと言うことだけです。 そうでなければ、パフォーマンスを気にするなら、netstandardはすでに死んでいると言っています...

5日後、BUILDイベントを開始しようとしています。

待って、Microsoftに(願わくば)発表をさせ、彼らのビジョンとロードマップをみんなと共有しましょう

@CMircea :指摘してくれてありがとう。 それは確かに明白です。 ページの文字と精神に従うには、.NETデスクトップフレームワークとの互換性を維持する必要があるようです。

Azureでホストされている.NET462に加えてASP.NETCore1.1を使用するクライアントの大規模な作業が完了しました。 MS Accessデータベースをアップロードしてサイトにデータを更新し、データをAzure SQLにインポートするため、このルートを使用する必要がありました。 これを行うことができる唯一の方法(そしてそれは苦労でした)は、完全なフレームワークを使用することでした。 私は、このソリューションが運が良ければ1年、2年、おそらく3年しかサポートされないことをクライアントに伝えなければならない立場になりたくありません。 アクセスの問題を取り除くためにプロセス全体を変更する必要があることを彼らに伝えることは選択肢ではありません、私は何年も試みてきました!

Accessデータベースを読み取るためのより良いオプションがある場合、またはそれがどこかのロードマップにある場合、私は幸せになります。 そうでなければ、これは懸念しています。

@bencyoung大きな違いは、JSON.NETはアプリケーションではなく、ライブラリであるということだと思います。 ASP.NET Coreはアプリケーションモデルであるのに対し、ライブラリの作成者は.NET Standardをターゲットにして、可能な限り幅広い互換性を確保することを目的としています。 私が持っている質問は、ASP.NETCoreのレイヤーのどれだけが.NETStandardと互換性があるのか​​、そして何がnetcoreをターゲットにしているのかということです。 .NET Standardに対して作成した新しいコードがありますが、ASP.NET Coreレイヤーの側面への参照がありますが、ライブラリとして利用できるようになっています。

そうは言っても、ライブラリの作成者がnetstandardではなくnetcoreをターゲットにすることを妨げるものは何もありませんが、ASP.NET Coreが(現在の)特定のランタイムで実行されているアプリケーションへのダメージを制限するのに対し、ASP.NETCoreは多数の潜在的なプロジェクト間の互換性を低下させるリスクがあります。

@Antaris ASP.NETは、私が知る限り、ライブラリです。 ケストレルはアプリケーションです。 現在必要な任意のアプリケーションでASP.NETCoreをセルフホストできますか?

@bencyoungフェアポイント、私の側の言い回しが悪い。

私が言いたいのは(私がそれを正しい言い方で見つけることができれば)、ASP.NET Coreを(スタックとして)1つの特定の方法で使用してWebアプリケーションを実行するということです。 アプリケーションモデルに応じて、JSON.NETなどのライブラリをさまざまな方法で使用できます。 ASP.NET Coreの可動部分について考えると、Razorのようなものは引き続き.NET Standardに対して構築され、これらのものは通常、他のアプリケーションモデルで使用できます。 それは理にかなっていますか?

誤解しないでください。私は一方のアプローチともう一方のアプローチを擁護していませんが、netfxとの将来の互換性を条件として、レガシーコードベースと統合/アップグレードする代わりに、いくつかのグリーンフィールドプロジェクトに取り組むことで恩恵を受けています。 したがって、その意味では、互換性を高めるための議論にあまり重みを加えることはできないと思います(netfx上のASP.NET Core 2+)

@Antarisありがとう、それについてはよくわかりませんが! Windowsサービス内で、下位互換性のためにWCFサービスと同じプロセスでRESTAPIをセルフホストします。

うわー、マイクロソフトによるなんてひどい決断だ。 まず、.NET Coreが新しい.NETになる予定でしたが、Microsoftは、古いAPIをできるだけ多く戻す必要があると判断しました。 現在、彼らは、完全なフレームワークでASP.NET Coreプロジェクトを開始することにより、Microsoftを信頼していた人々を置き去りにしています。 私は毎日ますます.NETへの信頼を失っています。 Golangは完璧ではありませんが、毎日ますます魅力的に見えています...そして誰かが気づいていない場合は...それはますます牽引力を増しています。 MicrosoftはJavaコミュニティが短い順序で何かを成し遂げることができないことを利用できると思っていましたが、.NET Coreは完全に失望しており、過去2年間、多かれ少なかれ水を踏んでいます...それと引き換えに、クロスプラットフォーム(Windows Nanoのコンテナーで.NETを実行できることを気にしています)と非常に複雑なもの(途方もなくひどいツール、F#サポート(VS)なし、.NET標準ビンゴ)があります。

更新:ここにいくつかの親指が下がっていますが、絵文字と意味のある会話をするのは難しいです;)何に同意しませんか?

クロスプラットフォームのサポートは、私がASP.NET Coreに切り替えた主な理由であり、私はそれだけではないと思います。 しかし、ASP.NETCoreの改善点はそれだけではありません。 モジュール化された構造のように、もちろんフレームワークで非常に必要とされているものは、何年にもわたって成長しています。 BuildinDIも新しいです。

古い4.xフレームワークをASP.NETCoreと一緒に使用する可能性は、私にとっては良い妥協点のようです。私のようなOS/LinuxファンはWindowsの使用を強制されていません。 しかし、(AD認証のように)本当にWindowsを必要とする企業はそれらを使用することができます。 マイクロソフトがなぜこの良い中間点を破っているのか理解できません。 特に今、古い4.xフレームワークの多くの重要な名前空間がまだASP.NETCoreに移植されていない場合。

@ DMWOO7.NETCoreとASP.NETCoreを混同しないでください。

.NETCoreとASP.NETCoreを混同しないでください。

皮肉。 😆

@MartinJohns投稿を更新して、わかりやすくしました。

@bencyoung

では、Newtonsoft.JSONが次のバージョンでそれを実行し、1年のタイムスケールで既存のバージョンのサポートを終了することを嬉しく思いますか? 解析、IO、および高性能ライブラリがnetstandardおよび.NET Frameworkのサポートを終了し始めたことに満足していますか?

個人的には、コンテナ内のLinuxサーバーで実行するWebアプリケーションとサービスを構築しているので、それで問題ありません。自分自身と自分のユースケース以外は気にしないので、このスレッド。

真剣に、JSON.NETがnetstandardのサポートを終了することは期待していませんが、誰かがより最適なforで動作するCore.Jsonライブラリをリリースするのを見てもまったく驚かないでしょう。 -web-development netcore API。

.NETのPython3へようこそ。 Coreが何年も前に発表されて以来、これは毎回起こるだろうと感じました。

ASP.NETCoreターゲットnetcoreapp2.0を持つことが最も理にかなっています。 .NET Coreは、新たなスタートを切り、複数のプラットフォームでアプリケーションを実行する方法を提供しました。 Windows用に作成されたすべてのAPIをドラッグしようとすると、発生するのを待っているだけの列車の大破です。 Python 3のアナロジーは優れており、Python3も同様です。

OK、スレッドを読んだので、私は少し異なる見方を提供します、明らかにわずかな見方です:

  • 私は生活のためのウェブサイトを作成していません(まだ勉強中です)。時々、私は自分自身のために、または小さな会社/組織のために、より小さなまたはより大きなウェブサイトをスピンします。 時々、人々は技術的なアドバイスを求めに来ます。
  • 私は最初からASP.NETを使用していましたが、「Webフォームスタック」をほとんど無視し、HTMLを直接処理して作成してきました。RazorPagesを考えてみてください。
  • 私がこれまでに作成したWeb関連のものはすべて、常にIISで実行されていました。 クロスプラットフォームのサポートは私には興味がありませんが、私はそれに腹を立てていません。
  • 私は小さすぎて、公式にサポートされているものを気にすることはできません。
  • 私は通常、サードパーティのライブラリに依存していません。

Microsoftをフォローしている人なら誰でも、.NETCoreが.NETFrameworkよりも多くのリソースを取得し、最終的に.NETFrameworkがメンテナンス専用モードになる可能性があることに気付いたはずです。 また、不足しているAPIが追加されていますが、完全な.NETFrameworkと同等の機能を提供する意図がなかったことは明らかです。

ASP.NETCoreが.NETFrameworkで実行されているという事実により、フレームワークのすべての機能セット(およびOS)。 ASP.NET Coreでいくつかの単純なWebページを試しましたが、さらに大きなWebページを開始することも計画していました。 実際、私は.NETFramework上のASP.NETCoreですべての新しい開発を行うことを計画していました。 まあ、私はもう推測しません。

いくつかの質問に(順不同で)答えさせてください。

  • なぜASP.NETCore2.xではなく1.xなのか
    かみそりのページは間違いなく。 それが私の主な仕事のやり方です。 修正がバックポートされることが示唆されていますが、安定性と他の人が「成熟度」と呼んでいるように見えるものは別のものです。 分割された場合、ツールは大きな影響を与えると思います。
    つまり、3.xに延期するとうまくいくということです。

  • ASP.NETではなくASP.NETCoreを選ぶ理由
    さて、このトピックに照らして、それは公正な質問です。 完全な.NETFrameworkを使用している場合、ASP.NETCoreは定義上それに付加価値をもたらします。 最新のスタック、タグヘルパー、統合APIとMVC、最新機能。 完全な.NETFrameworkがなければ、それほど多くはありません。 確かに、ASP.NETに戻ることが私にとって最良の解決策のように見えます。

  • 新機能または互換性?
    100%の新機能。 しかし、文字列をUTF-8(および4バイト文字!)に切り替えるか、アーキテクチャのリファクタリングは、私にとって互換性のある変更です。 機能を取り出すことはできません。

  • 使用している.NETFrameworkの機能
    私が心配している大きなもの:

  • _System.Windows.Media.Imaging_。 絶対に~~System.Drawing〜ではありません。 それは、.NETCoreのすべてに反するように聞こえます。 これは長いスレッドなので、 @JimBobSquarePants@mstumを引用します。
    > System.Drawingは、特に混乱を招き、懸念を抱いています。 そのAPIを任意のプラットフォームの.NETCoreに移植したいと思う理由を理解することはできません。 作業が難しく、サーバーでサポートされておらず、最新の開発に必要な多くの重要な機能(マルチスレッド、ピクセル形式、ICC、EXIF、量子化、インデックス付きPNGなど)が不足しています。

System.Drawing名前空間内のクラスは、WindowsまたはASP.NETサービス内での使用はサポートされていません。 これらのアプリケーションタイプのいずれかからこれらのクラスを使用しようとすると、サービスパフォーマンスの低下や実行時の例外など、予期しない問題が発生する可能性があります。 サポートされている代替方法については、WindowsImagingComponentsを参照してください。

私のすべてのWebイメージングは​​WICを使用しています。 何年にもわたって推奨されてきたものを移植せずにサポートされなかった技術を移植することは少しがっかりするでしょう(それがほとんどの顧客が要求するものであるかどうかは理解できますが)。

  1. _System.Windows.Xps_および_System.Windows.Markup_。 XPSですべてのドキュメント(請求書から出荷ラベルまで)を生成します。 XAMLでドキュメントを作成し、フル機能のデータバインディング、テキストスタック、ページ付け、テンプレート、生成中のトリガーを使用したスタイル設定などを含むXAMLレイアウトを作成すると、デザイン時のサポートが得られます。これは非常に便利です。
  2. アセンブリの検査、ドキュメントの生成など、フレームワークのギャップを埋めるための_System.Reflection_。
    言及されている他の人:
  3. _WCF_と_ServiceModel_、政府とのコミュニケーションはこれを超えます
  4. _DirectoryServices.Protocols_およびNTLM認証
  5. SQLの空間タイプ
  6. 暗号化
    私が使用している他のものは利用可能だと思います:電子メール、ZIPアーカイブ。

最後に、これは完全にビジネス上の決定です。 私にとって、完全な.NETFrameworkのないASP.NETCoreは、作成できるものを制限しており、現時点でそれを使用する説得力のある理由はありません。 状況が変わったのか、それとも私の生活がそれに依存していたのかを再評価してください。
しかし、私がプラットフォーム上にいるかどうかは重要ではないと思います。 人気のある名前と大企業の顧客がいるかどうかは重要です。 作成されたアプリケーションが最終的にAzureに含まれるかどうかは重要ですが、私の場合はそうではありません。 ですから、フレームワークを存続させるものと一緒に遊ぶ必要があると思います。

この変更がそれを存続させ、競争力を維持するかどうかは別の問題です。 ただし、公平を期すために、誰かが上で述べたように、.NETFrameworkのバックグラウンドを持たない人々をターゲットにしていると思います。 他の人にとっては、切り替える価値があるか、そうでないかのどちらかです。 そして、私のように、両方の世界で最高のものを手に入れることができると思った人がいます。 決定は突然で、おそらく不公平でさえありましたが、開発中の最新のテクノロジーを使用する場合、それは常にリスクです。 .csprojで発生し、現在は.NET Frameworkで発生しており、将来的にも発生すると確信しています。

PS。 この「伝達されていない」ギャップを埋める役割がこれまで指摘されたことはありません。 私はmsbuildプロジェクトシステムをサポートしていましたが、.NET Frameworkが数か月で計画から外れることが明らかになっていれば、そのような関心はなかったでしょう(または言うべきだと感じました)。 大きな決断を下すのは良いことだと思いますし、今までにないよりも遅くするほうがいいと思いますが、ターゲットオーディエンスが一貫していれば役立つでしょう。

最後に、これは完全にビジネス上の決定です。

問題は、マイクロソフトが不確実性を生み出していることです。 大企業は不確実性を嫌います。 マイクロソフトはかつて互換性の王様でした(私の呼びかけではなく、良いか悪いか)。その後、.NETCoreが登場しました...互換性を破りました...そして素晴らしいニュースです。古いAPIをたくさん追加します。 ..そして今、このASP.NETCore2.0のブレークがあります。

大企業は退屈で信頼できる技術スタックが好きです。 スタートアップはあまり気にせず、Microsoftは彼らが喜ばせようとしているグループを決定できないようだ。

@GiorgioG既存のアプリを使用する大企業がASP.NETCoreに切り替えたい理由がよくわかりません。 それはファッションのものか何かのように見えます。

@miloushそれは将来のための準備についてだと思います。 既存のコードベースをゆっくりと.NETStandard/ ASP.NET Coreに移行し、完全なフレームワークで実行する場合、将来的に.NET Coreと互換性があるようにコードを配置するため、作成する必要はありません。古いシステムのサポートが終了したときに、すべての変換を一度に停止します。

.NET Standardに変換するだけでは不十分であるため、企業はそれを行うことができません。クールエイドを完全に飲むか、まったく飲まないかのどちらかです。

@miloush-完全なフレームワークでASP.NETCore1.1を使用してプロジェクトを開始したと言います。 フルフレームワークでASP.NETCore2.0に移行することはできません。 それは受け入れられますか? そのボートの誰にとってもかなりひどいように聞こえます。

@miloush .Netコアの方が生産性が高く(ここですべての技術の進歩を列挙したくないので、API / MVCコントローラー、タグヘルパー、ローカリゼーションサポートなどを統合しました)、ビジネスがアップグレードするためです。 彼らが通常行わないのはビッグバンのアップグレードです。なぜなら、不連続性を許容できないため、通常は少しずつ行う必要があるからです。

以前のバージョンのサポートが削除されても気にしないスタートアップにとっては、まったく異なります。 彼らには遺産がなく、この種の問題もありません。

@popcatalin81-完全なフレームワークでもこのすべてのポイントに到達できます。一方は他方と競合していません。問題は一方と他方の開発のペースです。MSはマイクロリリースを急いでいます-ベンチマークチャートで見栄えのするサービスフレームワークは、執着になっているように見えます。

見ることをお勧めします:

「3つのランタイム、1つの標準….NET標準:すべてVisualStudio2017で」

ビルドhttps://channel9.msdn.com/で45分で2人のスコットと一緒に何か言及するかもしれませんか?

@adrianlmm関連性はありますが、厳密には関連していませんが、マイクロサービスのクールエイドを飲むのはもうやめましたか? それは非常に複雑なもの(ビルド/デプロイメント/運用/トラブルシューティングなど)を追加し、ほとんどの企業はそれらを必要としません(追加の運用の複雑さを保証する水平スケーラビリティを必要とする企業はいくつありますか?)そのために50のマイクロサービスは必要ありません。

@GiorgioG私の質問は、そもそもなぜASP.NETCore1.1に移行するのかということでした。 ええ、私はそうしました、そして私は感じます-私の最高の日ではありません、それは確かです。 しかし、私は移行しなければならない大きなコードベースを持っておらず、物事がどのように落ち着くかを待ってから、より大きな投資をコミットします。 つまり、予算がなくても、ASP.NET Coreでの新しいより大きなWebサイトの開発を、使用可能なツールが利用できるようになる前に延期していました。将来は少し明確です。それほど悪い決断ではないことがわかりました。 (免責事項:この決定を大企業のコードベースで行う必要はありませんでした。

私は人々が飛びついたと非難しているわけではありません(私も小さなことでやりました)、そして私は間違いなく反対側を守りたくありません-ASP.NETCoreが.NETFrameworkを永遠にサポートしていれば私は興奮します!

私がよく理解していないのは、RTMと新しいツールチェーンの要件から6か月後に、変化と不確実性が問題となる大企業がどのように状況に陥ったかということです。

@miloush私たちは1年以上「.NETCoreが落ち着くのを待っていました」。 ある時点で、人々は実際に開始する必要があります....そしてプロジェクトを提供します;)

@miloush ASP.NET Coreの改善点を利用したかったのですが、それでも.NETライブラリを使用する必要があります。 そして公式には、.NETと.NETCoreのどちらかを選択できると述べられていました。 現在、彼らは突然非常に悪い状況に陥っています。ASP.NETCoreバージョン2.0にアップグレードできず、バージョン1.xでスタックします。 そして、ある時点で1.xのサポートがなくなり、1.xでも新機能が提供されなくなります。

@GiorgioG 、私はこれまで新しいプロジェクトに.Netコアを使用し、別のフルフレームワークのAsp.Netコアに移行しました。 両方のアクティブなプロジェクト。

どこでもNetCoreを使いたくないというわけではありませんが、実際のところ、まだどこでも使用することはできません。 それが問題です。 希望的観測を脇に置いて、まずは現実の世界を考えるべきです...

@MartinJohns私はそれを理解しました、私はまったく同じ状況にあります。

恐れ入りますが、完全なフレームワークがサポートされていない場合、今後のプロジェクトで多くの問題が発生します。pact-net-coreもその1つです。

ASP.NETCoreとMVCを削除する以外に選択肢はありません。 ASP.NETCoreMVCのサポートが終了しました

そして、.NETのベトナムに到着しました。 大胆にマイクロソフトを動かして、それが報われるかどうか見てみましょう。

ASP.NETCoreとMVCを削除する以外に選択肢はありません。 ASP.NETCoreMVCのサポートが終了しました
@shanselmanこれを決めるのは時期尚早ではないですか? これを言っている公の発表/投稿はありますか?

.NETFramework上のASP.NETCore1.1でいくつかの新しいプロジェクトを実行しました。 今は行き止まりになっていることにわくわくしていません。 古いASP.NETでそれらを実行したいのですが。

スコッツは今ビルドに話をしている、おそらくこの話の中または直後にいくつかのニュースがある。 ここでライブストリーミングできます: https ://channel9.msdn.com/?wt.mc_id = build_hp

共有してくれてありがとう@NickCraver

代表的なマイクロソフト。
ほぼ30年から40年後、彼らはまともなブラウザを開発することができませんでした。
ほぼ20年-将来の希望がある1年を超える寿命のフレームワークはありません。
それでおしまい!。
親指を下に向けても、事実は変わりません。

免責事項:私は多くのことを読みましたが、上記の500以上のコメントの_すべて_ではありません。

私を悩ませているのは、MSがアップグレードする必要があるかのように動作し続け、「何があなたを妨げているのか」と尋ねることです。

くそー、妄想するのをやめなさい! 😡.NETCoreは.NETfxを置き換える準備ができていません。 今日ではなく、1年ではありません!

これが(.NETfxで実行されている私のASP.NETCore 1.1プロジェクト)を妨げるものです:

  • ビジネスをゼロにするために移行を行うには、お金と時間が必要です。 経営陣から得るのは本当に難しい。
  • 多くのテストが必要です...ビジネスの改善はありませんが、実際の回帰リスクがあります。
  • COMAPIを公開する他のエンタープライズサービスと統合する必要があります。 私はそれが嫌いですが、選択の余地はありません。 @shanselmanは、.NET fxでプロセス外サービスを作成し、「苦痛の世界にいる」ことを提案しています。 申し訳ありませんが、いいえ、それはしません。
  • EFは、私がまだfxを使用している主な理由です。 MSはあなた自身のものをまっすぐに取得し、それからあなたは移行について私たちに話します。 EFコアはEF6を置き換える準備ができていません。
  • OracleDBプロバイダーはCoreをサポートしていません。 さらに悪いことに、彼らはフルマネージドプロバイダーのみをコアに移植する計画を発表しました。コアには多くの制限があります。たとえば、OracleAdvancedQueuesはサポートされていません。
  • 私たちは多くのサードパーティライブラリを使用しており、そのうちのいくつかは移行されており、一部は移行されていません(まだまたはこれまで?)。

@davidfowl
あなたのコメントは私に.NETfxが徐々に時代遅れになっているように感じさせます...それであなたはfxでHTTP/2を決してサポートしない予定ですか?
申し訳ありませんが、作業の多くを.NET fxに移植する必要があります。そのプラットフォームは、機能していません。 WPFアプリからHTTP/2を実行したい場合はどうなりますか?
改善が.NETCoreに迅速に提供されるかどうか、または重要ではない改善の一部がCoreのみであるかどうかは関係ありません。 しかし、.NETCoreはすぐに.NETfxに取って代わることはありません。

今日.NETfxでWebアプリを構築するためのMSガイダンスは何ですか(.NET Coreでは明らかにできないため)?

私が新機能を切望しているわけではありませんが(私はそうではありません)、死んだプラットフォームではなく、生きているプラ​​ットフォームになりたいと思っています。 維持され、必要な更新を取得するもの-たとえゆっくりであっても。

また、マイクロソフト、これを考慮してください:

ASP.NETCore2.0が.NETfx5.0で実行されている場合、これは私がやがて整理できるアップグレードです。
.NET 5.0をいつ出荷するかは問題ではなく、ASP.NET Core 2.0よりもはるかに遅い場合でも、.NET4.6からのアップグレードにかかる時間は関係ありません。 _私にはアップグレードパスと未来があります。_

ASP.NETCore2.0が.NETCore_only_で実行されている場合、行き詰まりに陥っています。
私が望む限り、次の_年_にfxからコアへの移行を見ることができません。 理由については上記を参照してください。

@Kukkimonsutaには、上記の最高の要約の1つがあります。 私の場合、Core-on-netfxを使用したプロジェクトに着手するための決定要因は、EF Core v EF6と、 netstandard互換性を備えていない他のOSSツールセットでした。

このディスカッションで気がかりなことの1つは、 @ davidfowlとその回答者がお互いに「話し合っている」ことです。彼の怒鳴り声に対する反応は、血のない「大丈夫ですが、本当に必要なAPIは何ですか?」 これは会話に再び焦点を合わせるための称賛に値する試みですが、彼は(おそらく無意識のうちに)重要な問題を隠しています。 彼(および@shanselman )の他の応答は、ASP.NETCoreを「可能な限り速く前進させる」ためにこれが必要であるというものです。 再び称賛に値する目標ですが、やはり重要な問題を隠しています。 (隠された問題は両方とも、一般的にOSSのコアとなる「隠された問題」である傾向があります。)

@MisterGoodcatが分裂を埋める試みで争うので、これは単に心理的/感情的な問題でもありません。 @GiorgioGは、「不確実性」は「大企業」が好まないものであるという彼の主張で、マークに近づきました。

根本的な問題はコストです。 不確実性によって引き起こされるコスト、および絶えず変化する開発環境に単に最新の状態を保つためのコスト。 これらは単に「大企業」に打撃を与えるだけでなく、すべての開発者に打撃を与えます。 多分金銭的にではなく(前もって)、確かに時間、ストレス、そしてそれ故に(はい)ビジネス問題の解決策を迅速かつ自信を持って実行する能力。

不足しているAPIは本当に必要ですか? 」というチャレンジレスポンスをもう一度考えてみましょう。その質問をかなりのプロジェクトツールチェーンにさかのぼり、おそらくサードパーティのライブラリに戻します。 この質問に答えるだけでも、それを修正するコストを考慮する前に、コストがかかります。

できるだけ早く前進する」のはどうですか? 繰り返しになりますが、それは素晴らしいことですが、「前進」するたびに、開発者は変更に遅れないようにする必要があるというコストがかかります。 これは、仕事に伴う学習/使用の違いだけでなく、新しい才能を見つけて訓練するための学習曲線と費用の両方に影響を与えます。

最も厄介なのは、古い、移植性のないライブラリへの依存関係の「エッジケース」は検討に値する問題ではないという態度です。 確かに、誰もが罠にかけられることを望んでいる場所ではありませんが、技術的負債に対処することは、非利害関係者のスケジュールで負担されるべきコストではありません

さて、これらのコストはささいなことではありませんが、私たちは皆、この一連の作業でそれらを知っており、期待しています。 実際、.NET Coreへの移行に関しては、強制されていなくても、そのようにすることが正しいことだとほとんどの人が期待していたと思います。 問題点:

  • これを推し進めると、積極的に行動を起こすという観点からも、技術的負債(移植性のないコード)に対処するという観点からも、私たちのほとんどが取り組んできた「償却スケジュール」(時には何年にもわたる)が崩壊します。
  • それが推進されている方法(「私たちはあなた自身の利益のためにこれを行っています。」)は、将来の安定性の前兆ではありません。

@shanselmanがボタンを押してオープンソースのASP.NETにしたとき、私はラスベガスで基調講演をしていました。 それ以来、MSはOSSに向かっているだけです。 しかし、これには常に疑問が伴います。OSSの良さとともに、「悪」もマイクロソフトの倫理に忍び寄るのでしょうか。 言い換えれば、私たちが得ているものと引き換えに何を失っているのでしょうか? これが私たちが見始めているところだと思います。


もう1つ余談ですが、 @ markrendleからのアイデアに感謝します。この動きは、すべてのツール/ライブラリのメンテナが実際にnetfxから前進するための「ズボンのキック」になるというものです。 ただし、これには2つの問題があります。1つは、タイムラインで十分だったということです。 バージョンM.0でASP.NETCoreが.NETCoreに一般的に吸収されるという、N年のバージョンサイクルの発表があったとしたら、それで十分でした。 私は(いわば)私が消費するツールのメンテナに対してそれを振るう最初の一人になるでしょう。 次に、この発表により、特にASP.NET(MVCまたはCore)に焦点を当てたツールは、 netstandardについて心配する必要がなくなる可能性が高くなります。互換性があり、.NET Coreにも直接ジャンプして、.NETランドスケープをさらに分岐させます。

FYI .NET Core 2.0プレビューがリリースされました:
https://www.microsoft.com/net/core/preview

Asp.netコアプレビューのリリースノートを読んでも、Full.Netフレームワークをサポートしていないことについては何も見つかりません。

それはすでに少しずつ行われていますね。

ウェルプ、私の恐れの1つが確認されました。

MS Buildの講演からのほぼ直接の引用:「NuGetのすべての70%は.NET Standard 2 APIと互換性があります...そして、WinFormsやWPFのようなものだけではありません。これらは、すべてのプラットフォームに存在するわけではないからです。 。しかし、他のすべてはそこにあります。再コンパイルはありません。ただ機能します。」

これは信じられないほど誤解を招く恐れがあります。

@PabloAlarconこれはあなたが探している変更です:

https://github.com/aspnet/Mvc/commit/1c5e4176069ea20671e1738ac599e544633f47ce

プラットフォームターゲットとしてのnet46のサポートを終了し、ほとんどのプロジェクトファイルには次のものがあります。

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netcoreapp2.0</TargetFramework>

ほとんどの人がこの変更を望んでいたのは次のとおりだと思います。

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netstandard2.0</TargetFramework>

ああ、ありがとう。でも、公開されたばかりのプレビュー1のリリースノートを意味しました: https ://github.com/dotnet/core/blob/master/release-notes/2.0/2.0.0-preview1.md

@PabloAlarconここでの大きな問題の1つは、この問題に関する事前のコミュニケーションの完全な欠如であり、現在Buildの講演者でさえ、エコシステムに関する誤解を招く情報/統計を引用していると思います。

彼らは皆、ほとんどのライブラリがnetstandard2.0互換であると主張しています。つまり、どこでも(最終的には)実行する必要がありますが、この変更は、プロジェクトがMVCの方向に息を吹き込んでも、.NETCoreランタイムでのみ実行できることを意味します。

これらは.NETCore2プレビューリリースノートであり、ASP.NETCore2プレビューリリースノートではありません。 この変更はここにあります: https ://github.com/aspnet/home/releases/2.0.0-preview1

そして、私はそれがそこにある既知の問題と重大な変更のリストの下にあるはずだと思います...しかしそこで利用可能な唯一のリンクをクリックすると結果のないgithubリストが表示されます

悪いことに、両方のページを読みましたが、.netコアのページをコピーしました。

それでも同じですが、何も言及されていません。

@marcrocnyあなたは、なぜ私が「どの図書館?」と思ったのか、もっとよく言いました。 質問は私ができるよりも目前の本当の問題を損なうので、ありがとう。 新しくて光沢のあるプロントは必要ありません。妥当な時間枠で新しい機能が必要です。それらは安定していて、さらに重要なことに、しばらくの間サポートされます。

10ドルは、HTTP2が完全な.Netになることは決してないということです。

ASP.NetCoreのコミュニティフォークの時間だと思います。

そもそもASP.NETCoreに切り替える理由によっては、完全な.NETFrameworkとNancyFXに戻すことがいくつかの選択肢になる場合があります。

@ dbus0問題は、Microsoftのフレームワークの神聖で祝福された土地を離れると、それをサポートするライブラリの小さなエコシステムになってしまうことです(ASP.NETと比較して)

Web用のASP.NETを廃止する場合は、.NET以外の技術スタックIMOを選択する方がよい場合があります。

誰かがaspnetcore2.0が不可能にする機能のリストを教えてもらえますか?

皆さん、あなたはかつて美しい.NETフレームワークを殺しています。 .NETを管理しているLinux風の方法は、すべてを巨大な大きなハックのように見せかけるだけです。 MS-devのすべてがアマチュアっぽく見え始めており、すべてのチーム/製品が単独で独立している状態になっています。 ベータ版のすべて、進行中のすべて、巨大な巨大なものを試してみて、何が起こるかを見てみましょう、私たちは冗談を言いました、私たちはまだそれをしないと約束しました...、あなたは本当にそれが必要ですか? なんで ? 等々。 このようなものが必要な場合は、PHPとLinuxに投資して、パッケージZに互換性がないためにライブラリXがカーネルYとどのように連携しないかについて話し合うことができたので、楽しみのためにすべてのアプリケーションを書き直す必要があります。

さらに、チームが「より速く動く」、「機会を探る」などのマーケティングマントラの背後に隠れて、偽の技術的理由の背後にビジネス目標を隠すことは嫌いです。 エコシステムのあちこちで「これはオープンソースです。自分で修正してください」という返信を見始めました。 私が理解しているのは、多くのMSテクノロジ、特にそれがどこに向かっているのか、そしてその理由がわからない.NETCoreを信頼できなくなっているということです。 私はすでに非常に動揺していましたが、互換性のないバージョンの狂気と、.NET Coreの開発のあらゆるレベルとステータスでの重大な変更(ASP.NET CoreはRCですべてを変更しますか?ああお願いします...)しかし、実際には、開発者とビジネスユーザーは、Core 1.1がサポートしているのに対し、Core 1.0がサポートしていないことについての無限の議論を開始するためだけに、私の会社に代わってCoreに投資することを推奨したり、決定したりすることはできませんが、これを壊すため、またはそれをアップグレードすることはできません。 2.0だけが持つ新機能が必要なので、2.0にアップグレードしたいのですが...何ですか? 冗談ですか ?

そして、この種のアプローチが何かを壊したり、人々が望むかもしれない機能をサポートするための新しい遅い時間の変更を導入するために人々が実際に使用している名前空間や機能を理解したりするかどうかは関係ありません。 あなたは私が見た最悪の振る舞いによって物事を短絡させています。それは、新しいXYZリリースを発行して、アップグレードするように人々に指示できるため、以前の計画ではありません。 何らかの理由で彼らができない場合は、運が悪い。 v8.0で作業している場合でも、v8.0の機能がないことを除いて、v1.0を「サポート」します。したがって、サポートは基本的に、苦情を言って人生が難しいと述べたときに背中を軽くたたくことで構成されます。

過去2年間にどれだけのMSテクノロジーを落としたか信じられません。 1998年からマイクロソフトのショップをやっていたので、それができるとは思っていませんでした。私たちの地域では、「。NETのもの」または「Windowsのもの」の場合は常に採用されています(質問はありません。 Windows->それらを呼び出します)しかし、今日私が新しいプロジェクトのための技術を選ばなければならないとき、私はいつも、一般的に言えば、.NETフレームワークにとどまることが正気であるかどうか疑問に思います。 そして確かに、これを読んだ後、.NET Coreへのすべての投資は、少なくともそれで何が起こっているのかを理解するまで停止します。 .NET Core 1.1は2.0と互換性がないため、またはライブラリをホストするためだけに誰かが維持する必要がある小さな別個のプロジェクトを作成する必要があるため、なぜそれまたはこれを書き直す必要があるのか​​を顧客に説明する意志も時間もありません。必要ですが、これはフレームワークの「古い」バージョンと互換性があります。「古い」とは、3か月前にリリースされたバージョンを意味します。 それでも、維持される「古い」バージョン(MAYBE)のためにアップグレードする必要がありますが、新しい機能は提供されません。

このようなアプローチにより、.NET Frameworkを全体として再考する必要があり、.NET Frameworkを再検討することは、Windowsを再検討することを意味することを知っておく必要があります。 また、Windowsを再検討するということは、Microsoftが必要かどうかを再検討することを意味します。 GitHubやあいまいなフォーラムを清掃して、vNextでサポートされる機能を理解し、それらをvCurrentと比較して、vNextと互換性を持たせるためにベータ版またはアルファ版のリリースをターゲットに開発を開始できるかどうかを理解するのは私たちの責任ではありません。特定の機能があるため、この段階では古いバージョンを使用して開発することは意味がありませんが、最終的なものではなく、数か月後にこの狂気を再開するためにのみ変更される可能性がある(そして変更される)リリースをターゲットにして開発するのはリスクです。 それは「アジャイル」ではなく、自由な時間がたくさんある子供たちです。

ゲイツが恋しいといつも思っていたが、バルマーも恋しいとは思ってもみなかった。 よくやった、みんな。

私の意見では、.NETCoreに完全に切り替えるのはどういうわけか時期尚早です。 現在、多くのサードパーティのフレームワークとライブラリは.NETCoreをサポートしていません。 例としてNServiceBusを取り上げます。 少なくともASP.NETCore3..までは.NETFrameworkをサポートしてください。

公式(関連)発表
https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

プレビュー1の問題

このプレビューバージョンのASP.NETCore2.0には、.NET Core2.0SDKのみがサポートされています。 私たちの目標は、ASP.NETCore2.0を.NETStandard2.0に同梱して、アプリケーションを.NET Core、Mono、および.NETFrameworkで実行できるようにすることです。

チームがビルド前に最後の問題に取り組んでいたときに、ASP.NET Core2.0のプレビューで.NETStandard2.0の外部にあるAPIが使用され、.NETFrameworkで実行できないことが判明しました。 このため、プレビュー1のサポートは.NET Coreのみに限定し、開発者がASP.NETCore1.xアプリケーションを.NETFramework上のASP.NETCore2プレビューにアップグレードしても問題が発生しないようにしました。

そこに素敵なバックペダル。

では、.NET Frameworkを削除するためのこのスレッドのすべてのフィードバックと「正当化」は、プレビューのためだけのものでしたか?

心の変化がここでも発表されなかったことは注目に値します...

@benaadams

私たちの目標は、ASP.NETCore2.0を.NETStandard2.0に同梱して、アプリケーションを.NET Core、Mono、および.NETFrameworkで実行できるようにすることです。

「私たちは常に東アジアと戦争をしてきました」

それは慰めですが、公式のASP.NETCoreメンバーからの上記のいくつかのコメントは_非常に_異なるメッセージを配信しました。

.NETFrameworkに関するASP.NETCoreの中期的な将来についての公式声明をお願いします。

MSはASP.NETCoreをnetstandardと互換性を維持することを約束していますか?
ASP.NET Core 2.0リリースだけではありません(必ずしも4.7ではありません)。

ここで、頭がおかしくなる状況について話します。 何起こっているのですか? :考え:

そこに素敵なバックペダル。

では、.NET Frameworkを削除するためのこのスレッドのすべてのフィードバックと「正当化」は、プレビューのためだけのものでしたか?

ねえ、これについてディックにならないでください。 彼らはASP.NETCoreがどうあるべきかについてのビジョンを持っており、多くのフィードバックが提供され、フィードバックが聞かれました。

ASP.NETチームに感謝します👍

@davidfowl

.NET Frameworkで文字列と配列を最後に変更したのはいつですか?

.Net Framework 4.6では、両方。 これは、新しい.Net Framework 4.7の背後にあるマイナーバージョンの1つであり、2年未満前のものです。

.Net Frameworkで文字列と配列を変更するのが、音を立てるほど難しいかどうかはわかりません。

@JamesNK

たくさんのフィードバックが寄せられ、フィードバックが聞かれました

でしたか? フィードバックの少なくとも一部は、不十分なコミュニケーションについて不平を言っていました。 現在、MSの人々がこのスレッドで1つのことを言っていますが、少し最近のブログ投稿で別のことを言っていますが、変更や将来についての情報はありません。

少なくともMSの誰かがこのスレッドに表示され、ASP.NET 2.0の考え方が変わり、.Net Frameworkの削除は将来のバージョンに向けてまだ準備が整っていると言うことを期待しますが、すぐに通知されます。彼らはもっと知っています(または実際の状況が何であれ)。

少なくともMSの誰かがこのスレッドに表示され、ASP.NET 2.0の考え方が変わり、.Net Frameworkの削除は将来のバージョンに向けてまだ準備が整っていると言うことを期待しますが、すぐに通知されます。彼らはもっと知っています(または実際の状況が何であれ)。

彼らの弁護において(そしてこれがまったくうまく処理されたとは思わないが)、チーム全体がほぼBuil​​dにいる。 私たちはここですぐに何かを聞くと確信しています。 この決定により、数日で誰の人生も変わることはありません。

ねえ、これについてディックにならないでください。

私は今日と昨日、疑似危機モードでチームと数時間を過ごし、これが今後12か月間にもたらす影響と技術戦略の変更について話し合いましたが、「おっと、悪い!」とだけ言われました。

私は変化を歓迎し、私たちが聞いてくれたことに感謝しています。 私はディックになろうとはしていませんが、これを介したコミュニケーションに「腹を立てています」。

文字列を.NETCoreで取り組みたい主要なものの1つとして特定しました。アイデアはたくさんありますが、そのうちの1つは、文字列をデフォルトでutf8にすることです(互換性の問題がたくさんありますが、ここでフォローしてください)。
修正したいもう1つの点は、配列/文字列の安価なスライス、隣接するメモリの任意の部分を取得する機能です。 Spanを追加しましたとバッファを見ていますこれを表すために。 これは、StringとArrayが、0の割り当てを必要とするスライスを取得できるようにする新しいインターフェイスを実装していることを意味する場合があります。
これにより、毎回配列を割り当てない分割を可能にするStringの新しいメソッドが作成されます。
これにより、Spanを使用するInt、UIntなど(TryParse)へのオーバーロードが発生しますとスパン
これにより、Spanを使用する新しいエンコーディングルーチンが作成されます
バッファとスパン均一な方法でメモリを表すことができます。ネットワークスタックをアップグレードして、Spanを使用する事前に固定されたバッファを渡すことができるようにします。またはバッファ
Kestrelは2.xタイムフレーム(現在2.1を目指しています)でHTTP2を実装し、ALPN(https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)を実行するにはSSLストリームに新しいAPIが必要です。
.NET Core上のHttpクライアントは、二重ストリーミングをサポートします。これにより、単一の非WebSocket http要求を介して、Signalのhttpを介してストリーミングエンドポイントを実装できるようになります。
ヘッダーパーサーの実装をHttpClientとSystem.Net.Httpからフォークし、名前を変更して(https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers)、それらを改善できるようにしました。 .NETFrameworkと.NETCoreの両方をサポートするようにします。 .NET Coreには、これらの改善のコピーがありますが、改善する必要がないため(消費できませんでした)、元に戻されていません。
新しいAPIを必要とする新しいスレッドプリミティブがたくさんあり、それらを使用できる場合は新しいシナリオを照らします(https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl + label%3Aarea-System.Threading)、これらは私が個人的に提出したもののほんの一部です。

RIPの最新のプラットフォーム。 asp.netコアチームが上記からソリューションを受け取った場合。

私は今日と昨日、疑似危機モードでチームと数時間を過ごし、これが今後12か月間にもたらす影響と技術戦略の変更について話し合いましたが、「おっと、悪い!」とだけ言われました。

私は変化を歓迎し、私たちが聞いてくれたことに感謝しています。 私はアソコになろうとはしていませんが、これをめぐるコミュニケーションに腹を立てています。

彼らがコミュニティに耳を傾け、(一見)コースを変更したことにあなたは腹を立てていますか? 完成しなかったものに時間を費やしているのは、コミュニティでもマイクロソフトのせいでもありません。

素晴らしいニュース!

これが、デフォルトでutf8文字列を見逃していることや、 @ davidfowlが話している他の機能(.NET Coreで実行している場合)を見逃していることを意味しないことを願っています。

「ASP.NETCore2.0に対する.NETDesktopのサポートなし」プランが最終的にキャンセルされたため、このスレッドを閉じることができると思います(ただし、再度開く場合は、遠慮なくpingしてください)。

このスレッドに参加するために時間を割いてくれた皆さんに感謝します; 間違いなく、Microsoftの責任者は、コミュニティに相談したり、エコシステム全体に対する一方的な決定の実際の影響を測定したりせずに、このような大きな重大な変更を最後の最後に黙って採用することはできないことを認識しました。

私たち全員が異なる意見を持っていましたが、最も重要なことは、この変化について実際に話し合うことでした。 これは明らかに大きな成功であり、前例のない成功です(150人の参加者と600以上のメッセージ、うわー!)

このような素晴らしいコミュニティが活動しているのを見るのは驚くべきことです。私はその一部であることをとても誇りに思っています:call_me_hand:

@davidfowl @ DamianEdwards@ shanselmanありがとうございます。 これにより、私の生活はずっと楽になり、今では不確実性なしに移行する計画を推し進めることができます。 これはASP.NETチームにとって理想的ではないことはわかっていますが、プラットフォームの成長にとって現時点で最善の策だと心から思います。

そして、このスレッドは、生産的ではないコメントがあっても、非常にうまく処理されました。 ごくまれに、何百ものコメントにしばらくすると役立つものが含まれている問題が発生することはほとんどありません( @davidfowl 、あなたは素晴らしいです)。

プラットフォームがポイントに達するまで、サポートを削除する方がはるかに簡単なオプションであり、取り残されるユーザーが大幅に少なくなることを願って、3.0でこの議論をすることを楽しみにしています。 そこにたどり着くのを手伝うのを楽しみにしています。

この結果は問題ないようです。 近いうちにロードマップをまとめることができると確信しています。すべてをコアに移行する計画があります。ある期間にわたって、全員が事前にそれを知っているのです:)

また、私の考えを残したかった...コミュニティのフィードバックを聞いた後、ASP.NETチームが迅速にコースを修正できたのは素晴らしいことです。これは、.NETフレームワークと最終的には.NETの将来を繁栄させるための最良の戦略であると私は信じています。 .NET Core自体の採用は、ほとんどの採用が既存の.NET開発者からのものであると私は予想しています。その多くは、既存のコードベースをASP.NETの新しい開発モデルに移行し続けることができます。

私はまた、間違いがあったことにも間違いはありません。特にオープンで開発する場合、重要な部分は私たちがそれらから何を学ぶことができるかということです。 OSSの最大の利点の1つは、フィードバックを早期に取得できることです。これにより、プロジェクトの将来とそのユーザーに最適なコースについて情報に基づいた決定を下すことができます。これは、ASP.NETチームがここで実行できたと思います。 また、プロジェクトの方向性、ビジョン、ロードマップの両方にとってメッセージングがいかに重要であるか、アーリーアダプターと最も忠実な利害関係者の戦略的決定の基礎をどのように形成するか、そしてファンダメンタルズを提案する際にコミュニティに関与することがいかに重要であるかを繰り返し述べていただければ幸いです。プラットフォームへの既存および将来の投資に影響を与える可能性のある変更。

最後に、私がGithubで積極的に開発してきた9年間で、これは私がこれまで参加した中で最もアクティブなスレッドであり、ほとんどのコメントは思慮深く丁寧であり続けることができます。 NETは、ASP .NET Coreを採用し、MSをフォローして、.NETStandardと.NETCoreが可能にするエキサイティングな新しい多面的な未来を目指しています。 これからのエキサイティングな時代!

マイクロソフトを聞いてくれてありがとう!

@davidfowl @ DamianEdwards@ shanselmanありがとうございます。
マイクロソフトに感謝します

ホリーカウ! 私はどんな熱い混乱を逃しましたか? 最終的に結果がどうであれ、ドットネットのエコシステムを弱めるのではなく、強化することを願っています。 私は革新を試みて、ある時点で過去を断ち切る必要があることで大丈夫ですが、次のPython 2vs3になるためのそれらの参照はすべて現実的すぎます。 私は自分のプロジェクトに個人的に影響を受けていませんが、ここですべての開発者のサポートを見ることができてうれしいです。 製品に強い関心を持っているこれらすべての人々は、それが彼らにどのように影響するかについての詳細な例とともに、このコミュニティがどれほど強いかを確認しています。 このコミュニティを気遣い、維持してくれてありがとう!

みんなうまくやった!
.NET上のOSSにとって素晴らしいニュースです!!

@davidfowl @ DamianEdwards@ shanselmanフィードバックをお聞きいただきありがとうございます。 また、プラットフォームの移植性を向上させるために.NET Standardをターゲットにする方法について、組織内で話し合いを開始していただき、ありがとうございます。 WinFormsアプリケーションとASP.NETCoreアプリケーションの間で共有されているすべてのライブラリを.NETStandard2.0にターゲティングして、実際に.NETCoreでASP.NETCore製品を実行できるようにする方法を見つけられることを願っています。将来。

バージョン3.0でまた会いましょう?

ポジティブなメモ:あなたがこれを変更することを決定したことをうれしく思います。 開発者としての私の生活がはるかに楽になり、.Netでの学習と開発に時間とエネルギーを投資することの正当性は良いものになります。

ほんとありがと。

ええと、完全なnetFxのサポートをやめるのは間違いではないと思います。 それどころか、唯一の間違いは、ASP.NETCoreが最初から完全なnetFxをサポートしていたことです。

つまり、ASP.NetCoreは完全なnetFxをサポートできないはずです。 これは、.NetCore用に特別に構築されたWebフレームワークである必要があります。

ASP.Net Coreは、特定のバージョンの.NetStandardを実装する.NetCoreの上にあると想定されており、完全なnetFxとは何の関係もありません。

ASP.Net Coreアプリは、.Net Coreが実行できる限り、どのプラットフォーム/OSでも実行できます。 ただし、プラットフォーム固有のすべての機能をサポートするのではなく、実行する機能についてです。 Windows固有の機能が本当に必要な場合は、Windowsをサポートする複数のターゲットのnugetパッケージを使用するか、代わりにASP.Netを使用する必要があります。

ですから、チームがやろうとしていることは間違いを正していたと思います。 しかし、残念ながら、皆さんはそれらをうまく停止します。

ところで、「ASP.NetCore」を「ASPfor .Net Core」に変更し、「ASP.Net」を「ASP for.NetFramework」に変更することはすべて意味があります。 そして、皆さんが必要としているのは、実際には「ASP.NetStandard」または「ASPfor.NetStandard」のようなものです。

@davidfowl @DamianEdwards @shanselmanまた、私の声に加わって、決定に感謝します。

.NET Frameworkは私たちにとって非常に重要であり、依存しているライブラリもそこにない限り、それを超えることは決してありません。

コミュニティにリストしていただきありがとうございます。

真のオープンソースへようこそ

素晴らしいニュース! :)信頼できる、信頼できる未来への信頼が私たちの多くにとって重要であり、彼らがすぐにこの間違いを犯さないことをマイクロソフトが知っていることを願っています。

正直なところ、皆さんがすでに祝っている理由はわかりません。 ブログ投稿は、この号のファウラーとエドワードの声明と矛盾しており、彼らはまだ声明を撤回したり修正したりしていません。 ブログの投稿は、ジェフリー、さらに別の人によって書かれました。 この号では、.NETサポートの廃止は意図的な決定であると述べられました。 ブログ投稿で、彼らはサポートの欠如が「明らかにされた」と述べています。 コミュニティからのバックスラッシュの後で彼らが彼らの計画を変更したというブログ投稿には言及がありませんでした。

ですから、私にはまだ明確さが欠けています。 チームのさまざまなメンバーによる矛盾するステートメント。

@DamianEdwards @davidfowl :この問題について明確に説明していただけますか?

@PinpointTownes :思ったほど明確ではないので、おそらくこの問題を再度開く必要があります。

私は@MartinJohnsと一緒です。 これは、ASP.NET Coreが、 @davidfowlが話している.NETCoreの急速な開発から利益を得ていないことを意味しますか?

私も懐疑的です。 車両は今のところ正しい方向に進んでいるように戻ってきましたが、ドライバーが問題を適切に把握していないという証拠はこれまでになく強力です。

ここで起こっていること、プレスリリース/ブログで起こっていること、そして私たち全員が内部で起こっていることを推測しなければならないことの間の矛盾は恐ろしいものです。 ここカスタマーランドでは、今後X年間、MSをビジネスに信頼することを決定しようとしています。これは、信頼を得るための衝撃的な方法です。

歴史を見てください:

  • 秘密裏に下された悪い決定(悪い)
  • それを正当化するためのやや不快な試み(やや良い、やや悪い)
  • 悪い決定の逆転(良い)
  • 最初の3つのステップをグロスしてみてください(ぞっとする)

昨日の2つのスコットのショーでやった賢明なことはパワーポイントを捨てて、真ん中にプラスチックの椅子に6人のシニア.NETの人々を置くことだったので、ビルドがそのような過度に光沢のあるワンクフェストであることは残念ですステージの位置を合理的に説明しながら、男らしくたわごとを取ります。

代わりに、彼らは部屋の周りで荒れ狂う象を完全に無視し、今ではそもそも何も起こらなかったふりをしようとしているようです。

悪い決定と逆転は開発プロセスの自然な部分であり、OSSを使用するとそれらを見ることができます-それは問題ありません。 企業の隠蔽はそうではありません。

.NETは、MSがAzureを販売するためのツールです。これは、開発フレームワークを選択するだけでなく、さらに長期的な信頼を必要とする提案です。 今週の信頼醸成はどうですか?

ここで2番目の@MartinJohns :空が落ちるため、netstandard2.0をターゲットにすることはできませんでしたが、現在はターゲットにできます。 (もちろんできますが、できないという技術的な理由はありませんが、 @ davidfowl@DamianEdwardsによると必要でした)。 彼らは今これをどのように行うつもりですか、今何が決定されていますか? //ビルドとすべてであることは知っていますが、誰もこのスレッドに来て少し説明することができないほど人員が不足しているわけではありません。 それとも、私たち全員がお気に入りのMicrosoft従業員にメッセージを送り、バックチャネルを介して質問する必要がありますか? 私は本当にそうしないことを望みます。

昨日の2つのスコッツのショーでやった賢明なことは、パワーポイントを捨てて、ステージの真ん中にあるプラスチックの椅子に6人のシニア.NETの人々を置き、彼らの立場を合理的に説明しながら、たわごとを巧みに取るということでした。

@willdeanビルド基調講演またはスコット²のセッションを見ている大多数の人々は、そもそもこれが起こっていることについての手がかりを持っていませんでした。 彼らがこの事故を明るみに出すことを望まなかったことは完全に理解できます。それが単なる間違いであり、とにかく決定に戻ることにした場合、何十万もの開発者がこのスレッドと同じように混乱したままになります。

チームに少し余裕を持たせて、Build:smile:の後に良い説明/事後分析を期待しましょう。

ビルド基調講演またはスコット²のセッションを見ている大多数の人々は、そもそもこれが起こっていることについての手がかりを持っていませんでした。

それは公正な点です。

@FransBoumaこれらはnetstandard2.0をサポートできますが、ポリフィル、クロスコンパイル、および追加のコードの点で苦痛になります。 http2のように、特定の新機能が導入されるまで、一部の機能を実装することは事実上不可能な場合もあります。

しかし、それは不可能ではありません。 誰もがやりたくない余分な作業がたくさんあります。

コアエコシステム全体は、イノベーションとレガシーサポートの間のバランスを取る行為です。 最終的にほとんどのものをコアに配置するには十分なレガシーサポートが必要ですが、コアを魅力的なプラットフォームにするためには十分なイノベーションが必要です。

良い事後分析を望んでいますが、ここで対処するには十分です。 ブログ投稿を投稿すると、これが問題であることを知らなかった99%が混乱するだけです。

@hallatore 「誰もがやりたくないのは、余分な作業がたくさんあるだけです。」
君の気持ち、分かるよ。 私は個人的には明日グリーンを始めたいと思っていますが、誰も「私」にそのオプションを与えていません...あなたが知っているので、現実...

ASP.Netは、CMS、サードパーティライブラリ、コンポーネント、17年の寿命にわたって構築されたソフトウェアを備えた「エコシステム」であることを忘れないでください。 エコシステムやコミュニティにボールを落として、すべてを置き去りにすることを意味する場合でも、ファンシーストリングを本当に使用したいと言うことはできません...あなたは「できません」...それはあなたができる最悪のことです支援コミュニティ。

進歩を利用したい場合は、ぜひ、プラットフォーム固有のコードパスを構築して利用してください。 このようにして、時間の経過とともに、ユーザーベースはプラットフォームの違いを利用するように切り替わります。 しかし、いかなる状況においても、エコシステムの大部分の「ニーズ」を無視することは賢明な選択肢ではありません。

@hallatore

それらはnetstandard2.0をサポートできますが、ポリフィル、クロスコンパイル、および余分なコードの点で苦痛になります。 http2のように、特定の新機能が導入されるまで、一部の機能を実装することは事実上不可能な場合もあります。

いや。 これは、コード、C#を記述して実行するだけです。 彼らが.netフルでできないことのリストを読んだとき、私は真剣に笑わなければならず、それが原因で.netフルで休憩しなければなりませんでした。 それはただの政治です。 私たち部外者は、.NETで非常に高速なコードを完全に記述し、これらのAPIを処理し、それを最大限に活用する必要があります。 私たちはそれをします。 私たちは、彼らが取り組む必要のある同じ問題を解決します。 そうすることができます。 彼らはそれをしたくないだけです。 しかし率直に言って、私は年を取りすぎて、マイクロソフトの石鹸を何度も扱ってきたので、それを真剣に受け止めることはできません。 彼らにレドモンドの内部政治を維持させ、それのためにユーザー(私たち!)を苦しめさせないでください。 これまで何度も行ってきたので、気を付けてください。

良い事後分析を期待していますが、ここで対処するには十分です。 ブログ投稿を投稿すると、これが問題であることを知らなかった99%が混乱するだけです。

ええ、ブログ投稿は適切な場所ではありません。 このスレッドは、彼らが今それをどのように解決しようとしているのかを知るのに最適な場所です。

@FransBouma

Coreには、asp.netコアとkestrelの調査により作成された多くの新機能が含まれています。 これはC#ではなく、コードが完全なフレームワークには存在しないものを使用しているということです。

@davidfowlが言ったように。 彼らは現在のもののほとんどのためのポリフィルを持っています。 しかし、彼らはポリフィルすらできないものを見始めています。 つまり、ほとんどの場合、コンテンツを削除するか、完全なフレームワークに変更を加える必要があります。 また、新しい機能を完全なフレームワークとコアに組み込むために必要な作業は膨大であり、時間枠がはるかに長くなります。

そして、バランスをとる行為に戻ります。 完全なフレームワークのためにコアを制限する必要がありますか、それともコアはasp.netがこれまでにできたよりも速いペースで革新できる必要がありますか?

彼らがコアだけをサポートしたかった理由をよく理解しています。 そして、完全なフレームワークをサポートする純粋な技術の観点から、彼らが今説明する必要のあるものがたくさん追加されます。 しかし、エコシステムとコミュニティはコアのみの準備ができていません(はっきりとわかるように)。そのための価格は、より複雑なasp.netコア開発です。

@hallatore互換性を破りたい場合は、事前にアナウンスし、移行パスをアナウンスします。 何らかの方法で投資して、ユーザーに移行パスを提供します。

これは多かれ少なかれユーザーを持つことの代償であり、ユーザーを持つことは煩わしいことではなく、責任です。

より多くのプラットフォームをサポートすることがより多くの作業であるかどうかについては議論していないと思います。 です。 コストが高くなると、コードパスが複雑になるなどです。このコストを取り除き、単一のプラットフォームを選択できますか? ここでの答えのほとんど、つまりコミュニティの声は、現時点ではエコシステムの準備ができていないと言っています。 これは、ある種の中間的な解決策を見つける責任があることを意味します。

@hallatore

Coreには、asp.netコアとkestrelの調査により作成された多くの新機能が含まれています。 これはC#ではなく、コードが完全なフレームワークには存在しないものを使用しているということです。

それでは、移植してください。 彼らは両方を所有しています、なぜ問題があるのか​​分かりません。 注意:netstandard2.0ライブラリを作成するだけでコードを移植できます。さらに良いのは、.netコアでのより高速な実装と.netフルでのより低速な実装(たとえば、nugetからのlibを使用)を対象とするshimを作成することです。

実行時にILを生成して、ORMのデータリーダーから超高速の予測を取得します。 誰も私のためにそれを解決しないので、私は手を空中に投げません'できません!'。 他の誰もタブを手に取らないように、単に掘り下げて機能させる必要があるという同様の問題があったに違いありません。 彼らも今それをしなければなりません。

彼らは現在のもののほとんどのためのポリフィルを持っています。 しかし、彼らはポリフィルすらできないものを見始めています。 つまり、ほとんどの場合、コンテンツを削除するか、完全なフレームワークに変更を加える必要があります。 また、新しい機能を完全なフレームワークとコアに組み込むために必要な作業は膨大であり、時間枠がはるかに長くなります。

申し訳ありませんが、「ポリフィル」できないものは何ですか? はい、彼らは.NETでひどい混乱を引き起こしました、そしてパフォーマンスは場所でひどいです、そして物事を彼らが厳しい選択をしなければならない競争のように実行させるために。 さて、それを解決します。 そして、どこかでではありませんが、コアの問題を解決します。Javaでも解決でき、パフォーマンスは驚くべきものであり、コアAPIを壊さず、2つ目のプラットフォームを作成することでそれを実現しました。 それは単なるソフトウェアです。インターフェースを同じに保ち、バックエンドを解決します。 はい、それは大変な作業ですが、たとえばORMを高速化することは一晩で行われると思いますか? :)または、Webサービスを適切に実行して、大企業の重要なビジネスロジックを実行できるようにしますか? いいえ、手間がかかります。 そして、それは大丈夫です。

ここの部屋にいる本当の象は、.NETがいっぱいで、その管理方法です。 またはそれ以上:そこでの管理の欠如。 私は彼らが重大な変更を導入できないことを知っています。 それでは、壊れない変更を導入します。 Win32を見ると、重大な変更が導入されたことはありません。 ものは単に機能します。 はい、物事は成長し、むしろすべてを切り取りたい人々のグループは日ごとに成長しますが、それは無関係です:私たちは皆、かつては重要で今はそれほど重要ではない部分を持っているソフトウェアを扱っていますが、それらを残すことはできません/人々のコードを壊してしまうので、それらを切り取ったり変更したりしないでください。

そして、バランスをとる行為に戻ります。 完全なフレームワークのためにコアを制限する必要がありますか、それともコアはasp.netがこれまでにできたよりも速いペースで革新できる必要がありますか?

何度か言及されていますが、同じ速度で完全なフレームワークを革新できない理由がわかりません。 私たちは皆、.netフルで独自のソフトウェアを革新する必要があります。 文字列のサポートなどにボトルネックがあると思いますが、コピーしない文字列が必要な場合は、文字列を作成して次に進みます。 はい、あなたはそれがどれほど醜いのか、次の10年間自転車に乗ることができます。あるいは、そのクラスを紹介し、それにあなたの速いものを構築して進歩させることができます。 私は最近、win32でC ++ / x64アセンブラーをかなりの割合で使用しています。そこで文字列を再定義した回数を確認し、誰も目を賭けていないようであれば、.netではまったく問題ありません。 つまり、すでに2つの文字列型(charとstringの配列)があります。

彼らがコアだけをサポートしたかった理由をよく理解しています。 そして、完全なフレームワークをサポートする純粋な技術の観点から、彼らが今説明する必要のあるものがたくさん追加されます。 しかし、エコシステムとコミュニティはコアのみの準備ができていません(はっきりとわかるように)。そのための価格は、より複雑なasp.netコア開発です。

信じられないかもしれませんが、私は彼らが.NETから完全に脱却したい理由を十分に理解しています。 つまり、私自身のランタイム/ APIは場所によっては14歳ですが、昨日もその一部から抜け出したいのです。 しかし、私はそれができないことも学びました。単純な事実のために、私の顧客はそれによって傷つけられ、それは彼らにとっても私にとっても悪いことです。 プラットフォーム/ランタイム/APIを作成するときは、最初のリリース以降、降りることができない道を進んでいることを考慮に入れる必要があります。APIは、その瞬間から石になります。 あなたはそれからがらくたを非難することができます、しかしあなたはそれのユーザーが壊れるであろうものを取り除くことができません。 Angular 1.x-> 2.x、python 2.x-> 3.x、十分な例。

BCLプリミティブへの変更をnetstandardパッケージにパッケージ化することはできません。 System.StringとSystem.Int32を変更する場合は、別のBCLが必要です。

また、完全なフレームワークへのすべての更新は以前のバージョンに対するインプレース更新であり、機能のすべての可能な組み合わせ(文書化されていないものを含む)に応じて数十億行のコードが実際に存在するため、同じ速度で完全なフレームワークを革新することはできません。特徴)。 .NET Coreでより迅速に革新できる理由は、.NET Coreのすべての異なるバージョンを対象とするアプリケーションを、それぞれがランタイムの独自のコピーを使用して、同じサーバー上で分離して実行できるようにするためです。 それが全体のポイントです。 彼らはそれを構築したので、より速く反復することができました。 今、彼らはより速く反復できることを利用したいと思っています。

個人的には、そもそもASP.NETCoreから完全な.NETをサポートしていたことが間違いだったと思います。 それは最初からきれいな休憩だったはずです。

個人的には、そもそもASP.NETCoreから完全な.NETをサポートしていたことが間違いだったと思います。

正直なところ、これをリモートで実行可能にするために、2.0のツールと互換性のあるシムが必要だったので、IMO、これは彼らがそれを行うことができた最も早いものです。 遅らせることで、人々はコンバージョンを遅らせ、ユーザーをどのように嫌うかについてマイクロソフトに怒鳴るのを遅らせることができます。 あなたは彼らがこれをするときはいつでも-どんな種類の警告でも-人々はそれについて彼らのクソの心を失うでしょう。

率直に言って、このスレッドの大部分は、.NETコミュニティにとって非常に悲しいものです。

BCLプリミティブへの変更をnetstandardパッケージにパッケージ化することはできません。 System.StringとSystem.Int32を変更する場合は、別のBCLが必要です。

はい、私は知っています、そしてそれは私が言うことを暗示したものではありません。 その観点から私の投稿を誤解している人もいますが、それは私が意図したことではありません。 可能であれば、ここでトピックになっている例を示したいと思います。ORM内では、クエリ文字列を作成するために文字列連結も使用しています。 これは、すべてのORMにとって大きなオーバーヘッドです。 そのためにデフォルトの文字列クラスを使用することは、ある意味では役に立ちますが、すべてのコピーで醜くなります。 そこで、そのコピーを大幅に軽減するか、まったく回避する特定のクラスを導入しました。 これには欠点があります。文字列型で十分な場所で使用することも、文字列インスタンスを取得するすべてのAPIで使用することもできないためです。 ただし、自分が最も必要としている場所、つまり自分のコードを介したホットパスでそれらを使用することはできます。

これは_はるかに_理想的ではなく、これを回避できるのであれば、明らかにそうすべきです。 しかし、人生は散らかっていて、私たちがリリースするものは永遠にそこにとどまります。 すでに出ているものを変更することはできないので、_その状況に対処する必要があります_。その解決策の1つは、新しいタイプとこれらのタイプで動作する新しいコードを導入することです。 このアプローチは、すべての主要なOS APIで長年使用されており、お尻が醜いのでひどいですが、行き詰まった過去にとどまるのではなく、前進するための実証済みの方法です。

行き詰まった過去にとどまる代わりに前進するためのもう1つの実証済みの方法は、嫌いな人がとにかく物事を嫌い、壊すつもりであることを受け入れることです(Angular2+とPython3を参照してください。どちらもうまく機能しています)。

@NickCraver 3.0、2.2、23.5のいずれであっても、最終的にこの休憩をとるときはいつでも、ピーナッツギャラリーから今日と同じくらい多くの嘆きと衣服の貸し出しが行われることに100ドル賭けます。

行き詰まった過去にとどまる代わりに前進するためのもう1つの実証済みの方法は、嫌いな人がとにかく物事を嫌い、壊すつもりであることを受け入れることです(Angular2+とPython3を参照してください。どちらもうまく機能しています)。

もちろん。 ただし、どちらにも結果があります。「OS API」メソッドは醜く、何年にもわたって多くの行き止まりがある大規模なAPIにつながります。 'angular / python'メソッドは、人々のアップグレードパスを壊し、コミュニティを分割します(Angularの世界がどれほど断片化されているかはわかりません)。 ASP.NET Coreに照らして、どのルートが優れているかわかりません。 技術的な観点からは、もちろんPythonルートが望ましいです。 安定性の観点から、それはiMHOを殺しています。

Angularの世界のほとんどすべての人が「ああ、そうだ、それは_はるかに_良い」と移行し始めた。 Pythonは現在最も急速に成長している言語の1つであり、それを推進しているのはPython3です。

個人的には、そもそもASP.NETCoreから完全な.NETをサポートしていたことが間違いだったと思います。 それは最初からきれいな休憩だったはずです。

明らかに、そのアイデアにはいくらかのコスト削減がありますが、それはMSが完全に支配的な地位を築いた方法とは完全に反対です。

  • WindowsはDOSアプリケーションを実行しました
  • 32ビットWindowsは16ビットWindowsアプリケーションとDOSアプリケーションを実行しました
  • 64ビットWindowsは32ビットおよび64ビットアプリケーションを実行します
  • .NETアプリケーションは、リリース時に関連するすべてのオペレーティングシステムで実行されていました

これらは非常に困難な技術的課題であり、非常に費用のかかる妥協案でしたが、MSが大まかに長い間彼らの側にいるコンピューターを使用して作業を行う必要がある世代全体を安心させました。

Win32 / Win16相互運用機能の話や、Win3-> Win95-> WinNTでのDOSアプリケーションの実行など、技術的に何が関係していたかを振り返るのは難しいです。

@markrendle

Angularの世界のほとんどすべての人が「ああ、そう、それははるかに優れている」と移行し始めました。

正直に言って、Angularを.NETランタイムと比較したいですか? ほとんどの人は、すぐに.NETCoreに移行したいと考えています。 しかし、現実的にはできません。 多くの依存関係が利用できないか、リスクが高すぎるか、単にコストが高すぎます。

@markrendle

Angularの世界のほとんどすべての人が「ああ、そう、それははるかに優れている」と移行し始めました。 Pythonは現在最も急速に成長している言語の1つであり、それを推進しているのはPython3です。

Python 3が9年間リリースされ、ついに新しいプロジェクトで使用するデフォルトのPythonになりつつあるという事実について、あなたは論文を書いていると思います。 ただし、最新のOSXを実行している私のMacにはPython2.7.12が付属しています。 私のNAS、同じです。

同じことがAngularにも当てはまります-数時間のうちにAngular2に移植できるちっぽけな小さなデモアプリを書いているなら、それは素晴らしいことです。 現実の世界では、2〜3年前の大規模なアプリケーションの移行は簡単な作業ではないため、引き続きAngular1を使用しています。 移植には時間とお金がかかり、ビジネスは正当化を望んでいます。

@bradwilson

率直に言って、このスレッドの大部分は、.NETコミュニティにとって非常に悲しいものです。

そもそも私たちをここに連れて行った彼らの失敗について、ここでマイクロソフトの足元に責任を負わないでしょうか? .NETCoreはクリーンブレイクになるはずでした。 その後、そうではありませんでした。 彼らがそれを「.NETCore」と名付けたという事実はあなたが知っていることを意味します....NETのコアは正しいですか? そして、.NETとは何ですか? 過去15年間、それは.NETフルフレームワークでした。 Microsoftがすっきりとした休憩を望んでいたのなら、このことについて新しい名前を選び、戻ってすべての古いAPIを再導入するのではなく、その銃に固執し、人々に古い世界と新しい世界のどちらかを選択させるべきでした。 彼らが現在バックペダルを踏んでいるという決定は、次の3つの状況のいずれかにプロジェクトを残していたでしょう。

  1. フルフレームワークでASP.NETMVCを使用しており、フルフレームワークでASP.NET Core 1.Xに移植できますが、その後は、.NETCoreに移行するまでSOLになります。
  2. フルフレームワークでASP.NETCore1.Xを使用しており、ASP.NETCore2.0に移行するには.NETCoreに移植する必要があります
  3. .NETCore上のASP.NETCoreで作業しています。

Microsoftが前進し、完全なフレームワークでASP.NET Core 2.0をサポートしていなかったとすると、状況1と2の人々には、既存のアプリケーションをASP.NETCore2.0に移行するための明確で現実的な道がありませんでした。 状況1の人々は理解するかもしれませんが、2の人々は当然のことながら怒っているでしょう。 状況2は小さなグループかもしれませんが、これは私たちが話しているMicrosoftであり、1人の男によって維持されている小さなオープンソースプロジェクトではありません。 企業/人々の生活はこれらのシステムに依存しています。 彼らがマイクロソフトに頼ることができないなら、次にあなたがあなたのお尻に賭けることができるとき、彼らはプラットフォームを使わないでしょう。 信頼が重要です。 Microsoftスタックの使用を検討しているショップでは、対戦相手はこれを注意喚起として使用します。

この問題の責任は、Microsoftの.NETCoreのひどいメッセージング/マーケティング/ネーミングにあります。 いつもみんなを喜ばせることはできませんが、戦いの半分は最初から正しい期待を設定しています。

@MartinJohns前のコメントに返信していました。

@markrendleなぜ笑うのですか? 説明してください。 「APIがほぼ同じ」の場合、文字列などの基本的な変更はこの方法で処理できる可能性があります。 APIに変更があった場合、.Net Coreで、誰かがそれを使用したい場合にのみ、別のパッケージにすることができますか?

OKみんな-InternetExplorerだと思います。 マイクロソフトは_最終的に_それを殺している。 もちろん、彼らは長い間待っていたので、代わりのブラウザであるEdgeはおそらくまだ市場で生まれています。 誰もがChromeを使用しています。 それでも、最新のブラウザーを使用するようにアプリをアップグレードすることにビジネス価値がないため、IEを使用する場所はたくさんあります。また、Microsoftがプラグを抜くのが非常に遅いことに不満を言う人もいます。

ASP.NET Coreは、Microsoftが.NETを、過去15年ほどで私たち全員が学んだことに基づいたものに置き換えることを目的としています。 開発者が.NETWindowsフレームワークを使い続けながら、新しいASP.NETCore機能を提供することはIE9によく似ています。.Net4.xのサポートを、出荷されたOSのサポート期間に結び付けることをお勧めします。次に進みます。

@glennsillsIEとEdgeの類似点が欠けています。 一部の機能がEdgeで機能しないため、IEは引き続きWindowsに同梱されています。 Edgeが私の仕事のVPNをサポートしていないことに私は怒っていません-それは問題ありません...それは別のブラウザです。 名前もまったく違うので、ActiveXをサポートする必要があるという先入観はありません;)

@glennsillsあなたはどのような間違いを指しますか?

@markrendle 「Angularの世界のほとんどすべての人が「ああ、ええ、それははるかに優れています」と移行を開始しました。」

あなたは本当にこのような悪い例を選ぶことによってあなたの議論を不幸にしている。 どちらかといえば、彼らが移行を処理した方法は彼らに彼らのリードを犠牲にしました(彼らは当時かなりの差を持っていました)。
Python 3と同じです-断片化は、彼らが何も持っていた勢いをすべて殺しました。

だから、私はここで何かを理解しようとしています。
.NetRemotingを使用する古いAspWebフォームアプリケーションをAsp.NetコアMVCアプリケーションに変換することを計画していました。 私の計画は、システムからそのがらくたを取り除く機会が得られるまで、.NetRemotingを使い続けることでした。 その音では、Asp .Net Core 2.0をターゲットにした場合、これを行うことはできませんか? しかし、私がNet Core 1.1をターゲットにした場合、私はそうしますか?

@wbuck昨日の時点で、完全なフレームワークに対してビルドできないのは、ASP.NETCore2.0の単一のプレビューバージョンのみであるという話です。 おそらく2.0-preview-2で、この機能が復活するでしょう。 したがって、現時点では1.1をターゲットにすることはできますが、2.0-preview-1をターゲットにすることはできません。

長期的な将来が何であるかを誰が知っているか-明らかに完全なフレームワークは最終的には削除されます-タイムスケールは誰の推測でもあります。

@ popcatalin81ええと、複数のプラットフォームで実行したい場合、COMオブジェクトへのアクセスは間違いなく間違いです。 Windowsでのみ実行する場合は「間違い」ではないかもしれませんが、クロスプラットフォームになりたい場合は、このようなことがたくさんあります。 AspNETとIISの結合について考えてみてください。 当時は問題ありませんでしたが、時間の経過とともにスタックが非常に複雑になり(Windowsでも)、他のWebサーバーでアプリケーションを実行するのが面倒になりました。 ASP.NETにはデフォルトで依存性注入がないため、コントローラーなどの単体テストは非常に困難です。 これは、時間の流れの例であり、人々が物事を行うためのより良い方法を理解しているという「間違い」ではありません。

@GiorgioG-ええ、それは私のポイントのようなものです。 Windows 10ではIEとEdgeのどちらかを選択できますが、_選択_する必要があります。 EdgeでIE機能を取得することはできません。これは意図的なものです。つまり、IE機能とEdge機能を1つのプロセスで同時に機能させることは、非常に面倒です。 また、IEの将来のサポートは、バグ修正に限定されています。 Microsoftがこれを10年前に行っていたとしたら、Edgeは現在よりもChromeに対してはるかに競争力があります。 したがって、Microsoftはかなり長い間.NET Classicをサポートし続けるべきだと思いますが、より多くのバグ修正モードでサポートします。 Asp.Net Coreは、クロスプラットフォームの開発とパフォーマンスの容易さに焦点を当てる必要があります。

キャンセルの公式発表はありますか?

@pantonis

これに関する公式発表はありますか?

いいえ、ありません。 異なるチームメンバーによる矛盾する声明があります。 @DamianEdwards@davidfowlは、この号で、サポートを終了することは意図的な決定であると述べました。 Jeffreyは、ASP.NETブログの投稿に、.NETのサポートは継続されると書いています。 しかし、彼らはお互いを参照していませんでした。

こんにちは、みんな、

今回は問題のスレッドに飛びつきませんでしたが、メッセージと方向性を修正するのにかかった時間には非常に満足しています。

私は、BUILDの前にすべてを機能させるために、最初の決定が土壇場で行われたことを理解しています。 .NETStandard2.0を実行する意向を表明することも非常に安心です。

.NETチームには、すべての非生産的なコメントにもかかわらず、迅速なフィードバックとニーズの取得を試みてくれたことに改めて感謝します。

本当に感謝。

@MartinJohnsああ、男の子..では、誰が正しいのでしょうか。

@wbuck

.NET Remotingの将来の使用は、下位互換性を約束する人々によって引き起こされる問題を象徴しています。 リモーティングはさまざまな理由でうまくいきませんでしたが、過去に人々がそれを使用したため(マイクロソフトの誰かがこれは良い考えだと言ったので公平に)、彼らはまだそれを使いたいと思っています。 WEBAPIを介してASP.NETCoreアプリケーションの情報にアクセスするのは非常に簡単で、非常に古い.NET@@frameworksから呼び出すことができます。

私の卑劣な同僚がかつて言ったように、「新しいレガシーアプリケーションの構築をやめる必要がある」。 .NETRemotingをサポートするASP.NETサーバーアプリケーションを構築することはまさにそれを行っています。

@pantonis率直に言って、わかりません。 この号の多くの人々は、後で来たので、この号で述べられた決定の復帰としてすぐにブログ投稿を飛び越えて受け取ります。 しかし、この号とブログ投稿の声明は独立して行われたと思います。まだ明確な声明はありません。

@pantonis最新のものはブログ投稿での公式発表です

https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

プレビュー1の問題

このプレビューバージョンのASP.NETCore2.0には、.NET Core2.0SDKのみがサポートされています。 私たちの目標は、ASP.NETCore2.0を.NETStandard2.0に同梱して、アプリケーションを.NET Core、Mono、および.NETFrameworkで実行できるようにすることです。

チームがビルド前に最後の問題に取り組んでいたときに、ASP.NET Core2.0のプレビューで.NETStandard2.0の外部にあるAPIが使用され、.NETFrameworkで実行できないことが判明しました。

このため、プレビュー1のサポートは.NET Coreのみに限定し、開発者がASP.NETCore1.xアプリケーションを.NETFramework上のASP.NETCore2プレビューにアップグレードしても問題が発生しないようにしました。

@benaadamsしかし、そのブログ投稿のステートメントは、ここで行われたステートメントとの相関関係では意味がありません。 ブログの投稿で、彼らはそれが「発見された」と述べ、「プレビュー1のサポート」を制限したと述べています。 この号では、彼らはずっと何か他のことについて言及しました。 そして、彼らはここのブログ投稿での議論に言及していませんでした。

この号のブログ投稿にある声明の公式の承認を得ることができれば素晴らしいと思います。 または、ブログ投稿にここで行われた議論を認めさせます。 これらの異なる人がお互いの声明を知っていることを私たちが知っている何か。

ブログ投稿は、私たちがここで行った非公式のコミュニティディスカッションに明らかに取って代わる公式のコミュニケーションです。 そして、それが完全に一致していなければ、私たちは皆、企業コミュニケーションの緊急性を理解していると確信しています。適切な聴衆に適切なストーリーを伝えることは、技術的に正しいことよりも重要です。

特定の人に自分の言葉などを食べさせようとする必要はありません。重要なのは、選択した方向が、安全に推測できる、フィードバックに反応した良い方向であるように見えることです。

マイクロソフトが混乱を解消する声明を発表することを願っています。 あなたがそれをすることができるMSに来てください!!!

@pantonis @MartinJohns

私はMSにいないので、これを非公式に確認することしかできません。
昨日のブログ投稿は今後の計画であり、asp.netコアに取り組んでいる人々はそれに非常に一致しています。

tl; dr:これは今後の計画です: https ://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

@pantonis公式発表は公式声明です。

声明?

@PinpointTownes :思ったほど明確ではないので、おそらくこの問題を再度開く必要があります。

完了😄

@pantonis上記のほんの少しのコメント。

https://github.com/aspnet/Home/issues/2022#issuecomment -300774201

マイクロソフトが混乱を解消する声明を発表することを願っています。 あなたがそれをすることができるMSに来てください!!!

彼らに公平を期すために、彼らは今週、強制的な興奮の状態で飛び回るのに忙しくて、ここで時間を無駄にすることはできません。 そして、これまでに与えられた.NET Coreのすべての説明が、世界の理解のレベルを下げるのに役立っただけであることを考えると、おそらく、物事を嘘にするだけの方が良いでしょう。

これまで読んでいる人に物事を明確にするためだけに...

最近の公式発表がこのスレッドの内容と矛盾する場合は、公式公式発表がこのスレッドで以前に述べられたことを上書きするものと見なす必要があります。

公式ブログ投稿>GitHubコメント

どこにも書かれていませんが、私にとって、このルールは長い間当てはまりました。

@MaximRouiller

そうでない場合は、 @benaadamsがおそらく知っているでしょう。
また、数時間前に@davidfowlとも話しました。 発表は正しいです。

編集:この発表: https ://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

@hallatoreどの発表? ジェフリーまたは他の人からのASP.NETブログ投稿で?

手放す。

声明は、.NETFrameworkはASP.NET2.0プレビュー1ではサポートされていないということです。 しかし、彼らはその後それをサポートすることを計画しています。 空はもう落ちていません。

事後にそれについて不平を言い続けること; おそらく、彼らの関与を減らし、アイデアの共有を減らし、初期段階の人々の関与を減らし、はるかに後の段階の人々に情報を提供することを正当化するでしょう。 より臨床的に分析された反応を伴う; 方向を変えるのも難しいとき。

あなたの見解では、間違った決定をするために誰かに飛びついた場合。 その後、彼らはあなたのフィードバックに基づいて考えを変えます。 それからあなたは彼らの決定を変えるために彼らの鼻をこすります-それは将来の関係のためにどのようにうまくいくと思いますか? それは本当に速く機能不全になるだろう。

より新しいよりオープンなMS; 開発者や顧客と直接関わることはエキサイティングです。 あなたの行動がそれをシャットダウンし、すべてが最初に広報の承認を経由しなければならないようにしないでください。 それは誰にとっても良くありません。

もう少し専門的になり、より良いエコシステムのために、私たち全員が一緒に前進する方法を検討してください。

@benaadamsあなたは明確なコミュニケーションの願いと苦情を混同しています。 これは、だれかを追い払う試みではありませんが、彼らがさらに関与し、混乱を解消することを望んでいます。 あなたは彼らが私たちのフィードバックに基づいて彼らの考えを変えたと言います-それは素晴らしいことです。 しかし、ブログ投稿ではこれについて言及されていないため、これが事実であるというのは純粋にあなたの仮定です。

この重大な変更はほとんど発表されていませんでした。 明らかに元に戻された決定はほとんど発表されていませんでした。 エンゲージメントを減らしたいのではなく、エンゲージメントを増やしたいと思っています。

@MartinJohns公の発表では、あなたは今とは何かについて話します。

どのようにしてその時点に到達したかではありません。 事実はまさに@benaadamsが言ったことです。

^ここにGIFを挿入します^

@benaadamsは同意しました。 時間内に(つまり//ビルド後)、.netフルで実行するのが困難/困難であった@davidfowlが提案したアイテムのリストの結果がどうなるか、そしてなぜそれらがきれいな休憩が必要でした。 それがこのスレッド以外の場所で行われるべき理由はわかりませんが、非公式な開発者から開発者へ。 私見では、将来の計画でaspnetcore 2.0に今何を期待するか、そしてこの時間枠では現在何ができないか、したがって延期する必要があるかについて、より多くの洞察を提供します。 それはまた、スレッドを潜んでいる/読んだだけの(そして彼らの結論を引き出した...)ここの人々とまだ疑問を持っているここの人々の信頼を取り戻すのに役立ちます。

非常に長く、良い議論が数日間続いているので、突然の沈黙ではなく、このスレッドでの「公式」発表を期待し、この議論について言及していないブログでの発表を指摘されます。

それは、発表が正しければ、これはもちろん良いニュースであるという事実を変えるものではありません。

これについては申し訳ありませんが、私はこれについての私の理解を明確にしたいだけです

image

上記の図を例として使用すると、ASP.NET Coreの将来は、速度が遅いために実際には.NET Standardレイヤーに配置されるのではなく、ASP.NETCoreを.NETCoreに配置することになると実際に言っていますか? これの将来のバージョンが何であれ、2.0または3.0などになります。

たとえば:-
.NET Core-> ASP.NET
または、それでも.NET Standard-> .NET Core->ASP.NETCoreになります

@lilpugこれは、説明が事態を悪化させるだけであるという私の(人気のない;-)ポイントを示す一種の図です。 「.NET標準」はライブラリではありません。ASP.NETCoreは、.NETFrameworkのピアであるボックス内に配置しないでください。

ダイアグラムは基本的に間違っているので、無視する必要があります。

こんにちは@willdeanあなたはより適切なより良い例を提供することができますか?

しかし、正直に言うと、.NET Standardをライブラリとして指摘するのではなく、継承された位置を示すために例として使用しました。用語は別として、これについての私の見解が私が考えていることでいくらか正しいかどうかを知りたいですか?

より適切なより良い例を提供することができますか?

いいえ、それは図の表現に反するか、少なくとも私が見たすべての図の作者の能力に反すると思います。 @shanselman完璧なコミュニケーター)がそれをすべて説明しようとする記事を書いたとしても、それは丁寧に言うと「用語の正確さ」の束になってしまいます。

多数のコードライブラリが含まれているダイアグラムに「.netstandard」を配置しようとする試みはすべて運命づけられています。これは、ライブラリではなくAPI仕様であり、その存在はライブラリに直交しているためです。

ASP.NETチームは、ASP.NETを維持する負担を受け入れる必要があります。ASP.NETは、敬意を払って、Angularではありません。 また、Microsoftに代わって話すことの負担も考慮する必要がありますが、これは正式には真実ではないかもしれませんが、それが非公式に正しいことは確かです。これは、ASP.NETチームが行う(または行わない)ことで、エコシステム全体であり、直接的または間接的にマイクロソフトの優先事項を反映しています。

簡単な例はADのサポートです。地球上でこれがオプションと見なされる方法がわかりません。 または、ADは確かにインターネット以前の時代の遺物であり、遅かれ早かれ段階的に廃止されることになるので、私は知っていますが、Microsoft/DNFがADをそのに移植する努力さえ考慮していない場合は事実です公式のASP.NETCoreフレームワーク(おそらく夏の前に追加されるという漠然とした約束を除いて...)、メッセージは、テクノロジーがマイクロソフト自体によって傍観されているということです。 ほとんどのMicrosoft製品はADが機能する必要があることを除いて、ADのサポートはそれほど重要ではないとMicrosoftが考えているのに、ADを使用して新しい仮想化クラスターを構築する自信はありますか? 追加しない限り、送信するメッセージは間違いです。今後は、インフラストラクチャへのADの追加を停止してください。 それが、マイクロソフトでの開発が切り離された方法で行われていると言ったときに私が意味したことです。

ASP.NETチームは、このスレッドで、彼らが立ち上がって何かを述べると、人々は緊急の危機前会議を開き、必死に情報を探し、間違った選択をしたと思うことを学びました。 ASP.NETはコアテクノロジ(しゃれを意図したもの)であり、すべてが正常に機能している場合に無視できる単純なライブラリではないため、これが現実の世界で起こります。 したがって、安定性が必要であり、コアテクノロジーを使用する方法であるため、改善も必要です。

別のばかげた例:人気のあるIdentityServer4は、ASP.NET Core 1.1のみをサポートすると述べているので、Core 1.0アプリケーションを持っている人がいて、何をすべきかを変換できない場合はどうでしょうか。 彼らのバージョンが...何...4ヶ月前の場合、古いフレームワークにとどまらないように変換する必要があると彼らに言うのは公正だと思いますか? それは彼ら次第ですか? 一度もない。 リスクは開発者を断片化し、中期的には単に人々に切り替えを強制することであるため、実際に避けられない場合にのみ重大な変更を提供するのはあなた次第です。

正直なところ、このバックトラックは何も修正しません。 オープンソーシング.NETが最悪の選択であり、ほとんどの場合、Microsoftによる離脱を意味することを私は知っていました。 私の前の誰かがこのスレッドで言ったように、.NETは基本的に現在Azureをサポートするためのツールです。

開発者がその変更を受け入れたくないというわけではありません(または、私たちがあなたの髪の色について話し合っている小学生のように誰かが言ったように嫌いです):彼らは受け入れましたが、正直なところ、Microsoftはこの選択の背後に重みを置いておらず、変更を使用して追求していますそのビジネス目標。 完全な.NETFrameworkをサポートすることが可能であり、それが政治であることがわかっていました。 そして、ここでのビジネス上の意見やコメントは、すべての技術的な問題を修正できるため、技術的なものよりもはるかに重要です。 このスレッドで問題がUTF8文字列を持っているかどうかではなく、正直なところ、これらのテクノロジーに依存している人々がいることを教えてくれなかったとしたら...

それはASP.NETチームの責任が大きすぎますか? 多分。 もしそうなら、それらの決定を、エコシステムとプラットフォーム全体の責任を負う「スーパーチーム」に任せてください。

それがGitHubでどのように議論されるのかさえわかりません。

@willdean okは、「図ではなく」別の方法で配置できます:)、

たとえば、.NET Standard 2.0でライブラリを構築した場合、これはASP.NET Core(.NET Core)でサポートされます(将来的には)場合は、「NET Standard-> .NET Core->ASP.NETCore」を意味します。 「そうでない場合は、.NET Coreが崩壊し、NETStandardのベースを利用しないことを意味します。

@lilpugライブラリが.NETStandardの場合、上のレイヤーのすべてで使用できます。

したがって、.NET Standardライブラリは、図に示すように、.NET Framework、.NET Core、Xamarin、Mono、Unityなどで使用できます。

.NET Standardは、可能な限り最大のリーチを可能にするためにライブラリが理想的に準拠する必要があるものです(バージョンが低いほどリーチが大きくなります)。

上のレイヤーはアプリモデルです。 そのexes/実行可能ファイルが何であるか。 それらは最終的なエンドポイントです。

したがって、.NET Framework exeがあり、Windowsでのみ実行されます。

Xamarin実行可能ファイル。 iOS、Android、OSXで実行されます(ただし、それぞれに3つの異なる実行可能ファイルが必要です)。

.NET Core exeは完全に移植可能で、dotnetランチャーdonet my.dllで実行するか、特定のプラットフォームWindows、Linux、MacOS、Tizen用に特別にターゲットを絞った実行可能ファイルを作成してそれらでのみ実行できます。 また、同じコードから特定のプラットフォームすべてのターゲット実行可能ファイル(自己完結型)を出力できます。 あなたがそれをしたいのなら。

たとえば、.NET Standard 2.0でライブラリを構築すると、これはASP.NET Core(.NET Core)でサポートされます

はい; そしてそれは常にそうでした。 ASP.NETCoreライブラリが特に.NETCoreを対象としていたとしても、.NETCoreでのみ使用できます。 ASP.NETCoreで.NET標準ライブラリを引き続き使用できます。 これは、この問題で提起されたものによって影響を受けることはありませんでした。

@benaadamsは、これを非常に理にかなっていることに感謝します。

将来の最終結果として、ASP.NET Coreでの.NETフルフレームワークのサポートが次のリリースであろうと将来のリリースであろうと、.NETStandardで「可能であれば」構築を開始するかどうかを知りたいと思いました。 .NET Framework 4.6以降ではなく、これがASP.NET Coreの使用を将来的に証明し、他のレイヤーとの互換性を高めるのに役立つ場合。

話は明日なので、待たなければなりません。

https://channel9.msdn.com/Events/Build/2017/C9L18

@lilpug

わかりました、「図ではなく」別の方法でそれを置くことができます:)、

たとえば、.NET Standard 2.0でライブラリを構築した場合、これはASP.NET Core(.NET Core)でサポートされます。サポートされていない場合は、「NET Standard-> .NET Core->ASP.NETCore」を意味します。これは、.NET Coreが崩壊し、NETStandardのベースを利用しないことを意味します。

インターフェイスとしての.NET標準を参照してください。これは、.NETコアと.NETフルの2つのクラスによって実装されます。 xamarinやUWPなど、他の実装も存在します。 これは物理的なインターフェースではなく、ここでの比喩です。 ここで、その_interface_を対象とするコードを作成すると、実行時に、.netコアまたは.netフルのクラスであるかどうかにかかわらず、そのインターフェイスの実装を操作できます。

そのため、netstandard2.0では、さまざまなプラットフォーム(.netコア、.netフル、xamarin、uwpなど)に実装されたAPIインターフェイスが定義されています。 したがって、netstandard2.0と互換性のあるライブラリを作成できます。つまり、その標準API定義にあるAPIのみを使用します。つまり、ライブラリは、そのインターフェイスが実装されているすべてのプラットフォームで実行されます。

ASP.NET Core 2.0がnetstandard2.0と互換性があるということは、netstandard2.0のAPIのみを利用することを意味します。つまり、ASP.NET Core 2.0は、netstandard2.0が実装されているすべてのプラットフォームで実行されます。

(編集)ドラッツ、 @benaadamsは私をそれに打ち負かしました。

@lilpug .NET標準ライブラリを作成し、.NET標準ライブラリのみを使用する場合は、すべて問題なく、将来にわたって利用できます。

提起された懸念は、現時点では.NETStandardと互換性のないライブラリを使用している人々によるものでした。 したがって、これらのライブラリは.NETCore2.0では実行できません。

ASP.NETCoreライブラリが.NETCore2.0ライブラリになっているため、フルフレームワークで実行できませんでした(ただし、.NET標準ライブラリは引き続き使用できます)。

皆さんのフィードバックに感謝します。私の主な関心事は、これの最初のスレッドが次のように始まったことでした:-

今日の初めに、ほとんどのASP.NET Core 2.0パッケージは、netstandard1。*およびnet4*ではなくnetcoreapp2.0をターゲットにするように更新されました。

そのため、.NET Full Frameworkだけでなく、.NETStandardのベースレイヤーも削除することについて話しているのではないかと心配しました。

私のためにこれを片付けてくれてありがとう私はそれを感謝します👍

事後分析については、私が真剣に明確にすることに興味があることがあります。

チームがビルド前に最後の問題に取り組んでいたときに、ASP.NET Core2.0のプレビューで.NETStandard2.0の外部にあるAPIが使用され、.NETFrameworkで実行できないことが判明しました。

Kestrelのようにnetstandard1.3net46をターゲットにしている場合(他のパッケージにも同様のターゲットがあります)。 どのようにして「.NETStandard2.0の外部にあるAPIを利用する」ことになりますか?

AFAIK、 netstandard2.0netstandard1.3 _と_ net46の両方のスーパーセットであるため、APIを使用して実行できない状況に陥る可能性があるかどうかを確認するのに苦労しています.NETFrameworkで。 そのプロジェクトはどのようにコンパイルされますか? OK、おそらくいくつかの追加のAPIを備えた別のパッケージを使用しますが、そのようなパッケージを参照するためにも、すべてのターゲットフレームワークをサポートする必要があります。

確かに、ベイトアンドスイッチングやリファレンスアセンブリなどについて何かがあるはずです。私はここに到達していませんか、それともブログ投稿のコメントは、これが決して問題ではなかったふりをするための方法ですか? 😕

また、プレビューの直前にこの変更を急ぐ必要があったのはなぜですか? .NET Frameworkはテストマトリックスの一部ではありませんか?

@adrianlmmありがとうバディ。

これで、それをサポートするかどうかについてのコメントが終了し、さらに混乱が生じます。 あなたが言ったように、イベントを待ちましょう

そして、ここで最後のコメントにしてください。このスレッドを初めて見る人は、この長いスレッドをすべて読む必要はありませんが、代わりにイベントへのリンクを表示してください。

@khellang

たぶん@benaadamsは知っています。
彼には、コアの外部では機能しないものを含むいくつかのプルリクエスト(おそらくすでにマージされていますか?)があったと確信しています。

@khellangこの問題を引き起こしたPRとブログ投稿のステートメントは、まったく一貫性がありません。

事実が実際にブログ投稿に記載されているとおりである場合(直前の認識、一時的な変更)、なぜこの変更の一部として#if NET46コードのロードが削除されたのでしょうか。

この変更の一環として、 #if NET46コードのロードが削除されたのはなぜですか?

@willdeanええ、それは良い点です。 ターゲットフレームワークを変更するだけで、暗黙の定義がなくなるだけで、(コンパイルされたバイナリからの)コードもなくなります。¯\ _(ツ)_/¯

それまでの間、公式の公式を探している人にとっては、 @ migueldeicazaは、.Net Standard 2(したがってNetFx)上のASP.NET Core 2が公式の計画であることをRegisterで確認したようです: https ://www.theregister.co

.NET Frameworkとの互換性を維持するための妥協点についてはどうですか?それはASP.NET Coreを抑制しますか、それともそのパフォーマンスを低下させますか?

その答えは、条件付きコードを使用して「パフォーマンスを革新し、追求することです」とdeIcaza氏は言います。 最小公分母をターゲットにしながら、さまざまなことができます。 いつでも新しいものを照らすことができます。」 これは、PCで、アプリケーションが古いハードウェアで実行しながら、最新のCPUまたはGPUの革新をサポートする方法に似ています。 「CPUに新しい機能がある場合はそれらを使用しましょう。そうでない場合は古いコードにフォールバックします。」

以前のコメントを明確にするために、失われたように見えるので、Angular 2について言及したのは、前のコメントがAngular 2について言及したからであり、それが素晴らしいアナロジーだと思ったからではありません。

とは言うものの、AngularチームがAngularJSの構築から学んだことを取り入れ、ES2016とTypeScriptの形で利用できる新しいテクノロジーに適用し、古い、遅い、リッチなブラウザとモバイルエクスペリエンスを構築するために指数関数的に優れた何かを構築するための不格好でCPUを集中的に使用するコード。 彼らはヒットしました、そしてAngularはそれに適しています。

完全な.NETFrameworkは、その上にWebアプリケーションを構築するのに最適なものではありません。 決してそうなることはありません。 クラウドネイティブで、パフォーマンスが高く、コストに敏感な分散型サービスの世界には適合しません。 それが.NETCoreが構築されている世界であり、常に変化しています。 ASP.NET Coreは、 TechEmpower Round 14で10位から15位に下がりました。これは、過去数か月で新しいことが起こったためです。 いいえ、ベンチマークがすべてではありませんが、ベンチマークは重要であり、競争力を持つことが重要です。

ですから、皆さん、この死刑執行の滞在を賢く使ってください。 .NET Core 2.0、NetStandard2、および既存の.NETパッケージとの互換性の向上(そして、できればより実際のnetstandardパッケージのリリース)が、完全な.NETからCoreに移行できることを意味する場合は、それを実行してください。 しかし、数百万行のレガシーコードがまだオプションではないことを意味する場合は、おそらくそれはASP.NET4.7にとどまるようにあなたに言っているのかもしれません。

@tbprince

このスレッドで問題がUTF8文字列を持っているかどうかではなく、正直なところ、これらのテクノロジーに依存している人々がいることを教えてくれなかったとしたら...

洞察に満ちた投稿をありがとう。 特に上記の行は私見非常に洞察力があります。

@willdean Asp.Net Coreがターゲットとする場合、適切なnetstandard2xプラットフォームにあるものになると予想される可能性があります。

@FransBouma

少し皮肉に見えます。 私はそれを受け入れます。 しかし、私はとてつもなく真剣でした。

@stefanolson @alexwiese @ yaakov-h余談ですが、XAMLStandard1.0はビルドhttps://github.com/microsoft/xaml-standardで発表されました。

@markrendleはマークを愛していますが、ここで全体像を見逃しています。 TechEmpowerベンチマークは、物事の壮大な計画では些細なことであり、私は、彼の一日の仕事のかなりの部分をパフォーマンスを最適化するNETFXコードに費やしている人として言っています。 ASP.NET Coreチームは、進捗状況を他の競合するテクノロジの進捗状況と比較する手段としてそれらを気にする可能性があり、Node.JSなどの他のプラットフォームから離れた.NET Coreに、しかし責任のある開発者に、ネットの新しい人々を引き付けることに影響を与える可能性があります。現在IISとWindowsで実行されている累積ビジネス価値で数千億ドルを生み出すことは、聖杯ではなく、単なる優れた機能です。

その上、.NETはすでにクラウドネイティブです。つまり、大規模な分散アプリケーションを実行しており(1日あたり数億のリクエスト)、DockerやLinuxを使用する必要はありませんでした。 このスレッドには、私が思うよりもさらに大規模なことをした人がいます。 パフォーマンスの向上(編集:および展開エクスペリエンスの向上)の観点から.NET Coreが提供するものを望まないという意味ではありませんが、今日、その規模に達することを技術的に妨げるものは何もないということを意味します。

1日に数億ドルを動かす金融アプリケーション、患者に治療を提供するヘルスケアアプリケーション、エネルギーの生産と消費を管理するサービス、および輸送システム全体のリアルタイムの安全監視を構築するASP.NET/NETFX開発者に伝えてみてください彼らの「レガシー」コードを捨てて最初からやり直す世界。 これらの開発者は、ASP.NETチームが最初に採用される理由です。彼らは、MSDNライセンス、大規模なAzureエンタープライズ契約、巨大なOfficeサブスクリプション、および作成、開発、保守に資金を提供する大規模なSQLServer展開を購入します。そもそもこれらのツールの

これらの人々がスレッドで言っていることは、「私は、この規模の変更を私の経営陣にほとんど利益をもたらさずに売ることはできません」ということです。 1秒あたりのリクエスト数のスループットが10倍向上することは、ビジネスアクティビティの停止と比較して、適切なトレードオフではありません。特に、2つのテクノロジーのギャップが現在のようになっているため、プラットフォームを急激に再構築する必要があります。 @NickCraverは、このスレッドのSOについて、その問題を詳細に綴るのに優れた仕事をしました。 プラットフォームの移行は、経済的であるために、ビジネスの継続企業の前提と並行して実行する必要があります。 これらの開発者はラッダイトやバカではありません。 彼らは給料を支払うビジネスの現実に制約されており、ソフトウェアを使用する顧客は、そのビジネスと顧客に多大な利益をもたらすことなく、ソフトウェアのプラットフォームを変更するために数か月または数年の休暇を取ることを容認しません。

ここには明らかに2つの陣営があります。.NETの過去に制約されないグリーンフィールドの未来を望んでいる人々と、それを実現したいが、現在は経済的に実現可能ではないことを認識している人々です。 後者のグループはすでに議論に勝っています。当然のことながら、後者のグループは.NETプラットフォームの最大の消費者を構成するユーザーだからです。 新しいテクノロジーをすぐに採用できる独立したオペレーターである人々は、私たちと同じ船に閉じ込められるでしょうが、それは、Visual Studio、Code、MSFTなどの優れたOSSツールの無料版と引き換えに支払う代償です。 al。

エンタープライズ/NETFXユーザーが、より良いベンチマークの名の下に、ある種の技術的な純粋さに屈することは、実行不可能な要求です。 MSFTが勇敢なことを行い、NETCoreと並行してNETFXをより良くすることは、顧客がこのスレッドで要求していることだからです。

.NETは大きなテントであり、Microsoftが.NETCoreと.NETStandardを使用してそれを大きくするために行っている努力に感心します。その努力は、コミュニティから称賛され、支持されるべきです。 しかし、そうは言っても、NETFX(およびそのユーザー)での15年以上の採用を、急いで放棄して忘れるべきある種の不便な遺産として無視することは、せいぜい耳障りです。 運命が最終的に2つのプラットフォームを分岐させることである場合は、これらの開発者と協力して、クリーンで段階的な移行パスを提供することをお勧めします。 ASP.NET Core / .NET Coreが、.NETとはまったく関係のないまったく異なるものとしてブランド化されていれば最高だったかもしれませんが、その鐘を鳴らすことはできず、今は戻ることはできません。 それまでの間、マイクロソフトをサポートし、彼らにも説明責任を負わせましょう。

@markrendle

完全な.NETFrameworkは、その上にWebアプリケーションを構築するのに最適なものではありません。 決してそうなることはありません。 クラウドネイティブで、パフォーマンスが高く、コストに敏感な分散型サービスの世界には適合しません。 それが.NETCoreが構築されている世界であり、常に変化しています。 ASP.NET Coreは、TechEmpower Round 14で10位から15位に下がりました。これは、過去数か月で新しいことが起こったためです。 いいえ、ベンチマークがすべてではありませんが、ベンチマークは重要であり、競争力を持つことが重要です。

ですから、皆さん、この死刑執行の滞在を賢く使ってください。 .NET Core 2.0、NetStandard2、および既存の.NETパッケージとの互換性の向上(そしてできればより実際のnetstandardパッケージのリリース)が、完全な.NETからCoreに移行できることを意味する場合は、それを実行してください。 しかし、数百万行のレガシーコードがまだオプションではないことを意味する場合は、おそらくそれはASP.NET4.7にとどまるようにあなたに言っているのかもしれません。

鈍感になり、他の人に将来の努力をどこに捧げるべきかを指示することは控えてください。あなたは、どれだけの時間、努力、献身、生計が危機に瀕しているのかわかりません。誰もが自分のユースケースをあなたよりもよく知っており、どこに捧げるべきかを知っています。彼らの将来の努力は、ロードマップがより明確になったときに、彼ら自身の個々のユースケースに基づいて、彼ら自身の情報に基づいた決定を下します。

ASP.NETチームの公式スポークスパーソンは、準備が整ったときに独自の公式発表とコミットメントを行います。選択したプラットフォームの将来の方向性が明確になった後、誰もが自分で何をすべきかを決めることができます。お気に入り。

あなたは単一のベンチマークを見て毒殺されており、それは信頼を破壊し、不確実性を生み出し、既存のユーザーベースのほとんどを放棄し、15年間の賢明な言語とプラットフォームの進化を正当化するものだと考えています。 時間がかかる場合があり、別のアーキテクチャが必要になる場合がありますが、互換性を維持しながらパフォーマンスを達成できます。 最大のパフォーマンスは他のすべてを犠牲にするだけではありませんが、最速のフレームワークのほとんどは不明であり、上位3つのフレームワークはC / C ++で記述されています。可能な限り最速のパフォーマンスが必要な場合は、C /C++で帝国を構築してください。トップスポットに到達することはありません。 Kestrelは、リバースプロキシの背後で実行することをお勧めします。これにより、わずかなマイクロの改善に関係なく、影が薄くなります。そのため、問題となる主なことは、より早く自慢できる権利を取得することです。 私たちは皆、より高速なパフォーマンスを望んでいますが、価値を創造し、ソリューションを提供したいと考えています-プラットフォームは、ほとんどのフレームワークと同様に、目的を達成するための手段であり、プラットフォーム自体。

前進するための最善の道は、ASP.NETチームが私たちのために用意している計画をすべて受け入れ、プラットフォームを前進させるために私たち自身の努力をすることです。

特に私のアプリケーションはActiveDirectoryに依存しているため、これについて多くの懸念があります。 ActiveDirectoryアクセス用の.NETCoreソリューションが現在存在するか、または存在するかどうかはわかりません。

@twilliamsgsnetxActiveDirectoryが登場します。 さらに上の最初の100件のコメントにはいくつかの良い投稿があります。

@hallatoreええ私はスコットの投稿を読んでいました。 良いこと...マイクロソフトがマイクロソフト製品の解決策を提供しない何かを追求することはあまり意味がありません。 ふふ。

ありがとう! :+1:

@hallatore最近リリースされたプレビューでActiveDirectoryサポートが利用可能かどうか知っていますか? それとも、夏のいつかはまだ予定されていますか? AD統合を必要とするグリーンフィールドプロジェクトがあり、本当にCoreを使用したいと思います。

@ adam3039 、.NET Frameworkの上に座っている場合は、現在Core1.xでADを使用できます。 System.DirectoryServicesは、おそらく次の.NET Core2.xプレビューで提供されるようです。

@snickler説明ありがとうございます! .NET Framework上に新しいコアアプリケーションを作成するときに、AzureAD認証オプションのみが表示されました。 さらに調査します!

ベンチマークのポイントは、生の速度ではなく、同じハードウェアではるかに優れたパフォーマンスとスケーラビリティを提供する機能です。 これは、はるかに少ないハードウェアを使用して現在と同等のパフォーマンスを提供することを意味し、ビジネス価値の提供に直接関係します。 これは、現在のハードウェアセットアップまたはクラウドコミットメントの10分の1でシステムを実行できることを意味します。 さらに、.NET Coreは最新のパターンとプラクティスをサポートしているため、開発者はより効果的に作業し、反復と革新をより迅速に行い、ビジネスにより多くのより優れたソリューションを提供することを推進できます。

また、ここで問題になっているほとんどのシステムでは、堅牢で堅牢なサービス指向アーキテクチャまたはマイクロサービスアーキテクチャへの適切に計画された移行を、一度に1つのモノリスで行うことをお勧めします。 いくつかのファイルまたはコード行を新しいプロジェクトにコピーして貼り付けるだけで、それを実行できるパスがあるのは素晴らしいことです。 以前は、COBOLから4GLなどにすべてを書き直す必要がありました。そのため、世界中でCOBOLがまだ非常に多く実行されています。

そして、最悪のシナリオが、あなたが本当に完全なWindows ASP.NETとIISで立ち往生しているということであるなら、それは起こり得る最悪の事態からはほど遠いです。 あなたはまだ来ているすべてのクールなC#のものを手に入れるつもりです、そして.NET Coreに入るこれらのものは最終的にあなたに届きます、それはほんの少し長くかかるでしょう。

@mythz私が人々にすべきことを提案していたのは、まさにあなたが彼らがすべきだと言ったことだったと確信しています。

@markrendle

ベンチマークのポイントは、生の速度ではなく、同じハードウェアではるかに優れたパフォーマンスとスケーラビリティを提供する機能です。 これは、はるかに少ないハードウェアを使用して現在と同等のパフォーマンスを提供することを意味し、ビジネス価値の提供に直接関係します。 これは、現在のハードウェアセットアップまたはクラウドコミットメントの10分の1でシステムを実行できることを意味します。 さらに、.NET Coreは最新のパターンとプラクティスをサポートしているため、開発者はより効果的に作業し、反復と革新をより迅速に行い、ビジネスにより多くのより優れたソリューションを提供することを推進できます。

これらは、.NET Coreがすでに実行し、すでに優れたパフォーマンスを提供しているパフォーマンスに焦点を当てる理由です。.NETCoreが最速のCより4.2倍高速になるため、どこから10倍優れた使用率を引き出すのかわかりません。フレームワークが利用可能であり、トップラインの数値を増やしても、実際のワークロードに対応できるようになるとすぐにこれらの数値が無視されるため、大きな違いはありません。 ビジネス価値を提供することが重要であり、.NET Coreに移行できない組織にとっては、パフォーマンスの数値を高速化することは重要ではなく、.NET Coreは、より小さなエコシステム、知識のプール、不確実性、不安定性、貧弱さの恩恵を受けないことに同意します。互換性など

最も価値のあるインターネットプロパティは、最速のフレームワークを使用していない動的言語で構築されました。さらに重要なのは、豊かで活気に満ちた、生産的で安定したエコシステムです。 彼らにとって、スケーラビリティは生のパフォーマンスよりも重要であり、最も遅いフレームワークでさえ、生のパフォーマンスよりも重要である優れたキャッシング戦略で高速化することができます。

また、ここで問題になっているほとんどのシステムでは、堅牢で堅牢なサービス指向アーキテクチャまたはマイクロサービスアーキテクチャへの適切に計画された移行を、一度に1つのモノリスで行うことをお勧めします。

それで、以前は最大のパフォーマンスが何よりも重要でしたが、今では、動作中のシステムをリファクタリングしてより多くのネットワークホップを導入することをお勧めしますか? マイクロサービスアーキテクチャは、すべてのユースケースですべてのシステムを魔法のように改善できるフェアリーダストテクノロジーではありません。 @ NickCraverは、StackOverflowに意味がない理由、Basecampや他の多くの著名な業界リーダーにも意味がない理由をすでに説明しています。最初にモノリスを使用するか、システムをモジュール化することで、より少ないトレードオフでより多くのメリットを得ることができることをお勧めします。 ほとんどの場合、作業システムのリファクタリングと書き換えは、顧客の価値を提供しないリソースの不適切な使用である重大な罪であるため、グリーンフィールドプロジェクトではより理にかなっています。

@mythz私が人々にすべきことを提案していたのは、まさにあなたが彼らがすべきだと言ったことだったと確信しています。

そうではなく、あなたはそれを知っています。

FYI .NETStandard2.0および.NETCore2.0は、 https: //channel9.msdn.comでライブアドレス指定されました-11:54:00から開始。 ビデオへの直接リンクもあります。

すべての懸念が公式に緩和されたようです。

スコットハンター:

計画では、プレビュー2でASP.NETCore2.0を.NETFrameworkで動作させる予定です。

Githubは.NETが何であるかについて権限がありません。ブログ(.NETブログまたはASP.NETブログ)は、チームがツールで行っていることに対して実際にメッセージを送信する場所であり、ツールを移動します。等々。

WinForms、WPFはWindowsの機能であり、.NET Coreは.NETのクロスプラットフォームフレーバーであることが意図されているため、Windowsのみの主義を.NETCoreに移行するつもりはありません...私が顧客に伝えたいこと。 NET Frameworkはどこにも行きません。私たちは、.NET Frameworkを永久にサポートする予定です。したがって、古いコードをすべて取得して.NETCoreに移動する必要があると感じてはいけません。 .NET Coreに移行する理由は、クロスプラットフォームが必要なため、または完全にサイドバイサイドにしたいためです。

.NET Coreは、Windowsの一部ではなく、サイドバイサイドをサポートしていないため、.NET Frameworkよりも高速に移動できます。そのため、すべてのユーザーがアプリを.NETFrameworkから.NETに完全に移動する必要があるとは言えません。コア、WinForms、WPF、またはWCFを実行している場合、これらは.NET Frameworkで実行するのに最適なワークロードであり、これらを永久にサポートします。 移動する必要があるとは思わないでください。クロスプラットフォームが必要なため、または完全に並べて移動する必要があるため、移動する必要があります。

彼らは上記のチャンネル9ストリームでこれに答えました:

  • ASP.NET Core 2.0は、netstandard2.0アセンブリを使用することも、netstandard2.0準拠のプラットフォームで実行することもできます。
  • ASP.NET Core 2.0は、.NETFrameworkで実行できます。

このスレッドの他のMS開発者による上記のステートメントにもかかわらず、それはかなり明確に聞こえます。

みんな素晴らしい議論。

ここでの私の2セントは、ASP.NET Coreが、開発者の間で.NETCoreの使用を促進するMicrosoftの最大のライブラリであるということです。

彼らは互換性をサポートするために.NETStandardを大量に作成し、.NETのさまざまなフレーバー全体でライブラリを使用するため、asp.netコアのNETSTANDARD2.0をターゲットにして、どこでも使用できるようにする必要があります。 XamarinアプリまたはWPFアプリ内で使用して、組み込みWebサーバーシナリオをサポートします。 そのため、ASP.NET Coreはゼロから切り離されています(ホスティング、サーバーなど)。

彼らが探しているのは、.NET Coreはどこでも実行できるため、他の種類の.NETをサポートする必要はなく、ASP.NET Coreの将来の厳しいAPI要件をサポートし、ASPを結び付けるために、急速に変化する新しいものに進むだけです。 .NETCoreと.NETCore。

.NETCoreでASP.NETCoreを成長させ続けるために、どのような超高度なAPIが必要かは正確にはわかりませんが、おそらくそれは別の話です。 重要なのは、ASP.NET Coreは単なる別のライブラリであり、その状態を維持する必要があるということです。

完全な.NETFrameworkはまだ成熟したものであり、バトルテストが行​​われています。 多くの企業顧客(私を含む)がそれを使用しており、.NETFrameworkでASP.NETCoreを使い続けたいと考えています。

ありがとう

FYI .NETStandard2.0および.NETCore2.0は、 https: //channel9.msdn.comでライブで対処されました...すべての懸念が公式に緩和されたようです

MS内の政治は一般的に残忍であることを知っているので、ビデオのかなり疑わしい修正主義は、バスの下でこのスレッドへの以前の貢献者を公に投げることを避けるための努力だと思います。 私は企業の不正を称賛する傾向はありませんが、おそらくこの場合、それは実際にはより大きな利益のためです。

以前のミーム「次へ、オセアニア!」を借りる

@markrendle

そして、最悪のシナリオが、あなたが本当に完全なWindows ASP.NETとIISで立ち往生しているということであるなら、それは起こり得る最悪の事態からはほど遠いです。 あなたはまだ来ているすべてのクールなC#のものを手に入れるつもりです、そして.NET Coreに入るこれらのものは最終的にあなたに届きます、それはほんの少し長くかかるでしょう。<

それがこのスレッドの要点の1つです。 追いつくのに6か月から1年かかるとしても、asp.netコアが.netフレームワークで実行できれば、私たちのほとんどは非常に満足するでしょう。 しかし、私が得た印象は、aspチームが完全に分離し、.netFrameworkで実行できるように戻ることは決してないということです。 長期的な開発と管理の計画を立てる責任をクライアントに負っている私たちにとって、将来の計画が明確になっていないことが非常に困難です。

@mythzそうだった。

前進するための最善の道は、ASP.NETチームが私たちのために用意している計画をすべて受け入れ、プラットフォームを前進させるために私たち自身の努力をすることです。

@stefanolsonあなたは私を誤解しました、私は明らかに十分に明確ではありませんでした。 何らかの理由で.NETCoreで実行されているASP.NETCoreが、コードを実行できるレベルに到達せず(C ++ / CLIなど)、コードを書き直したり、アーキテクチャをリファクタリングしたりできない場合は、ClassicASPを使用してください。 .NET MVC/WebAPIまたはWebForms。

(ちなみに、私たちはついにWebFormsのカーファッフルから移行したことに気づきました。それらの人たちはちょうどそれを続けています。)

@markrendleそれは明らかに言及されていたものではありません

@markrendle WebFormsからMVCは、まったく別の魚のやかんでした。 UIレイヤーを変更するだけでした。 同じバックエンドコードを使用して、ドキュメントの生成などを行うこともできます。 ですから、まったく問題ありませんでした。 ここで説明しているのは、UIコードだけでなく、すべてのコードとの互換性を完全に壊していることです。実際、UIコードはおそらく最も移植性の高い部分です。

@stefanolsonたぶんあなたとあなたのコードにとって、WebFormsからMVCへの移行は簡単でしたが、多くの人にとっては、完全な.NETからCoreへの移行と同じくらい乗り越えられませんでした。 そして、私の主張は今も変わりません。コードをASP.NET Coreに移行できない場合は、移行しないでください。

@stefanolson @markrendleは、現在WebForms-> MVC5への移行の途中ですが、これはMVC / MVC2には乗り越えられませんでしたが、MVC5では乗り越えられませんでした。 ASP .NET Core 3以降の方が移行が簡単な場合もありますが、同様の状況にある可能性があります。

ただし、WebForms Coolaid HARDを飲んだ人は、基本的に移行中に失敗しました。 ViewStateの泥沼をハードダウンしなかったので、私たちは救われました。 フレームワーク->コア移行にとって重要なのは、信頼性が高く、明確で、文書化された移行計画を立てることだと思います。

これに関連して生じた不確実性が問題です。近い将来、.NET標準に記述されたコードが移植可能であり、無駄な努力がなくても、古いプロジェクトが新しいコードを記述して移行プロセスを開始するのに役立つことが明確に区別されている場合です。 NETStandardとそれにライブラリを移動します。

その目標が変更される可能性がある場合、それは素晴らしいことではありません。それは、あなたが行うことはプロジェクトの棺桶に釘付けになる可能性があることを意味します。

パラダイムの変化と同様に、正しいパラダイムを使用していない人々は進んでいます
苦労する。

HttpContext.Currentを使用しないように多くの人に警告しました...まだ...それは
今日も書かれています。 これらのアプリは、
コンテキスト値に応じて、大量のコードが含まれます。

WebFormscoolaidでも同じ問題が発生しました。 イベント、UpdatePanels、
など...ASMXを使用してjQueryでAJAXを実行することもできます。 大変でしたが
それはそれを行うための「正しい」方法でした。 これらの種類のアプリからのスワッピングは
MVCが登場したときは簡単になりました。

同じことが今起こっています。 パターンは変化していて、何ですか
「グッドプラクティス」と見なされるものも進化しました。 で書かれたすべてのコード
古い方法(穀物に対して)は、前に完全に再考する必要があります
前進します。

何であるかを知る以外に簡単な移行計画はないと思います
「穀物に対して」そしてそれを修正する方法。 移植されていないAPIは含まれていません
もちろんあります。 それはまったく別の問題です。

2017年5月12日金曜日午後3時29分[email protected]
書きました:

@stefanolson https://github.com/stefanolson @markrendle
WebFormsの途中でhttps://github.com/markrendle->MVC5
現在の移行では、これはMVC / MVC2には乗り越えられませんでしたが、MVC5では乗り越えられませんでした。
ASP .NETCore3以降が
より簡単な移行。

しかし、WebFormscoolaidHARDを飲んだ人は基本的に失敗しました
移行中。 私たちはハードダウンしなかったので救われました
ViewStateの泥沼。 フレームワーク->コアにとって何が重要になると思います
移行とは、信頼性が高く、明確で、文書化された移行計画を立てることです。

これの周りに生じた不確実性は、それが
.NETに書き込まれる予見可能な将来のコードの明確な区別
標準は移植可能であり、無駄な努力は古いプロジェクトに役立ちません
.NET Standardで新しいコードを記述して移行プロセスを開始し、
ライブラリをそこに移動します。

その目標が変更される可能性がある場合、それは素晴らしいことではなく、それは何かを意味します
プロジェクトの棺桶に釘付けになる可能性があります。そうしないと、Pythonに固執することになります。
2.x .NETFramework4.xは長い間使用されていました。


あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/Home/issues/2022#issuecomment-301165679 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAMx6CoEdzs_Ys5a8W7Ri7lwfBqcIGUdks5r5LMIgaJpZM4NReOn

うわー、このスレッドはジェットコースターの旅でした。

  1. マイクロソフトがgithubの.netコミュニティを聞いているので安心しました
  2. この議論が情熱的でありながら、ほぼ完全に専門的であったことに驚きと喜びを感じています。
  3. 私はついに.net標準が何を意味するのかを理解したと思います(!!)

編集:実際には問題ではないものについての暴言を削除しました。 最後に投稿の最後まで読んでください-ビデオはすべての心配を片付けました。

@poter134ええと。 スレッドを読みましたか? わかったよ; 長いですが、それでも...すべてが解決されました。 それは事故でした。 ASP.NET Coreの次のプレビュー(および最終バージョン)は、.NETStandardをサポートします。これも.NETFrameworkを意味します。

@PinpointTownesたぶん、問題を閉じて、結論が出たという通知を(上部に)追加する必要がありますか?

ロックして共同編集者に制限することもお勧めします。 私はすべてが言われたと思います。

謝罪-ビデオに取り掛かった! それは安心です。 おそらく、75%を読んで絶望している私のような人々にとっては、一番上の要約が最適でしょう。

たぶん、この問題を参照し、 https://channel9.msdn.com/Events/Build/2017/C9L18を明確にするビルドビデオにリンクしてください

@PinpointTownesたぶん、問題を閉じて、結論が出たという通知を(上部に)追加する必要がありますか?

完了:+1:

@PinpointTownes 、私たちコミュニティは私たちの側のコミュニケーションもきれいにする必要がありますが、それは簡単ではありません。 問題やコメントなどがGitHubに投稿される割合が非常に高いため、小規模なaspnetチームがすべてを処理および追跡することは困難です。 私たちと.netコアの背後にいる人々との間のこの数の非対称性は、asp.netコミュニティのスタンドアップでよく表されています。これは、彼らから私たちへのほぼ一方向の流れです。 おそらく、一部のコミュニティメンバーと.Netチームの間に、スカイプ会議やスタンドアップで提案などが転送される追加のレイヤーを含めることを考えることができます。 それを実装するのは難しいと思いますが、コミュニティが非常に大きいため、おそらく検討すべき方向です。

@ponant :それは私たちが以前持っていたものと同等です。つまり、あなたは誰かに報告し、その人がそれを渡すことを望んでいます。 いいえ、コミュニティは問題をそのまま投稿できる必要があります。そうすれば、チームは続行したい問題を選択できます。 それが多くの作業である場合、彼ら(コミュニティではなく)は、たとえばgithubの問題よりも優れたツールの使用を検討することによって(コミュニティではなく)それを処理できることを確認する必要があります(理想的ではないため:物事がどのように機能するか、または物事がなぜ機能しないかに関する一連の質問作業は一連のバグレポートと混合されます)、質問と彼らが取り組む必要のある問題を取り除くためのレイヤーを追加します。 コミュニティがどの問題が取り上げられているかを確認し、他の人の問題についてもフィードバックを提供できるため、最も透過的なIMHOです。 それがブラックボックスに渡された場合、私たちはそれを制御することはできません。

PR、貢献、バグ修正もできることを忘れないでください。 今すぐリポジトリを見つける場所を明確に知ってください😉

@FransBouma 、私は透明性に関してあなたに同意します、そして私はレイヤーを追加することは一般的に悪い考えであることを認めます。 ただし、GitHubに情報をダンプして、別の方向に進むと文句を言うことができないため、チームが外部からの情報に圧倒された場合は、チームを理解する必要があります。 GitHubよりも優れたツールが歓迎され、GitHubと連携して機能し、ユーザーの声よりも最新のツールになります。

なぜあなたはMSの人がレッスンを決して学ばなかったのですか? WP 7.xから8で発生するのと同じように、すべてを中断する更新は、.NETCoreの評判と市場を破壊します。

ASP.NET4からASP.NETCoreへの移行は、困難で長期的な苦痛を伴う進歩です。それ以上難しくしないでください。

彼らは、MSDNライセンス、大規模なAzureエンタープライズ契約、巨大なOfficeサブスクリプション、およびこれらのツールの作成、開発、および保守に資金を提供する大規模なSQLServer展開を購入します。

つまり、これは一流の乗客が経済の改善を妨げているようなものです。 わかった。

@markrendle Microsoftは現在、週に20億ドル以上の収益を上げています。 彼らはエンジニアリングプロジェクトを管理するためのより良い仕事をする余裕があります。

毎日4億ドルで、.NETチーム全体が伝説的なくだらないNuGetを使用して、TechTomatoという名前の会社にアウトソーシングしているベルギーの過負荷のサーバーからデイリービルドをプルする以上のことを期待しています。 現在、78kDLLをインストールするには200MBのメタデータが必要です。 https://github.com/NuGet/Home/issues/4448

おそらくそれはMicrosoftがGitHubの使用を選択する方法ですが、エンドユーザーのコミュニケーションはひどく、チーム間のコミュニケーションは、コミュニティの十分な注目を集める前に、バグレポートを時期尚早に閉じて問題を分割する競争に変わります。

しかし、Microsoftが上位のUserVoiceリクエストを無視し、作業が面白くないと思われるものすべてに「バックログ」のタグが付けられた場合、オープンで物事を行う意味は何でしょうか。 ええ、あなたは忙しいです、私たちはそれを理解します。 あなたは前に忙しかった。 今、あなたは忙しいだけでなく、公共のコミュニティ旅団との取引にも忙しい。

運営が不十分な1990年代のWebフォーラムと同様に、ストレスのたまった管理者は予想どおりに反応します。 コメントは不思議なことに古いスレッドから消えます。 そして、上級管理職は、コミュニティの怒りを抑えることを約束しますが、それを実現しません。

https://github.com/dotnet/cli/issues/5328
https://github.com/dotnet/corefx/issues/17522

マイクロソフトの従業員の中にはGitHubを採用している人もいれば、必要な時間は管理できないと判断した人もいれば、投票を投稿してTwitterアカウントを宣伝する以外に何もしないGitHub中毒者になり、ファクトリメソッドに名前を付けるのに最適な方法を「コミュニティ」に尋ねたり、提供したりする人もいます。 Logitechマウススクロールホイールの絶賛。

そのため、1992年以来のように、社内の連絡先にメールを送信して問題を修正します。最初の返信では、必然的に、このGitHubのものが完全に軌道に乗っていないことに言及しています。

マウスホイールについて私を信じていなかった@PureKromeのために編集してください。

Mouse Wheels is the new Mouse Balls

ちなみに、ハンゼルマンが決定を擁護するこのスレッドに現れたとき、私はそれが逆転することを知っていました。 マイクロソフトが何をしているのか知りたい場合は、彼のブログを読んでから、テクノロジーが正反対の方向に進むまで6か月待ちます。

参考:2.0.0-preview2および.NETFrameworkに関する情報。 https://github.com/aspnet/Announcements/issues/243

@chadwackerman実際、彼らが.NETの開発に20億ドルを費やすことはないと思います。 その一部は、トイレットペーパー、カフェイン飲料、Azureデータセンターなど、ばかげているが不可欠なものに使われている可能性があります。

@oldrev

なぜあなたはMSの人がレッスンを決して学ばなかったのですか? WP 7.xから8で発生するのと同じように、すべてを中断する更新は、.NETCoreの評判と市場を破壊します。

多分彼らはしました。 そうでなければ、さらに多くの重大な変更があったでしょう。

ASP.NET4からASP.NETCoreへの移行は、困難で長期的な苦痛を伴う進歩です。それ以上難しくしないでください。

私は、進歩が困難で、苦痛であり、しばらく時間がかかることに完全に同意します。MSの人々もそれを認識していると確信しています(進歩を容易にするかどうかは別の話です)

少し前に戻って、私のチームはASP.netからASP.NETコア以外のものに切り替える可能性を評価しましたが、MS techに非常に多くの依存関係があるため、決定は簡単です。 結局のところ、私たちは現実を受け入れる必要があります。

MSが自分の過ちを繰り返し、 Microsoft.Data.Sqliteリポジトリhttps://github.com/aspnet/Microsoft.Data.Sqlite/pull/370で完全な.NETのサポートを終了しようとしています

コミュニティとの話し合いも発表もありません。

@alexvaluyskiy何をしているのかわからない。 彼らはnet451netstandard2.0に置き換えているので、.NETサポートを削除していません。 netstandard2.0は.NET4.6.1でサポートされています。

@MartinJohns TFSのすべての変更は大きな重大な変更であり、最初に発表して議論する必要があると思います。
.NET 4.5.2は引き続きMSでサポートされており、その上でMicrosoft.Data.Sqliteを実行できます。 MSがサポートを終了し、ユーザーにnet4.6.1またはnetstandard2.0への更新を強制するのはなぜですか?

.NETバージョンを更新することは合理的な期待であるためです。 これにより、.NET Standard 2.0のみをサポートする必要があり、複数のターゲットランタイムをサポートする必要がないため、メンテナンスコストが削減されます。 彼らが.NETを削除しているわけではありません-彼らはまだそれをサポートしていますが、ただより新しいバージョンです。

マイクロソフトが.NET1.0までのすべてのパッケージをサポートする必要があることを意味していますか?

あるバージョンでは、スタッフはnetstandardに収束する必要があります

@irwissそのコメントはあまり役に立ちません。 彼は、パッケージが.NET1.0までサポートされるべきだとはどこにも示唆していませんでした。 しかし、彼は「まだサポートされている」と述べました。それは正しいです。 .NET 4.5.2は、2017年5月3日の時点でまだ公式にサポートされているバージョンであり、有効期間の終了は予定されていません(https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework)。

サポートされている.NETバージョンをサポートすることは、大したことではありません。

@MartinJohnsどちらの当事者も正直に言うとそれほど役に立ちません-sqliteの問題への最初のリンクは誤った前提に基づいており、穴を(些細な4.5.2対4.6.1の議論に)再形成しようとしています少し余分に掘るのは良い考えではありませんでした。

何が起こっているのか本当にわかりません。 なぜこれとあれに多くのドットネットがあるのですか。 これは本当にクレイジーです。 これをどのように追跡しますか?

あるものから別のものへの移行に関する適切なドキュメントがありません。

最初にDLL-hellがあり、今ではPackage-hellがあります...さらに多くのことが変更されます....;)

このスレッドをロックする方法はありますか? これは、GitHubの問題ではなく、チャット形式に属しているようです。

@MaximRouiller昨日から、netcoreapp1.1からnetcoreapp2.0にアップグレードするためだけに、私が経験したことをあなただけが知っているなら。

私にとってそれをより簡単にすることができるリンクを知っているなら、それを私に紹介してください。

ありがとう

@smithaitufeそれはこの問題のちょっとオフトピックです。 代わりに新しい問題を開きます。

@PinpointTownes @Eilon

このスレッドをロックする方法はありますか? 何かにコメントする人は誰でも、新しいスレッドに属している可能性がある間、新しいアクティビティを通知するために100通以上の電子メールを送信します。

@MaximRouiller私はそれを経験しましたが、役に立ちませんでした。

たとえば、そのブログでこれを読みましたか?

*
全体として、このフレームワークの更新は、いくつかの重大な変更を除いて、比較的スムーズなアップグレードパスを提供します。

しかし、非常に苛立たしいことの1つは、SDK、ランタイム、ツール、およびそれらに組み込まれているすべての異なるバージョンの急増です。 特に、それらはすべてプレビューのさまざまな段階にあるため、それらが完全に整列していない場合は特にそうです。
*
うまくいかなかったという理由だけで、新しいプロジェクトを作成することにしました。

@Rutixありがとう。 私は道を見つけます

ここでの議論の一部によると、この問題が次のプレビュー2リリースで修正されていることを考えると、私はこの問題をロックしています。 ASP.NET Coreの変更または問題に関するその他の質問については、適切なリポジトリに新しい問題を提出してください。 どこにファイルするかわからない場合は、ホームリポジトリに問題を記録し、私(@Eilon)にタグを付けてください。適切な場所を見つけるお手伝いをします。

ありがとう!

このページは役に立ちましたか?
0 / 5 - 0 評価