Aspnetcore: Microsoft.AspNetCore.App3.0から削除されるアセンブリ

MVCパッケージも追加のNuGetパッケージになるはずだと思います。 MVCは素晴らしいですが、バニラASP.NET Coreとは異なり、すべての.NET言語のパラダイムに適合していることは言うまでもなく、実際にはすべての人のお茶ではないアプリケーションのレイアウト方法については非常に意見が分かれています。 共有ASP.NETCoreフレームワークは、MVCを使用しないか、MVCを使用しない2番目のバージョンを用意する価値があると本当に信じています。 どう思いますか？

メリットは何ですか？ これにより、ASP.NET Coreアプリケーションを構築する人々の生活がどのように改善されるでしょうか？

素晴らしい！ asp.netコアを使用するときに必要なものが必要です。

@davidfowl

メリットは何ですか？ これにより、ASP.NET Coreアプリケーションを構築する人々の生活がどのように改善されるでしょうか？

この号の冒頭に記載されているパッケージを含めないのと同じ理由で。 後でパッケージを削除するよりも、.NET Core3.0に付属するフレームワークにパッケージを追加する方が常に簡単だと思います。 最小公分母を追加して、バニラASP.NET Coreアプリを実行し、残りをNuGetパッケージとして提供してみませんか。 これが開発者にとって問題であることが判明した場合は、いつでも後で追加することができますが、後で簡単に削除することはできなくなります。

デフォルトでも役立つこととバランスをとる必要があるからです。

さて、バニラASP.NET Coreはすでに便利だと思います（そして、あなたもそう思うと思いましたが、そうでなければ、なぜそれを便利にしなかったのですか？）それなら気にしないでください;）

あなたが純粋主義者であるならば、それらが厳密に必要ではないので、あなたは箱の中にミドルウェアまたはMVCまたはSignalRのほとんどを持っていないでしょう。 デフォルトのセットがどうあるべきかとそうでないかとの間にこの線を引くことは、かなり直感的で曖昧なことです（経験に基づいて、過去と現在の他のプラットフォームを見て、電話をかけます）。 ASP.NET Core 3.0の時点では、それらを削除する予定はありません（少なくとも現時点では）。

ええ、これは常に難しい呼びかけであることを私は知っていますが、（マイクロソフトによる）必要以上に物事を膨らませる傾向の正当性が何であるかわからないことがあります。 自分の製品を市場に配置する方法は、それがどのように認識されるかです。 ASP.NET Coreは、新しい最新の構成可能で柔軟なWebフレームワークであると想定されていますが、すべてを配置する方法は、MVC + SignalR + Identity + EFをすべての人に強制しない限り、ASP.NETCoreは役に立たないということです。 私の意見では、線を引く場所についてはすでに電話をかけています。そのため、MVCとSignalRはASP.NET Coreに埋め込まれていませんが、必要に応じて追加できる個別のフレームワークです。なぜ今、これらの線をぼかすのですか？ 一貫性がなく、そこから得られる価値は考えられません。 ASP.NET Core +繁栄しているオープンソースのエコシステムを宣伝するだけでなく、非常に狭いWebエクスペリエンスを宣伝しています。 それがするのは、あなたが彼らが望まないかもしれない人々に物事を押し付けることになるので、わずかに異なって、あなた自身のためにより多くの仕事をしたい人々に欲求不満を作り出すことです。

デフォルトのフレームワークにMVCを詰め込まないと、人々がMVCを使用しないわけではありません。 単一のNuGetパッケージにすると、NuGetからMVCを取得する必要があると誰も文句を言うことはありません。 より多くの人々が来て、なぜあなたがデフォルトのフレームワークを私のように望まないもので肥大化させたのかと尋ねる可能性が高くなります。

これは議論であり、まだ皆さんが検討するかもしれないことだと思います。ですから、私が質問したいことが1つある場合は、おそらくもう一度この質問をチームに持ち込んで、全員が本当にこれに取り組んでいるかどうかを確認してください。あなたは私の考えに向かって和らげることができます:)

PS：それが当てはまるかどうかはわかりませんが、SignalRも別のNuGetパッケージであることを願っています。 これは、BootstrapとAngular2をデフォルトのフレームワークに含めるようなものです。 これらの2つの製品がマイクロソフトによって開発された場合、おそらくそれを行うでしょうが、それは意味がありません。サードパーティによって行われているという理由だけで、それがどのように意味をなさないかがわかります。

TBHデフォルトのインストールからもっと多くのものが削除されるのを見たいです。 特にMVC。 これが、ASP.NETCore上の代替フレームワークをさらに魅力的なものにしている理由です。 また、ContentResultのようなものがコアではなくMVCに存在するのはなぜだろうか。 これは紺碧の関数で多く使用されており、今では常にMVCのものを参照する必要があります-ContentResultのためだけに。

重要なのは、ASPNETSDKにMVCを含めることで実際に悪影響を与えるべきではないということです。 ほとんどの開発者はそれを使用するので、その方法で出荷することは、復元の負荷を膨らませることよりも優先されます。 あなたがそれを望まないならば、あなたはそれを使うことができないだけです。 上記のパッケージのほとんどは、サードパーティの依存関係（json）をもたらすか、重い側面（かみそり）を持っているか、概念的にASPNETから分離されており、SDK（EFCore）の外部で参照されることがよくあります。

OSSフレームワークの平等な競争の場を促進するために、デフォルトで最小値に設定することに同意する限り、それはバランスを取る必要があります。 コア（ベータ版、さらには1.0）の初期には、物事はいたるところにパッケージであり、それははるかに混乱し、復元には永遠に時間がかかりました。

@psib​​erneticは、個別のパッケージに

@psib​​erneticあなたはバランスを取ることが重要だと言っている2番目の人ですが、それはどういう意味ですか？ 何のバランス？ 極端なことについては話さないでください。それは明らかに良くないので、ここで現実的な提案について話しましょう。 MVCが単一のNuGetパッケージである場合、それはどのようにユーザビリティに影響しますか？ それは本当にそうではなく、それが私のポイントです。 反対の極値を実装することによって一方の極値を解決しようとしていると考えることは、狭い考え方です。 間にはたくさんあります。 フレームワークを肥大化させる必要はなく、MVCとSignalRを100個のパッケージにフラグメント化する必要もありません。 両方を同時に回避することができます。

MVCを単一のNuGetパッケージとして使用すると混乱する、復元に永遠に時間がかかる、またはあなたが言及した他の欠点があるという現実の事例を1つ挙げてください。

そして、復元時間について話します...

私見では、開発者のマシンで少し速くビルドするよりも、高速で起動するコンテナーまたはサーバーレスアーキテクチャを使用する方が重要です（これがビジネスに実際の影響を与えるためです）。 はい、後者も非常に重要であり、非常に高速にしたいのですが、重要度をランク付けする必要がある場合は、クラウドの本番インフラストラクチャよりも開発マシンに小さな打撃を与えます。 したがって、フットプリントをできるだけ小さく保つことは、復元時間を短縮することよりも（それ以上ではないにしても）重要です。

メリットは何ですか？ これにより、ASP.NET Coreアプリケーションを構築する人々の生活がどのように改善されるでしょうか？

Windows 10 PCにプリインストールされているCandyCrushのように、MVCを使用していない他のすべてのユーザーにとっては不要なブロートウェアだと思います。 Asp.netコアは、必要に応じてミドルウェアなどを完全に構成できるため、意見が少なくなっていると説きました。dotnetテンプレートを使用すると、MVCをコアに組み込む必要なしに、デフォルトの付属パッケージにすることができますか？

Nancy、ServiceStack、Giraffeのような他の多くのフレームワークがありますが、それらはすべてメリットがあり、不要な/不要なMVC強制インストールとの肥大化/競合があってはなりません。 認証、かみそり、EFなどがすべてパッケージ化されていることを考えると、一貫性がないように見えますが、MVC、ゴールデンチャイルドはコアではないときにコアフレームワークの一部になりますか？

MVCがコアに緊密に結合されているためにデカップリングが大量の作業になる場合、私はそれを得ることができますが、一般的に一部の開発者の生活を楽にすることに基づいて、怠惰で古いasp.netに非常によく似ていますMVCの考え方私たちが遠ざかっていることを望みました。

.NET Coreは、.NET用のnode.jsの無駄のないモジュラークローンであると想定されていましたが、繁栄し、活気に満ちたエコシステムを促進する特性を複製する意図はないようです。意見のあるWebフレームワークにバンドルされていないため、コアのメリットはすべて、独自の独立したコミュニティで多数の人気のあるフレームワークを楽しんでいる実験に熟しています。

つまり、ASP.NETチームは、可能な限り最高のフレームワークを構築していると信じていますが、選択されたすべての意見や、何かを成し遂げるために必要な複雑さのレベルに全員が同意するわけではありません。 .NET Coreのすべては、後知恵の恩恵を受けて開発されました。他のプラットフォームで成功するようになったアプローチに多くのインスピレーションを得て、使用するテクノロジーの意見を取り入れることで、.NETからの次のイノベーションを飢えさせています。次のものが他のプラットフォームで牽引力を集めるとき、ASP.NET Coreはその成功を再現するのに不利になります。これは、すべてのWebで開発モデルを使用することが期待されるデフォルトの「MVC税」を今後永久に支払うためです。アプリは無限に。

Nodeは軽量であるため、Electron、Native Mobile Apps、IOT、シェルスクリプトなど、他の多くのユースケースの開発にも適しています。つまり、デフォルトのインストールにWebフレームワークをバンドルしてもメリットはありません。 デフォルトのインストールが肥大化すればするほど、他のシナリオでの使用には役立たなくなります。

IMOのデフォルトは、機能の追加を容易にする（誰もが利用できる）ことに重点を置いた、無駄のないモジュラーコアを持つという.NET Coreの当初のビジョンに戻す必要があります。つまり、デフォルトでバンドルしてデフォルトを肥大化させることではありません。インストール。

フィードバックありがとうございます。 私はいくつかの考えを共有させてください。

1. アセンブリをトリミングしているわけではありません。 削除する各アセンブリは重大な変更であり、2.xから3.0へのアップグレードのコストが増加します。 これらは、Microsoft.AspNetCore.Appに何を入れるかを決定するために使用する基本原則です： //github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md。 削除を提案しているアセンブリには、共有フレームワークに含めるための基準の一部が欠落しています。 特に、これらのアセンブリは、（1）サービスを提供できないサードパーティのコードに依存している（2）アセンブリ自体が3.0で非推奨になっている、または（3）変更される可能性の高いプロトコルまたは認証メカニズムを実装している（たとえば、Facebook / Google / Twitterは明日、認証の動作方法を変更することを決定する可能性があります）

2. Microsoft.AspNetCore.AppからMVCを削除することは、私たちが検討することではありません。 すべてのユーザーがアプリケーションでMVCを参照しているわけではありませんが、これはASP.NETCoreの製品の中心的な部分であると考えています。 これはMicrosoft.AspNetCore.Appに保持する予定です。

3. MVCは2.1以降Microsoft.AspNetCore.Appの一部ですが、 2.1の「空のWeb」テンプレートに示されているように、MVCを使用する必要はありません。 共有フレームワークに存在することで、アプリケーションでの使用を強制されることはありません。 代替手段を使用したり、独自のビューフレームワークを作成したり、より「生の」aspnetcoreAPIを使用してHTTPリクエストとレスポンスを直接読み書きしたりすることもできます。

4. @dustinmoris ：後でパッケージを削除するよりも、.NET

   それがまさに私たちがやろうとしていることです。 削除するよりも追加する方が簡単です。 2.0ではあまりにも多くのものを追加しましたが、今後の予見可能な道のために維持可能な一連のものであると私たちが信じているものに再調整しています。 Microsoft.AspNetCore.Appから削除されたアセンブリのほとんどは、引き続きNuGetパッケージとして提供されます。 後で、すべての顧客の90％が同じパッケージを参照していることがわかった場合、それは共有フレームワークの良い候補です。 ただし、ガイダンスドキュメントに記載されて

5. 「バニラ」は主観的です。 多くのユーザーにとって、MVCとSignalRは「バニラ」です。

6. 何人かの人々は、.NETCoreがこれかそれか何か他のものであるはずだったと言いました。 状況は変化し、ユーザーフィードバックを収集し、製品がどのように使用されているかを観察し、最大数の顧客に利益をもたらすと思われるものに一致するようにデフォルトを調整しようとします。 この号で提案されている調整は、.NET Core2.xで受け取ったフィードバックを反映しています。

最終的な考え：この問題は皆を幸せにするつもりはありません。 フィードバックを無視しているように思われる場合は、お詫び申し上げます。 数十万のお客様がおり、フィードバックを共有するためにGitHubにアクセスするお客様はごくわずかです。 また、直接の訪問、電話、電子メール、ソーシャルメディア、カスタマーサポートリクエスト、ブログ、VisualStudioテレメトリなどから情報を収集します。 これらはすべて、意思決定の際に考慮するものの一部であり、デフォルトのエクスペリエンスの一部であるものとそうでないものです。

私たちの動機や理由がはっきりしない場合は、お知らせください。明確にしようと思います。

顧客との直接の連絡が非常に多い場合、MVCとSignalRを使用している顧客の数を最後に尋ねたのはいつですか。 必要なときに非常に簡単にインストールできる単一のNuGetパッケージにそれぞれを含めるのではなく、確実に維持するというこのスタンスの背後にある実際の使用状況メトリックはありますか？

共有ランタイムにMVCを含む@dustinmorisは、コンパイル済みで出荷されることを意味します。これは失われる利点であり、起動時間が最小限になり、IMOになり、高速起動の例ではトレードオフが不十分になります。 Dockerコンテナ。 それに加えて、すべてのデプロイはランタイムにないため、アプリと一緒にパッケージを出荷する必要があります。これにより、すべてのMVCアプリのデプロイパッケージサイズが増加します。 最後に、ランタイムでMVCに依存するパッケージも、個別のデプロイ可能にする必要があります。完全なリストが見つからないため、これがいくつあるかはわかりません。

とはいえ、Microsoftまたはaspnetチームとの提携はありませんが、コミュニティが実際にそれを発声し、それが主要な要望であることを証明した場合、最低限のaspnetcoreである別のランタイムが出荷されるのを見ることができます。 ミッションは、できるだけ多くのアプリケーションと開発者に素晴らしいエクスペリエンスを提供することであり、現時点では、共有ランタイムでMVCの恩恵を受ける割合が非常に高いという事実があります。 @natemcmasterは、関係者が将来のためにこれに投票するための好ましい方法があります。おそらくGitHubの問題であり、これは合理的な解決策ですか？

@psib​​ernetic共有フレームワークからMVCを削除するための新しいGitHubの問題を開始することを歓迎しますが、前述したように、Microsoft.AspNetCore.AppからMVCを削除することは私たちが検討することではないため、この問題が内部で集める可能性は低いです。私たちのチーム。

@Bomret私たちが調査したほとんどすべての実際の顧客アプリは、何らかの方法でMVCを使用しています。 共有フレームワークに保持することには多くの利点があり、削除する必要がある明確な理由はわかりません。

@Natemcmaster ：私は今電話中ですが、説明に感謝します。
私が話していたときにこれがメタパッケージについてであることに気づきました
共有フレームワーク。

@natemcmaster @ forki 、 @ dustinmorris 、 @ gerardtoconnor 、 @ mythzは、反論をまだ聞いていない非常に確かな理由を述べていると

これは「Microsoft.AspNetCore.App」と呼ばれます。2つ目の「Microsoft.AspNetCoreMVC.App」を作成してみませんか？

とにかく線を引くのは非常に難しいと思いますが、ここでの一般的なフィードバックは、aspnet coreで行ったことを好きであるが、MVCやかみそりのようなものはあまり好きではない人が増えているということだと思います、EFまたはsignalR。

それはそう。 コミュニティは、API、Web、WebSocket、テンプレート、DBアクセスなどを処理するためのライブラリとフレームワークのアイデアがたくさんあるほど活気に満ちていると期待できます。 MVC、Razor、EFなどを使用しているユーザーには1つのオプションを提供しますが、デフォルトのオプションだけではありません。

@natemcmaster私の間違い、私は実際にこの問題の共有フレームワークについてここで話していました。 同じ理由がメタパッケージにも当てはまると思いますが、正直言って、メタパッケージの代わりに個々のパッケージを参照できるので、それほど気になりませんが、保持したい場合は共有フレームワークを簡単に削除できませんコンテナはできるだけ小さいので、共有フレームワークの新しい問題を開くという提案は理にかなっています👍

@natemcmaster私が物事を正しく理解したかどうかをすぐに確認できますか？

• 共有ASP.NETCoreフレームワークが次の.NETCoreランタイム（3.0）に組み込まれます。つまり、ASP.NETCoreは環境への.NETCoreインストールの一部として出荷されます。

• さらに、ASP.NET Coreアプリ用のNuGetパッケージのコレクションであるMicrosoft.AspNetCore.AppおよびMicrosoft.AspNetCore.Allと呼ばれるメタパッケージがあります。

• 共有ASP.NETCoreフレームワーク<EFCoreなどを含むMicrosoft.AspNetCore.Appメタパッケージ？

• 非常に小さなAPIを作成したいだけの場合、EF Core、SignalR、MVCなどを含むMicrosoft.AspNetCore.Appメタパッケージを含めることなくASP.NET Core Webアプリを構築できますか？

• 何をしていても、小さなAPIを実行するために、ASP.NET Coreの依存関係を最小限に抑えたDockerコンテナーを作成することは可能ですか？

共有ASP.NETCoreフレームワークが次の.NETCoreランタイム（3.0）に組み込まれます。つまり、ASP.NETCoreは環境への.NETCoreインストールの一部として出荷されます。

はい

さらに、ASP.NETCoreアプリ用のNuGetパッケージのコレクションであるMicrosoft.AspNetCore.AppおよびMicrosoft.AspNetCore.Allと呼ばれるメタパッケージがあります。

いいえ。 FrameworkReferenceと呼ばれる新しい概念があり、Microsoft.AspNetCore.Appはその1つになります。 Microsoft.AspNetCore.Allは3.0には存在しません。

共有ASP.NETCoreフレームワーク<EFCoreなどを含むMicrosoft.AspNetCore.Appメタパッケージ？

いいえ、EFは含まれていません。

何をしていても、小さなAPIを実行するために、ASP.NET Coreの依存関係を最小限に抑えたDockerコンテナーを作成することは可能ですか？

ASP.NET Coreにはパッケージがないため、パッケージを削除するのではなく、アセンブリのトリミングとリンカーを使用します。

@natemcmaster

アセンブリをトリミングしているわけではありません。 削除する各アセンブリは重大な変更であり、2.xから3.0へのアップグレードのコストが増加します。

修正を行う適切な場所は、v3メジャーバージョンウィンドウ内です。これは、事実上、このような変更が発生する可能性がある唯一の時間、つまり他のパッケージが削除されるのと同じ時間です。

Microsoft.AspNetCore.AppからMVCを削除することは、私たちが検討することではありません。 すべてのユーザーがアプリケーションでMVCを参照しているわけではありません。

これは「Microsoft.AspNetCore.App」と呼ばれ、「ASP.NET Coreアプリ」を作成している場合は、論理的に「このパッケージを参照する」と読みます。

これはASP.NETCoreの製品の中心的な部分であると信じています。 これはMicrosoft.AspNetCore.Appに保持する予定です。

これは、ASP.NET Coreの目標が、無駄のないオープンなnode.js風のエコシステムの育成から遠ざかっているように見える問題の核心に近づいています。 チームは、ASP.NET CoreアプリをMVCアプリの同義語として混同することを全員が意図していますか？ ASP.NET Coreのセールスポイントのいくつかは、「Pay to play」と分離された「レイヤリング」でしたが、これは、「ASP.NETCoreアプリ」が永遠にMVCアプリを意図していることを示唆しています。

パッケージがより明確である場合、関係するすべての人にとってより明確になります。

• Microsoft.AspNetCore.App =>すべてのASP.NETCoreアプリのベース
• Microsoft.AspNetCore.Mvc => ASP.NET CoreMVCアプリ

しかし、「Microsoft.AspNetCore.App」に触れられない場合は、少なくとも、コアサーバー機能のみを備えた（つまり、意見のあるライブラリを含まない）公式の「ベースライン」メタパッケージ（またはFrameworkReference）を作成できます。

• Microsoft.AspNetCore。[ベース| 裸| ライト| 基本]

（「コア」も適切でしたが、この用語はすでに使いすぎています）。

公式のメタパッケージ/名前がないと、すべてのASP.NETCoreアプリの推奨ベースである現在推奨されている「Microsoft.AspNetCore.App」ほどアクセスできなくなります。

制約はイノベーションを生み出します。MVCが他のすべての人と同じ競技場でしか実行できない場合、アプリが必要とする製品（パッケージのスイート）を簡単かつ明示的に宣言できる機能にアクセスできる可能性があります。たとえば、何かに見える可能性があります。お気に入り：

• Microsoft.AspNetCore.Mvc + SignalR + EF

誰もが簡単に宣言して必要なものだけをインストールでき、舞台裏のツールで「Microsoft.AspNetCore.Mvc」、「Microsoft.AspNetCore.SignalR」、「Microsoft.AspNetCore.EF」メタパッケージを組み合わせることができます。 （または、意図を実現するための優れたソリューションを代替します）。

共有フレームワークに存在することで、アプリケーションでの使用を強制されることはありません。

これまでに作成されたすべてのモノリスの理論的根拠のように聞こえます。 「私たちがバンドルしているものすべてを使用する必要はありません。便利な場所にあります」。

代替手段を使用したり、独自のビューフレームワークを作成したりすることもできます。

たとえば、MVCとRazorに代わる独自の「ビューフレームワーク」を開発しているときに、.NET Coreで魔法の動作に遭遇し、標準コマンドを実行して。を公開するとビルドが失敗しました。 NET Coreプロジェクト、すなわち：

 dotnet publish -c Release

これは失敗します：

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

MVC、Razorを明示的に参照しない、または.cshtmlページを含まないMVCの代替を開発していたことを考えると、驚くべき動作です。その目的は、アプリを使用せずにビルドすることでした。

複数のGitHubスレッドを精査してさまざまな回避策を試した後、他の人が同じ問題を経験していることに気付きました。この問題では、ソリューションがMVCRazorのコンパイルをオプトアウトしてビルドを壊します。

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

これにより、プロジェクトを公開することができました。 壊れたビルドを修正するためにさまざまなスイッチを試している間に、.NET Core 2.0 Webアプリを不必要に肥大化させていたメタデータをオプトアウトすることで、 /refs/*.dll内の150の.dllによって公開されたフットプリントを削減できることも発見しました。 Razorが必要とするメタデータをオプトアウトする：

<PreserveCompilationContext>false</PreserveCompilationContext>

そのため、基本的にモグラたたきを実行して、MVCを使用していないツールに、プロジェクトビルドの破損や、MVC / RazorAppsのみが必要とする不要なメタデータの出力を防ぐために必要なスイッチを見つける必要があります。 MVCビットが存在しないため、ツールがすべてのアプリがMVCを使用していると想定できなかったため、このような問題が発生しなかった「ベース」メタデータパッケージから始める方がはるかに望ましいでしょう。

ASP.NET Coreは、代替の「ビューフレームワーク」の実験、作成、および使用を促進する歓迎のプラットフォームであると言うのは簡単ですが、MVCのような規定された意見のあるWebフレームワークをバンドルすることは、作成を思いとどまらせるために実行できる最も敵対的なことです。上記の代替の使用法。 出現している人気のある代替案の数を見て回ることは、プラットフォームが彼らにとってどれほど魅力的であるかを知るための良い基準です。

すべてのASP.NETCoreアプリに他のすべての代替「ビューフレームワーク」（extメソッドの単一の.csファイルドロップインを含む）よりもMVCを含めることが意図されている場合、より「重い」ように見えます。 "そして、バンドルされたMVCを使用するよりも面倒です。なぜなら、それらはすべて、バンドルされている必要があり、ビューフレームワークが必要とするその他のものであるためです。

要約すると、「MVC」がオプトインであり、 .Appパッケージに含まれていないことが望ましいですが、決定が元に戻せない場合は、少なくとも公式のベースラインメタパッケージベースがあります。それを含めないのですか？

数十万のお客様がおり、フィードバックを共有するためにGitHubにアクセスするお客様はごくわずかです。

IMOは、肥大化していない開始パッケージの需要を過小評価しています。逸話：VS 2012、VS 2013、VS 2015、VS 2017、および.NET Core用に作成したすべてのC＃/。NETプロジェクトテンプレートの中で、一貫して最も人気のあるテンプレートです。これまでは常に「空の」テンプレートでした。これは、VS.NETのデフォルトの空のASP.NETテンプレートが十分に空ではなかったという古典的なASP.NETに対する頻繁な批判でもありました。 これは、MVCなしで「空の」クラシックASP.NET .NET Frameworkを作成できたときでしたが、現在、MVCは、より新しく、より軽量で、よりモジュール化されたASP.NET Coreフレームワークに、推奨される最小限の開始パッケージにバンドルされています。

また、直接の訪問、電話、電子メール、ソーシャルメディア、カスタマーサポートのリクエスト、ブログから情報を収集します

人々は、取り外し不可能な複雑さと見なされることが多い肥大化を嫌います。要求される可能性が高いのは、プロジェクトをできるだけ単純にすることです。これは、焦点を当てるべきであり、デフォルトのプロジェクトを肥大化させることなく実行できます。

私の経験では、明示的であることは、魔法の振る舞いを伴う肥大化したフレームワークよりも推論が簡単です。 明示的な場合は、操作、検索、読み取り、削除、使用せずに実行をテスト（問題の原因かどうかを確認）でき、さまざまな構成のプロジェクトを比較すると表示されます。 しかし、上記のmvc / razor-lessプロジェクトのビルドを壊すMVCツールの魔法の動作では、プロジェクトのどの部分がトリガーされているのか、なぜ実行されているのか、無効にする方法、解決する方法がわかりませんでした。 MVCがバンドルされているために、MVCを使用していないプロジェクトの速度が低下していないことや、MVCまたはRazorに対応する必要があるために最適ではない出力が生成されていることを確信できません。

VisualStudioテレメトリなど。

存在しないベースラインメタパッケージの人気のテレメトリを比較するのは難しいでしょう。IMOを実行した場合、それを含める価値があるほどの人気があるでしょう。 以前の「Microsoft.AspNetCore.All」は、スペクトルのもう一方の端を対象としており、ユニバースが含まれていましたが、最小限の有用なベースラインを持つことのより有用な逆ではありませんでした。

MVCアプリを構築しておらず、それなしでベースラインを選択するオプションも同様にアクセス可能である場合、MVCを含むより肥大化したスターターオプションよりもそれを選択しないのは当然です。

@Bomret

フレームワークの作成者が意見のあるものをバンドルする代わりに、nodejsのように上に構築できるベースのWebランタイム/ライブラリがあれば非常に良かったでしょう。

しかし、それはまさにそれがどのように機能するかです。 使用したい方法でアプリケーションを自由に作成できます。 MVCを使用したくない場合は、ミドルウェアを追加しないでください。 はい、テンプレートは意見が分かれていますが、好きなことを使って、好きなことをするようにアプリを変更できます。

ここで共有フレームワークを少し誤解していると思います。 .NETCoreに同梱されている一種の標準ライブラリとして見る必要があります。 Node参照を作成するには：Expressの現在のバージョンがNodeにバンドルされていると想像してください。 あなたはそれを使う必要はありませんが、あなたがそれを使いたいときにすでにそこにあります。

また、MVCについては、MVCが実際にASP.NETCoreに何を含んでいるかを正確に認識していないと思います。 コントローラーとRazorビューを使用したくない場合は問題ありませんが、とにかくアプリでかなり多くのMVC機能を使用する可能性があります。

コントローラーとRazorビューを使用したくない場合は問題ありませんが、とにかくアプリでかなり多くのMVC機能を使用する可能性があります。

どのような？

コントローラーとRazorビューを使用したくない場合は問題ありませんが、とにかくアプリでかなり多くのMVC機能を使用する可能性があります。

はい、教えてください、少しひいきになります、私たちのほとんどはコアミドルウェア/ケストレル上に構築された代替フレームワークに関与しているので、私たちは何を使用しているかについてまともな考えを持っています、コントローラーとRazorビューはMVCの小さなサブセットです、私たちはことを知っている。 F＃フレームワークであるGiraffe / Saturn＆Zebraは、MVCよりもパフォーマンスが高く、ルーティングと処理モデルが簡素化されています。 レンダリングでは、TechEmpowerのMVCよりもZebra x2の方が高速であるため、デフォルトでは除外します。 アセンブリトリミング/リンカーが後でフットプリントを削減できる場合、それは少なくとも何かですが、他のフレームワークのより均一な競争の場を可能にするためにデフォルトで含まれていなければ理想的であり、asp.netコアプラットフォームへの最大の魅力を獲得します。

@mythz組織の観点からすると、ここにはいくつかの論理的な区分があります。 ただし、細分化すると、複雑さが大幅に増し、エンジニアリングのオーバーヘッドが発生するため、製品の機能の改善に時間がかかります。 大多数の顧客がMVCコンポーネントを利用することを期待している場合、それらを分割するコストに見合うだけの価値はありません。 それらを使用しない開発者の欠点はごくわずかであり、インストールディレクトリに数MB余分にあり、それらをロードしない限りランタイムへの影響はありません。

ポイントを説明するために

@ポーク
他の人がすでに書いているように：そうではありません。 これは、基本ランタイムとは関係のないものをバンドルしています。 Expressフレームワークがデフォルトでノードにバンドルされているとしたら、エコシステムはとても活気に満ちて多様になったと思いますか？

また、MVC、SingalRなどを基本インストールから削除し、それらを単一のNuGetパッケージとして提供することで、それぞれが「複雑さの追加」とラベル付けできる方法がまったくわかりません。 とにかく、ほとんどの場合、開発者は追加のパッケージをインストールします。 そして、それらを追加のパッケージとして提供すると、復元時間が「大幅に」増加する場合は、とにかく太すぎます。

@Tratcher

ただし、細分化

これが参照している細分化はMVCの分離であるため、ASP.NET Core Appsの開発に何を使用するかを規定する開発者フレームワークがなくても、ASP.NET CoreAppsは最小限の有用なベースラインを持つことができます。

製品の機能の改善に時間がかかる複雑さとエンジニアリングのオーバーヘッドが大幅に追加されています。

これがどのように読み取られるかを明確にするために：MVCを使用しないすべてのASP.NET Coreアプリから不要なオーバーヘッドを削除するには、エンジニアリングオーバーヘッドが多すぎる必要があります。これは、MVCが他のすべての代替フレームワークと同様に機能する必要がある場合、「MVCに」複雑さが大幅に追加されるためです。

MVCが、他のすべての代替フレームワークが機能しなければならないのと同じ拡張オプション内で機能するためにかなりの複雑さを必要とする場合、それはMVCに問題があることを示しており、よりシームレスに機能するように追加された機能は、すべての人の利益に追加できます。 モノリスを分析するのと同じように、ツールとランタイムの複雑さはよりスリムで複雑ではなくなり、MVCとその統合/ツールに属する場所に複雑さが追加されます。

代わりに、MVCがデフォルトのツールに定着し、公開プロジェクトを中断し、それを使用しないプロジェクトの出力を肥大化させる可能性があるという状況に陥りました。 他のすべてのように機能するわけではないため、MVCを使用していることを通知する方法や、MVCを使用していないことを通知する方法はありません。常に想定されています。

大多数のお客様がMVCコンポーネントを利用することを期待している場合

それは当然のことですが、他のすべての選択肢を犠牲にして、デフォルトの最小推奨インストールにバンドルされている規定のフレームワークです。たとえば、Appleは、好きかどうかに関係なく、すべての人に無料のU2曲を提供します。

それらを使用しない開発者にとっての欠点はごくわずかです

開発者は、より多様性、オプション、革新性を備えたより健康的なエコシステムから利益を得るでしょうか？

開発者は、「ASP.NET Core App」とは何かという混乱と曖昧な定義の追加から恩恵を受けますか？ 「以前は.NET用のnode.jsのようなものでしたが、今では、基本的にすべてのアプリがWebアプリの構築方法を規定する多数の意見のあるものから始まる、意見のある単一ベンダーのフレームワークになっています。 Expressとその依存関係がデフォルトでプリインストールされているアプリ-あなたはそれを使用することが期待されています」

開発者はMVCの特別なケーシングから恩恵を受けますか？ それは他のもののようにインストールまたは更新されておらず、存在を認識して無効にするために探し回らなければならない隠されたツールと魔法の動作に依存しています。 このような特別なケーシングは、偶発的な複雑さを追加するものです。プロジェクトについて推論するときは、MVCの動作と他のすべての動作について異なるルールのセットを維持する必要があります。

明示的である場合、読みやすさが向上し、プロジェクト構成から、MVCアプリであることがわかります。例：

• Microsoft.AspNetCore.Mvc

これは、MVCアプリであることを示し、すべての依存関係をインストールし、MVCが必要とするすべての特注ツールを自動構成します。理想的には、他のすべての人がアクセスできる同じオープン拡張可能モデルを使用します。

これをデフォルトの「Microsoft.AspNetCore.App」プロジェクトに保持することで、すべてのASP.NET Coreアプリと永久に結び付けられ、より良いものが実現するのに不利になります。 ASP.NET Webページは、数年前にASP.NETに追加されたもう1つのRazorビューフレームワークであり、インストールされており、デフォルトで侵襲的な魔法の動作が有効になっています。 サポートされなくなった、またはダウンロードできない独自のWeb Matrix IDEが付属していたため、残っているのは、死んだテクノロジーの複雑さが従来のASP.NETに永遠に埋め込まれ、他のアクティブなWebフレームワークに積極的に問題を引き起こしている場合です。 Razor .cshtmlページを使用することに結びつくと、Webページがビューフレームワークを壊すことを明示的に防ぐために、以下の手荷物を永久に持ち歩く必要があります。

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

優先順に機能リクエストを繰り返すには、次のようにします。

1. 「Microsoft.AspNetCore.App」を、すべてのASP.NET Coreアプリ（つまり、MVCなし）の最小限の有用なベースラインになるように変更します。
2. 「Microsoft.AspNetCore.Base」のようなメタパッケージを維持します。これは、MVCを使用していないすべての人が最小限の有用なベースラインとして使用できます。

これらのいずれも考慮されない場合、少なくともmvc:enabled = falseようなプロジェクト全体のフラグを設定して、すべてのMVCツールがそれらの実行を無効にして防止するためにチェックできるようにすることはできますか？

@mythzあなたは私の口に言葉を入れています。 追加された複雑さはMVCではなく、そのレイヤーが何で構成されているかに関係なく、コンポーネントのさらに別のレイヤーを作成して出荷するために必要なインフラストラクチャ、パッケージング、インストーラーなどを構築することです。

これらのいずれも考慮されない場合、少なくともmvc：enabled = falseのようなプロジェクト全体のフラグを

どのツール機能を無効にしてほしいかについて、より具体的に教えてください。 それは別の問題の価値があるかもしれません。

@Tratcher

追加された複雑さはMVCではなく、そのレイヤーが何で構成されているかに関係なく、コンポーネントのさらに別のレイヤーを作成して出荷するために必要なインフラストラクチャ、パッケージング、インストーラーなどを構築することです。

つまり、MVCを機能させるために必要となる複雑さが増します。

どのツール機能を無効にしてほしいかについて、より具体的に教えてください。 それは別の問題の価値があるかもしれません。

私が遭遇した2つの問題は、 /p:MvcRazorCompileOnPublish=falseを手動で構成する必要があり、プロジェクト（.cshtmlページなし）を公開できなかったことです。 無効にする必要がある他のフラグは次のとおりです。

<PreserveCompilationContext>false</PreserveCompilationContext>

ほとんどの魔法の振る舞いと同じように、私はもっとたくさんあると思いますが、私がそれに遭遇したときだけそれらについて知ります。

基本的に、MVCが使用されないことを指定し、MVCのために追加されたデフォルトで有効になっているすべてのツールまたは譲歩を無効にするフラグ。

@mythzは先に進み、その問題を提出します。

追加のMVCおよびSignalRdllがユーザーにとって懸念事項である場合は、実際にサービススタック用に同様の共有フレームワークを作成できます。

@davidfowlそれは実際にはかなり素晴らしいように聞こえますが、コミュニティが提供するフレームワークの

ご想像のとおり、これを行う人の数は少ないため、ファーストクラスのサポートを構築することはできません。 それは、私たちがどのように私たちを構築し、その振る舞いを模倣するかを見ることができると言われています。

@davidfowl最小限の基本パッケージは、MVC以外のすべてのアプリに役立ちます。たとえば、すべてのフレームワークをバイパスして応答自体に直接書き込みたい他の軽量アプリやマイクロサービスがたくさんあります。 IMOこのオプションはボックスで利用できるはずです。私たちが制御できないパッケージバージョンで構成される非公式のベースから始めたくないのです。 理想的には、外部で維持されている異なる接線から開始するのではなく、すべてが基本パッケージから追加されます。 しかし、これは、外部コミュニティが集まって、MVC以外のすべてのアプリとフレームワークに役立つ基本の「AspNetCore」サブセットを維持できる領域の1つである可能性があります。

そうは言っても、カスタムフレームワークを作成するにはどこを見ればよいのでしょうか。 「Microsoft.AspNetCore.App」の作成に使用されたもののコピーから始めて、不要なライブラリをすべて削除して、最小限の有用なサブセットに戻すのと同じくらい簡単かもしれません。

@mythzなぜフレームワークが必要なのか、サーバーを直接Kestrelを使用するだけです。 これは、あなたのバージョンの光が他の誰かの光やコアの考えではないかもしれないと言っているだけです。 私たちは現在意見を持っており、コミュニティがここにステップアップして、テンプレートと十分に最小限の代替共有フレームワークを作成できれば素晴らしいと思います。 私たちはOSSです。何かをカスタム化するために必要なものはすべてそろっています。私たちは非常に敏感で、喜んでお手伝いします。

@natemcmasterカスタム共有フレームワークを作成する方法の詳細を支援できます。

@davidfowlあなたがカスタムのものを作ることを提案しました、私は意見のあるフレームワークなしで最小限の有用なベースから始めることができた後でのみです。 すべてのASP.NETCoreアプリで「Microsoft.AspNetCore.App」を参照することをお勧めするのと同じ理由で、複数のパッケージを個別に参照する必要はありません。単一のパッケージを参照できる方がアクセスしやすくなります。

これは、あなたのバージョンの光が他の誰かの光やコアの考えではないかもしれないと言っているだけです。

ここでは、MVCが基本パッケージに属していないことは誰もがかなり一致しているようです。 含まれているように見える他の唯一の「製品」はSignalRであり、MVCよりも使用量が少なく、含まれる理由が少ないと思います。 私は各パッケージの内容に精通していませんが、他のすべては一般的に有用であり、ASP.NETCore「プラットフォーム」の助けとなる部分のようです。

OK、ここで建設的になるように提案を投げさせてください。 Microsoft.AspNetCore.Appは変更していません。これは、大多数のユーザーが必要とし、使用するものだと考えています。 この「コア」共有フレームワークである別のレイヤーを紹介しましょう（元々はhttps://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497でこのようなことを行いました）。 これは、これらの他のフレームワーク（NancyやServiceStackなど）のベースとなる共有フレームワークです。

デフォルトのテンプレートは今と同じようにMicrosoft.AspNetCore.Appに同梱されますが、自分のようなフレームワークの作成者は、基本の共有フレームワークを使用する他のテンプレートを使用できます。

PS：このスレッドは、お客様の大多数をリモートで表すものではないので、ここだけで結論を出すことはしません。 私たちは多くの場所からフィードバックを受け取り、githubには最も声高で情熱的なガイダンスがあります。

ええ、それはアプリを構成して起動して実行するための多くの必需品を含むことに近いと思います。 Microsoft.AspNetCore.Appの部門から、次のものも使用しています。

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

したがって、HTTP、ホスティング、ロギング、構成の抽象化（ほとんどのHTTPアプリに役立ちます）なども含まれていると便利です。 私の唯一の好みは、MVC / SignalRを含めないことです。

そして今、それは面白くなります。 デビッドがすでに言ったように：人々は異なっています
「コア」が何を意味するかについての考え。 私のPOVから、DependencyInjectionはないと思います
/肩をすくめる

Am Do.、2018年11月8日um 08:30 Uhr schrieb Demis Bellot <
[email protected]>：

ええ、それは多くの必需品を含むことに近いと思います
アプリを構成し、起動して実行します。 の部門から
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App私たちも
使用：

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

つまり、HTTP、ホスティング、ロギング、構成の抽象化などです。
（ほとんどのHTTPアプリに便利です）含まれているといいでしょう
そうでなければ、誰もが適切だと考えます。 私の唯一の好みは持っていないことです
MVC / SignalRが含まれています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
。

@mythzそれらのほとんどは推移的に含まれています。

@ forki😆私たちの世界へようこそ。

Microsoft.AspNetCore.Appは変更していません。これは、大多数のユーザーが必要とし、使用するものだと考えています。

有名な最後の言葉。 これはすべての悪い決定の正当化です-「私たちは彼らがそれを必要としていると思います」。

あなたは私がどう思うか知っていますか？ マイクロソフトは、開発者ベースを羊の開発者としてではなく、独立したインテリジェントエンジニアとして扱い始める必要があります。そうです、羊の開発者はたくさんいます。コミュニティを作成し、.NETスタックに新しいスタートアップを構築します。

パワーユーザーの話を聞くのが良い場合もあります。

とにかく、Microsoft.AspNetCore.Appを変更するつもりはありません。 ここでの要件を満たすと思う妥協案を提示しました。

@forkiとにかくDIに直面しているaspnetコアを使用している場合は、デフォルトで便利なメソッドを含めるようにすることをお勧めします（サービスを受ける、GetRequiredServiceなどがそのパッケージに含まれています）。 そして、T：> U制約がないため、F＃はそれ自体でそれらを作成することさえできませんhttps://github.com/fsharp/fslang-suggestions/issues/255したがって、¯_（ツ）_ /¯

そのベース共有フレームワーク@davidfowlについて言及してもらいたいのですが... @ mythzと@dustinmorrisはどちらもそのようなアプローチで

とにかくDIに直面しています

私は知っています、そして私たちはその議論を何度もしました。 それは私がむしろしたくないだけです
;-)しかし、それはそれが何であるかです...

アム神父、2018年11月9、10：57帽子ニノフロリス[email protected]
geschrieben：

@forki https://github.com/forkiaspnetコアを使用している場合は
とにかくDIに直面し、便利な方法を含めるようにする方が良い
デフォルト（Get service、GetRequiredServiceなどはその中にあります
パッケージ）。 そして、ちょっとF＃は行方不明のためにそれ自体でそれらを作成することさえできません
T：> U制約fsharp / fslang-suggestions＃255
https://github.com/fsharp/fslang-suggestions/issues/255なので、¯_（ツ）_ /¯

そのベース共有フレームワーク@davidfowlが欲しいです
https://github.com/davidfowl言及...私は@mythzだと思います
https://github.com/mythzおよび@dustinmorris
https://github.com/dustinmorrisは、どちらもこのようなアプローチで問題ありません。
これは土星@ Krzysztof-Cieslakにとっても好都合です
https://github.com/Krzysztof-Cieslak

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
。

元の投稿を更新して、次のものを含めました。

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

これらは共有フレームワークから削除されており、NuGetパッケージとして出荷されます。 これらのアセンブリは、共有フレームワークのガイドラインにまだ適合していないIdentityModelAPIに依存しています。 IdentityModelチームとの協力を開始しており、将来的にはこれらを共有フレームワークに戻すことを検討しています。 cref https://github.com/aspnet/AspNetCore/pull/6035

元の投稿を更新して、Microsoft.AspNet.WebApi.Clientを含めます。 https://github.com/aspnet/AspNetCore/pull/6552#issuecomment-453177732を参照して

それが私が含める必要があるものであるため、私はしばしば十分に混乱します。

Visual Studioの話- Microsoft.AspNetCore.Appノードを開いて、その下にあるすべてのものを、個別にインストールしたものと相互参照することになっていますか？

私はいくつかのハウスクリーニングを行っています、そして私がこれらのパッケージを持っているのを見ます。 では、どちらが冗長ですか？

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

SpaServicesツールとEntityFrameworkツールでさえ現在含まれているのを見て非常に驚きました（これは以前は気づいていませんでした-そして素晴らしいです）-しかし、何も役に立たない古い2.2.1リファレンスもいくつかあります。

重要なのは、これらのメガパッケージを理解し、何かを削除しても安全だと言ってIDEがもう少しインテリジェントになるように、Visual Studioチームとのより良い調整作業を行うことができるかどうかです。その後、v3では追加する必要があると言われます。再び戻って;-)

@simeylaフィードバックをありがとう。 あなたが言っていることは主題に関連していますが、それはこのスレッドが何であるかを正確に示しているわけではありません。 パッケージ参照を最適化するためのツールは、VisualStudioの新しい機能になります。 この機能は、このシナリオだけでなく、一般的に役立つ可能性があるため、このフィードバックをVisualStudioに直接送信することをお勧めします。 VSでは、「ヘルプ>フィードバックの送信...」を使用します。 投稿を作成した後でリンクを共有すると、VSで作業するピアチームに内部的に転送できます。

3.0では、Microsoft.AspNetCore.Appメタパッケージを完全に削除し、出荷するパッケージに多くの調整を加えます。 2.xから3.0にアップグレードする方法の文書化を開始し、3.0で出荷されるアセンブリのリストを完成させながら、このドキュメントを更新し続けます。

このアイテムは作業を追跡していないため、「ディスカッション」マイルストーンに移動しますが、実装の変更の詳細に応じて更新します。

リストにMicrosoft.Extensions.DependencyModelを追加しました。 https://github.com/aspnet/AspNetCore/pull/10271の一部として変更されました

ここで質問@ natemcmaster @ DamianEdwards 、ローカルでビルドするために必要なすべてを備えたテンプレートについての言及があります。 この考えとAuthライブラリの削除で、それはどの認証テンプレートも3.0でオフラインでビルドされないことを意味しますか？ オフラインで機能する認証ライブラリがないことは理解していますが、nugetキャッシュがない場合、オフラインの場合、新しい認証テンプレートを新規作成した後、理論的にはビルドエラーが発生する可能性があります。 それは悪い経験のようです。

はい、それはこの変更の結果の1つです。 プレビュー6（近日公開）の​​時点で、 dotnet new mvc 、 dotnet new razor 、 dotnet new webなどにはPackageReferencesがないため、影響を受けることはありませんが、追加のオプションを指定します、 --auth individualように、PackageReferenceが存在する可能性があり、パッケージのダウンロードが必要になります。

ここでは意図的なトレードオフを行っています。 PackageReferenceを含むテンプレートは、クリーンなマシンでオフラインで復元されませんが、事前入力されたオフラインNuGetキャッシュを作成しようとすることから生じる多くの問題も回避しています（初心者の場合は、https：//github.com/dotnet/をチェックアウトしてください）。 dotnet-docker / issues / 237、https：//github.com/NuGet/Home/issues/6309、およびhttp://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html）。

@natemcmasterは完全に理解しており、私はその理由を理解しています。十分に文書化する必要があります。そうしないと、最初の3.0リリースで、 dotnet new webapp --auth Individualがビルドされないと言われる多くの問題が発生します。

Microsoft.AspNetCore.Authentication.JwtBearerが.netcoreapp3.0に依存してコンパイルされている理由について誰かに教えてもらえますか？ .netstandard2.xに含めることはできませんか？ クラスライブラリで使用したいのですが、classlibをすべて.netstandardのままにしておきたいです。

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchieこの問題は、ASP.NET <PackageReference>を追加する必要があります。

@Bomret私たちが調査したほとんどすべての実際の顧客アプリは、何らかの方法でMVCを使用しています。 共有フレームワークに保持することには多くの利点があり、削除する必要がある明確な理由はわかりません。

私たちは確かにそうではありません。サーバーレスアプリやWebAPIなどに.netCoreを使用している他のショップでは、MVCの必要性がまったくない人がかなりいます。

本日3.0を出荷しましたので、締めくくります。

このリストをドキュメントに移動する必要があります

@davidfowlが追加されました： https ：//docs.microsoft.com/en-us/aspnet/core/migration/22-to-30

@pranavkmのリストは、実際には正反対です。パッケージではなくなったものの、共有フレームワークに残っている可能性が高いものです。

これは、共有フレームワークから削除されたものについてですが、現在はパッケージとしてのみ利用可能になっている可能性があります。

@scottaddieこれは、

@DamianEdwards this- https： //docs.microsoft.com/en-us/aspnet/core/migration/22-to-30

それだ ：）

パーティーに遅れましたが、これは私の開発を簡素化するという目標を達成するのに役立っているようには感じません。

a）AspNetCoreコンポーネント（SignalRなど）に改善があった場合、Microsoft.AspNetCore.Appの新しい「ドットネットパック」がリリースされて使用できるようになるまで待つ必要があるようです。そのパックの他に？
b）netstandardクラスライブラリ（Authミドルウェアなど）でAspNetCoreのユーティリティクラスを作成できなくなりました。 このようなものを格納するには、クラスライブラリをnetcoreapp3.0にする必要があります。 これは、ユーティリティクラスライブラリをnetstandard / netcore実装に分割することを意味します。
編集：c） <Project Sdk="Microsoft.NET.Sdk.Web">を実行する場合、使用しているパックのバージョンを実際に定義するにはどうすればよいですか？ 明らかに、dotnetを更新した後、さまざまなブランチで再現可能なビルドが必要です。

a）AspNetCoreコンポーネント（SignalRなど）に改善があった場合、Microsoft.AspNetCore.Appの新しい「ドットネットパック」がリリースされて使用できるようになるまで待つ必要があるようです。そのパックの他に？

SignalRは、他のAspNetCoreと同じスケジュールで出荷されるため、ここではスケジュールの変更はありません。

SignalRは、他のAspNetCoreと同じスケジュールで出荷されるため、ここではスケジュールの変更はありません。

だからこれは悪い例ですか？ 削除された他のすべてのNuGetパッケージについても同じことが言えますか？

SignalRは、他のAspNetCoreと同じスケジュールで出荷されるため、ここではスケジュールの変更はありません。

だからこれは悪い例ですか？ 削除された他のすべてのNuGetパッケージについても同じことが言えますか？

そう思います。 すべての.NETCoreおよびASP.NETCoreコンポーネントは同じ出荷スケジュールを使用します。 何かがそうでなかったならば、それはそれ自身のパッケージで出荷しなければならないでしょう。

そう思います。 すべての.NETCoreおよびASP.NETCoreコンポーネントは同じ出荷スケジュールを使用します。 何かがそうでなかったならば、それはそれ自身のパッケージで出荷しなければならないでしょう。

私はあなたの言葉を信じます。 具体的な反例はありません。 過去にAspNetCoreNuGetパッケージを更新したとき、そのように「感じ」なかっただけです。