スタンドアップで、Damianは、Nuget関連のものが現在のpackages.configの代わりになるものに移動する可能性があると述べています。 明らかに、これらの決定は道のりで公正な方法です。この時点で具体的な答えが得られるとは思えません。

そして、私は「JSONがそれらの依存関係を表すために簡単に受け継がれる」ことに同意しません。 長所と短所があります。 こちらをご覧くださいhttps://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

_if_がnuget.jsonに移動する変更について同意します。 それはプロジェクトの唯一の部分です。とにかく開発可能である必要があると私が思ったJson。

@darrelmiller Yamlは、冗長性の点でおそらくさらに優れた代替手段です。 そして、配列の代わりにコンマ区切りの文字列で不正行為をしました;）。

@sandorfrです。 ただし、XMLベースのプロジェクトシステムに戻る理由の1つは、.netエコシステムのXMLベースのプロジェクトシステムに関する既存の重要なツールが原因であると思われます。 私のコメントは、XMLが本質的に悪いものではないことを指摘するためだけに、最適な形式を特定しようとするものではありません。

はい、それは今週の最悪のニュースです。 それは時間に戻されたようなものです... :(確かにXmlは悪くありませんが、msbuildは...そしてmsbuildxmlベースプロジェクトはあなたが説明したほど洗練されていません。

ただし、XMLベースのプロジェクトシステムに戻る理由の1つは、.netエコシステムのXMLベースのプロジェクトシステムに関する既存の重要なツールが原因であると思われます。

msbuildのように手荷物を前に運ぶことも意図しているのであれば、それがまったく新しいものであることを示すために、すべてのものに「コア」という接尾辞が付いている理由がわかりません。

このプロセスは2年以上も苦痛でしたが、新しい追加や改善のすべてがエコシステムを他のエコシステムと整合させ、それらすべてが正当な理由で変更されたため、多くの人々は大丈夫でした。 しかし、突然、暗黒物質の企業開発者が密室でフィードバックを提供し始め、多くの荷物が持ち越されるのを目にしています。

XMLベースの構成を持つエコシステムはそれほど多くありません。 実際、新しく設計されたエコシステムはすべて、他の形式（YAML、JSONなど）を採用しています。 ソーシャルメディア上のすべての人々の反応を見てください。この変化を好む人はあまりいません。 ただし、個人的に提供されたフィードバックは、チームにとってより重要であるように思われます。 それは悪いことではありません、私は理由を理解していますが、それは決定がこのエコシステムで処理されている方法を示しているだけです。

今週の最悪のニュースで+1。 これについての議論はどこにありましたか？ 私は何も見つけることができず、一方的な決定だけです。

この決定に対するコミュニティの支持は見られず、反対もたくさんあります（最終的には85％から15％）。 どのような情報に基づいて、誰が決定を下したのか、議論はどのように進みましたか？

これは、.NET Coreでの作業方法ですか？ レガシー技術の非公開リストをサポートしたいので、密室で品質を妥協しますか？

ぜひ、これらの古いテクノロジーを使用する人々が利用できるproject.jsonから.csprojを作成するVS拡張機能を実行してみましょう。

しかし、XMLベースのプロジェクトファイルの悪夢に私たちを送り返さないでください。 それらが導入されたときは悪い考えでした。私たちは10年以上の間、悪いマージと読みにくいという税金を払ってきました。 それは十分だ。

あなたは悲観的すぎると思います-そしてそれは主に私たち全員がこれに驚いたからだと思います。 彼らに彼らの計画に関するより多くの情報を共有させてください、そうすれば私達は見るでしょう。 @DamianEdwardsは、project.jsonモデルの良い部分を維持したいと明確に述べています。

私の意見では、それは次のようになります。

• 各csファイルを指定する必要はありません
• プロジェクトをアンロードせずにファイルを変更できる
• ファイル内のnuget依存関係を直接変更できる（IntelliSenseを使用）
• global.jsonを介してnugetパッケージをローカルソースに置き換えることができます

コンパイルに関しては、VisualStudioをインストールしなくてもコンパイルできるはずだと思います。 私にとって、実際のコマンドが「dotnetbuild」であるか「msbuild」であるかは関係ありません。 重要なことは、ソリューション全体をコンパイルする方法があるはずです。ちなみに、これは「dotnetcli」にはまだ存在していません（少なくとも私が知る限りでは）。

これが達成できれば、私は彼らが使用する構文に関係なく大丈夫です。 XMLは素晴らしいものではありませんが、JSONには明らかに欠点もあります。

編集：これは、.NET Coreなどの基本的な（そして素晴らしい）アイデアを変えるものではないと思います。

私見、主な問題は、RTMの直前のこれらのタイプの劇的な変化が良くないということです。 これがベータ期間に発生した場合、開発者/チームはそれほど驚かないでしょう。 過去2年間に人々が行っている投資について考えてみてください。 project.jsonシステムに応じて、現在の製品/ライブラリ/フレームワークについて考えてください。 Asp.Netはプレビュー/アルファ/ベータではなくRCにあり、これらのタイプの変更は開発者/チームの信頼を壊します:(。

私見、主な問題は、RTMの直前のこれらのタイプの劇的な変化が良くないということです。

私も最初はそう思いましたが、私が理解している限り、これによってアプリケーションコードが変更されることはありません。 これはproject.json / xproj / csprojファイルにのみ影響し、変更は自動的に行われる可能性があると言われています。したがって、これは、VisualStudioをアップグレードしたときにすでに何度も行われた古き良きプロジェクトの移行手順に似ています。

ところで、私はいつもproject.jsonとxprojファイル（Visual Studioテンプレートのデフォルトの名前空間といくつかの出力パスが含まれているので、時々それも編集する必要がある）があるのは変だと思っていました。

ところで、私はいつもproject.jsonとxprojファイル（Visual Studioテンプレートのデフォルトの名前空間といくつかの出力パスが含まれているので、時々それも編集する必要がある）があるのは変だと思っていました。

奇妙かもしれませんが、彼らはさまざまなことに答えています。project.jsonは.netコアプロジェクトを構築するために必要な唯一のファイルであり、xprojは独自のツール（別名ビジュアルスタジオ）に関連しています。 webstormを使用してノードプロジェクトで作業する場合は、package.jsonおよび.ideaと非常によく似ています。 関心の分離だけです。 Visual Studioは、必要に応じて、プロパティの下にproject.jsonを非表示にし、必要に応じて、すべてを混在させることなく、統合されたキュレートされたGUIエクスペリエンスを提供できます。

私はVSCodeのMacでこのようなものを長い間使用してきましたが、xprojのことをすべて忘れていました。 OTOH、私は本当にデバッグを逃しました、そしてVisual Studioからかなり多くのものを！

あなたは悲観的すぎると思います-そしてそれは主に私たち全員がこれに驚いたからだと思います

いいえ、悲観的すぎるとは思わないのでごめんなさい。 XMLは、コードマージを行うすべての状況、つまりすべてのソフトウェアプロジェクトに適した形式ではありません。 XMLは、構成ファイルやプロジェクトファイルなどのために設計されたものではなく、決して使用されるべきではありませんでした。XMLですべてを解決できると誰もが思ったときに、.NETを再構築するのは不運でした。

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

現在、.NET Coreは、JSONがすべてを解決すると誰もが考えているときに構築されています。 JSONがXMLよりも長期的なソリューションであるとは思いませんが、JSONの競合をXMLの競合よりもマージする方が簡単であることは

プロジェクトファイルのXMLのゴミを処理しないのは新鮮な空気であり、JSONファイルが読みやすく、VisualStudioの外部でJSONファイルを操作しやすいことがわかりました。 XML / MSBuildに戻りたくない。

はい、これらは私の個人的な感情であり、はい、主観的ですが、Twitterや他の場所でのコメントに基づくと、それらが孤立しているとは思いません。 正直なところ、この決定により、.NET Coreの全体的な方向性、特にこのような重要な決定が行われる方法を完全に疑うことになります。

@DamianEdwardsは、project.jsonモデルの良い部分を維持したいと明確に述べています。

私の見解では、project.jsonモデルの最良の部分は、csprojでも、MSBuildでも、XMLでもないということです。 それらの「良い」部品は保管されますか？ どうやらそうではありません。 彼らがようやく芝生になっていると私たちが信じ込んだ後、それはすべて間違った方向であったことがわかりました。 新しいビルドシステム、Gulpとproject.json、そして今の状況がどう違うかについて話を聞いたところ、それはすべて偽物であり、古いMSBuildが再び壊れていることがわかりました。

JSONとXMLの形式は、マージに関してはほとんど同じだと思います。どちらにも終了タグがあります（ただし、JSONでは中かっこです）。つまり、空/ 1つ/多くのシナリオで問題が発生します。 空のJSON配列をアイテムを含む配列に変更するだけです。 JSONには、リストに項目を追加すると2行が変更される終了コンマという追加の欠点もあると私は主張します。

それを避けたい場合は、YAMLなどに移行する必要があります。

IMOのcsprojの問題は、XMLではなく、Visual StudioによるXMLの処理方法と、すべてのcsファイルが含まれていることです。 これが修正され、ツールがファイル内の内容をランダムに変更しない場合、マージはもう問題にはなりません。

ただし、読みやすさの観点から、JSONも好みます。 project.jsonを最初から作成することができました-csprojでは作成できなくなると思います（csprojにはランダムなProjectGuidなどが必要です）。 したがって、これには間違いなくツール/コマンドラインのサポートが必要です。

私があまり聞いたことがないこの全体についての私の主な懸念は、 project.jsonは、参照に関しては、 .csprojプロジェクトファイルよりもはるかに宣言的であるということです。 project.jsonファイルの依存関係の美しさと、コードベースをそれに移行することを楽しみにしていた理由は、「この依存関係が必要です」と言うだけで、それがローカルプロジェクトであるか、 NuGetパッケージ。 私たちの場合、これは私たちに多くの柔軟性とクールな新しいオプションを購入するでしょう。 対照的に、現在、 .csprojファイル内の.dllファイルへのハードな相対パスです。 現在、従来のプロジェクトのpackages.configにエントリを追加しても、実際には何も起こりません。また、そのパッケージの特定の.dllへの.csprojファイルに追加する必要があります。 。 これは、Visual Studio内のNuGetツールによって実行されますが、 project.jsonファイルにテキスト行を追加する方がはるかに簡単な場合は、これらのツールを使用したくありません。

チームはproject.jsonファイルによって提供されるすべての機能を維持し、 .csproj形式の機能を拡張したいと考えていますが、 project.jsonファイルとして保持することについても話し合いました。であなたのNuGetパッケージを指定する。私はそれが持つ現在の状況と比べて追加することになりますか見ていないpackages.configそれでもへの参照を追加する必要があるため、どこちょうどそれにエントリを追加するだけでは十分ではありません.dll .csprojにも.dll 。 .csprojファイルが未来になる場合は、コアチームが最後まで行き、 project.jsonまたはnuget.jsonを削除するか、または_全体_と呼ばれて追加することをお勧めします。 .csproj形式への参照を追加するためのより宣言的な方法。 JSONファイルの代わりにXMLファイルを編集する必要があるので問題なく生きることができます（私は確かにJSONを好みますが）が、 project.jsonの宣言型の性質を失うことは本当に残念であり、2つは必要ありません依存関係を指定する必要があるさまざまな場所。

https://www.surveymonkey.com/r/H6Q88PPでフィードバックをお

明確にするために、スタンドアップノートを読む際に、1つのオプションはnugetをインストールすることであると述べています-一種のオプションを保存します（https://blogs.msdn.microsoft.com/webdev/2016/05/11/を参照） notes-from-the-asp-net-community-standup-may-10-2016 /）。 それは良い考えだと思いますが、「。jsonファイルをインテリセンスに編集する」をそれで置き換えるのは悪い考えだと思います。 すべてを行うためにシェルに切り替えたくない人にとっては、エディターにとどまるのは良い考えだと思います。 私の好みは、個人的には両方の経験をすることです。 依存関係を追加するためのコマンドライン+ UIは十分ではありません。

私はコーダーです。エディターを離れたくありません。

これは恐ろしい決断だと思います。 皆さんは、.NET Coreを本当にシンプルにしたいと言っていましたが、その後、この変更を行います。 あなたがMSBuildにどれだけ口紅をつけても、それはまだMSBuildであり、部外者はそれを見てすぐにオフになります。 単純な手作業で編集可能な形式になることは決してありません。 難しい技術的な問題があったかもしれませんが、それはプロジェクトシステムを単なるプロジェクトシステム以上のものにしようとしたことに関係しているようです。 ビルドでより複雑なことをしたい場合は、スクリプトを作成するか、msbuildを使用してそれを行うことができます。 project.jsonは美しくシンプルなものであり、私は今本当に困惑しています。

MSBUILDファイルに関する私のお気に入りの引用は？

私は最近、csprojファイルに多くの時間を費やさなければなりませんでした。 それらはAnt / Mavenにかなりよく似ています。 これは彼らに有利な点ではありません。
Ant / Mavenは愛され、その後多くのJava開発者に嫌われました。 XMLは、処理しなければならない非常に冗長な構文です。
しかし、本当のキラーはロックインの1つです。 はい、msbuildを使用してそれらを処理できますが、構文は実際には、開発者がそれらを読み取り/編集するためではなく、IDEが状態をシリアル化するために設計されています。 コマンドラインランナーがあるからといって、その形式が開発者にとって使いやすいとは限りません。 VSにとどまっている限り、実際には気付かないでしょう。 あなたが去るとすぐにそれはもはや快適ではありませんが。 csprojファイルは、.Netがのjavaとは異なるパスをとっていればよかったことの1つです。

ソース

MSBuildと、VisualStudioが現在MSBuildを使用している方法を区別することが重要だと思います。 私は何年もの間MSBuildファイルを手作業で編集しており、すべてのプロジェクトでそれらを使用しています。 例： https ：

Visual Studioが作成するcsprojファイルはかなり厄介ですが、MSBuildでそれを非難するのは、コードジェネレーターが醜いコードを一度作成するのを見たので、C＃はくだらないと言っているようなものです。

@darrelmiller同意します。

時間を6か月前に進めて、それが「あなたにそう言った」瞬間なのか、それとも「弾丸をかわした」瞬間なのかを見てみましょう。

彼のブログでの@shawnwildermuthの呼び出しに続いて、私は自分の2セントを投入します。

なぜこれがそんなに大したことなのかわかりません。 XMLベースのcsprojに戻ることができてうれしいです。理由は次のとおりです。

• JSONを手動で編集することは、XMLよりも自然で簡単ではありません。 それは実際には反対の私見です。 すべての愚かなエディターは私にXMLタグの補完を与え、フォーマットエラーを手動で見つけるのは簡単です。 JSONを手動で作成する必要がある場合、JSONは簡単ではありません。 それが私をポイント2に導くと言って...
• そもそも、エディターでプロジェクトファイルを編集することに大騒ぎするのはなぜですか？ プロジェクトファイルの編集は、開発者として時間を過ごしたい場所ではありません。 これは、新しいプロジェクトの開始時には1回限りのことですが、その後はあまり頻繁に発生しないはずです。 JSON、XML、YAML、TOMLなど、その時点で誰かが思いついたもので編集する必要がある場合は、まったく関係ありません。
• 私が避けたいことの1つは、NuGetをASP.NETと緊密に結合することです。 NuGetは素晴らしいです。私はそれが大好きで、ASP.NETを非常にうまく機能させたいのですが、ASP.NETを実行する必要はありません。 はい、MVCなどの機能を取得するためにNuGetフィードからバイナリをプルする必要があるかもしれませんが、公式のNuGetフィードを介してこれを行うか、ソースをプルする場合は、ローカルでコンパイルしてコピーして貼り付けます。フォルダは、私が利用できる柔軟性である必要があります。 ASP.NET、csproj、またはその他のものを、これらの「サポートする」サードパーティシステムに緊密に結合したくありません。 私は彼らに素晴らしい統合を可能にしてもらいたいのですが、カスタマイズのためにドアを開いた
  明確に定義されたインターフェースの背後にある緊密な統合==素晴らしい。
  これがすべての人の標準であると仮定すると、密結合==悪い。
• 最後に、project.jsonは.NETCoreおよびASP.NETCoreとはほとんど関係がありません。 Coreには、project.jsonファイルよりもはるかに多くの機能があります。 Project.jsonは新しい機能ではなく、別の形式ですでに存在していたものを再設計する試みでした。 開発者として、私はたまに行う必要のある退屈な構成ではなく、クラウドで優れたアプリケーションを開発するために.NETCoreによって提供される新機能と可能性に焦点を合わせているのであまり気にしません。

開発者として私は互換性にもっと関心があり、これが鍵だと思うので、MSBuildに戻ることは素晴らしい動きだと思います。 MSBuildは機能します。公平を期すために、ほとんどの部分で非常にうまく機能します。新しいものに置き換えるのではなく、新しい問題を引き起こし、互換性の問題を引き起こします。 当時重要だった小さな問題スペースしか解決できなかったことに気付くまで、誰もが書き直して改善できると考えています。その後、拡張したいときに、同じ古いものを再構築していることに気づきます。あなたは最初に交換しようとしました。 すでに機能しているものを改善する方が良いです。

これは、新しいクロスプラットフォームランタイムを実装するのではなく、Monoを改善してギャップを埋めることをおそらく好んだ理由でもありますが、それは別の議論です。

最終調査結果：100の回答、900万の.NET開発者人口に対して、95％の信頼度で±10％。

project.jsonへの移行は気に入りましたか？
はい、それは私の最も期待された機能の1つでした19.19％
はい39.39％
いいえ13.13％
いいえ、16.16％を取るのはひどい方向でした

MSBuildに戻って満足していますか？
はい、今はそれを採用することを考えることができます9.09％
はい16.16％
いいえ30.30％
いいえ、これは.NET Coreが29.29％を取っている方向性に疑問を投げかけます
気にしない15.15％

MSBuildが改善されると思いますか
改善されましたか？ すでに完璧です。 1.01％
はい63.64％
いいえ12.12％
それは根本的に壊れています、どうすればそれを改善できますか？ 20.20％
気にしない3.03％

この決定は正しく行われたと思いますか？
はい、チームは船上でフィードバックを受け取り、20.41％になったら方向を変えました
はい6.12％
いいえ24.49％
いいえ、チームはコミュニティを巻き込むことなく、説明のつかない非公開の決定を下しました39.80％
気にしない9.18％

この決定は、.NET Coreの認識にどのように影響しますか？
それを改善し、彼らはついに正気に近づいています13.00％
それを11.00％改善します
それを悪化させる42.00％
さらに悪いことに、全体に疑問を投げかけます18.00％
気にしない16％

100人が調査を行いました。 今まで知らなかった。 100人はせいぜい悪い冗談なので、代表的な番号があるときにもう一度見てみましょう。

実際、示されているように、100人の場合、95％の信頼度で±10％の許容誤差が得られます。 真の反射を見ていることを確認するには、どの程度の信頼が必要ですか？ 900万人の開発者全員を調査する必要がありますか？

project.jsonを残りのVSに拡張するためのUserVoiceへの800票も、傾向を示していませんか？

そして、真に代表的なサンプルを作成する場合は、Microsoftがそれを実行する必要があります。 彼らは一度もこの決定について意見を求めたことが後でも。

彼らは私が個人的な調査をするよりもはるかに良いリーチを持っているでしょう。 SurveyMonkeyプランをアップグレードして、100を超える結果にアクセスするには、コストがかかります。これにより、Microsoftが自分で行う

意味のある数字が必要な場合は、900万人の開発者の公正な表現を目指したいと思います。 私が100人のTwitterフォロワーを持っていて、私たちが同じ関心を共有しているために私をフォローしている場合、すべての人にアンケートに回答してもらいます。100人の人々が、特定の1つの開発者グループのみを表す非常に一方的な見方をしています。

MSBUILDを復活させるためのスタンドアップで与えられた正当化は、既存のツール間の統合を可能にし、既存のプロジェクトが.NETコアをより簡単に利用できるようにすることでした。 ただし、かなり大規模なプロジェクトを.NET Coreに移行した後、正直に言うと、プロジェクトシステムは私の課題の中で最も少ないものでした。 したがって、それを唯一の正当化として使用することは、私には大きな理由のようには思えません。 また、ファイルを手動で編集するなど、csprojシステムで何年も働いてきました。 それはいつも苦痛でした。 project.jsonベースのシステムは、はるかにシンプルで、すべての人（初心者を含む）にとってはるかに親しみやすいものです。 これが目標だと思います。 それでも今、MSBUILDを復活させることで一歩後退しています。 私の個人的な意見では、これは大きな間違いです。 project.jsonを維持するために投票しました。

実際、私にはTwitterのフォロワーがほとんどいません。それらは、主に、Twitterストリームを投稿した.NETCore開発者のフォロワーです。

そして繰り返しますが、確かにそのような調査を行うのに正しい人はマイクロソフトでしょう？ 実際に人々に何が欲しいのかを尋ねるのは私だけに任されているのはなぜですか？

なぜMSは人々が考えていることを気にしないのですか？

TBH 30分前まで調査があったことを知りませんでしたし、あなたが個人的に調査をしていることも知りませんでした。 私は同意します...マイクロソフトがこの変更に対する開発者の反応に関心を持っている場合、彼らはそのような調査を実行する必要があります。 しかし、おそらく彼らはすでに宿題をしているので、これが彼らがこの変更を行っている理由です。 わかりませんが、いつもネガティブに見えるとは限りません。結局、これらの人たちが私たちのためにこのようなものを構築しているので、彼らは私たちにとって最高の関心しか持っていないはずです。

彼らが宿題をしていたら、開発者の60％がこの動きに反対していることを知っていたでしょうし、それに応じてコミュニケーションを取り、関与していたでしょう。 彼らはそうしませんでした、それは彼らが反応の見当がつかなかったことを意味します、それは彼らが従事しなかったことを意味します。

私はVSのエンタープライズライセンスの有料顧客です。 何も見えませんでした。 私は4つの優良フィンサービス会社で働いており、企業の顧客にも支払いをしています。 彼らは何も見ませんでした。 では、彼らは正確に誰と関わったのでしょうか？ 私は昨夜からその質問をしてきましたが、それに対する返答はありません。

これは、.NET Coreストーリーの基本的な部分、つまり未来の核となるものとして私たちに伝えられた部分への大規模で最新の変更であり、私たちは（おそらく愚かにも）それらを彼らに受け入れたので、私は物事を否定的に見ていますつまり、この技術に基づいてCD / CIパイプラインを構築しましたが、これは今ではまったく価値がありません。 私はまた、意思決定の詳細を尋ねる丸一日の間に完全なラジオの沈黙があったので、それを否定的に見ています。

私が聞いたところによると、彼らはツールメーカーを助けるためにユーザーをバスの下に投げ込んだようです。 もしそうなら、彼らは私からではなく、ツールメーカーから私のVSライセンス料を徴収することができますか？

@shederman私はあなたの調査の結果に同意しますが、その質問は明らかにjson形式を維持するという好ましい方向に傾いており、それは実際には良い調査にはなりません。 私はそれを楽しみのために取りました、そして私はその結果を真剣に受け止めませんでした（申し訳ありません）。 私はmsbuildやその他のもののファンではないので、なぜ両方を使用できないのか疑問に思います。いずれかの方法でオプションにします。 私はjsonが大好きです、それは私の友達です。

理想的な調査ではないことに同意します。 5分で作成しました。 重要なのは、なぜ私がそれを作成するのかということです。

なぜマイクロソフトは人々がどう思うかを知ることに興味がないのですか？

予想していた回答は30件程度でしたが、大雑把に意見を述べるのではなく、議論を再開し、率直に意見を共有し、適切に関与するよう説得するだけで十分だと思いました。

現在138件の回答がありますが、Microsoftの決定が悪いものだったと考えても、Microsoftの兆候はまだありません。 事実に裏付けられていない、非常に漠然とした手を振る説明。

私が望んでいるのは、この決定に適切に関与することです。 秘密情報とフィードバックに基づいて密室で行われた主要な決定ではありません。 これは公然と透明性を持って行われるべきであり、このプロセスで唯一欠けている言葉です。

ああみんな来ます。 Microsoftはフレームワークを所有しており、彼がやりたいことを実行できるようにしています。 しかし、ちょっと考えてみてください。人々は2014年3月から4月にかけてこれに取り組んでおり、リリースの1か月前に、このような劇的な変化を起こすのはばかげています。 それは開発者の信頼を壊します。 それは人々の時間を無駄にします。 コミュニティを信頼できない場合は、オープンソースフレームワークを作成する必要はありません。 暗い部屋でこの種の変更を行ったときに誰も気にしないように、すぐにソースを閉じてください。

マイクロソフトの弁証学者と同情的（MVPまたはコミュニティメンバー）に、今回は現実的にお願いします。

@shederman

彼らが宿題をしていたら、開発者の60％がこの動きに反対していることを知っていたでしょう。

.netエコシステムの開発者の20％以上が、project.jsonの存在さえ知っているとしたら、私は驚きます。 私たちは、新しい技術開発の最前線に乗って、開発者のバブルの中に住んでいることを時々忘れます。

project.jsonの魅力の多くはそのシンプルさだと思います。 ただし、3年前のASP Net Insidersで最初に導入されて以来、開発を続けていると、より多くのユースケースをサポートしようとするため、複雑さが増し始めています。 .netエコシステム全体をサポートするために、私は最愛のシンプルさの多くが失われるのではないかと心配しています。

これは、project.jsonがいくつかの素晴らしい新機能をもたらさないということではありません。プロジェクト形式をより人間的にアクセスしやすくすることは良いことだと思います。 ただし、MSBuildにその良さをもたらすことは、project.jsonをどこにでも持ち込もうとするよりも早く達成可能であり、はるかに多くの人々に利益をもたらすと思います。

.netエコシステムの開発者の20％以上が、project.jsonの存在さえ知っているとしたら、私は驚きます。

.net ecoの開発者がMVCとWebApiについて知っているのは20％未満だと思います。 70人以上がWebForms、WCF、WebServiceを使用しています。 もう一度、マイクロソフトの弁証学者にお願いします。同情してください。現実的にしてください。

@shederman調査結果からの信頼に関するレポートは、.NET開発者全体にとっておそらく正しくなく、...の代表的なサンプルでさえない可能性があります。 "これらは主にランダムなサンプルではあり

人口全体の調査に基づいて、有用な統計的結論を引き出すことはできません。 しかし、あなたが調査をしてくれてうれしいです。 あなたは多くの優れた点を提示します。 結果は、多くの人々が変化に動揺しているか心配していることを示していると思います。 ただし、誤った統計的結論を公表しないでください...事実上無意味な数字を

では、市場ベースの70％以上を悩ませるのであれば、何かを変える意味は何でしょうか。 私たちのいる場所に正確にとどまり、漸進的な進化を続けましょう。 壊れていないのなら直さないでしょ？

project.jsonが複雑さを蓄積していることを私は知っています。 私はその点に100％同意します。 マージしてcsprojに戻すソリューションはありましたか？ 私は以前に人々に言った、私は急いで出荷するのではなく、物事を正しくするためにマイクロソフトに完全に遅れをとっている。 csprojへの移行は急いでいるようです。

なぜRC2の後にこれを行うのですか？ これはどこから来たのですか？ Xamarinの買収はこれと関係がありますか？ それはdotnet-cli統合でしたか？ それは大きなクライアントでしたか？ 知るか...

RC1-> RC2が最高だったと大衆に説明することができました。 dotnetcliと統合されています。 しかし、project.jsonは変更されますか？ 私はそれを説明するために言うことは何もありません。 わからない。 人々は混乱していて、私には彼らに対する説得力のある議論はありません。

なぜRC2の後にこれを行うのですか？ これはどこから来たのですか？ Xamarinの買収はこれと関係がありますか？ それはdotnet-cli統合でしたか？ それは大きなクライアントでしたか？ 知るか...

これがポイント思考です。 csprojへの移行の背後にある完全なストーリーはわかりません。 今では、身を乗り出してリラックスし、これが起こっている理由を見て理解する代わりに、誰もがマイクロソフトを罵倒し、最悪の事態を想定しています。 これは意味がありません。 これらの人たちは私たちと私たちだけのためにこのようなものを作っています。 コミュニティ全体を失うリスクがある場合、1人の大口顧客は無価値であるため、1人の大口顧客のために彼らは間違いなくそのような変更を行いません。 Microsoft .NETエコシステムはHUUUUUUGEであり、.NET Coreをそれにうまく適合させることは明らかに複雑な作業です。そのため、少し冷静になって、これらの人たちの背後に賢い人がいると想定して、正しい決定を下すことをお勧めします。私たちはそれから最も恩恵を受けることができます-長期的です。 私はここから出ています。なぜなら、この否定的な時期尚早の憶測はすべて私を退屈させているからです。

@darrelmiller申し訳ありませんが、私が60％と言うとき、私は調査に回答した人の60％を意味します。

@GuardRexあなたは絶対に正しいです。 適切な結果を得ることができる唯一の組織はMSであり、彼らは気にしていないようです。

私の調査は、統計的に有意なサンプルを提供するためではなく、漠然としたレベルのサポートを測定することを目的としていました。 私はこの決定を開くのに十分な不幸があることを示したと思いますが、彼らのラジオの沈黙が何らかの兆候であるならば、マイクロソフトは同意しないようです。

ここに質問があります：MSがおそらく間違いを犯したことを認めるのに正確に何が必要でしょうか？ 彼らに議論を再開させるには何が必要でしょうか？ 現時点では、答えは「私たちはあなたの視点を気にしない、私たちの決定は有効であり、理由を共有するつもりはない」と思われるためです。

私は皆が少し落ち着いて、これらの人がその後ろに何人かの賢い人々を持っていると仮定して、私たちがそれから最大の利益を得ることができるように正しい決定をすることを提案します-長期

それは私が言ったことです。なぜなら、その背後にいる賢い人々は常に正しく、オープンソースコミュニティはばかだからです。

@shederman 「統計的に有意なサンプルを提供しない」...それは問題ありませんが、調査をそれ自体のメリットに立たせて、この行を削除していただければ幸いです...

最終調査結果：100の回答、900万の.NET開発者人口に対して、95％の信頼度で±10％。

それは本当に危険な部分です。 .NET開発者の60％がこの変更を嫌う、または嫌うのは正確かもしれません。 ただし、そのサンプルでは表示できません。 ええ、多くの開発者が変更とその処理方法について大きな懸念を抱いているとだけ言って。 それは明らかであり、調査はその点を非常によく強調しています。

@abcplex ：オープンソースは、16人がGitHubで問題を開いてジャンプを叫ぶたびにジャンプする必要があるという意味ではありません。

@MaximRouillerスタンドアップノートは、変更の動機を説明するのにかなり良い仕事をします。 そして現実には、私が読んだように、xprojはcsprojに置き換えられ、project.jsonはnuget.jsonに名前が変更される可能性が高く、_some_のものはproject.jsonから移動されます。

そして、スタンドアップで行われたコメントから、これはかなり最近の決定であり、コミュニティはほぼ即座に伝えられました。project.jsonはRTMが終了するまでどこにも行かないため、変更が再び発生する可能性があります。

私には、これはおそらく起こった可能性のある最も包括的で透明なプロセスのように思えます。

@darrelmillerそれ、私はあなたに同意する必要があります。 かなり透明です。

彼らがフィードバックを望んでいたなら、私は彼らがそれを得たと思います。 いずれにせよ、それと戦うことはありません。 人々は話しました。 マイクロソフトは耳を傾けました。 それが彼らが何かできることなのか、それとも彼らの手が結ばれているのかを見てみましょう。

時間だけが今私たちに教えてくれます。

問題は彼らの透明性にあったとは思いません。 彼らは透明であるという素晴らしい仕事をしました。 問題は、コミュニティがこれについてどう思っているかを知らずに、彼らが大きな決定を下していることだと思います。 委員会による設計は不可能だと思いますが、多分彼らは、この変更と同じくらい基本的な何かのために、彼らが調べた賛否両論のリストを文書化し、それをコミュニティに提示すべきでした。 うまくいけば、彼らはすぐにそのタイプの情報を投稿するでしょう、しかしそれでも、それはすでに決定がなされているように思えます。

これは、他の誰よりもアーリーアダプターに影響を及ぼします。

JSONは読みやすくなっていますが、それは単純な場合に限られます。 私の意見では、 </system>は]}よりも理解しやすいです。

ここでの最も合理的なコメントは、プロジェクトのアンロード/ロードおよびXMLに固有の冗長性を必要としない依存関係管理に関する私自身の考えを反映しています。

それは本当にJSONとXMLについての議論であるべきですか？ 私見は本当に関係ありません
（確かに、個人的にはXMLよりもJSONが好きですが、これは重要ではありません）

ASP.NET Coreについて私が本当に気に入っているのは、それがかなりオープンで、VisualStudioや他のIDEから独立していることです。 これがまだ与えられている場合、私はこの決定に問題はありません。

この号では非常に多くの有毒な議論が行われており、多くの人々が視力を失う原因になっていると私は感じています。 一般的な議論は「MSBuildが悪い！」のようです。 しかし、両方のアプローチの良い点と悪い点について十分に理解されていません。

これは「後退」であると言うすべての人にとって、これは「csproj」に戻りますが、私たちが何年も持っていたcsprojファイルとは_同じ_​​ではないことに注意してください。 1つは、「新しい」csproj形式のファイルのリストは表示されないことを明確に述べてい

すぐにそれはすぐに違います。 今日のxprojを見てください。そうすれば、「新しい」csprojに何が期待できるかがほぼわかります。 少し大きくなりますが、project.jsonからいくつかの追加のプロパティが取得されるためです。 実際の議論は、「MSBuildがどれほど悪いか」ではなく、新しいcsprojに何を表示し、.jsonファイルに何を残したいかについてではありません。

@dustinmorisあなたは不公平です、私はコミュニティがほとんどの変更を歓迎したと思いますが、これは。 これは私たちを後退させており、彼らはすでにその理由についての洞察なしにそれをどのように行うかについて話し合っています。 彼らは決定が最終的なものであるように聞こえるので、コミュニティがより良い提案を思い付く場所はありません。

はい、プロジェクトファイルを直接編集し、project.jsonの前に苦労して編集していました。 Msbuildは部族の知識がすべてであり、それを習得するのは少し難しくなります。

そして、「。net4.5から.netcoreへの移行が容易になる」というのは少し不誠実なようです。 これは間違いなく問題点ではありません...

それは私たちが何年も持っていたcsprojファイルと同じではありません。

XMLになりますか？ ええ、そう思いました。

ほとんどの人がproject.json形式を気に入っている主な利点と主な理由は、このファイルのリストがないことです。

あなたはこれをどのような情報に基づいて言いますか？ つまり、ファイルのリストがないことは大きなプラスですが、私にとっては決して唯一のファイルではありません。

今日のxprojを見てください。そうすれば、「新しい」csprojに何が期待できるかがほぼわかります。

今日はxprojを持っていません。 なぜ私はそのようなものが必要なのでしょうか？

本当の議論は、「MSBuildがどれほど悪いか」についてではなく、またそうすべきではありません。

なぜそれが議論になるべきではないのですか？ ターフィングMSBuildは、.NETCoreを採用した大きなプラスポイントでした。 私の（明らかに）非科学的なエコーチェンバーの偏った調査の回答者の20％は、それが根本的に壊れていることに同意しています。

@shedermanあなたの反応は、まさに私が言及している一種の有毒な議論です。 あなたは一般的な主張をしているだけですが（「MSBuildは悪いです！」など）、建設的な議論でそれらを裏付けているわけではありません。

XMLになりますか？ ええ、そう思いました。

はい。 と？ 問題が_XML_が気に入らないことである場合は、十分に公平です。 JSONがXMLよりも優れていると思われる場合は、先に進んで理由を説明してください。ただし、それは_プロジェクト構造_や構文とは関係ありません。 残念ながら、XMLとJSONの両方が世界でその地位を占めており、両方に明確な長所と短所があり、どちらが優れているかについての決定的な「正しい」答えは決してありません。 繰り返しになりますが、もし私があなたなら、_プロジェクト構造_の違いが移動によってどうなるかに集中します。

あなたはこれをどのような情報に基づいて言いますか？ つまり、ファイルのリストがないことは大きなプラスですが、私にとっては決して唯一のファイルではありません。

私はそれが唯一の利益であるとは決して主張しませんでした、私はそれがはるかに_主な_利益であると単に言いました。 数か月前にさかのぼるproject.json形式についての議論を見てください。人々が最初に話すのは、それがどれほど小さくて単純かということです。 これは、JSONが構文的にクリーンであるためではなく、プロジェクトファイルのリストを削除することになります。 人々が言及する最大のプラスは、それがうまくマージされ、ファイル参照の束がリストされていないため、うまくマージされることです。

今日はxprojを持っていません。 なぜ私はそのようなものが必要なのでしょうか？

この全体の議論は、新しいプロジェクトファイル形式に関するものです。現在の状況を比較したくない場合、あなたの意見は情報に基づいていないものになります。

なぜそれが議論ではないのですか？ ターフィングMSBuildは、.NETCoreを採用した大きなプラスポイントでした。 私の（明らかに）非科学的なエコーチェンバーの偏った調査の回答者の20％は、それが根本的に壊れていることに同意しています。

あなたは実際には_MSBuild_について話し合っていないので、Visual StudioがこれまでMSBuildプロジェクトを処理してきた方法について話し合っています。これは、Microsoft自身が貧弱だと認めています。 MSBuildは、プロジェクト内のすべてのファイルを一覧表示する必要がないなど、すでに必要なほぼすべてのものを実際にサポートしています。

もっと要点を言えば、この議論でこれまでに行ったことは、XMLが好きではないという悲鳴と叫びだけですが、「これは、私が何度も述べてきたように、一般的に「古い」csprojにリストされているファイルの量にまで低下します。 xproj形式をわざわざ見てみると、非常に小さいことがわかります。ダニエルは、スタンドアップ中に、「新しい」csproj形式は現在のproject.jsonファイルとほぼ同じサイズになると言いました。問題？ あなたは大胆な主張をしますが、それらをまったくバックアップしません。

@neoKushan正当な理由もなく、Microsoftから何らかの賞を守ることで、すぐに何らかの賞を獲得できるはずです。 これは裏口で行われた最悪の決定であるということを実感してください。 asp netを再びクローズソースにして、Microsoftとuのようなサポーターが、オープンソースコミュニティのメンバーに尋ねることなく、何をしたいかを決定できるようにすることをお勧めします。

@abcplex名前を呼ん

これまでのところ、実際の問題が何であるかを1つの理由だけで説明せずに、変更について文句を言うだけです。

@neoKushanの最大のポイントは、この種の変更の時期ではなく、ちょうど1か月前にRTMに移行したことです。 今回この変更を行っても意味がありません。

@abcplex変更はRTMでは発生していません。 これは、 RTM後の段階的な

JSONとXML（対XAML、一部の人々がそれを求めているStandup Blog Postのように）は、以前のツールとのあらゆる種類の下位互換性を持つことのメリットから気をそらすものであることに同意します。

そして、これは非常に誤った考え方であると私は主張します。 好むと好まざるとにかかわらず、csprojとMSBuildは、プロジェクトを定義するのではなく、ツールチェーンにプロジェクトの構築方法を指示するというantの伝統に従います。 これらは非常に異なるものですが、この遺産はプロジェクトに「定義」力を与えているようです。これは、プロジェクトにロジックを適用できるようになったためです。 それがすることは物事を信じられないほど複雑にすることです。

旧世界では、「一番下にある必要がある」行が上に移動した、または誰かが環境変数を台無しにして突然間違った.targetsファイルを取得したために、プロジェクトファイルが壊れているのを何度も目にしました。 宣言型構文では、第1レベルの要素（ルートの子）が順序に依存しているという概念は完全に破られています。 それがMSBuildとcsprojの土地です。 これが私たちがここに持ち帰っている遺産です。 ここで、csprojを理解するには、それを「実行」し、MSBuildとまったく同じように実行する必要があります。 はい、MSBuildはオープンソースですが、実際には何も修正されていません。 それでも、単一の強制的な依存関係が導入されます。 それはまだどこかにある魔法のターゲットファイルに依存しています。

プロジェクトファイルには、特定のショップが使用することを決定したツールチェーンの形状にとらわれないいくつかの品質が必要です。

• 人間が編集可能/読み取り可能である必要があります
• コメントを許可する必要があります
• 宣言型である必要があります
• 自己完結型である必要があります
• 可能であれば、マージの競合を減らし、マージを簡素化するように設計する必要があります
• 完全に文書化できる必要があります（文書化に自己完結の原則が適用されます）
• ツールに依存しない必要があります

そして、「。net4.5から.netcoreへの移行が容易になる」というのは少し不誠実なようです。 これは間違いなく問題点ではありません...

100％同意しました。 私たちにとっての課題が何であったかを明確にしましょう。コードベースの移行に関するこれまでの唯一の問題は、特定の.NETクラスライブラリ（System.Drawingを参照）の喪失、.NETCoreのサポートにおけるMicrosoftチームの躊躇でした。 （DocumentDBを見て）そしてメジャーバージョン間で予想される標準的な重大な変更。

project.jsonが問題になることはありませんでした。 実際、それは利点の1つでした。 Ctrl + Shift + Bのときに魔法のように発生する非表示の詳細にMSBuildをダンプできることも同じです。

@neoKushan

1. XMLは好きではありません。 これは、プロジェクトファイルと構成ファイルには不適切な形式です。 「XMLforeverything」フェーズで導入されたときは悪い考えでしたが、今では悪い考えです。
2. JSONファイルはXMLファイルよりもはるかにうまくマージできることがわかりました。 私はこれが意見であることを認めますが、それは私のものであり、私の経験に基づいています。
3. xprojファイルを必要としないvscodeを使用しています。 _それ_は私の現在の状況であり、私にとって何の意味もないxprojファイルは必要ありません。
4. いいえ、MSBuildについて話し合っています。 私はMSBuildとTeamBuildでたくさんのことをしました。 彼らは決して楽しくも簡単でもなかったし、泥の中で豚と格闘することを常に含んでいた。 私はMSBuildを_嫌い_ですが、私は間違いなく一人ではありません。
5. MSBuildを使用すると、単純なタスクでも困難になります。 MSBuildに目がくらむのではなく、代替案を検討することをお勧めします。 特に、gulpとsbtがどのように機能するかを見てください。

@shederman

XMLは好きではありません。 これは、プロジェクトファイルと構成ファイルには不適切な形式です。 「XMLforeverything」フェーズで導入されたときは悪い考えでしたが、今では悪い考えです。

これのどれもそれが悪い考えである_理由_を説明しません。

JSONファイルはXMLファイルよりもはるかにうまくマージできることがわかりました。 私はこれが意見であることを認めますが、それは私のものであり、私の経験に基づいています。

私は悪夢の.jsonマージと悪夢の.xmlマージを行ってきましたが、マージに関してはどちらも特に好きではありません。 私の経験では、形式に関係なく、問題のあるマージの可能性はファイルの_size_とともに増加します。

xprojファイルを必要としないvscodeを使用しています。 それが私の現在の状況であり、私にとって何の意味もないxprojファイルは必要ありません。

これは、現在のxprojファイルを理解できないという意味ではありません。 そうしないことで、あなたはあなたの耳に指を刺し、目を閉じて「ラ・ラ・ラ」と言うのと同じことをしているのです。
言い換えれば、変化が起こっているという事実に腹を立てて、それについてうめき声を上げて何も達成しないか、実際の会話に参加してこの結果を導くのを手伝うことができます。

たとえば、まだ決定されていないことの1つは、nugetの依存関係がcsprojの一部になるのか、それともnuget.jsonになるのかということです。そこに好みがあります。 依存関係のリストを.jsonファイルに入れたら、csprojに何を残しますか？ それはどのくらいの頻度で変わりますか？ マージするのはどれくらい難しいでしょうか？

個人的には、すべてが1つのプロジェクトファイルに含まれていることを望んでいますが、プロジェクト自体からnugetを分離することの魅力と利点を理解できます。 両方に長所と短所があり、おそらく最善の解決策は、両方を許可し、依存関係のリストを含むcsprojを用意するだけでなく、代わりに依存関係を含む.jsonファイルを指定できるようにすることです。 MSbuild自体にいくらかの複雑さを追加することを犠牲にして、両方の世界とすべての人のベストが勝ちます。

いいえ、MSBuildについて話し合っています。 私はMSBuildとTeamBuildでたくさんのことをしました。 彼らは決して楽しくも簡単でもなかったし、泥の中で豚と格闘することを常に含んでいた。 私はMSBuildが嫌いで、私は間違いなく一人ではありません。

TFSのXAMLベースのビルド定義を処理する必要があったので、少なくともこれ（の一部）については同意できます。

MSBuildを使用すると、単純なタスクでも困難になります。 MSBuildに目がくらむのではなく、代替案を検討することをお勧めします。 特に、gulpとsbtがどのように機能するかを見てください。

次に、おもちゃを乳母車から投げ出すのをやめて、「新しい」プロジェクト構造が「実際に」どのように見えるべきかについての議論に積極的に参加することをお勧めします。 XMLベースのプロジェクトファイルを処理する必要がある将来を想像してみてください。そのプロジェクトファイルを実際にどのように見せたいですか？

XMLベースのプロジェクトファイルを処理する必要がある未来を想像してみてください

ええとさて、私は私が望まない未来を想像し、それがどのように機能するかをあなたに説明しなければなりませんか？ ええと、私はそうは思いません。 むしろ、いくつかの最新の、より革新的なビルドシステムを見てみましょう。 ご存知のように、XMLを遠い過去に残したものです。

どうですか：

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

または多分

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

そうそう、あなたがリンクしたそのxprojはとても良いです。 素晴らしく、明確で簡潔です。 そして表現力豊かな、表現力豊かなことを忘れないでください。 そのProjectGuidは何のためのものですか？ そして、ツールのバージョンを設定するための90文字が大好きです。 そして、DnxInvisibleContent？ それは私のビルドシステムが知るのに役立ちますか？ 実行していないIDEに表示されないファイルはどれですか？

乳母車からおもちゃを投げるのをやめることをお勧めします

したくない:-)

いや、終わった。 イモと長いおしゃべりをしていて、私はこの戦いを終わらせています。 誰もが部分的な見方をしており、自分たちのやり方がすべての人にとって完璧ではないかもしれないというとんでもない概念を誰も聞きたがりません。

[不機嫌を取り除くために編集]

@shederman ：ここにビルド定義ファイルを表示します。 プロジェクト定義としてのビルド定義から離れたい。 生成方法の説明とは関係なく、生成されるプロジェクト/アーティファクトに関する静的な詳細を定義するためのスペースがあります。 2つを統合することは、MSBuildファイルをプロジェクトファイルとして使用する際の大きな問題の1つです。

生成するアーティファクト、使用する依存関係とツールチェーン、およびディスク上のプロジェクトを構成するさまざまな要素のレイアウトを説明するために必要な情報だけを指定できるようにしたいと思います。 他のすべては分離する必要があります。 内部でMSBuildを使用する場合は、すぐに実行してください。 あなたがgulp、またはbabelまたはwhat-have-youを好むなら同上。 私にとって、それはproject.jsonが行うように設定されたものです。 （私はそこでコマンドを定義する機能のファンではありませんでしたが）

ええ、それは理にかなっています。 それは私がproject.jsonについて気に入った点の1つでした。 それは「方法」ではなく「何」を定義しました。 1つのファイルに多くのものを入れると、特にIDEが愚かである場合、ファイルが複雑になりすぎます。 そして、そのようなものは、エディターや単純なIDEには必要ありません。

VS Codeのような儀式の少ないUIからは、プロジェクトシステムはそれほど必要ありません。 それはすべてビルドです。 その多くは宣言型であり、何を構築する必要があるか、メタデータを示しています。 どのステップを実行する必要があるかを言うために、いくつかは必須かもしれません。

ええ、MSBuildsの最大の問題は、すべてを1つのシステムで実行しようとすることです。

私が把握していないのはこれだと思います。project.jsonを機能させるだけでなく、プロジェクトシステムとしてMSBuildを使用することで改善されるいくつかのユースケースを示してください。 見えません。 たぶん私のユースケースは単純すぎるので、いくつか見せてください。

@shedermanスタンドアップノートには、プロジェクト間でソースファイルを共有できるようにする必要があることが記載されています

つまり...これはオープンソースプロジェクトであり、Microsoftが「存在する力」であることは知っていますが、これが人々にとって非常に重要である場合、ここで無知な質問をしていることになります。 .NET CoreがMSBuildの代わりにproject.jsonを引き続き使用できるようにするには、/ effort / energyを消費する必要がありますか？ 十分な数の人々が貢献し、コードが十分に優れている場合、なぜMSはそれをこのプロジェクトに受け入れないのでしょうか。 オープンソースの美しさ（そして失敗）の一部は、プライマリメンテナが他の人から提供されたものの多くを拒否した場合にコードをフォークするという脅威です。 オープンソースであるコードのポイントの一部は、単に見るだけでなく、修正して改善することです。

この変更についての私の個人的な見解は、将来の計画に関するものであるという点で、Xamarinと関係があるということです。 また、最近のスタンドアップでは、コンソールアプリの構築を第一級市民にしたいと言っているのを聞いたと思います。 当初、新しい.NET（ASP.NET 5 + DNX）はWebアプリの構築に重点を置いていましたが、現在はそれ以上のものになっています。 これらはすべて比較的最近に発生し、.NETチームとASP.NETチームが統合され、Xamarinも購入されました。 彼らは、これらの複数のシナリオ（およびここでは推測しない新しい将来のシナリオ）をサポートするためのより良いプロジェクトシステムが必要であり、.NETCoreもすぐに出荷したいと考えているという結論に達しました。 何をすべきか？ 必要なものをすでに処理し、最初から開始できる既存のMSBuildを完全に無視しますか？ 申し訳ありませんが、私は私が選択するパスを知っています。

プロジェクトファイルにプロジェクト内のファイルの名前が含まれていない場合、および依存関係が別の構成ファイルにプッシュされる場合、プロジェクトファイルが変更されるため、マージの問題は解消されるはずです。比較的まれです。

私の意見だけ

マージの問題は1つの問題にすぎません。 MSBuildから離れることは別です。 このシナリオのクレイジーな結果の1つは、MSBuildをLinuxとOSXに移植するために時間と労力を費やすことになります。 想像してみろ。

私は彼らの理由を理解していますが、彼らの理由は私にはまったく効果がなく、多くの人には効果がありません。 私たちは彼らが取っている方向性についての確固たる保証に基づいて投資を行い、彼らは説明責任をゼロにしてそれに戻ってきました。 彼らは、MSBuildがサポートするエッジケースと、それらのエッジケースをサポートするのがどれほど難しいかに基づいてproject.jsonを決定しています。 まあ、それはそれが使用されるのを決してやめないことを意味します、なぜなら彼らの正しい心の誰もそれらのすべてのエッジケースをサポートしないからです。 確かに、ASP.NETプロジェクトを実行している人は、これらのエッジケースを必要としません。

フォークすることは可能ですが、すべてがどれほど大きく統合されているかを考えると、関連するコードを学ぶことさえ検討することは困難な見通しです。 現実には、これは実際にはオープンソースプロジェクトではなく、Microsoftプロジェクトであり、彼らは私たちの意見なしに企業の決定を下しました。私たちはそれを吸い上げて受け入れる必要があります。 どんな反対があったとしても、彼らが再考する可能性は基本的にないことが私には明らかにされました。

つまり、私たちが労力を費やしてproject.jsonビルドシステムをフォークするか、別のビルドシステム（FAKE？）に切り替えるか、それを吸い上げるか、別のプラットフォームを使用するかのいずれかです。 私はそこにすべての選択肢を列挙したと思います。

@shederman MSBuildは2015年の初めからオープンソースであり、ビルドはOSX / Ubuntuに渡されているため、移植するほどの作業はないと思います（https://github.com/Microsoft/msbuild） 、リポジトリを閲覧すると、たとえば3月にOSXがOKを構築していたように見えます。

まあ。 私たちはこれを行うべきかどうか心配しています、そして彼らは立ち去ってそれをしました...

フランケンシュタインの怪物が遠くに飛び出すのを見ている人のように少し感じてください。 興味があり、興味をそそられ、心配していて、少しうんざりしている:-)

@darrelmillerスタンドアップノートには、プロジェクト間でソースファイルを共有できる必要があることが記載されています

本当に？ 人々はまだそれをしますか？ つまり、AssemblyInfo.csでこれを行っていたのですが、暗黒時代に戻ると、StrongNameキーを共有ソースファイルに入れていました。

さて、それはユースケースですが、今は本当にユースケースのユースケースを聞きたいです。 興味をそそられました。

@shederman

ええとさて、私は私が望まない未来を想像し、それがどのように機能するかをあなたに説明しなければなりませんか？ ええと、いいえ、私はそうは思いません

JSONの代わりにXMLを受け入れて、どのようなメリットがあるかを確認するだけですが、実際に理由を説明せずにXMLの悪さについて話すだけなので、そのゲームをプレイする気はありません。

まあ。 私はこれを行うべきかどうか心配しています、そして彼らは行ってそれをしました...

彼らは文字通り何年もの間「立ち去ってそれをやっている」のです。 彼らは何年も前にオープンソーシング.netについて話し、ロードマップを提供し、最終的にはあらゆるユースケースのあらゆるプラットフォームで実行することを明確にしました。

あなたはこの変更にかなり腹を立てており、この変更に腹を立てている人の大多数はすべてWeb開発者だと思いますが、それは.netエコシステムのほんの一部であり、サービス、モバイル、クラウドの開発者の巨大なエコシステムがあります。 .netコアに移植できるようにしたいコードのライブラリ。 好むと好まざるとにかかわらず、project.jsonは現在これらすべてのモデルで機能するわけではありません。 あなたは「それを機能させる」と言いますが、明確で明確に定義された構造を持たず、さらに悪いことにコメントがないものを除いて、別の厄介なプロジェクトファイルになってしまいます。 その最後のポイントは、project.jsonを再考するのに十分な理由です。

そうそう、あなたがリンクしたそのxprojはとても良いです。 素晴らしく、明確で簡潔です。 そして表現力豊かな、表現力豊かなことを忘れないでください。

少なくともあなたはついにそれを見ました。 あなたが気にする前に、この問題で72のコメントが必要でしたか？ 私はあなたにこれを言い続けます、しかしあなたはそれを理解していません：MSBuildがどれほどひどいのかについて不平を言う代わりに、なぜそれがひどいのかについて話してください。

マージの問題は1つの問題にすぎません。 MSBuildから離れることは別です。

なぜこれが問題なのですか？ あなたはMSBuildが嫌いです、私たちはそれを理解していますが、XMLを使用することが_大胆_であるという事実を除いて、MSBuildについて何が嫌いですか？

このシナリオのクレイジーな結果の1つは、MSBuildをLinuxとOSXに移植するために時間と労力を費やすことになります。 想像してみろ。

あなたが正しい！ これはひどいことであり、必要なIDEを使用して、任意のプラットフォームで任意の種類の.netアプリを開発できます。 子供たちのことを考えてください！
マイクロソフトが自社のクローズドソース技術に投資する代わりに、自分たちの仕事をオープンソーシングし、ツールを他のプラットフォームに移植することに時間を費やすなんてあえて。

私は彼らの理由を理解していますが、彼らの理由は私にはまったく効果がなく、多くの人には効果がありません。

しかし、おそらく彼らはあなたよりもはるかに多くの人々のために働いていますか？

私たちは彼らが取っている方向性についての確固たる保証に基づいて投資を行いました、そして彼らは説明責任をゼロにしてそれに戻ってきました、そしておそらく彼らが決定をよりよく伝えるべきだったという兆候にすぎません。

何を指しているのですか？ 目標は常にどこでも.netであり、「あらゆる開発者、あらゆるアプリ、あらゆるプラットフォーム」がその日の信条であり、それに影響を与えるこの変更についてはまったく何もありません。 彼らの目標は、プロジェクトファイルを小さく、シンプルで、人間が読める形式にし、IDEなしで人間が編集できるようにすることであると明確に述べています。 あなたから何も奪われていません。 少しのXMLに対処する必要があるかもしれませんが、それが.netがモバイル、クラウド、およびWebのファーストクラスのエクスペリエンスであることを意味する場合は、それだけの価値があります。

彼らは、MSBuildがサポートするエッジケースに基づいてproject.jsonを決定しています。

これは_edge_の場合をはるかに超えており、project.jsonがほぼ完璧であると示唆するのはばかげています。

確かに、ASP.NETプロジェクトを実行している人は、これらのエッジケースを必要としません。

これが問題の核心だと思います。asp.net開発者である自分以外の人は気にしません。 十分に公平ですが、もう一度言います。他の開発者が重要であることを受け入れ、単に腕を上げるのではなく、最高のシステムにするために努力してください。 これは、完全に異なるマークアップの任意の構文を作成することを意味するので
私が言い続けているように、nuget.jsonがすべての依存関係をリストした場合、何が残っていますか？ XMLの名前付き要素でかなり静的なフィールドを定義することの問題は何ですか？

現実には、これは実際にはオープンソースプロジェクトではありません

他の人が言っているように、オープンソースであることは、少数の不平を言う人に後ろ向きに屈することを意味しません。 彼らはプルリクエストを受け入れ、より良いものを書きに行きます。

すべてがどれほど大きく統合されているかを考えると、関連するコードを学ぶことさえ検討するのは困難な見通しです。

さて、私は基本的にこれを「全体像を理解しておらず、全体像を理解したくない」と読んでいますが、それは私の小さな泡に影響を及ぼし、その影響を完全に無視しているので、それでも文句を言います私のバブルは他の人にあります」。

つまり、私たちが労力を費やしてproject.jsonビルドシステムをフォークするか、別のビルドシステム（FAKE？）に切り替えるか、それを吸い上げるか、別のプラットフォームを使用するかのいずれかです。 私はそこにすべての選択肢を列挙したと思います。

または...そして、これはただのクレイジーで独創的な考えですが、実際に会話に建設的な何かを貢献してみることができます。

トピックに戻る...

私はそれをもっと考えて、現在、project.jsonをnuget.jsonにして、依存関係の管理を現在と同じように維持することに傾倒しています。 現在はうまく機能しており、インテリセンスはすでに存在しており、gulpやnpmなどと一致しています。

csprojに静的パーツを単純に定義させます。

ただし、私が見ることができるこのアプローチの欠点は、複数のフレームワークをターゲットにするときにどれだけうまくいくかわからないことです。それをnuget.jsonに入れるのは意味がないと思いますが、nuget.jsonはまだそれについて知る必要があります。

project.jsonは単なるjsonファイルではありません。
csprojは単なるXMLファイルではありません。

私のような多くの人々は、マイクロソフト、より正確にはAsp.Netチームを見て興奮していました。
非常に古いレガシーコード/コンセプト/システム/ツール/外観/ ...から自分自身を解放します。

これは私たちに「希望」を与えました！

私は最初のプレビュービットからAsp.Netを開発しています。 私は主にそれを扱うのが大好きです。 しかし、15年後、
XMLのような「古い」ものは、​​本当に、本当に重く、時代遅れだと感じます。 知覚は重要です。

XMLがなく、少なくとも代わりにJSONを使用すると、私の「開発者の幸せ」ははるかに大きくなります。
私は物事を扱うことができます、世界の残りの部分は使用することにしました。 私のIDEは、レガシーフォーマットよりもこれらのことを優先しています。
「アングルブラケット税」を支払う必要はもうありません。

project.jsonを削除することは大したことではありませんが、ほとんど最後の瞬間に密室でそれを行うと、その「希望」が即座に失われます。

突然、これはもはやオープンソースプロジェクトのようには感じられなくなりました。

fyi：「Asp.NetCore」には多くの素晴らしい機能があります。 私は主にそれが大好きです。
Asp.Netチームは素晴らしく、Asp.Net開発者であることを誇りに思うことができませんでした。

しかし、私は傷ついています。 多分私だけではありません。

ちょうど私の2セント。

msbuild（特にVSがそれをどのように使用するか）が完璧ではないことにほぼ全員が同意できると思います。project.jsonに興奮している間、MSが私の多くの問題点を修正し、正直に言うと、彼らはおそらく彼らがそれをどのようにしたかについてはそれほど気にしないでしょう。

• csprojのマージはそれほどうまく機能しません。私は、壊れたマージを隔週で手動で修正する必要があることに気付きました。 csprojからファイルのリストを削除すると、ここで大いに役立ちます。
• NuGet参照とプロジェクト参照が常に一致するとは限りません。これもマージが壊れていることが原因である可能性があります。 いずれにせよ、診断して修正するのは面倒です。
• ビルドプロセスにプラグインする必要がある場合がありますが（project.jsonでどのように機能するのかわかりません）、アンロード/ロードが必要なため、ビルドスクリプトのデバッグが面倒なプロセスになります。

彼らがこれらの3つの項目を修正する方法を見つけた場合、私はおそらくcsprojファイルについてそれほど文句を言うことはないでしょう。

@neoKushan

あなたがしたいのは、実際に理由を述べずに、XMLがどれほど悪いかについて話すことだけです

完全に公平ではありませんが、MSBuildがいかに悪いかについても話したいと思います:-)

ビルドファイルにXMLが好きではない理由を実際に_持っている_と確信していますが、もう一度試してみましょう。 XMLは冗長で、醜く、手作業よりもツールの方が優れており、XMLをマージする経験を楽しんでいません。 当時、業界はXMLをすべてに使用できると考えていたため、MSBuildに使用されていました。 それ以来、私たちは先に進みました。 まあ、いくつかの場所で。

さらに悪い-コメントなし

私は何人かの人々がここで代替案を提供したと信じています。 HJsonは1つのオプションにすぎません。 わーい！ 結局、考え直す必要はありません;-)

あなたはこの変更にかなり腹を立てています

公平を期すために、私は、project.jsonに対する以前の非常に堅固なサポートを額面通りに受けたコミュニティを考慮したり関与したりせずに、この変更が密室で行われた方法にほとんど腹を立てています。 少年、二度とその間違いを犯さないでください！

誤解しないでください。XMLは好きではありません。MSBuildは好きではありません。 しかし、私が本当に好きなものを採用するように言われ、最後の最後にそれが取り上げられていると言われるのは嫌いです。 私のチーズを動かさないでください！

この変更に腹を立てている人の大多数はすべてWeb開発者だと思います

ええと、そうです、それはあなたがproject.jsonを提供した唯一の開発者だからでしょう。 他のニュースでは、Swift開発者もこの決定に腹を立てていません。 私はあなたがここで言っていることを考えることを意味します：

1. Web開発者だけがこの新機能を手に入れました
2. 私たちがそれを奪ったとき、彼らの多くは本当に動揺していました
3. 他の誰もそれを使うことができませんでした
4. それを使わなかった人々はそれが奪われたことに腹を立てていません
   エルゴ他のすべての開発者はそれを望まないでしょう。

私はあなたがあなたの思考の質を見る必要があると思います、そしてそれは私がかなり長い間尋問しようとしたものであり、どこにも行きませんでした。 思考に関する情報が不足していること、および関係者が押し寄せているという事実は、思考が疑わしい可能性があることを私に示しています。

そして、「Web開発者」とはどういう意味ですか？ あなたは小さな会社のためにいくつかの小さなウェブサイトを考えていますか？ 数百億ドルの管理下にある資産管理ビジネスをサポートするマイクロサービスのスタックはどうですか。 もちろん、そこにもウェブサイトがあります。 しかし、それはシステムの約10％です。 そうそう、実際にはクラウドも対象にしているので、実際には「クラウド開発者」と言っているのかもしれません。

急いで決定を下しているテクノロジーがどのように使用されているのか、誰によって使用されているのかさえ理解していないようです。

XMLをあえて使用するという事実を除けば、MSBuildについて何が嫌いですか

複雑すぎる
これはインピーダンスの不一致であり、推論ベースのロジックを、人々が主に命令型または宣言型のロジックを扱っている状況に押し込みます。
なんてこった、MSBuildファイルを実際に_見た_？ さて、申し訳ありませんが、XMLの使用は別としてあなたは言いました;-)
プロパティとアイテムの宣言方法は、定期的に使用しない人にとっては直感に反します。
これは、スクリプトで実行する必要のあるタスクを実行しようとするすべてのツールに1つのサイズで適合するために使用されます。 ハンマー、釘。
多くの場合、大きなファイルで行うことはすべて、最大3行のスクリプトで表現できます。
それに吐き出されるVSのゴミ。 修正されると聞きました。 それもカットされるかどうかを確認するために少し不安を持って待っています。 上で述べたように、私は今、約束について少し恥ずかしがり屋です。

何が大好きですか？ そして最も重要なことは、他の人があなたの意見を共有しないかもしれないことを喜んで受け入れますか？ もしそうなら、「1つのサイズですべてに対応」が適切なアプローチではない可能性があることを認めることができますか？

あなたはどの方向を指しているのですか

project.jsonは、私たちの新しいプロジェクトアプローチの基礎であり、伝達されたものです。 私たちはそのコミットメントに基づいて、実際のお金と時間と苦痛を投資しました。

しかし、おそらく彼らはあなたよりもはるかに多くの人々のために働いていますか？

多分彼らは確かにそうします。 しかし、もしそうなら、その証拠はどこにありますか？ 私はこれで使用された思考と意思決定と証拠を調査しようとしましたが、誰からも何も得られません。 提供されたすべての証拠のために、あなたは私たちが知っているすべてのためにマジック8ボールを振った可能性があります。

何人がどういうわけか考えているのか誰も知りません。 私が実際に見つけようとしたのは私だけです。

asp.net開発者である自分以外の人は気にしません

とても素敵ではありません。 私が実際に言っているのは、新しい方向性はすべてのユースケースで機能するという主張であり、私は手を突き出して、それは私には機能しないと言っています。 あなたはすべての反対派を荒っぽく乗り越えている人です。 私は人々に彼らがどう思うかを尋ねる人です、MSはそうではありません。

「MSBuildを完全に削除し、他のすべての開発者にビルドプロセスを適用する」と言ったことはありません。 あなたは「project.jsonを完全に取り除き、すべての開発者にMSBuildを適用する」と言っです。 すべてのプレビューに2つのビルドシステムがあり、満足していました。 Web開発者は満足しており、非Web開発者は満足していました。

それがどれほど実現可能であるか、そしておそらくそうではないかもしれませんが、私たちは相談も関与もしなかったわかりません。

あなたは本当に排中律のあなたの議論を愛しています。

プルリクエストを受け入れます

本当に？ 読み取り専用のproject.jsonであるMSBuildベースではないビルドツールをメインのツール機能に残すプルリクエストを発行した場合、それをフレームワークに含めますか？ 本当に？

さて、私は基本的にこれを次のように読んでいます...

うわー、あなたはそれをたくさん読んだ。 私があなたのように読んだら、私は本を終わらせることは決してないだろう。 そして、それは作者が書いたものとはかなり異なるでしょう。

むしろ、「全体像を完全には理解しておらず、これを行うために必要な労力と時間を検討しています。既存の開発者の支援を得て、かなりの部分を提供できれば、はるかに良いでしょう。彼らのコミュニティの

くそー！ 私はあなたのように読んだ！ それが実際にあなたの幾分ヒステリックな解釈より少しよく元のテキストに合うことを除いて。

会話に建設的な何かを実際に貢献してみることができます。

実は建設的だと思いました。 最初のショックを乗り越えた後、私はこの決定の根拠が何であるかを見つけようとしました。 私は意思決定プロセスが何であるかを調べようとしました。 その背後にある思考の質を調べてみました。 開発者の大多数がこれを望んでいると言われたが、この主張を裏付ける証拠が提供されなかったとき、私は実際に彼らに尋ねました。

私は何を手に入れましたか？ 妨害、侮辱、回避。 では、何百万人もの人々に影響を与える大きな決断を下した人が宿題をしたかどうかを尋ねるのは、なぜ非建設的だと思いますか？ そして、人々が宿題の本を見せることを拒否したとき、それは建設的または疑わしいと思いますか？

つまり、現実的には、次のようなシナリオが考えられます。
1）フィードバックと情報の完全なセットに基づいて決定を下しました。この決定は、前進するための最善の選択肢です。 もしそうなら、私は黙っています、私は約束します。 あなたが受けた反対のレベル、そしてあなたが証拠と意思決定を隠しているという事実のために、この状況はかなりありそうもないと思います。
2）部分的な見解に基づいて決定を下しましたが、その時点で最高でした。 正しい答えは、決定を再開し、あなたが除外した意見を求めることだと思います。 これが最も可能性の高い状況だと思います。
3）あなたは悪いまたは悪い情報に基づいて決定を下しました。 その場合も、決定を再開してコミュニティに要請する必要があります。 あなたが私を信じていないかもしれないが、私はDotNetCore開発者を非常に尊敬しているので、私はこれが状況であるとはまったく思いません。 それらのすべて。

そして、あなたが決定を再開し、意見を求め、そして決定がそれと同じように下がった場合、あなたは何を知っていますか？ そして、意見を求めた後、意思決定の一部に欠陥があることに気づき、それを修正した場合、それは実際には良いことではありませんか？

うわー、真剣に。 これを終わらせることができますか？

簡単な質問：反対意見を取り入れて、新しい情報に基づいて決定を再検討しますか？

それとも、あなたに同意しない人々が狂気、愚か、未熟、_無知_、または情報に基づいた有効な意見を保持することができないことをほのめかし続けるつもりですか？

提案：msbuildcsprojレガシーカスタマーをサポートするためのMicrosoftフォーク。 #carryOnAsNormal

私は長年の.Net開発者でもあり、マーケティングが.Net名を発明する前に、1.0のプレビューで作業していました。 雑草に迷うことなく、ここに私の2セントがあります。

別のxml構成ファイルを見ることなく、残りの人生を歩むことができ、完全に満足することができました。

xml設定は必要ありません。 どこでも。 これまで。

チームがcsprojのすべての問題点を修正するかどうかは気にしません。 完了してもまだxml構成ファイルである場合は、興味がありません。 .net4.5プロジェクトシステムをそのままにしておくこともできます。

MSBuildに関しては... MSBuildは火事で死ぬ可能性があります。

私はそれが強力であり、その周りに多くのツールが存在することを知っていますが、MSの外では、MSBuildの真剣に深い専門家だけが実際にそれが何をするのかまたはどのように機能するのかを知っています。 カスタマイズをビルドプロセスに組み込む必要があるたびに、私は3〜5日間の職業生活を失うことになります。 VS、VSパブリッシング、およびCIサーバーで同時に正しく機能するように、出力に空のフォルダーを含めるなどの些細なことでも、ほとんど何も取得できません。

わかりました... asp.netコア1.0の時間枠でMSBuildの適切な代替品を構築する時間がない場合は、確かに... asp.netコア2.0までMSBuildを活用し続ける方法を考えてください。サイクル; しかし、少なくとも、その糞を他の人が作業できる可能性のあるものに置き換える方向で作業を続けてください。

それまでの間、できるだけ多くの構成をjsonに保持するようにしてください。 それがproject.jsonなのか、それとも新しくてより良いものなのかは特に気にしません。 必要に応じて、必要に応じてツールにレガシーMSBuildファイルをオンザフライで生成させ、サブフォルダーのどこかに貼り付けます。

私が望まないのは、私のファイルシステムが次のようになっていることです。

• bower.json
• package.json
• nuget.json
• すべて-else.json
• microsoft-old-ass.xml.csproj

また、260文字のパスの長さの制限を修正していただけますか...お願いします...はい、それはウィンドウと関係があることはわかっていますが、真剣に... 2016年です。

PS。 反対を無視し続ける場合は、次の情報を提供してください。

• ビルドツールの開発者のSlackチャネルにアクセスする方法
• 現在のアーキテクチャとコードの概要、およびMSBuild / xprojに移行するための変更が行われる場所。これにより、必要なビットを維持し、適切に統合するためのアプローチを計画できます。
• 品質基準を満たしている場合、project.jsonベースのツールでのプルリクエストのベイク処理が受け入れられます。
• 品質基準が満たされている場合は、完全なproject.json、ASP.NET Simpleテンプレート、および場合によってはより標準的なプロジェクトタイプの一部のテンプレートに対する「dotnetbuild」サポートを含めることができるという保証。

「建設的であること」、「貢献しないこと、声を上げないこと」。 さて、あなたはあなたが求めるものを手に入れます...

@ Mike-EEE、SimpleUseCaseBuildのXamlシリアル化を実行しますか？

これをすべて読んだ後、私はこれらの結論に達しました：

• project.jsonは多くの改善をもたらしました。 .netとasp.netコアがレガシーコードとツールに関連付けられていたとしたら、これは不可能でした。
• project.json（およびjson）は完璧ではありません
• xml vs json vsanyserializationlanguageは無菌です。 それらを活用して.netコアの課題に答える方法についての議論はもっと興味深いでしょう
• msbuildに戻ると、レガシーが復活します。これは、.netチームが自由の一部を失う可能性があるため、プロジェクトシステムにこれ以上の改善が見られないことを意味します。

.netチームが深呼吸し、これを少し失速させ、フィードバックを収集し（そして、この新しいスタックの採用と認識を検討し）、msbuildアプローチ（私たちの一部が考えるほど悪くはないかもしれません）に挑戦することを願っていますいくつかの選択肢。 急ぐ必要があると思います。

笑@shedermanあなたは今私を何に引き込んだのですか？！ ：smile：そしてなんという議論でしょう！ 本当にすごい。

xml vs json vsanyserializationlanguageは無菌です。 それらを活用して.netコアの課題に答える方法についての議論はもっと興味深いでしょう

はい、私にとって重要なのは、プロジェクトやプロジェクトの内容を説明するために使用されるバッキングモデルであり、この会話の一部はそれに触れています。 記述と操作が簡単な、改善されたプロジェクトモデル/ APIが欲しいです（記述されている形式に関係なく、そうですが、：heart：my Xaml！）。 これに関して、MSBuildのリポジトリ（https://github.com/Microsoft/msbuild/issues/613）と、Roslynのプロジェクトシステム（https://github.com/dotnet/roslyn-project）についてオープンディスカッションを行っています。 -system / issues / 37）も、興味があれば。

ここには本当に素晴らしい点がたくさんあります。私は個人的に、「非建設的」かどうかにかかわらず、エネルギーを掘り下げています。 ここにいる誰もがMSFTを改善し、生産されているものを最大限に活用することに心を持っていると思います。 ：+1：

私の2セント：

この変更について話し合っているのは2種類あると思います。

• さまざまな種類のプロジェクトを構築するためにVSと.NETを使用していて、それらのプロジェクトを長期間サポートする必要がある開発者
• そのような手荷物を持たず、新しく、クリーンで派手な、クロスプラットフォームのASP.NETCoreフレームワークを必要とする開発者

個人的には、私は最初のカテゴリに属しているので、新しいASP.NET Coreを他のVSプロジェクトタイプと可能な限り互換性があるようにしたいので、「古い」csproj / msbuildソリューションに移行することは私にとっての勝利です（+ myチームとおそらく他の多くの開発者）。 このようにして、移行ははるかにスムーズで明確になります。 たぶん、2番目のカテゴリーの人々は私に同意しないでしょう（または彼らは単に気にしません）。

私が今目にしている唯一の大きな問題は、NuGetパッケージがどのように定義および参照されているかです。 packages.configファイルとcsprojファイルの両方を維持する必要があるのは面倒です（ @JulianRoozeはすでにhttps://github.com/aspnet/Home/issues/1433#issuecomment-218606377で言及されています）。 これはリファクタリングする必要があります。 理想的には、https： //github.com/aspnet/Home/issues/1433#issuecomment-218519705で提案されている

XML / JSONの聖戦については...私見ですが、XMLはJSONよりも手作業での編集に適しています。 XMLはコメントをサポートし、それを見ているときに、より多くのコンテキスト情報を持っています。 JSONは、構成ファイルではなく、データに適しています。 マージは両方の形式で同じように良いことも悪いこともあります。それはコンテンツにのみ依存します。 プロジェクト参照が現在のcsprojファイルから分離されている場合、マージもはるかに簡単になります...

@Funbitが人々を分類しようとしても役に立ちません。 そして、私はあなたのどのカテゴリーにも当てはまりません。 私はv1ベータ版以来asp.net開発者です。 私は2年前にほとんど存在しなくなりましたが、.netコアはクリーンな状態であり、.netとノードの世界で最高だったため、私を元に戻しました。

私は、.net Coreが、採用もコミュニティもない古い企業テクノではなく、成功することを望んでいます。

私としては、この決定についてはあまり気にせず、XMLについてはあまり気にせず、引用符を盗みます。「中括弧は山括弧よりも優れています」が、戻るのはそれほど面倒ではありません。 csproj / msbuild-柔軟に対応できます。

@shedermanのコメントのいくつかをエコーし​​たいと思います：

現実には、これは実際にはオープンソースプロジェクトではなく、Microsoftプロジェクトであり、彼らは私たちの意見なしに企業の決定を下しました。私たちはそれを吸い上げて受け入れる必要があります。 どんな反対があったとしても、彼らが再考する可能性は基本的にないことが私には明らかにされました。

と

公平を期すために、私は、project.jsonに対する以前の非常に堅固なサポートを額面通りに受けたコミュニティを考慮したり関与したりせずに、この変更が密室で行われた方法にほとんど腹を立てています。 少年、二度とその間違いを犯さないでください！

これは私を悩ませます。マイクロソフトはオープンソーシング.NETを大量に作成しており、コミュニティに実際に関与して協力し、フィードバックを得て、コミュニティの優れた「メンバー」（パートナー？）になりたいと考えています。 しかし、この種のことは実際にその全体の努力を後退させ、全体の「ゴージャス」が/のように感じる.NETエコシステムを与えます。 コミュニティは何年もの間それをラベル付けしました。

マイクロソフトに公平を期すために、企業が後援するプロジェクトでこの種のことを行うのは彼らだけではありません。 nodejsコミュニティの分割（io.jsフォークの原因）を覚えていますか？ しかし、それがマイクロソフトの場合、それははるかに悪いことだと思います。

それは当初の意図よりもかなりの割合で吹き飛ばされました。

それは当初意図されていたものよりもはるかに不均衡に吹き飛ばされました

@MaximRouillerあなたも開発者

@ Mike-EEEそうです。 私はいくつかの白熱した議論を期待していましたが、私はあまりにも多くの個人的な攻撃を見てきました。 ：残念だった：

プロジェクト間でソースファイルを共有できる必要がある

@darrelmillerこれは、.csproj内のリストファイルが戻ってくることを意味しているように思われるため、私には怖いように聞こえます。

@lokitothリンクされたファイルがワイルドカードグロブも使用できない理由はおそらくありません。

@MaximRouiller私も、取り戻し、衝動的になりすぎて、私の心を話すことで罪を犯しています。 私は悪いと思ったが、 @ shedermanは投げる方法を知っている！ はは。 ちなみに、 @ shedermanは私の内側のコーディング動物を表していると言うつもりでしたが、それは

私たちがしていることは本当に大変な仕事であり、それがうまくいくときだということを自覚する必要があると思います。 そこにたどり着くのはさらに難しい。 Silverlightでの私の経験では（そうです、私はそれでやけどを負ったので、 @ shedermanがどこから来ているのかを知ってい

とにかく、今は「ウェブ」キャンプと「ネイティブ」キャンプに分かれていても、深呼吸をして、謙虚な精神を持ち、同じチームに所属していることを思い出してください。 少し時間がかかるかもしれませんが、ここで話しているのは、10年以上、さらには長い間私たちに役立つものです。 他の人や彼らがどこから来ているのかについても共感を持ちながら、長期的なアプローチに焦点を当てましょう。

OK ...その日の十分な説教とララ。 ：stuck_out_tongue：定期的に予定されているスラッグフェストに戻りましょう！

これは、.csproj内のファイルの一覧表示が戻ってきたことを意味しているように思われるため、私には怖いように聞こえます。

また、余談ですが、この機能を高く評価しているのは私だけですか？ ：stuck_out_tongue：

これは、.csproj内のファイルの一覧表示が戻ってきたことを意味しているように思われるため、私には怖いように聞こえます。

また、余談ですが、この機能を高く評価しているのは地球上で唯一の人だと思いますか？ ：stuck_out_tongue：

@ Mike-EEEはい、そうだと思います。 ：ウィンク：

リンクされたファイルの主な使用例は、複数のプラットフォームをターゲットにすることです。 これは、私が本当に残したいproject.jsonの機能の1つです。 この機能について具体的なコメントは見たことがないと思いますが、チームがmsbuildでこれを再作成する意図を確認できれば幸いです。

@shedermanは投げる方法を知っています！
😆

やってみます。 でも誰も侮辱しなかったといいのですが。 私は議論を追いかけるだけに一生懸命努力しました。

私は特に個人的な侮辱に怒り狂うので、私に反対する人は誰でも私を黙らせる方法ではありません。 😉そしてそれらのかなりの数がありました。

csprojファイルを編集するためのユースケースに興味があります。 私の経験では、nugetが何かを台無しにしたとき、またはヒントパスが壊れたときに、csprojファイルを編集するだけで済みました。 ビルドプロセスに新しいステップを追加するために、私は常にCIシステムによって実行されたより高いレベルのbuild.projファイルを使用しました。 CIセットアップで.slnファイルを使用することはありません。

人々がcsprojファイルを編集して、Visual Studioでデバッグするときに実行するBeforeBuildおよびAfterBuildステップを追加することを主な目的としていますか？

@ Mike-EEEたぶん; 非常に多数のファイル（Expression Blend、Visual Studio XAML Designerなど）を使用するプロジェクトを処理するときに、ワイルドカードの選択に交換するまでは、それが非常に苦痛だったことをほとんど覚えています。これはVSが行います。正しく操作する方法がわからない。つまり、ファイルを追加するたびに、プロジェクトをリロードする必要があります（または、ビルド時に「このファイルは既に追加されています」というエラーが発生します）。

この「機能」について実際に気に入っている点は何ですか（プロジェクト間でファイルを共有するのではなく、明らかに便利ですが、VSは、すべてのファイルが個別にリストされている場合にのみ正しく機能します）。

この「機能」について実際に気に入っている点は何ですか（プロジェクト間でファイルを共有するのではなく、明らかに便利ですが、VSは、すべてのファイルが個別にリストされている場合にのみ正しく機能します）。

確かにこれは悪い習慣ですが、リファクタリングを行っているときにプロジェクトからファイルを削除できるのが好きです。 または歴史的な観点からさえ。 後で必要になる可能性のある作業を行っていることがわかっている場合は、それをディスクに保持しますが、プロジェクトから削除します。 確かに、これはリポジトリ/ソース管理（悪い習慣を参照）を汚しますが、私はその種の管理を楽しんでいます。 これで、そのファイルが必要になったときに、レポの履歴（削除されたファイルのこの履歴を見つける方法???作業が多すぎる！）をいじくり回す必要がないため、単に「すべてのファイルを表示」します。そして、それを私のソリューションに再度追加します。 インスタント履歴。 ：笑顔：

csprojファイルを編集するためのユースケースに興味があります

.csprojの場合（私が行ったこれらのすべて、および大部分の場合、複数回）

• デスクトップアプリケーションからUWPタイプを参照する必要がある場合
• NuGetを使用してVSの問題を修正する必要がある場合（特に、.targetsファイルと.proj / .propsインクルードの追加に関して）
• 生成された出力のレイアウトを変更する必要がある場合
• プロジェクトをリファクタリングし、アセンブリの名前を変更する場合
• 多くのファイルに影響を与える大規模なリファクタリングを行っている場合
• 複数の人が同じプロジェクトで作業していて、ワイルドカードを使用していないためにマージの競合が発生した場合
• ビルドが突然機能しなくなった理由を理解する必要がある場合（編集：指定する必要があります-これは、「読み取り可能で、「自己完結型」である必要がある理由」の詳細です）
• 煩わしい依存関係のためにアセンブリバージョンの競合をデバッグする必要がある場合
• 「リンクされた」（共有）ファイルを追加しようとしている場合

project.jsonの場合

• 手作業でファイルを最初から作成する（非常に重要）
• NuGetパッケージの追加/削除
• ターゲットフレームワークの変更
• 出力パッケージのバージョンを変更する

@shedermanあなたがイライラしていることはわかっていますが、

本当に？ 人々はまだそれをしますか？ つまり、AssemblyInfo.csでそれを行っていたのですが、暗黒時代に戻ったのです。

トーンを設定しています。 対面での会話は問題ありませんが、このような環境では、感情に基づいたさまざまな解説への扉が開かれ、会話が二極化し、重要なポイントに集中することが難しくなります。 これらの議論から感情を排除するのは難しいことを私は知っています（私の舌はかみ傷でいっぱいです;-)）が、議論を有用に保つために私たちは本当に努力しなければなりません。

@ Mike-EEE Exclude属性/パターンを使用して（すべてのファイルをリストせずに）同じことを達成できませんでしたか？ 記録のために、私はしばしば同じことをします。コミット/ロールバックサイクルを実行せずに何かをすばやく削除したい場合に非常に便利です。

記録としては、Roslynを使用し、プロジェクトファイルをシリアル化されたASTにする@ Mike-EEEの提案が実際に気に入っています。 ただし、メモ帳だけを使用して同じように簡単に作業できる場合に限ります。 （はい、私はメモ帳を意味します。メモ帳++やその他のより高度なものではありません。これは、人間が編集可能なファイル形式の使いやすさの「スモークテスト」です）

@CodingGorilla私はそれを

つまり、基本的には、「オプトイン」ではなく「オプトアウト」モデルを検討します。

アンロードせずにプロジェクトファイルを編集したい方のために.... https：//twitter.com/migueldeicaza/status/730978470734401536

アンロードせずにプロジェクトファイルを編集したい方のために…。

@darrelmillerここで何を見ているのか...代わりに

私は、最終的なファイルは、形式に関係なく、標準のテキストエディタ（メモ帳など）で簡単に編集および読み取りできる必要があるという考えを2番目に示しています。

また、より優れたツールを使用すれば、現在のcsprojの背後にある多くの問題点を取り除くことができると思います。 VSは最良の例ではなく、VSが提供する経験は、多くの人が実際にMSBuildプロジェクトシステムを嫌うものだと思います。

@ Mike-EEE Miguelのコメントへの返信は、新しいプロジェクトシステムに取り組んでいるDavidKeanからのものでした。 チームは、VSがこれも実行できる必要があることを知っています。

@ Mike-EEE私のことは、彼らが思いついたものは何でも処理できるということだと思います。 MSBuildプロジェクトシステムは、ほぼすべてのことを実行できるほど堅牢です（ @shedermanが言うように、XMLにすることはできません）。 「自分のやり方だろうか、失敗だ」と言っている人もいると思いますが、他の人が言ったように（誰を忘れてしまいました、このスレッドはYUUUUUUGEです！）「心を開いてください...」とただ適応する。

その上、あなたは何か新しいことを学ぶかもしれません、そしてそれは常に良いことです。 ：ニヤリ：

@neoKushan以前はmsbuildスクリプトを最初から作成していましたが、フレーバーのmsbuildよりもはるかに強力です。 しかし、それも素晴らしかったし、私はもうやっていなくてとてもうれしいです。 これよりももっと良い方法で解決できると思います。

@CodingGorilla実際、私のメインの牛肉はMSBuildを使用しています。 XMLは問題ですが、MSBuildほど悪くはありません。

project.jsonサポートをxprojと並行して実行し続けるために、自分で作業を行うことを提案しました。 最も気にかけている人は、仕事をしますよね？

そして、これが実際の核心です。 チームは私がこの貢献をすることを許可しますか？ そうでない場合は、なぜですか？ やっぱりOSSですね。

次に、MSBuildが好きで、そのパワーが必要な場合は、xprojを使用します。

また、ASP.NET Core用に構築されたツールが気に入った場合は、それを使い続けます。

それらは同じ基礎となるコンパイラを使用します。

そして、それはどんな場合でもそれほど多くの仕事でさえあるべきではありません。 私がしなければならないのは、非推奨になっているコードを別のコマンドにリファクタリングすることだけです。

理想的には、「dotnet build」を使用して、dirを確認し、そこにあるファイルに基づいてどちらを使用するかを決定できるようにしたいと思います。 ただし、ビルドまたは新しいコマンドのオプションフラグは問題ありません。

@sandorfr私はあなたの_全体_ビルドプロセスを定義する本格的なMSBuildファイルを書くことに同意しますが、私が間違っていなければ、それは私たちが実際にここで話していることではありません-私たちはプロジェクトについて話しているだけです構造。

別の言い方をすれば、MSBuildは巨大で強力なシステムであり、それに伴って非常に複雑になりますが、それを使用する場合に限ります。 VSはデフォルトで、必要のない多くのがらくたをそこに投げ込み、xprojを見ると、MSBuildも実際にはそれを必要としなかったことは明らかです。 ドネットチームがcsprojで必要なものを最小限に抑えることに焦点を当てている場合、ほとんどの人にとっては比較的最小限でクリーンなはずです。 「マージ地獄」に苦しむべきものは、その追加機能を必要とするものだけです（私が思うに、この変更を推進しているのは、頭の中でそれです）。

CAKEやTFSTeam Servicesなど、選択したビルドシステムの使用を妨げるものは何もありません。

繰り返しますが、これはチームがそれを「正しく」行うことを規定しています。

VSは最良の例ではなく、VSが提供する経験は、多くの人が実際にMSBuildプロジェクトシステムを嫌うものだと思います。

@neoKushanそれがTFSビルドとXamlについて私が感じていることです。 Xamlはとてつもなく素晴らしいです（そして、MSBuildの「スクリプト」の可能な形式として使用されるのを見るのが大好きです）が、TFSビルドでの使用はそれに悪い名前を付けました。

このgithubの問題をチャットウィンドウとして使用するのは生産的ではないと思います。 MSからの誰かが返信した場合に備えて、このスレッドの電子メール通知を保持したかったのですが、メールの量が煩わしくなりすぎました。

MSBuildプロジェクトシステムは、ほぼすべてのことを実行できるほど堅牢です

これは問題の一部であり、csprojファイルを読み取るときに何が起こっているのかを理解するのが非常に難しいため、プロジェクトファイル形式（ビルド定義ファイル形式と混同しないでください）には適していません。

（編集：追加）

CAKEやTFSTeam Servicesなど、選択したビルドシステムの使用を妨げるものは何もありません。

残念ながら、VSがMSBuildと通信できるようにしたい場合は、ビルドシステムをMSBuildにシューホーンしようとして立ち往生していることを意味します（管理されたコードとネイティブコードの両方があり、デバッグしたい場合は正しく機能します）。 これが、実際には、ビルドファイルからプロジェクトファイルを分割することが_機能_であると私が信じている理由です。

ハハええ@ cwe1ss （ツールの改善と言えば！）会話の中で物事が起こったとき、GitHubはひどいものだと思っていました。 ここには3つのスレッドがあります。 そして、私はちょうど別のものを始めました。 ：残念だった：

水曜日に次のコミュニティスタンドアップにジャンプすることをお勧めしますか？ ほとんどの場合、1日か2日前にRC2のリリースについて話していると思いますが（期待できます！）、必要な質問をして、ライブの聴衆と率直に話し合う機会が得られます。それは実際に答えを与えることができます。

水曜日に次のコミュニティスタンドアップにジャンプすることをお勧めしますか？

@shedermanが表す場合のみ。 彼が開発者と彼らのアイデアをリアルタイムで打ち砕くのを見たいです。 WWE PPVイベントのように！

[projectName] .csprojに対するproject.jsonの利点は、形式ではないと思います。 それは、すべての古いものと下位互換性がある必要がないということです。 それはそれがかなり単純になることを可能にしました。 ダミアン・エドワードとチームが彼の指定されたすべての目標を達成できると仮定すると、XML対JSON対YML対...私にとって重要なのは単純さであり、Linuxを使用しているときにWindowsにあるものを見る必要がないことです。 。

@glennsills MSBuildプロジェクトファイルには、_windows_に固有のものはほとんどないと思います。それは、MS Build自体、または他のプロジェクトタイプに固有のものであるということです。 MSBuildを満足させるためだけに、空の要素をたくさん用意する必要はありません。 チームが可能な限りそれを削減することを計画していることを望んでいますが、私たちは見るでしょう。

@ Mike-EEE @ shedermanが表す場合のみ。 彼が開発者と彼らのアイデアをリアルタイムで打ち砕くのを見たいです。 WWE PPVイベントのように！

作ってみます。 私がタイプするよりもゆっくり話すことを警告しますので、あなたの希望を上げないでください😄

したがって、 https：//github.com/dotnet/roslyn-project-system/issues/40を考えると、ワームの缶を開けるリスクがありますが、含まれているだけの真に削減されたcsprojファイルについて人々はどのように感じ

（これを「XMLが嫌いです！」というティレードに変えないでください）。

「MSBuildのティレードが嫌い」はどうですか？

@shederman

MSBuildにJSONファイルを受け入れさせたらどうなりますか？ ：笑う:(抵抗できませんでした）

@shedermanどんな種類のティレードも真剣に受け止めるのは難しいので、Microsoftがこれを真剣に受け止めたいと思います。

これが5年後に進むように、Swift、Java（!!）、Node.JS、またはElixirをプログラミングすることになります。 ;）

最近の.NETプロジェクト/ソリューション/その他のテクノロジーには2つのくだらないものがあります。 Nugetおよび.csprojファイル。 Git（およびGitFlowなど）を使用して5人以上のチームで作業している場合、それは完全な悪夢です。 「.csprojにファイルを含めるのを忘れた場合のくだらない」は面倒になりつつあります。 ツールはそれを修正する必要があります。ツールは、DLLバージョンが競合していることを警告する必要があります。ツールは、マージに役立つはずです。

がらくたをカットします。 Project.jsonは最初は良さそうに見えましたが、その後、政治や感情が起こりました。

MS Teamは、RCではなくベータと呼ぶ必要があります。
RTMがリリースされても信頼できないようです。'MSチームがすべてを壊したRTM2を出荷することを決定した可能性があります。
私は悲観論者ではありませんが、.NETCoreをめぐるこの動きは非常に奇妙です。

@neoKushan私は

私は、議論に参加するために私が保持している立場を放棄しなければならないという議論の条件に同意しません。 project.jsonに参加している私たちが、MSが決定したことを基本的に正確に受け入れなければならないことを、私は聞き続けています。

それがどうなるかわかりません。 約束され、コミットされたビルドシステムが欲しいだけです。 MSがそれを維持し、継続する気がない場合、私は申し出ました。

では、どこに問題があるのでしょうか。 私はMSに彼らの計画を撤回するように求めているのではなく、彼らに仕事を追加するように求めているのでもありません。 私はちょうど私は、彼らが一方的に破った約束を履行することを可能にするためにそれらを求めています。

革命的な要求はほとんどありません。

私の2セント：

この変更について話し合っているのは2種類あると思います。

さまざまな種類のプロジェクトを構築するためにVS＆.NETを使用していて、それらのプロジェクトを長い間サポートしなければならない開発者
そのような手荷物を持たず、新しく、クリーンで派手な、クロスプラットフォームのASP.NETCoreフレームワークを必要とする開発者
個人的には、私は最初のカテゴリに属しているので、新しいASP.NET Coreを他のVSプロジェクトタイプと可能な限り互換性があるようにしたいので、「古い」csproj / msbuildソリューションに移行することは私にとっての勝利です（+ myチームとおそらく他の多くの開発者）。 このようにして、移行ははるかにスムーズで明確になります。 たぶん、2番目のカテゴリーの人々は私に同意しないでしょう（または彼らは単に気にしません）。

私が今目にしている唯一の大きな問題は、NuGetパッケージがどのように定義および参照されているかです。 packages.configファイルとcsprojファイルの両方を維持しなければならないのは面倒です（ @JulianRoozeは＃1433（コメント）ですでに述べています）。 これはリファクタリングする必要があります。 理想的には、＃1433（コメント）で提案されている@ cwe1ssのように実行する必要があります）。 ところで、これはこのトピックで最も建設的なコメントの1つでした...

XML / JSONの聖戦については...私見ですが、XMLはJSONよりも手作業での編集に適しています。 XMLはコメントをサポートし、それを見ているときに、より多くのコンテキスト情報を持っています。 JSONは、構成ファイルではなく、データに適しています。 マージは両方の形式で同じように良いことも悪いこともあります。それはコンテンツにのみ依存します。 プロジェクト参照が現在のcsprojファイルから分離されている場合、マージもはるかに簡単になります...

私はカテゴリー1にも当てはまります（複数のプロジェクト/タイプを開発していて、それらを長い間サポートする必要がある開発者）。 私の雇用主は、csproj形式の数百万行のコードに相当するプロジェクトを持っており、ASP.NETRC1およびRC2devブランチで実行されている新しい製品もあります。 公正な警告です。カスタムMSBuildタスクアセンブリなどでMSBuildを高度に使用することもできます。

特に、ラップの生成、ラップされた依存関係が変更された場合のラップの再生成、これがソース管理でどのように見えるかなどを考慮すると、2つの間の実際の統合は（複数の理由で）大破しました（GitとTFVCの両方を内部でサポートして使用しています） ）、プロジェクトがVSの設計時にソリューションで相互に参照する方法と、ビルド/デプロイ時にプロジェクトがどのように引き込まれるか。 システムは決して_正しい_とは感じませんでした。 それぞれが.csファイルしかない2つの別々のプロジェクトを持つことができるのは意味がありませんでしたが、これら2つのプロジェクトタイプはうまく混ざり合うことができませんでした。

そのため、これまでに作成されたアプリケーションやコードをサポートすることが重要である理由を完全に理解しています。 この種の変更を導入するのは適切な時期ではないと思います。他のすべての変更が行われているので、一度に多くのことが起こっているように感じます。

おそらく、将来の解決策として考えられるのは、他の人からヒントを得て、LTSリリースなどについて考えることです。 これははるかに大きな会話ですが、プロジェクトシステムの置き換えなどの機能を導入して、人々がそれを吸収する時間を与えることができます。

もう1つの可能な解決策は、よりプラグイン可能なビルドシステムですが、これは長期的な解決策であり、現在の会話には役立ちません。 基本的に、いずれかまたは/またはサードパーティを許可します。

プロジェクトの依存関係については、すでに大量のpackages.configファイルが浮かんでおり、それらをpackages.json /nuget.jsonに移植することは大したことではありません。 依存関係のストレージ形式よりも、一貫性のないアセンブリバインディングリダイレクトの方が問題があります。

@shedermanあなたはMSBuildについてあなたの意見を非常によく知っていますが、あなたが明らかにしていないのは、MSBuildの実際の_問題_です。 これは私がとても苛立たしいと感じていることです。MSBuildで発生した実際の問題を知りたいだけです。なぜなら、それらは本当に対処できると感じているからです。

さて、あなたはXMLが好きではありません、大丈夫です-JSONとXMLの間の議論は新しいものではなく、ここでそれを解決することは決してありません。 ただし、それがMSBuildをそれほど嫌う_唯一の_理由にはなりません。 あなたが遭遇した実際の問題は何ですか？

私が尋ねる理由-そして私が尋ね続ける理由は、これらはマイクロソフトが修正したい正確な問題であり、問​​題が何であるかを明確にしない限り、それらは修正されないということです。 私たちがMSBuildについて嫌っていたものの多くは、私たちが知っているようにすでに修正されています。

1. プロジェクト内のすべてのファイルのリスト-削除/修正中（実際にはVSの問題）
2. 地獄をマージ-1で修正ほとんどの場合
3. 不必要な複雑さ/冗長性-うまくいけばhttps://github.com/dotnet/roslyn-project-system/issues/40によって解決され
4. 手で簡単に編集することはできません-繰り返しますが、1と3で修正されています。

何が残っていますか？ 実際にMSBuildの問題について話し合い、すべてをフォークしたり、何万もの複雑でビジネスに不可欠なプロジェクトを放棄したりすることを伴わないソリューションがあるかどうかを見てみましょう。 それが私がしたい議論です。

これについての私の2セント：
なぜ今、この種の変化が起こっているのでしょうか。 ロードマップによると、最終リリースまであと1か月です。
これを最初に見たとき、これは冗談だと思いました。 しかし悲しいことに、そうではありません。
これは、コミュニティの顔に大きな打撃を与えます。 そのような決定には、採用後ではなく、採用前に長い会話スレッドが必要です。

@neoKushanがここで指摘しているようにません。これはRTM後の変更になります（RTMも段階的になります）。 したがって、「最後の最後の変更がなぜ」という話はすべて、少し間違った議論です。物事がどのように進化するかを確認する時間はあります。

@laskoviymishkaRTMの前に変更

RTMは、現在も使用されているようにproject.jsonを使用します（RC2のスキーマは変更されていると思いますが、それは関係なく発生していました）。 「新しい」csprojへの移行は、RTMの後に行われる予定であり、徐々に行われる予定です。 RTMでは何も変更されません（xprojの名前が変更されることを除いて）。

@CodingGorillaこれはRC2で、1か月で1.0バージョンに移行されます。 現実の世界では、これはあなたがすべてを開発するのをやめ、安定化に集中することを意味します。 この変更は実際には何も安定しません。

@neoKushanそれがRTMの後に起こるなら、なぜそれについてコミュニティをascしませんか？ githubでディスカッションスレッドを開始します。 引数などを指摘し始めます。なぜ開発者との会話なしに強制する必要があるのでしょうか。

私見では、このproject.jsonからproject.csproj移行については、採用する前に話し合う必要があります。 今のところ、少なくとも私にとっては良い決断ではありません。

@laskoviymishkaコミュニティからの

RC2 /プレビュー1では、変更はありません。 RTM /プレビュー2では、_xprojファイルの名前がVisualStudioによってcsprojに変更されるかどうかを確認する唯一の変更_です。 その時点から、project.jsonはcsprojの隣に存在します。 その後、チームはproject.jsonからcsprojファイルへの機能の移行を開始します。 project.jsonファイルが残っている可能性があり、NuGetのすべてのパッケージ参照が含まれており、名前がnuget.jsonに変更されています。 チームは、project.jsonモデルの主な利点の1つである、プロジェクトファイル内のすべてのファイルを一覧表示する必要がないことを示すいくつかの作業をすでにテストしています。

したがって、これは主にツールの変更であり、非常に短期的に（つまり、RTM +）、project.jsonファイルは引き続き存在し、現在と同じように機能します。 これについての良いニュースは、私たちが物事を市民的で建設的なものに保つことができれば、コミュニティがこれに影響を与える時間はまだあると思います。

@laskoviymishkaええと、私はマイクロソフトについて話したくありません。彼らの最終的な計画が何であるかはわかりませんが、彼らも本当に知っているとは思いません。 多くの人が敷物を下から引き出したと言っており、Microsoftはこれを決定する前に私たちに相談するべきでしたが、現実的にはまだ何も変わっておらず、何ヶ月も変わらないでしょう-そして、変化が起こったとき、それは徐々に変化し、うまくいけば、ツールが多かれ少なかれあなたのためになるでしょう。

Microsoft、または少なくともasp.netチームはこれについてフィードバックを求めており、間違いなくこれらのスレッドを読んでいますが、おそらく私たちが見逃しているのは、Microsoftからの決定的な速報または投稿です。 _here_ "してください。 ただし、移行は人々が考えるよりもはるかに早いと思います。 これまでのところ、彼らが確実に行っていることを知っているのは、xprojの名前をcsprojに変更することだけです。

個人的には、やるのは少しくだらない変更ですが、彼らがそれを行う理由は理解しています。 これ以上の答えはないので、csprojスタイルのプロジェクトを処理する必要がある場合は、この期間を利用して、可能な限り最高のcsprojを提示することもできます。 それはproject.jsonではありませんが、両方の世界の長所を生かすことができれば、長期的には、私たち全員のほうがうまくいくでしょう。 誰もが同意するわけではなく、それは問題ありません。

@neoKushanこれは良い点です。MSがそれを見てくれることを願っています。 コアチームからのフィードバックを見るのは本当に素晴らしいことです。

@CodingGorillaさて、最終バージョンにはまだ変更がありますが、これは壊れています。 このような変更の主な問題は、コアチームが多くの時間を無駄に費やさなければならないことです。これはおそらくマネージャーの問題です。 ある作業を別のおそらく機能するものに変更するためだけに、多くの開発時間を費やしてみましょう。 本当の理由はありません。

@neoKushan

実際にMSBuildの問題について話し合いましょう

意見を述べるのに十分な情報を見つけるのに苦労しています。 project.jsonと.csprojファイルの削除によって有効になるように_seem_される多くの変更がありました。 これらの改善がなくなることは望んでいませんが、「新しく改善された」msbuildに移行することでワークフローがどのように変わるかわかりません。

• 現在、すべてのビルドタスクにgulpを使用しています。 それは変わりますか？ 私のgulpfileは、dnuまたはdotnet-cliに実行され、実際に.csファイルのコレクションをアセンブリに変換します。 私はそれを保つことができますよね？
• VSは、タスクエクスプローラー、およびgulpタスクのafterbuild / prebuild / etcトリガーを引き続きサポートし、VSユーザーがF5を実行できるようにしますか？ または、msbuildでgulpをキックオフする必要がありますか？つまり、すべてのgulpタスクでラッパーのmsbuildタスクを定義する必要がありますか？ （痛い）
• msbuildは別のインストールにありますか？ dotnet cliまたはランタイムとは別にバージョン管理されますか？ これにより、CIビルドサーバーで利用可能にする必要がある最小値がどのように変更されますか？ 開発環境にインストールするための最小値？
• テキストエディターを使用してnugetの依存関係または.csファイルを追加している場合、追加する必要がある手順があれば、それを追加する必要がありますか？
• VSユーザーがnuget依存関係と.csファイルを追加したチェンジセットを確認しているとき、csprojの変更は単純で人間が読める形式になりますか？ （比較のために、.net 4.6およびVS2015との比較では、csprojへの変更は人間が簡単に読める形式ではないというのが私の意見です。）

この変更を行っている人々が、検討する必要のあるシナリオ（私のように！）について連絡を取り、これらについて話し合うことを望んでいます。 「議論なしでチーズを動かしている」というようなことは、.netCoreのSOPにならないことを願っています。

そのツールは多かれ少なかれあなたのためになります

そしてそれが主な核心です。 必要な工具が少なければ少ないほど良いです。 現在、上流を泳いでいるように感じることなく、テキストエディタとコマンドラインを使用できます。 それが変わらないことを願っています。 .net46ランドでは、VSを使用したくない場合は、巨大で冗長なxmlファイルを編集する必要があります。同じプロジェクトでVSユーザーと非VSユーザーを混在させるのは悪夢です。

「RTMへようこそ。これは、プロジェクトファイルが近い将来に変更されることを思い出させるものです。これはすでに決定しています。理由ですが、ほとんどの場合、カーリーよりも角度が好きで、ツールをビルドします。ツール。最終的なスキーマは決定していません（ただし、xmlベースになります。上記を参照）。ファイル名は間違いなく.csprojで終わり、レガシーツールに最大限の混乱をもたらします。アジャイル。（psツールベンダーの場合:: o） "

@Oceanswaveの美しい例ソフトウェア開発を管理すべきではない方法

@neoKushan

しかし、あなたが明らかにしていないのは、MSBuildの実際の問題です

たぶん、あなたはあなたからのこのまったく同じ質問に対する私の以前の回答を読むべきですか？ https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

私は、MSBuildファイルの修正、開発、デバッグに何百時間も費やしてきました。 私はチームビルドを行い、巨大なビルドとデプロイのパイプラインを行いました。 何時間も何時間もかけて冗長なログを調べ、奇妙な状況が発生している理由を突き止めてきました。 私はこの技術で何年にもわたって会費を支払ってきました、そして私は個人的にそれとは何の関係も望んでいません。 project.jsonは新鮮な空気の息吹でした。 何年にもわたってMSBuildに苦しんでいた後、私たちはようやくMSがそれを手に入れ、変更が必要であり、適用されているという印象を受けました。

そしてそれは栄光でした。 シンプルなビルド、シンプルな編集、すばやく簡単に理解できる出力。 それは、MSBuildスクリプトで宣誓したそれらの時間の記憶を洗い流しました。 ついに過去の死体から自分たちを切り離しているように感じました。 しかし、いや、これが起こらないという約束にもかかわらず、今、私たちは私たちがとても嫌いな死体に縛られています。

話し合いもレビューもなし、いかなる種類の関与もありません。

一部の四半期でMSBuildがどれほど嫌われているかさえ知らないという事実は、この決定に何の努力もしなかったことを単に

MSBuildには、ビルドシステムとしての重要な機能制限はないと思います。 それは信じられないほど強力であり、ある意味でそれが主な弱点です。 非常に多くのシナリオを処理する必要があるため、複雑です。 単純な「復元、ビルド、テスト、パック」シナリオの場合、それは本当に大きなやり過ぎです。

私のチームでは、C＃開発者を扱っています。 彼らはプレッシャー、厳しい締め切り、高いストレスにさらされています。 彼らは邪魔になったり遅れたりするものは何も望んでいません。

MSBuildは別の考え方であり、命令型コーディングからの主要なコンテキストスイッチです。 開発者は単にそれを嫌います。 彼らはそれが鈍感で直感に反していると感じています。 彼らはそれを避けます。 最近私が監督しているチームのいずれかで作成されたMSBuildは、ツールで作成されたものだけです。

過去5年以上、MSBuildに興奮している、またはMSBuildでの作業を楽しんでいるC＃開発者に会ったことはありません。 Githubで過去数日間のコメントのいくつかを見てください。 MSBuildが嫌いなのは、私だけではありません。 MSBuildは、10年間、.NET開発者の首の周りの石臼として認識されてきました。 その認識の多くは不公平ですか？ ええ、おそらく。

しかし、それで何？ ソフトウェアエンジニアリングの責任者としての私の観点から、私は私が望む結果を生み出すツールが必要です。 MSBuildではこれらの結果は得られません。 これらの結果は、project.json + gulp.js + powershellから取得します。

_Can_ MSBuildは私にそれらの結果を得ることができますか？ 確かにそれは可能ですが、開発者がそれらの結果を得るためにMSBuildで作業を行う場合に限ります。 そして、彼らはそうしません。 私たちが彼らを

開発者が嫌うツールに頼ることはできません。 それが単純な現実です。 そして、自分で使わないのがどれだけ好きだったかを考えると、実際に彼らを責めることはできません。

実際にMSBuildの問題について話し合い、すべてをフォークしたり、何万もの複雑でビジネスに不可欠なプロジェクトを放棄したりすることを伴わないソリューションがあるかどうかを見てみましょう。

さて、それで、何ができるのでしょうか？

約5年前、現在議論されている変更のいくつかが導入されていれば、認識は良くなると思います。 しかし、そうではなく、今では膨大な数の開発者の間で大きなネガティブなマインドシェアを持っています。 私が覚えているように、これらの同じ問題のいくつかは、当時MSBuildで提起され、拒否されました。 現在の問題が提起され、拒否されているのと同じように。

それがどうやってそれを回復できるのか分かりません、私は本当に知りません。 私はいくつかの主要なクリーンブレイクが必要だと思います。 そこにあるものを壊さずにどうやってそれらを作るのですか？ 少なすぎて遅すぎます。 ですから、MSBuildで、私のためでも、私のために働く開発者のためでも、私のパートナーでも、私たちが相談するクライアントでもない、彼らのために働くチームのために、前進する道は見えません。 これらのオーディエンスは誰もMSBuildを使用したくないので、MSBuildを使用する必要があるため、ツールで使用し、繰り返し誓います。 確かに、通常はマージ時間の前後です。

それで、あなたはマージをより良くしたいですか？ 10年後。 ツールが多くの分野で誓いの言葉になった後は？

基本的に、90年代後半にビルドマスター用に設計されたツールを使用しています。これは、2010年以降、開発者が実際に使用しています。命令型作業に使用される開発者が使用するロジックの推論を使用するツール、および命令型ツール。 非常に柔軟ですが、プロパティセットが単純な代入演算子であると考え、 PropertyGroup 、気にしないでください。

それが私がしたい議論です。

確かに、わかりました。 しかし、私がしたい議論は異なります。それは、「あなたが私たちに約束したことを私たちに与えるか、私たち自身にそれを与えさせてください。私たちはあなたの古い新しいアイデアが好きではなく、私たちは約束されたものが好きだからです」。

悲しいことを共有できますか？ 私と同じくらいの経験を持つ（より実際には）ビジネスパートナーの中で、私は当時最もプロのMSBuildでした。 私は実際にそれを_使用_しました。 私はそれを学びました。 大きなパイプラインを作りました。 しかし、それは5年以上前のことであり、それ以来、多くの水が橋の下を流れてきました。

@shedermanのコメントと歴史を読んでいると、私のものと非常によく似ているので、うなずきます。 私はMSBuildとそのDSLに多くの時間を費やし、実際に数回苦労しました（それを学ばなければならないことに浸った時間の長さは言うまでもありません）。 その構文とアプローチは.NETの他のものとは異なり、それが問題の一部です（そのため、オブジェクトモデルを再起動/やり直し/改善して、もう一度やり直してください）。 それが私の主な関心事です。問題への取り組み方が他の（.NET）開発者とは異なり、関心や採用を促進するのではなく、製品を疎外するほどレガシーです。

考えてみてください：Visual Studio拡張機能（.vsix）。 最近出回っている他のすべてのものと比較して、レガシー/古い/異なるため、誰もそれらに触れたくありません。 ちょうどMSBuildのように-彼らはその不可解なシステムを学んで自分の会費を支払っているので、さて、あなたは、したい一部の開発者を持っています。

私も、MSBuildを扱ったことのある専門家の中で、おそらく最も経験豊富です。 ほとんどの開発者は、それを学ぶのに時間がかかることを望んでいません（あなたが最も確実にそうするからです）。 それはまるでそれ自身の言語であるかのようです。

もしそれが「より.NETに似ている」（そしてVSとのより良い統合があった）なら、それがより良い製品であり、検討するのに魅力的な提案であることに私たちは皆同意すると思います。

@ Mike-EEE＆@ shederman Mikeの指摘に@shedermanの応答を知っていると思います、私は彼の推論にほとんど同意します（私は、システムの構築とプロジェクトが奇妙な懸念の混合であるというテーマに同意します）。

繰り返しになりますが、私はこのレースに馬を持っていません。彼らがどちらの道を選んでもかまいません。 私は親指を立てて反応し、自分が話すのを聞くのが本当に好きです（会話への実際の知的関心の側面で：笑い:)

私は親指を立てて反応し、自分が話すのを聞くのが本当に好きです（会話への実際の知的関心の側面で：笑い:)

お力になれて、嬉しいです！ ：笑顔：

しかし、それは修理を超えていますか？ 修正できますか？

本当に、あなたが誰に尋ねるかによります。 @shedermanが示唆しているように、提起することは困難で困難でした（そして、はい、私はそこで私の言葉を検閲しました：stuck_out_tongue :)。 彼らは彼らのやり方で設定されているようです。 しかし、ソフトウェアの性質からわかるように、十分な時間と労力があれば、何でも可能です。 ：ウィンク：

@PhilipRieckあなたは本当に素晴らしい質問をしているのです！ 残念ながら、それらすべてについて明確な答えはありませんが、見てみましょう。

現在、すべてのビルドタスクにgulpを使用しています。 それは変わりますか？ 私のgulpfileは、dnuまたはdotnet-cliに実行され、実際に.csファイルのコレクションをアセンブリに変換します。 私はそれを保つことができますよね？

私はこれが変わるとは思いません。ここで話していることは、プロジェクトが実際にどのように構築されるかではなく、プロジェクトの定義にのみ影響することを95％確信しています（少なくともdotnetビルドを呼び出すことを超えて）。 dotnet CLIはある時点でMSbuildを呼び出す可能性がありますが、その時点では、それは内部的なものです。

msbuildは別のインストールにありますか？ dotnet cliまたはランタイムとは別にバージョン管理されますか？ これにより、CIビルドサーバーで利用可能にする必要がある最小値がどのように変更されますか？ 開発環境にインストールするための最小値？

これに対する明確な答えはありませんが、MSBuildが既にインストールされている場合でも（VSで言う）、MSBuildが完全に別個のインストールとしてdotnetCLIの一部として提供されることを想像してみてください。 しかし、私の側の純粋な憶測。 この「.neteverywhere」プロジェクト全体の大きな目標は、人々を成長させるための煩わしさを最小限に抑えることであることを私は知っています。 文字通りapt-getdotnet-cli（または何でも）、dotnet new、dotnetbuildである必要があります。 プロジェクトをビルドするためにMSBuildを呼び出す必要はありません。それがdotnet-cliの仕事です。

テキストエディターを使用してnugetの依存関係または.csファイルを追加している場合、追加する必要がある手順があれば、それを追加する必要がありますか？

.csファイルの場合、今日と同じように、間違いなく他には何もありません-彼らが非常に明確にしていることの1つは、プロジェクト内のすべての.csファイルを指定する日が私たちの後ろにあるということです（おそらく、必要に応じてそれを行うことができます） 、あなたを見て@ Mike-EEE）。 依存関係については、確かに短期的には（短期的には数か月）、project.jsonにとどまり、以前とまったく同じように機能します。 project.jsonがnuget.jsonになる可能性があるため、名前の変更を除いて、他に何も変更されませんが、これには他の可能性があり、これはMicrosoftが非常に確信していない主なことの1つであるようです-あなたの声を聞かせてくださいこれに対するあなたの好みについて聞いてください。
（私の個人的な好みは、次のようなことができることです.nu​​get.json しかし、それは私が唾を吐くだけです）。

VSユーザーがnuget依存関係と.csファイルを追加したチェンジセットを確認しているとき、csprojの変更は単純で人間が読める形式になりますか？ （比較のために、.net 4.6およびVS2015との比較では、csprojへの変更は人間が簡単に読める形式ではないというのが私の意見です。）

.csファイルの場合、csprojはまったく変更されません。 nugetの依存関係については、良い質問ですが、これもやや空中に浮かんでいます。 本当にcsprojを変更する必要はありませんが、現時点での大きな決定要因は、nugetをnuget.jsonに配置するか、csprojにそのようなものを含めるか、そしてそれらが分離している場合、囲い込みがどれほど難しいかということです。二つ？

そしてそれが主な核心です。 必要な工具が少なければ少ないほど良いです。 現在、上流を泳いでいるように感じることなく、テキストエディタとコマンドラインを使用できます。 それが変わらないことを願っています。 .net46ランドでは、VSを使用したくない場合は、巨大で冗長なxmlファイルを編集する必要があります。同じプロジェクトでVSユーザーと非VSユーザーを混在させるのは悪夢です。

私はこれに完全に完全に同意しますが、Microsoftはクロスプラットフォームの取り組みに多額の投資を行っており、突然それを悪夢にしています。 「ツール」とは、VSなどではなく.netCLIに依存することになると思います。 .net Coreの究極の「エンドゲーム」は、非常に機敏で動きの速いプラットフォームになることですが、数週間ごとにアップグレードに時間を費やす必要がないことを忘れないでください。 6月にdotnet1.0アプリケーションを作成した場合、それは数年後もビルドおよび実行されると確信していますが、新しいバージョンでは、準備ができたら「dotnetアップグレード」などを実行する場合があります。 。 RTMがヒットした場合でも、実際にアクセスしてターゲットをRTMに変更するまで（global.jsonかどこかで？）、RC2プロジェクトはRC2ビットをビルドして実行します。

：laughing：このようなスレッドを読んだとき、マイクロソフトに後悔の瞬間があるのではないかと思う必要があります。 私は、開発者にとって透明でオープンソースのコミュニティ志向の天国を作ることを目標に、マイクロソフトを裏返しにするために最善を尽くしてきた人々を本当に尊敬し、感じています。 この変革の背後にいる人たちは気にかけます。 彼らはいい人です。 彼らは今、岩と固い場所の間になければなりません。 （私を楽しませながら）浮かんでいる建設的ではないコミュニティの感情は、彼らの主張を助けていません。

現在IDEに存在する一連の魔法のプロジェクト作成機能を、多くの魔法のcsproj操作を実行するコマンドラインアプリに置き換えることは悪い考えであることを指摘したいと思います。 プロジェクト定義ファイルをできるだけ単純にすることは必須です。 project.jsonの最も優れた点は、それを読んで理解できることです。

@shederman MSBuildの問題は、大規模で複雑なシステムでは、大きくて複雑であるということです。

私はまた、ビルドチームで働いてきたし、私も絶対にそれを嫌っていました（ピング我々は両方この経験がどのようにひどいについて話してきましたbecuseマイク-EEE @）、私はそれを得るが、何を記述していることは完全に異なっていますかシナリオ。 MSbuildは大きくて複雑になる可能性があり、デフォルトではVSは大きくて複雑になりますが、それが

新しいcsprojファイルは非常に小さくする必要があります。つまり、「デバッグ」を大幅に簡素化する必要があります。 がらくたはありません（またはほとんどありません）。 引き続き、必要な_build system_を使用できます。つまり、*。csprojで「dotnetbuild」を呼び出すだけの.batファイルを呼び出すことができ、今日と同じように、必要な出力を取得できます。 dotnet cliにMSbuildを処理させれば、それに触れる必要はありません。

@neoKushanありがとう。

私は、私たちが離れようとしていると言われたことについての口紅ではなく、約束されたものが欲しいのです。

そして、あなたが約束されたものを私たちに与えたくないのなら、私たち自身にそれを与えましょう。 すでにすべてがあります。 これは、リファクタリングを維持するための単なるケースである必要があります。 前にも言ったように、私がその仕事をします。

それを残す意欲がない最大の理由は、これがMSBuildプロジェクトからの大規模な移行の始まりであるという認識にあると思います。 申し訳ありませんが、ライフサポートで古いテクノロジーを維持することは、.NETCoreの設計目標の1つではありません。 それは...ですか？

誰がそれを修正するか、そしてそれがどれくらいの時間がかかるかというmsbuildinの最大の問題。 現在、ASPnetプロジェクト全体で1000を超える未解決の問題が発生しており、そのうちのいくつかは非常に重要です。 SignalRを見てください。
リリースまで1か月あり、このバグは最終状態に非常に近づいています。

そして今、彼らはmsビルドが改善される可能性があると言っています。 MSには、このレガシーなたわごとをすべて管理するのに十分なリソースがありますか💩？ コミュニティはそれを処理できますか？ 私はそれを本当に信じていません。

@shederman

そして、あなたが約束されたものを私たちに与えたくないのなら、私たち自身にそれを与えましょう。

彼らはあなたが何かをするのを妨げていません。 先に進んでそれをフォークしてください、何もあなたを止めていません。 あなたがマイクロソフトの許可を待っているなら、あなたはすでにそれを持っています、あなたは彼らがコードをオープンソース化した2番目にそれを手に入れました。

すでにすべてがあります。 これは、リファクタリングを維持するための単なるケースである必要があります。 前にも言ったように、私がその仕事をします。

じゃやれ？ 繰り返しますが、何もあなたを止めていません。

それを残す意欲がない最大の理由は、これがMSBuildプロジェクトからの大規模な移行の始まりであるという認識にあると思います。

なぜ彼らは気にするのでしょうか？ MSbuildなどを使用すると、Microsoftにどのような違いがありますか？

本当の一番の理由は、ASp.netコアのプロジェクト構造がasp.netコアにのみ本当に適しているということです。 project.jsonには適さない、他にも何百ものプロジェクトタイプがあります。 project.jsonには独自の問題があるという事実を気にしないでください。これは、私たち全員が忘れているようです。コメントが不足しているのは私の愛玩動物です（いいえ、他の形式のように長いものではないことを示唆しています）。 XMLは役に立ちません）。

申し訳ありませんが、ライフサポートで古いテクノロジーを維持することは、.NETCoreの設計目標の1つではありません。 それは...ですか？

いいえ。ただし、古い既存のプロジェクトを.netCoreに移植できるようにすることが目標です。 その上、本格的なデスクトップバージョンではなく、MSBuildの.netコアバージョンについて話しているので、

あなたの唯一の問題は、彼らがあえてそれをMSBuildと呼んでいることです。 彼らがたまたまXMLであるが、「CoreBuild」などと呼ばれる新しいプロジェクトスタイルを思いついたとしたら、あなたは賢明ではなく、「私はXMLが嫌いです！」

あなたはマイクロソフトの許可を待っています、そしてあなたはすでにそれを持っています

まったく真実ではありません。 フォークしたくない、メインリポジトリで維持したい。 違いがあります。 したがって、まったく新しい.NETSDKをダウンロードする必要はありません。 私はそれを工具に入れたいのですが、そのためには、彼らの黙認が必要です。

あなたの唯一の問題は、彼らがあえてそれをMSBuildと呼んでいることです

いいえ、MSBuildを_使用_したいと思っています。 わずかですが、重要な違いです。 新しいproject.jsonビルドシステムの名前を変更し、MSBuildと呼びます。これを楽しく使用します。

あなたは賢明ではないでしょう、そしてあなたが続けなければならないのは「私はXMLが嫌いです！」だけです。

多分😄

とにかく、輪になって回る。

就寝。

私はそれをスタンドアップのために残しておくと言います。 誰も説得力がありません。 私はMSBuildのプロ側を理解していると確信していますが、同意しません。 そして、私はプロMSBuild側が非MSBuild側を理解していると確信していますが、それに同意しません。

私が言っているのは、両方を持つことができるということだけです。 MSチームからの余分な努力はありません（またはほとんどありません）。 次に、オプションを実際の本番環境のまぶしさの中で沈めるか泳ぎましょう。

@neoKushanの質問によると：

何が残っていますか？

私は実際に、もし可能であれば、上で概説した「教義」の周りに私の応答を組み立てたいと思っています。

• 人間が編集可能/読み取り可能である必要があります

上記の@neoKushanのステートメントを、対処されることを意味するものと

Guid ProjectTypeを取り除くことは、対処すべき最も重要な項目の1つだと思いますか？

しかし、私は上記の補遺を支持します。単純なプロジェクト（AngularのASP.Net Hello Worldなど）の場合、メモ帳でその全体を手動で作成できることは難しい（交渉不可能な）要件です。 Yeoman / VS / similarを使用する必要がある場合、人間が編集可能なプロジェクトファイルの提案に失敗しました。

• コメントを許可する必要があります

すでにMSBuildで動作しています

• 宣言型である必要があります

ファーストレベルの順序を変更する（の直接の子）プロジェクトの全体的な意味を変更する可能性があります。多くの場合、デバッグが困難です。 誤って.targetsインポートを一番上に持ってきた場合ほど、これが注目に値する場所はありません。

• 自己完結型である必要があります

これがMSBuildの最大の問題です。 ファイルを静的に読み取ると、そこで何が起こっているのかを実際に知るのに十分な情報が得られません。 _environment variable_で指定されたパスからの.targetsファイル、および環境変数がイベントでサポートされているという事実から、条件とインポートまで、非常に高いレベルの複雑さを犠牲にして、効果的にチューリング完全な環境を取得します。 、および貧弱な工具能力。 VSのMSBuildのひどい統合は、そのようなツールを構築することの難しさの結果であると私は思います。

これは、人間の可読性/編集性の問題に似ています。

• 可能であれば、マージの競合を減らし、マージを簡素化するように設計する必要があります

MSBuildは、これをワイルドカードの形式で技術的にサポートしています。 ワイルドカードのVSサポートは、ひどいものよりも悪いです。 それは積極的に働きにくくします。 上記のとおり、これは修正されることを承諾しますが、MSBuildへの_proposal_から_migrate_へのアイテムである必要があります（これまでのすべてのメッセージングは​​project.jsonに関するものであるため、への移行です）。ベースのプロジェクトファイル。

• 完全に文書化できる必要があります（文書化に自己完結の原則が適用されます）

MSBuildにはドキュメントがあると思います。 そのドキュメント、特にMSBuildのVS _flavor_については、かなりの要望があります。 なぜグループ内にさまざまなものがあるのか​​と戸惑うことがよくありますが、VSがそれらを移動するのを「支援」することはあまり役に立ちません。

完璧な例は、BondNuGetパッケージです。 ディスク上にBondIncludeフォルダーがない場合（csprojで参照されている場合）、ビルドが結果のアセンブリに実際にボンドタイプを生成できないことを知っている人はどれくらいいますか？ （エラースピューもありません）。 次に、その名前で空のフォルダーを作成し、プロジェクトを再ロードすると修正されます。

（はい、私は知っています、私はそれにバグを報告するつもりです）

• ツールに依存しない必要があります

MSBuildとは何の関係も望んでいないとしましょう（これ以上詳しく説明せずに、逆張りを感じているとしましょう）。 プロジェクトを定義し、ナゲットを介してパッケージをプルしたいだけです。 なぜこの特定のビルドシステムを使用せざるを得ないのですか？ 特に、プロジェクトを定義するだけの場合はどうでしょうか。

ビルド定義ファイルはプロジェクトファイル形式ではありません。 VSがそれを（ある程度）機能させることができたということは、それをそのまま使用し続けるための良い理由ではありません。 プロジェクト自体を表すだけの実際のファイルと、プロジェクトが生成するアーティファクトに関する情報（ビルド方法の説明ではありません）が必要です。 この場合、project.jsonでさえ、「コマンド」を定義できるため失敗します。 なぜそれらが存在するのですか？ 出力のタイプと、それがどこにあるかを定義するだけです。

私はこのスレッド全体を読みましたが、 project.jsonとproject.csprojこの議論で私が気付いたのは、これらのファイル名の1つだけにプログラミング言語全体が組み込まれていることです。 私はF＃でASP.NET開発を行うことを好みます。 それはASP.NETCoreでも可能ですか？ この時点で、私は最もかすかな考えを持っていませんが、そうではないと感じています。 人々がcsprojをcsproj, fsproj, vbproj省略形として使用しているのか、それとも本当にcsprojだけを意味しているのかさえ

更新：F＃の人々はCoreCLRのサポートに取り組んでいますが、実際のETAはまだありません。 私の言いたいことは、現在決定されているプロジェクトシステムは、今のところ人々の目に留まらないように見えるプログラミング言語に影響を与えるということです。 XMLよりもJSONを好むのと同じように、project.jsonが私をC＃に固定しようとしている場合（そしてコンパイル時のファイルの順序はF＃では非常に重要です）、私はそれを好みません。

今のところ、私にとってはFAKEとPaketに戻っているようです...

私は最初から.NETを使用していますが、MSBuildで注目すべき問題が発生したことはありません。 その主な理由は、すぐに使用できるソリューションのコンパイル以外の目的で使用したことがないということです。

そして、それは私がMSBuildのこの嫌いについて得ていないことです。 ソリューションのコンパイル以外の目的でMSBuildを使用するように強制する人は誰もいません。 そして、ソリューションをコンパイルできることは非常に便利な機能だと思います。ところで、「dotnet cli」にはまだ存在していません（今すぐプロジェクトを手動でループする必要があります。間違っている場合は修正してください）。

実際のビルドシステムを変更する必要はありません。 Nantを使用している場合は、引き続きNantを使用してください。 psakeを使用している場合は、引き続きpsakeを使用してください。 PowerShellスクリプトを使用している場合は、引き続き使用してください。 等！ ほとんどの場合、「dotnetbuild」部分のみをMSBuildの呼び出しに置き換える必要があります。 （dotnetビルドがMSBuildを呼び出す場合は、それも必要ないかもしれません）

これにより、MSBuildは非常に重要でない実装の詳細になると私は主張します。 それが私が過去10年間それを見てきた方法であり、それが私がそれを見続ける方法です。

しかしもちろん、このスレッドの冒頭ですでに述べたように、私たちが間違いなく必要としているのは、csprojをより適切に処理するためのproject.jsonとVisualStudioの_features_の一部です-そしてなぜそれらがそうしないのかわかりませんそれを提供することができます。

@jtmueller F＃（または、気が向いている場合はVB.net）を使用できないようにする必要がある_技術的な_理由はまったくありません。 MSBuildプロジェクトファイルへの移行の一部がそれを容易にするのに役立つとしても、私は驚かないでしょう。 DNXはこれに満足することはありませんでしたが、CoreCLRは間違いなくF＃をサポートしています。 F＃come RTMを使用できるかどうかはわかりませんが、間違いなくパイプラインにあります。

@ jtmueller project.jsonは、依存関係マニフェストとカスタムコマンドを備えたプロジェクト定義です。 特定の言語に結びついているものは何もありません。

私の夢のビルドシステム（MSBuildを完全に置き換える）では、Roslynを使用してタスクとターゲットを把握し、F＃を使用してビルドプロセス（またはC＃、またはVB.NET、Roslynがサポートするもの）を定義できるようにします。

もちろん、まだ誰もそれを提案していません。 しかし、MSBuildにロックバックすると、ほぼ確実にそのドアが非常に長い間閉じられます。

少し休憩しましたが、MSBuildを「保存」するために何をする必要があるかという課題について少し説明しました。 MSBuildを大幅に異なるビルドシステムに変えることができる、またはそうすべきではないと思います。 これは推論ベースのXML定義のビルドシステムであり、それで機能し、非常に多くの人々のシナリオ、特にいくつかのより複雑なシナリオで機能します。

しかし、私たち全員がMSBuildと格闘できる専用のビルドマスターを持っているわけではありません。 私たち全員がMSBuildの複雑さがもたらす力を必要としているわけではありません。 その複雑さを必要とするものの中には、MSBuildを使用したくないものもあります。 たとえば、私のチームの1つでは、すべてのカスタムビルドロジックはビルド前とビルド後のステップで実行され、Execは基本的にPowershellをシェル化しています。 MSBuildで実行できないからではなく、実行できます。その場合は、おそらく_すべき_です。 しかし、彼らはMSBuildでそれをしたくないからです。

ステップ1は、プロジェクト定義をビルドシステムから分離する必要があることです。 私にとって、それは非常に理にかなっています。 プロジェクト定義から依存関係を分割することについて議論することはできますが、それが必要であるとは思いません。

ステップ2は、ビルドシステムが必要なことです。 非常に単純なユースケースだけでなく、非常に複雑なユースケースも処理する必要があります。 しかし、1つのビルドシステムが_both_を処理する必要があるというルールはありません。 私の考えでは、最も理にかなっているのは、基本的にプロジェクト定義をビルドするだけのシンプルで軽量なビルドシステムを用意することです。 restore 、 build 、 test 、およびpackます。

ディレクトリ構造を定義として使用して、プロジェクト定義なしで機能する方法も探す必要があると思います。 明らかに、そのような状況は、デフォルトのフレームワークとデフォルトの依存関係を使用することを意味します。 多分可能かもしれないし、そうでないかもしれない。 しかし、定義の各要素を見て、「これのインテリジェントなデフォルトを推測できるか」と尋ねることはできますか？

しかし、ユースケースの80％にはおそらくそれで十分ですが、他の20％には十分ではありません。 彼らはもっと何かを必要としています。 （注意：ユースケースの比率に関する意見は異なる場合があります）。

ステップ3は、そのビルドシステムに非常に単純な形式の拡張性を許可することです。 しかし、私たちは非常に単純に話している。 基本的には、基本ビルドを実行することも、外部ビルドシステムを実行することもできます。 上記の外部ビルドシステムは、MSBuild、スクリプト、またはその他のビルドシステムです。

新しいビルドプロセスがMSBuildにシェルアウトできることを嬉しく思いますが、MSBuildのように（IMO）古く、意地悪で肥大化したものが、将来のすべてのビルドの基礎になるとは思いません。

Webフレームワークのようなものでは、MSチームが必死に反復しているのがわかります。 彼らは競争をしているからです。 たとえば、ナンシーが首から息を吸うことを心配する必要があります。 他のものに切り替えるのは_簡単_です。 そしてそれはMVC / WebAPIをより良くします。

MSBuildが.NETツール全体に組み込まれているため、他のものを使用するのは面倒になります。 競争はどこにありますか？ そして、その効果をMSBuildGithubボードで確認できます。 すべてのクローズドプロポーザルを確認してください。 彼らが今これらの「スリム化」の変更を行うことについて話している唯一の理由は、人々がproject.jsonからMSBuildに移動することを望んでいるからです。

MSBuildが最初から.NETCoreに組み込まれていれば、MSBuildチームから現在見られている動きは_none_になっていると思います。 しかし、ロックバックされるとどうなりますか？ 競争が基本的に除外されたら？ 何が起こるだろう？ 競争のないシナリオで常に起こること、そしてこれまで何年にもわたって起こったこと：大量の亡命を阻止するのに十分な改善ですが、特に興味深いことは何もありません。

人々は、MSBuildを「保存」する方法を私に尋ねました。 私はそれを本当の競争に開放し、選択が唯一の方法であると信じています。 すべての開発者に法定紙幣でそれを強制することは、それほど強力なものをほとんど必要としない人でさえ（そう、私はそれが強力であると信じています）、それに対してさらに多くの恨みを生むだけです。

これは、フレームワークを成功させるためのレシピではありません。

皆さん、覚えておいてください。私たちは皆、.NETが成功することを望んでいます。 私は.NETが大好きです。C＃は世の中で最高のプログラミング言語の1つであり、Scalaへの移行が遅いことを楽しんでいます-TheGoodParts™😉。
.NET Coreで新たに始めて、古いスタイルの.NETの（IMO）最悪の部分の1つに身を投じることでそれを行うとは思いません。 はい、MSBuildですが、いいえ、それに縛られていません。

必ずそれを維持してください。ただし、システムのコアに組み込まれているフロントとセンターは使用しないでください。

私の夢のビルドシステム（MSBuildを完全に置き換える）では、Roslynを使用してタスクとターゲットを把握し、F＃を使用してビルドプロセス（またはC＃、またはVB.NET、Roslynがサポートするもの）を定義できるようにします。

YAAAAAAAAAAS !!! そういえば...これはこの会話をするのに適切な場所ですか？ RoslynとMSBuildのリポジトリもあり、それらも関与する必要があるようです。 MSBuildリポジトリで試してみていると思いますが、（おっしゃるように）非常に堅固で柔軟性がありません。 このスレッドが生み出した関心のように、ここにもっと多くの人々がいることは、改革に大いに役立つかもしれないと思います。

ステップ3は、そのビルドシステムに非常に単純な形式の拡張性を許可することです。

プロバイダーベースのビルドシステム/モデル？！ 天才！ このメッセージを承認します。

ところで、あなたがあなたの望みを手に入れ、あなた自身のビルドシステムにアクセスできるなら、私たちはそれを呼ぶことをお勧めします... BERSERKER BUILD！ 「Berzerker @ shederman」にちなんで名付けられました...あなたのための私の新しいニックネーム。 ：笑顔：

@ Mike-EEE興奮しすぎないでください。 決して、私はそのすべての_まだ_ほど抜本的なものを提案しているわけではありません。

今のところ、MSBuildがステップ3をサポートしているので、ステップ1と2だけでよいと思います。

しかし、この種の可能性は、project.jsonを取得したときに私が目指していたものであり、ビルドプロバイダーを交換しやすくするために、プロジェクトをビルドから分離しました。 私の考えでは、MSBuildをルートに戻すと、これらの可能性がなくなります。 または、少なくとも彼らが牽引力を得る可能性をはるかに低くします。

ルートシステムは非常に強力であるため、現時点ではカスタムビルドは採用されていません。 MSビルドシステムが実際に必要なすべてを実行できるのに（痛みを無視して）、MS以外のビルドシステムを使用したい人を説得するのは難しい会話です。

これはこの会話をするのに適切な場所ですか

そうは思いません、違います。 また、今が適切な時期だとは思わないでください。 どのような方向性が可能かを確認する前に、この問題を解決する必要があります。

バーサーカービルド！ 「Berzerker @ shederman」にちなんで名付けられました...あなたのための私の新しいニックネーム。 ：笑顔：

それについてどう感じるかわからない😉

バーサーカーになろうとはしていません。 前進するときに後退したくないだけです。

やあみんな、多分車輪の再発明（ nuget.jsonまたはそれが呼ばれるものは何でも）の代わりに、依存関係管理の問題のほとんどを解決している既存のコミュニティ主導のソリューションを使用しましょう-Paket 。

1. 推移的な依存関係の概念があります
2. MsBuildとうまく統合されています
3. 依存関係を定義するための人間が読める形式のファイル形式です
4. packages.configからの移行パスは非常に優れています
5. そして他の多くの機能（しかし、明らかにこれらの4つは誰にとっても最も重要なものなので、Gitの依存関係やより良いパッケージ解決戦略などについては触れません）

@ Krzysztof-Cieslakは、MicrosoftがMSbuildプロジェクト定義を推進している最大の理由は、MSBuildに多額の投資を行った人々の移行を容易にするためであることを覚えています。 その点で、Paketはproject.json（またはproject.yamlやproject.csなど）に勝るものはありません。

そうは言っても、あなたが望むビルドシステムを使用できない理由はまだわかりません。 最終的に、「dotnetビルド」は、プロジェクト定義が最終的にどの形式になるかに関係なく、変更されません。dotnetビルドは引き続き出力を生成します。

@neoKushanはい。ただし、MSBuildを使用していない場合でも、「

@shederman間違いなく、「

私が言ったように、ちょうど限り、私は仕事をするために許可されていて、私は幸せだ、まったくのMSBuildを必要としない場所で軽量ビルドを、保ちます。 自己参照型の「MSBuildeverywhere」パイプラインを、行き止まりに合わせて構築できます。

しかし、それが機能する場合は、RichiCoderが提案したようにcsprojにproject.jsonを含める必要があります。

このようにして、「コアビルド」と「MSBuild」を並べて動作させることも、MSBuildなしでコアビルドを動作させることもできます。 そして、明らかに、project.jsonをインポートしない場合は、csprojでプロジェクトのプロパティを定義することもできます。

実際には非常に簡単な変更です。 頭のてっぺんから次のことを行う必要があります。

• 既存のdotnet-buildコードを保持し、特定の（未定の）状況で実行します。
• DotNetコアチームの計画に従って、MSBuildを実行しているものもあります
• VSがプロジェクトプロパティのproject.jsonまたはMSBuildのいずれかを読み取れるようにする
• project.jsonをMSBuildにインポートする機能を追加します

非常に少量の作業であり、Microsoftが「MSBuildforever」パスを継続できるようにし、.NET Coreコミュニティとの約束を守り、MSBuildをオプトアウトしたい人がそうすることを可能にします。

asp.netメンバーシップの誰もここで何も言っていないことは注目に値します。

その間、 ASP.NET Community Standupからの– 2016年5月10日、彼らは「新しい」MSBuildシステムについて話しますが、それが必要でないことを除いて、それが何であるかは言いません編集するVisualStudio。 asp.netに設計されておらず、ゲームの後半に（今）追加する必要があるのは残念です...設計にそもそもそれが含まれていなかったとき。 実際、project.jsonには、そのルートを使用する必要がある場合は、{"BuildSystem"： "MSBuild"}アイテムを含める必要があります。 また、MSが（有名な最後の言葉で）ツールを介してjsonファイルのコメントを「単に」許可できなかったのも不思議です。

@rhires私の理解では、「新しい」MSBuildシステムは、すべてのcsファイルをビルドに含めたり、依存関係をnuget.jsonファイルにオフロードしたりするなど、XMLを少し軽くするためのいくつかの調整です。 MSBuildの設計、アーキテクチャ、または使用法に大きな変更はありません。

私はあなたのproject.jsonのアイデアが好きです。 RC2の変更を行ったばかりで、「テストランナー」を入れたので、できなかった理由はありません。 _しかし_、彼らの心はproject.jsonを完全に削除し、MSBuildファーストの世界に戻ることに完全に固執しているようです。

MSが（有名な最後の言葉で）ツールを介してjsonファイルのコメントを「単に」許可できなかった理由

彼らができなかった理由はありません。 彼らが使用するライブラリであるJSON.Netは、コメントをサポートしています。

実際、project.jsonには、そのルートを使用する必要がある場合は、{"BuildSystem"： "MSBuild"}アイテムを含める必要があります。

プロジェクトに独自のビルドシステムを指示させるのはなぜですか？ 確かに、ビルドシステムはプロジェクトをビルドしますが、その逆ではありませんか？

@neoKushan ：

MicrosoftがMSbuildプロジェクト定義を推進している最大の理由は、MSBuildに多額の投資を行った人々の移行を容易にするためであることを忘れないでください。 その点で、Paketはproject.json（またはproject.yamlやproject.csなど）に勝るものはありません。

Paketは新しいビルドシステムではなく、MsBuildと100％互換性のある依存関係マネージャーです。 packages.config問題を解決するだけです。

@ Krzysztof-Cieslakビルドシステムであり、依存関係の管理は.netコアの大きな問題ではないと私は決して主張しませんでした（少なくとも私が知る限り）。 .NETコアは使用されませんpackages.configが使用するproject.json 。

.NetCoreがまだproject.jsonを使用するように計画されていた場合、この100件の投稿ディスカッションはありません。 ;）私が言っているのは、依存関係を処理するために「nuget.json」を使用するソリューションが多くの場所で提案されているのは、まったく同じことを行う製品があるため、車輪の再発明です。

@shederman

「最終調査結果：100の回答、900万の.NET開発者人口に対して、95％の信頼度で±10％です。」

はい、犬や猫が好むペットである猫のおもちゃについての会議で尋ねると、同様の結果が得られる可能性があります。

@darrelmiller

「MSBuildとVisualStudioが現在MSBuildを使用している方法を区別することが重要だと思います。私は、MSBuildファイルを何年も手作業で編集し、すべてのプロジェクトで使用しています。例： https ：

コマンドラインからmsbuildが機能しないプロジェクトファイルの上にあるVS固有のビルドファイルについて説明しますか？

@gregoryyoungすべきです。 以前にdevenvに依存するビルドファイルを作成しましたが、コマンドラインから実行されないファイルは表示されません。 例はありますか？

@gregoryyoung

はい、犬や猫が好むペットである猫のおもちゃについての会議で尋ねると、同様の結果が得られる可能性があります。

これは興味深い例えです。 それ外...

MSBuildへの移行を_サポート_した人々のTwitterフィードにリンクを投稿しました。 ですから、実際にはあなたのアナロジーとはまったく異なります。

そして、私は、調査が偏っている、間違ったフォーラムで、または非科学的であるという継続的なスラーが大好きです。 しかし、質問は先導的ではなく、回答には幅広い回答があり、調査は、はい、自己選択の聴衆でしたが、少なくとも理論的には、私の観点からはバイアスをかける必要がある幅広い聴衆でした。

私はまた、これらの告発をしている人々が調査について少しググったばかりであるという印象、そして場合によっては確認を得ました。 私は個人的に健康調査のための修士レベルの調査プロトコルを設計しました。調査が完璧であるとは言いませんが、マイクロソフトの従業員が行っているほど欠陥はありません。

それは間違いなく統計的に有意であり、意見がどこにあるかを示す良い指標になります。 GitHub、gitter、Twitter、ブログはすべて、ある程度までそれをバックアップしています。

同じことを言っている証拠の複数の情報源。 重要なユーザーの意見を無視したい場合は、そう言ってください。 あなたが「間違った」意見を持っている場合、あなたがあなたの意見を表明する権利を失うかのように彼らの反対を振り払おうとするのをやめなさい。

または、私が何度も言ったように、私が間違っていると思うことを改善する独自の調査を作成してください。

私が調査を行った理由は、マイクロソフトが人々が何を考えているのか見当がつかないことが完全に明らかだったからです。 今、完全に明らかになっているのは、人々が考えていることに「関心」がないということです。

自分自身やコミュニティに対して不正直になるのをやめ、反対派を振り払うのではなく、反対派と関わりましょう。

事実を変えようとするのをやめ、事実に基づいて考えを変え始めてください。

@shederman Microsoftチームが実際にこのスレッドに回答したという印象はありません（あなたの調査を含む）。 はい、チームの1人の男は、あなたほど信頼できるとは考えていないと言いましたが、それだけです。 彼らが現在進んでいる道への大規模な反対について話していること、そして彼らがとるべき正しい道について話し合っていること、そして彼らがもっと知ったときに私たちに対応することを彼らが現在話しているという希望はまだあると思います。

私たちはこのチームにいくらかの信用を与えることができると思います;）。

@gregoryyoung申し訳ありませんが、あなたが与えたアナロジーから、私はあなたがMSの従業員であると仮定しました。なぜなら、彼らは2日間同じおおよその線を速歩しているからです。

@sandorfr

このチームにクレジットを与えることができると思います

できると思いましたが、ここ数日の私の経験はその希望を強めていません。

それは「チームの」せいではなく、組織の上位の誰かがこの決定を下し、それを押し付けたのだと私は考えなければなりません...そして「チーム」はそれを吸い上げてきれいに見せなければなりません。 BTDT。 楽しくない。

Project.jsonは、ASP.NET Core以外のアプリケーションとの互換性を少し高めるために、最近すでにていることをご存知ですか？ そのアナウンスの投稿の例を見ると、そのすべてのビルド構成ですでにかなり肥大化しています。

それから「古典的な」csprojファイルに移行することは、実際にはそれほど遠くないように思えます。 また、csproj自体も、project.jsonから学んだより柔軟な方向に少し進化した場合、実際には「新しく改善された」csprojが非常にうまく機能していることがわかります。 そして、project.jsonに対するこれらの最近の変更は、すべての種類の.NETプロジェクトで使用できるようにするためのコースの最後の変更ではなかったと安全に推測できると思います。 ASP.NET（コア）以外の多くの他のターゲットです。

また、ファイル形式がJSON、XMLなど、実際にはそれほど重要ではありません。 はい、さまざまな正当な理由で一方が他方よりも有利である可能性がありますが、最終的には、プロジェクトファイル内で実際に費やしたい時間を考える必要があり

人々がproject.jsonについて考えるとき、彼らは主に設定より規約について多くの初期段階について考えて

したがって、tl; dr：はい、私はproject.jsonが本当に好きで、ASP.NET Core用にそれを保持する方法があればいいのにと思います（たとえば、特別なMSBuildタスクを使用します）。 しかし同時に、なぜこれが今起こっているのかを完全に理解しており、実際には彼らがしていることは悪いことではないと思います。 もちろん、タイミングは少し奇妙ですが、変更がASP.NETCoreと.NETCoreのリリースと並行して行われないことを考えると、タイミングは実際の問題ではないと思います（後の移行がスムーズになると仮定します） ）。

プロジェクト間でソースファイルを共有できる必要がある

@darrelmillerこれは、.csproj内のリストファイルが戻ってくることを意味しているように思われるため、私には怖いように聞こえます。

@lokitoth csprojが新しいproject.jsonと同様にファイル参照に対して

@shederman私はMSの従業員ではなく、合理的な人物です。 あなたが私をグーグルで検索すれば、私はプラットフォームに長期的な関心を持っていることがわかると確信しています。

変更に関連する多くの賛否両論がありますが、あなたが提供したものは、正気の議論には役立ちません。

これは、聞いてがっかりした変化でした。 project.json、自動ファイルインクルード/グロブ、および推移的な復元は、ASP.NET Coreの最初の機能であり、「ああ、いいね！」と思いました。 最初に。

そのすべてがなくなるわけではないことを私は理解しています（私は願っていますか？）。 しかし、XMLプロジェクトファイルに戻ることは、歴史的に人間にとって頭痛の種であったため、気分が悪くなります。 解析が難しいテキストの壁であるため、問題を修正するためにcsprojファイルを開くのは嫌いです。

ちょうど私の2セント。

@pokeの投稿の変更を見ると、基本的にcsprojをjsonに変換したように見えますが、これも正直なところかなり厄介です。

コンパイル、埋め込み、CopyToOutput、除外、共有ファイルなどのオプションをサポートしたいという事実に基づいて、実際にはjson形式はXMLよりもうまく機能しませんでした。 また、jsonは、大量のビルドスクリプトのカスタマイズではうまく機能しなかったと思います。

私は、これが、うまく行う方法を見つける時間ができるまで、さらにもう1つの半分焼き付けられたソリューションを本番環境に追加しないように努めているチームであることを願っています。

@gregoryyoungあなたが提供したものは、正気の議論には役に立ちません

すごい。 さて、見てみましょう、私が提供したもの：

• 他の多くの人たちと同様に、私はXMLへの移行について不満を持っています
• 他にもたくさんあるので、MSBuildへの移行について不満を言っています
• 私は決定の背後にある理由と証拠を理解しようとしましたが、それはいくつかの非常に手の波状のもの以外には実際には提供されていません
• 私は決定の背後にある根本的な_思考_に到達しようとしましたが、それは実際には提供されていません
• 私はコミュニティに彼らの意見を求めましたが、MSはまったく気にしませんでした
• 私は、理由を説明する人々によって述べられた結果を可能にするだけでなく、コミュニティが彼らが楽しむ彼らの単純な構築プロセスを維持することを可能にする代替案を考え出そうとしました
• 私は、前述の代替案をサポートするために必要な作業を行うことを申し出ました

興味をそそられて、非常識な部分は何ですか？ 最近、誰かの考えを尋問することは合理的ではありませんか？ それとも私はそこに何かを残しましたか？

つまり、私は怒っています、誤解しないでください。 私は、フレームワークの核となる約束を中心に、多くの作業、時間、およびお金を浪費してきました。 私は怒る_権利_を持っていませんか？

PS。 ああ、あなたはグレッグ・ヤングです。 尊敬。 あなたの仕事が大好きです。 本当です。

@bzbetty私はあなたに完全に同意します。 最後に見たいのは、MSBuildをproject.jsonに再考することです。 現在の形式のMSBuildの最大の問題の1つは、_プロジェクト定義_を_ビルドプロセス_と統合することです。

したがって、ビルドプロセスをproject.jsonに追加すると、MSBuild / VSとまったく同じ間違いが発生します。

プロジェクト定義は、ビルドプロセスとは別に立って、ビルドプロセスにフィードする必要があります。

そして、質問する必要があります。プロジェクトが単純で、プロジェクト定義を直接ビルドする必要がある場合、単純なビルドを行うためだけに、重量があり、拡張可能で、カスタマイズ可能で、柔軟性があり、直感に反するビルドシステムが本当に必要ですか。

別の言い方をすれば。 このような単純なプロジェクト定義があり、プロジェクト定義をビルドする以外に何もできない非常に単純なビルドツールがある場合、MSBuildやNAntなどをインストールして使用することを選択しますか？

いいえ、おそらくそうではありませんよね？ なぜ不必要に複雑さを増すのかということです。 効果的なソフトウェアエンジニアリングの実践の中核となる部分は、物事をシンプルに保つことです。

しかし、単純な「定義の構築」ツールでは処理できないシナリオに遭遇したら、どうでしょうか。 確かに、_それなら_あなたはそうするでしょう。

つまり、両方のツールを並べてインストールし、ニーズに最適なツールを選択できるようにします。 MSは次のように言っています。いいえ、必要なのは複雑で直感に反するツールだけですが、最もひどく悪い機能は削除します。

Soapboax

私が行ってきたちょっとした研究を共有したいと思います。 私はTwitter、Slack、Github、Gitter、Jabbrを見てきました。

コアチームの外への移動に対するサポートはほとんど見られませんでした。 つまり、いくつかありましたが、それほど多くはありませんでした。 ほとんどの人はその動きにかなり腹を立てています。

また、MSBuildを支持する陣営の多くの人が、対戦相手に誤った情報が提供されている、またはより一般的には資格がないと推測する傾向があることに、私はかなりがっかりしました。 これは、pro-project.jsonキャンプでの悪い動機（私自身を含む、mea culpa）を推測する傾向と一致しています。

私は次のことを聞きたいです：

• 自分の意見とは異なる意見を持っている人は、正当な理由で自分の意見を持っていると思い込む人がいます。 彼らは惑わされたり、無能だったり、共謀したり、狂ったりしていません
• 人ではなく議論や証拠を攻撃する人
• 提供された証拠は、確固たる理由なしに手に負えない形で却下されるべきではありません

の引数
私がMSBuildへの移行を進めた主な理由は、次のとおりです。

• ツールのサポート-VS、VSCode、Xamarinなどの異なるツール間のラウンドトリップを可能にします。
• 既存の投資-大規模なクライアントには、破棄する余裕のない既存のビルドがあります
• 「筋肉の記憶」-人々はMSBuildに慣れています

に対する議論

• 既存の投資-.NETCoreツールへの投資：ポストRC。 RC _should_は、大きな重大な変更がないことを意味します
• CSProj / MSBuild厄介-csprojとMSBuildを扱う際の過去の否定的な経験
• 後退-project.jsonへの移行は、新しい世代の開発者を引き付けるために、新しい作業方法に移行しました。 これは元に戻されています

意見
私はSurveyMonkeyの完全なサブスクリプションの料金を支払ったので、（最初の100ではなく）結果の完全なセットにアクセスできます。 これは321の応答であり、通常は±5.5％の許容誤差、900万の人口に対して95％の信頼度に相当します。

この調査に対して私が聞いた一般的な議論は次のとおりです。

• 質問/回答には偏りがあります。私はそれを信じていません。たとえそうであったとしても、それほど多くはありません。 幅広い答えがあります。
• 調査は偏った聴衆に投稿されました：Twitter？ さまざまなチームメンバーのタイムラインのフォロワーに。 それがどのように偏った聴衆であるかわからない。
• 科学的に関連性がない：さて、これに私を連れて行った。 私は完全な研究プロトコルを実行しなかったので、ピアレビューに合格しませんでした。 それは、提案のサポートを評価するために必要な確実性のレベルですか？

はい、どうぞ：

.NET Frameworkを愛する人への私の魅力は、これらの変更に対する不安のレベルを過小評価しないこと、そして彼らの懸念が有効であり、情報に基づいた経験から来ることに基づいて、フィードバックを取り入れてコミュニティに参加することです。 。

そして、それにもかかわらず先に進むという決定がなされた場合、これまでよりも優れた一連の推論と証拠が提供されるべきです。

Man @shedermanは、Silverlightがそれを食べたとき、x10とより集中的/経験豊富な

現在の形式のMSBuildの最大の問題の1つは、プロジェクト定義をビルドプロセスと統合することです。

したがって、ビルドプロセスをproject.jsonに追加すると、MSBuild / VSとまったく同じ間違いが発生します。

プロジェクト定義は、ビルドプロセスとは別に立って、ビルドプロセスにフィードする必要があります。

：+1 ：： + 1 ：： + 1：...問題を組み立てる優れた方法!!! あなたが知っている、私はこれに長い間私の鼻を持っていたので、これは私には実際には起こりませんでした。 しかし、あなたは（再び）100％オンポイントです。

解析が難しいテキストの壁であるため、問題を修正するためにcsprojファイルを開くのは嫌いです。

これはどこかで組み立てる必要があります、@ nbarbettini！ 私の感情も完璧に捉えています。

また、ファイル形式がJSON、XMLなど、実際にはそれほど重要ではありません。

ええ、私は人々にこれを思い出させようとするのは嫌いですが、一部の開発者はフォーマットの概念に固執しているようで、それは誤解を招きます。 「JSON」プロジェクトパラダイムは、実際には「JSONのもの」ではありませんが、「モデル」を記述するためのシリアル化の選択肢としてJSONを使用します。 JSONはXMLよりも簡潔でおしゃべりではないという事実により、JSONは（ほとんどの人にとって）はるかに魅力的なものになりました。

同様に、MSBuild自体はXMLに根ざしていませんが、MSBuildの設計方法は、その「モデル」をこの形式で記述することです。 これらのシステムは両方とも、最終的にメモリに逆シリアル化される実際のモデル/ APIの前にドキュメントモデルを配置するという（私が考える）設計上の欠陥に悩まされているため、「モデル」と言います。 つまり、本当に必要な数よりも多くのアーティファクトと概念を管理する必要があり、最終的にはシステムが複雑になります。 特定の形式（XMLまたはJSON）のみを受け入れるようにハードコーディングすると、事態はさらに悪化します。この場合も、この制約を緩和する方法を検討する必要があります。

とにかく、日曜日の朝のPSAはみんなのためにラメ。 ：stuck_out_tongue：

このスレッドのどこにもこれが投稿されているのを見ることができなかったので、ここに行きます... https：//youtu.be/N9MteJH-HsQ。 うまくいけば、変更が行われる理由についてもう少し説明します。

@shederman

「興味をそそられて、非常識な部分は何ですか？最近誰かの考えを尋問することは合理的ではありませんか？それとも私はそこに何かを残しましたか？」

私は調査結果を参照し、一般的な開発者集団に外挿しようとしていました。 私が述べたように、それは猫のおもちゃの大会でより良い犬対猫である世論調査を実行することとほぼ同等であり、それが全人口に適用されると仮定すると、大きくて明らかなサンプルバイアスがあります。

私の電話のGitHubでは、 @ gregoryyoungを+1することはできませんが、+ 1することができます。

チームは、変更の理由の一部はXamarinの買収であると説明しました。これは大きな問題です。 .NET、ASP.NET、およびXamarin mobile / x-platプロジェクト間でライブラリを共有する可能性は計り知れません。それがプロジェクト/ビルドファイル形式を損なうことを意味する場合、それは価値のあるトレードIMHOです。

最終的な意見を述べる前に、ツールと最終的なファイル設定がどのようになるかを待ちます。

@gregoryyoung私は調査結果を参照し、一般的な開発者集団に外挿しようとしていました...大きくて明らかなサンプルバイアスがあります。

それはどのサンプルバイアスでしょうか？ 変更を_好き_な人のTwitterフィードに主に投稿されたものですか？ 開発チームが使用しているのはSlackチャネルでしたか？

私が見る主なサンプルバイアスは、回答者がおそらく熱心で、情報に通じており、情熱を持っているということです。 確かに、それは代表的なサンプルではない可能性がありますが、重要なサンプルであると私は主張します。 そして、サンプルバイアスがあっても、それは結果を捨てなければならないことを意味しますか？ 回答者の視点は関係ありませんか？

322人のプロの.NET開発者が意見を表明しました。 あなたはそれが代表的ではないと信じているので（あなたを裏付ける証拠なしに）彼らの入力を完全に無視するつもりですか？

どうやら、ブログの投稿は来週来るでしょう、それから私達はより具体的な事柄について議論するでしょう。

うわあ、人々は一体を落ち着かせる必要があります:)

私はこの変化が大きく見えることに同意しますが、それが人々に与える影響は見た目よりもはるかに少ないと思います。 チームがCLIも含む「ツール」について話すときは覚えておいてください。 発生する必要のある変換もCLIによって行われ、参照を追加するための「ツール」は、jsonまたはxmlのいずれかに入力するよりも優れていると私は主張します。 Globbingはmsbuildですでにサポートされています。 Msbuildは明らかにdo n't sdkに含まれるため、追加のインストールはありません。新しいプロジェクトストーリーも同じで、dotnetコマンドは内部で他のことを実行します。 （私はマイクロソフトではありませんが、これは可能性が高いようです）

チームは馬鹿ではありません、彼らはこの変更を軽くしません。 それらには、主に言語間でのプラットフォームの他の部分との互換性と一貫性、ネイティブ参照とプロジェクトタイプ、nugetパッケージの粒度などの理由があります。 たった1週間で、彼らは変更とその理由をすぐに詳しく説明すると言っています。

私は人々が少なくともそれを待って、彼らの実際の計画が何であるかを完全に非難する前に望んでいます。

そして、はい、私はcsproj / tfprojファイルをデバッグし、ファイルインクルードなどの条件付きルールと戦いました。 ちなみに、カスタムビルドタスクを作成することもできます。 しかし、結局のところ、比較的単純なproject.jsonシステムでサポートする必要のあるすべての複雑なシナリオをサポートするよりも、単純なツール（CLIを含む）で複雑なシステムを抽象化する方がはるかに簡単です。

言い換えれば、project.jsonで人々が愛していたシンプルさはすでになくなっており、あらゆる種類またはプロジェクトとシナリオを備えた一般化されたドットネット環境の複雑な現実をサポートする必要がありました。 それらすべてをproject.jsonに実装した場合、基本的には再びmsbuildを使用することになります。 私は、project.jsonがスパゲッティの大きなボールになるまで、機能を次々と追加するのではなく、一歩下がってビルドシステム全体を見る方がはるかに好きです。

彼らが何を示唆しているのかを見て、それに誤りが見つかった場合は特定の問題を提起しましょう:)

@ aL3891

チームが彼らの推論と検討された代替案、およびそれらが拒否された理由を明確に説明し、ここで提案された提案を検討して関与する場合、私はそれと一緒に強打し、そのようなプロセスから出てきます。

実際、これはまさに私が3日間求めていたものです。 意思決定プロセスとそれを裏付ける証拠への洞察。 この点に関してこれまでに提供されてきた情報は、せいぜい圧倒的でした。

私たちがそれを手に入れたら、私から+10。

@ aL3891簡単な質問。 一部の人々は、これらの問題に対処するために水曜日のスタンドアップに参加する必要があると言っていました。 ブログの投稿を待つべきだと言っているのですか？

これはすべてオープンソースであることも誰もが覚えておく必要があります。 非msbuildの方が優れていると強く感じた場合は、既存のツールをフォークして続行してください。 すべての興味深いソフトウェア設計の選択と同様に、議論のすべての側面に賛否両論があります。 マイクロソフトは、高額の顧客に対応する必要がありますが、彼らの功績により、これらすべてをオープンソースにしています。 他の何かがあなたのために働くならば、それをしてください。

@khellangが投稿したYouTubeビデオを見ました

さらに、車輪の再発明のアイデアは魅力的ではなかったようですが、それが実際に正しいことであるように思えたときは...しかし、再び遺産になりました。

私は、.NETスタンドアップに基づいてMSBuildを使用するという新しい批評を持っていますが、多くの場所で関心の分離がありますが、MSBuildはそうではありません。 大まかに言って、スタンドアップによれば、効果を上げるには、どういうわけかすべてを知る必要があり、単に異なる部分を調整するだけでは十分ではありません。

その間、これは別のスレッドに進むべきだと私は考えています-後でコミュニティと共有される「内部エンジニアリングの決定」があるようです。 これは、MSが完全にオープンソースになっていないと私に思わせます-彼らがこれらの議論をオープンに行っていた（そして人々に彼らが起こっていることを認識させた）なら、それはそれほど驚くことではなく、私たちはすでに答えを持っているかもしれません、そして多くの利害関係者（つまり、MSBuildからの移行によって悪影響を受ける顧客）は、自分の立場を以前に明確に知らせることができ、コミュニティは、問題/懸念、さらには解決策について、よりタイムリーに対応できたはずです。提示された問題...代わりに、「それが私たちの唯一の選択肢でした」という理由で、ソフトウェアだけでなく開発プロセスもオープンソースにしています。 このように、「十分な眼球が与えられれば、すべてのバグは浅い」という格言が機能するはずです。 MSのエンジニアリングチームの規模はわかりませんが、コミュニティ全体よりも小さく、エンジニアリングチームが実行不可能であると判断したような課題に取り組む可能性のある、真剣に優れた才能がコミュニティに存在します。 ...そしてそれはおそらく彼らのためですが、コミュニティ全体ではありません。 オープンソースとは、そこにある未開発のリソースと才能を使用することです。

一方、どこかで何かを逃したのではないでしょうか。

@shederman既得権を持つ人は、スタンドアップに参加し、ブログ投稿（ほぼ確実にここにリンクされます）に注目することをお勧めします。

スタンドアップに気付いていない人は、 https ：

カレンダーに追加することができ、プロジェクト定義の変更を気にしない場合でも、見る価値があります。

@shederman私には、誰かに何をすべきかを教える権限があるとは思いませんが、私が何をするかはあなたに伝えることができます。 一体、私は他の人と同じ部外者です、私は何も_知りません_ :) on.netショーのスタンドアップは素晴らしい情報源であり、特に何が来るのかについての初期のヒントだと思うので、私は確かに見ますそれらの。 彼らが私がブログ投稿が来ると言ったら、私は少なくとも彼らに疑いの利益を与え、彼らが何を言わなければならないかを見るつもりです。 しかし、私はおそらく両方にコメントを残す/質問をするでしょう。

上にリンクされている最新のon.netエピソードは、いくつかの良い洞察を提供しましたが

roslynプロジェクトシステムリポジトリもあります。これは、今後数か月で多くのアクションが発生する可能性が最も高いです。

誰かがon.netエピソードにTL; DRを持っていますか？

私はプログラミングについてのビデオを見るのが_嫌い_で非常に珍しいと思います。 いつでもテキストメッセージをください😄

血まみれの地獄の火！ 私は自分の学習方法ではIDEでもありません😱

プログラミングについてのビデオを見るのが嫌いなのは非常に珍しいことだと思います。 いつでも私にテキストをください：smile：

どうしたの？ それはあなたの時間の_たった_1時間です。 ：ニヤリ：

@rhires

お前。 これはおそらく、過去3日間にこの問題で見た中で最高の投稿の1つです。

最先端のイモにとどまるために支払う小さな価格ですが、それぞれに;）

基本的なtl; dr：
チームは、xamarinなどの内部顧客と外部顧客の両方から、既存のプロジェクトのproject.jsonへの移行が困難であり、project.jsonを既存のプロジェクトや、ネイティブプロジェクトや他のツールチェーンなどの他のツールチェーンと連携させることでフィードバックを得るようになりました。 androidのようなプラットフォームは、msbuildから大量のコード（または概念）を取り込むことを意味します。 これには多くの時間と労力がかかり、許容できない時間でリリースが遅れるだけでなく、将来の作業が遅くなります（xamarin studioやmonodevelopなどの他の製品、およびVisual Studioプラグイン開発者を含む）。

そのため、代わりに、ビルドシステムをmsbuildに基づいて構築することを選択しましたが、新しいシステムから人々が気に入ったものを取り入れました。 タイミングについては、RC1が作成されたときでもxamarinの取得は不明でしたが、実行されたため、多くのことが変更されました。

彼らはまた、人々がproject.jsonを非常に気に入っており、彼らも同様であり、msbuildがターゲットを介してproject.jsonファイルを読み取ることさえ可能にすることで、そこからの良さをできるだけ多く保持したいと考えていることも認識しています。 CLIおよびVSなしのシナリオも、コアシナリオと見なされます。 また、他のビルドシステムについても少し話します。目標は、必要に応じて、msbuild以外のものを使用できるようにすることです。

次に、RC2とそこに出荷されているものについて少し話します。また、プロジェクトシステムの移行に関して、より早くオープンになり、GitHubでより多くの会話をするなど、さまざまな方法で何ができたかについても考察します。

私はそれを見ることをお勧めします、私はおそらくここでいくつかのより細かい点を見逃しています。

@ aL3891-すばらしい要約をありがとう。 ビデオを見るのはスローガンでした。 私は彼らがテキストの要約を書くべきであることに同意します。 私は彼らが「学んでいる」ことに気づきました、そして彼らがそれが良いことだと言っているとしても、彼らのプロセスを開くことにまだ不快です。 ですから、これが彼らにとって良い学習体験になることを願っています。私たちは変化を見て、その恩恵を受けるでしょう。

@ aL3891まとめてくれてありがとう！

最先端のイモにとどまるために支払う小さな価格ですが、それぞれに;）

ああ、私は最先端ではないよ、私はそこから少し背をご利用いただけます。 自分自身を切り落とさないように十分に遡ります。少なくとも、.NET Corepost-RC1を採用したときに考えました😢

@shedermanは、「post-RC1」が基本的にナイトリーまたはソースであることを考えると、ステーキはどの程度好きですか。

@neoKushanつまり、「採用* .NET Core _after_RC1がリリースされただけです。まだバニラRC1を使用しています。

だから、私たちはステーキミディアムレアが好きです。 しかし、私たちは本当に未調理のビットに切り込み、ウェイターを叫んでいます。

しかし、大丈夫です。ウェイターを呼ぶのをやめ、メートルドテル（グループマイクロソフトパートナーの代表者）に会いに来てもらいました。意思決定、情報の普及、プラットフォームの方向性について話し合うことができます。

私たちは何も知りません！

この問題については、十分な情報が提供されておらず、理論と推測が多すぎます。 このスレッドを読みたくない怠惰な人のための簡単な要約：

私たちが知っていること

1. xprojはcsprojに変換されます。
2. nuget.jsonファイルがある可能性があります。
3. msbuildます。
4. これはすべて段階的に行われます。
5. ライブラリは変更されません。
6. csprojですべてのファイルを指定する必要はありません。

まだわからないこと

1. csprojは.nu​​pkgにコンパイルされますか？
2. csprojは、一度に複数のアーキテクチャとターゲットにコンパイルされますかx86 / x64 dotnet / dotnetcore？
3. 別のnuget.configファイルがありますか。
4. npm / gulp / bower / etcを実行するためのコマンドはどのように処理されますか？
5. dotnet buildとmsbuildを使用できますか？ @shanselmanが目指す「 完全に賛成です。
6. プロジェクト参照のインテリセンスは残りますか、それともなくなりますか？
7. VSツールまたはコマンドラインは、csprojを編集する必要がないほど十分に優れていますか？
8. dotnet add reference MyAssemblyツールを入手できますか？

詳細がわかるまで、この問題は解決されるべきだと思います。

@shanselmanが目指す「 完全に賛成です。

これ？ ：smile ：： + 1 ：： + 1 ：： + 1：

詳細がわかるまで、この問題は解決されるべきだと思います。

しかし、しかし...それでは私は私の人生で何をしますか？ ：cry ：： grin：

@RehanSaeed

また、「知っていること」リストに問題がある場合はどうなりますか？

懸念を表明する前に、「まだわからないこと」リストが明確になるのを待つ必要がありますか？

それとも私はただ黙ってそれを吸う必要がありますか？

私は非常に多くの人々が望んでいることをよく知っているので...😉

私が見たすべてのことから、決定は100％であり、以下については変更できません。

では、「まだわからないこと」からさらに何が必要なのでしょうか。

@shedermanあなたは本当にOn.Netビデオを見たいかもしれません。 それは決定の背後にあるたくさんの推論を与えます。

fyi：私は通常、速度を1.5に変更して、より速く視聴します。 https://www.youtube.com/watch?v=N9MteJH-HsQ

XMLベースのプロジェクトファイルを使用する場合は、ツールがファイルの内容を何らかの順序で配置することを提案/奨励/要求してください。 そして、「年代順」は受け入れられる順序ではありません。 私がprojファイルで見つけた最大の問題は、それらをマージするのが難しいことです。 少なくともアルファベット順に並べてください。 はい、まだ時折マージの問題が発生しますが、私はいつでも「遍在」よりも「時折」を取り上げます。

@MelGrubb私たちが知っていることの1つは、新しいプロジェクトレイアウトには、存在するすべてのファイルがリストされないということです。これは、project.jsonが行うのと同じようになります。

手作業で管理することが予想されるものについては、TOMLでお願いします。

JSONは、構成にはまったく意味がありません。 XMLよりもさらに意味がありません。

興味のある人には、RC2ビットが利用可能であるように見えます（私が見ることができるブログ投稿はまだありません）

https://www.microsoft.com/net/core#windows

およびhttps://www.microsoft.com/net/download#core

私の2セント、fwiw：

私はproject.jsonのシンプルさが大好きです。 MSBuildベースのツールで見たい（そして見たくない）ものは次のとおりです。

• MSBuildは、VSまたはその他のIDE /エディターに関連付けないでください。 単独でインストールできるスタンドアロンツールである必要があります。 （または、dotnet cliインストールの一部として含まれています。）MSBuildを取得するためだけに、ビルドエージェントに完全なVSインスタンスをインストールする必要があったため、これを言います。 それは私には決して意味がありませんでした。
• MSBuild（またはMSBuildを含むdotnet cli）自体は、コマンドライン（apt-get、chocolately、homebrew、powershell、bash / curl）を使用してインストールできる必要があります。 ビルドエージェントの完全に自動化されたセットアップの一部としてこれをインストールできない場合（たとえば、circle.ymlまたはDockerfile）、障害となり、苦痛の原因になります。
• MSBuildは、コマンドラインに非常に適している必要があります。 私はコマンドラインから何でもできるはずです-したがって、ビルドプロセスで何でも自動化できるはずです-circle.yml、bashまたは他のスクリプトファイルで。 また、stdinとstdoutをうまく使用して、MSBuildコマンドをパイプイン/パイプアウトできるようにしたいと思います。
• VS Code（または別の非VSエディター）で.NET Coreプロジェクトを操作する場合、csprojファイルやその他の場所にVS固有の情報を含める必要はありません。 プロジェクト情報、nugetパッケージの依存関係、プラットフォームターゲット、コンパイラ指令などは、さまざまなIDE /エディターを使用する開発者間で共有可能である必要があります。 それらはプロジェクトファイルで意味があります。 ただし、VSを使用していない人は、VSツール設定を確認する必要はありません。これらは別のファイルに属しています。
• プロジェクトファイルは、理解しやすく、手作業で編集しやすいものである必要があります。 ツールは素晴らしいですが、ファイルを開いてツールが私のために何をしているかを理解できるはずです。 そして、簡単に変更を加えることができます。
• 機能/機能に違いはないことはわかっていますが、個人的にはxmlよりもjsonを強く好みます。 また、jsonを使用すると、他のスタックからの開発者を引き付けるのに役立つと思います。 大きくて解読しにくいXMLファイルを最初に目にするものの1つを作成せずに、人々を.NETに引き付けるのは十分に困難です。 （これは論理的というよりは感情的ですが、重要だと思います。）少なくともjsonをオプションにして、yeomanジェネレーターやその他の新しいプロジェクトテンプレートでそのオプションを使用してください。 最悪の場合、MSBuildリポジトリに単純なjson形式を実装する不可避のプルリクエストをすぐに受け入れてください。
• npmスタイルの「スクリプト」を保持しておくと、開発、テスト、デバッグ、ビルド、実行、Dockerビルド/実行などに使用されるコマンドをチームと簡単に共有できます。 それらは独自のスクリプトファイルに入れることができますが、プロジェクトファイルの一部として（私には）意味があります。

@jtbennett

「しかし、VSを使用していない人は、VSツールの設定を確認する必要はありません。これらは別のファイルに属しています。」

追加するだけで、他のファイルにもたくさんのものがあり、msbuildファイルに入れる可能性があります。 無視されたものは、プロジェクトファイルがまだサポートされているというこの良い例です。 VSに組み込まれているが、コマンドラインからは組み込まれていないプロジェクトがいくつあるかはわかりません。

@jtbennett

MSBuildは、VSまたはその他のIDE /エディターに関連付けないでください。

VSにはまったく関連付けられていません。Nuget経由で配信されるため、何にも関連付けられていません。

MSBuild（またはMSBuildを含むdotnet cli）自体は、コマンドラインでインストール可能である必要があります

これは今日から変更されていません。通常のパッケージソースを介してdotnetcliをインストールできます。

MSBuildは、コマンドラインに非常に適している必要があります。

_MSBuild_は事実上ビルド自体の一部になるので、コマンドラインオプションを渡す必要はないと思います。 ただし、donet（CLI）は明らかにコマンドラインに対応しているため、必要なのはこれだけだと思います。

VS Code（または別の非VSエディター）で.NET Coreプロジェクトを操作する場合、csprojファイルやその他の場所にVS固有の情報を含める必要はありません。

私はこれに完全に同意します。 「新しい」プロジェクト形式がはるかに簡素化されることを願っています。

プロジェクトファイルは、理解しやすく、手作業で編集しやすいものである必要があります。

彼らはこれが彼らにとっても優先事項であると言っています。

機能/機能に違いはないことはわかっていますが、個人的にはxmlよりもjsonを強く好みます。 また、jsonを使用すると、他のスタックからの開発者を引き付けるのに役立つと思います。 大きくて解読しにくいXMLファイルを最初に目にするものの1つを作成せずに、人々を.NETに引き付けるのは十分に困難です。

これは興味深いと思います。個人的には、XMLはJSONよりもはるかに解読しやすいと感じていますが、その多くは、スキーマが（どちらの場合も）どれだけうまく設計されているかにかかっていると思います。 私は過去にいくつかのひどいXMLを本当にひどい要素名（「Element」のような）で解読しなければなりませんでした。MSBuildはその点で決して最悪の犯罪者ではありませんが、それは確かに多くのことが望まれます。 JSONを使用すると、キー名で同じ問題が発生する可能性があります。

ちなみに、私は最近、誰かがJSONをXML要素に埋め込もうとしたプロジェクトに取り組む必要がありました:(

RC2ブログ投稿がアップしました： https ：

.netコアの投稿もアップしていますhttps://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

ありがとう@neoKushan ！

@michaelvolzこれが信じられるのであれば、ファイルが残るとは思わない： https ：

System.GC.Server（旧：gcServer）-サーバーGCを使用するかどうかを示すブール値（デフォルト：true）。

と

depsファイルに別の形式を使用することもできますが、すでにJSONパーサーをホストに統合している場合は、ここでそれを再利用するのが最も適切なようです。

_project config_にはXMLがありますが、_runtime config_には.jsonがあるのは少し奇妙に思えますか？

プロジェクトにはXMLがあり、ランタイムには.jsonがあるのは少し奇妙に思えますか？

今ですか？ ：笑い：

@ Mike-EEE良い点です！ うまくいけば、私が何を意味するのかを明確にするために更新しました：kissing：

@neoKushanいいえ、あなたは初めて正しかったです。 ：smile：私は、私の卑劣な、境界線の逆効果的な方法であなたに同意していました。 ：smirk_cat：

しかし、そうです...ソリューション内で異なるフォーマットを使用することは腹立たしいことであるという100％の合意。 全体的に単一のフォーマットを使用することで、複雑さ、コンテキストスイッチング、したがって_混乱_が軽減されます。 これが、 MSBuildでさまざまな形式を有効にして、形式に依存しないようにしたい理由の1つです。 おっと、警告、恥知らずなプラグ。 ：ニヤリ：

私はあなたの聖なる十字軍@ Mike-EEEのフォロワーになると思います。私たちは、msbuildで立ち往生しているので、それを改善しましょう。

@sandorfrに感謝し

@ Mike-EEEスレッドの一部を読みましたが、今はとても落ち込んでいます...あなたはレガシーマインドのレガシー世界に足を踏み入れました：D。

物事がより単純でわかりやすくなり、プロジェクトを編集するためにGUIが必要ない場合にのみ、実際にmsbuildで問題がないため、Microsoftの人々があなたのアイデアにもっとオープンになることを願っています（はい、jsonintellisenseの方がはるかに優れていました）通常のビジュアルスタジオプロジェクトタブよりも）。

あなたはレガシーマインドのレガシー世界に足を踏み入れました：D。

Wellllll-言った@sandorfr ... wellllll-言った。

スタンドアップに気付いていない人は、 https ：

OK私は完全に怠け者で、ついにこれをチェックしました。 次のスタンドアップは来週のようですか？ チームは今週スキップしますか？

@ Mike-EEE興味深いことに、ある時点で間違いなく今夜の予定でしたが、変更されたのではないかと思います。 私は@shanselmanをツイートしリリースされなかったことを考えると、今週はスキップしたいと思うかもしれません。

OKクール@neoKushan ...正気が私の頭に一度ボルトで固定されていることを確認するだけです。 確かに、私たちの質問や不満のすべてにこれほど迅速に対処したくはありません。 ：ウィンク：

Slackから：

jongalloway [9:31 AM]明日のASP.NETCommunity Standupはキャンセルされると確信しています。つまり、shanselmanとdamianedwardsの両方がOSCONにいます。
..。
davidfowl [9:34 AM] damianedwards：戻ってきた...しかしshanselmanはosconにいる
..。
jongalloway [9:46 AM]ええ、ASP.NETコミュニティスタンドアップは5/17に完全にキャンセルされます。 サイトを更新しました。

@ Mike-EEEは私たちのすべてを扱っています...不満

😆

疑問が残った場合： https ：

スキップする必要があります。 私は#vsliveとOSCONにいます

project.jsonで私がとても楽しんでいることが1つあります。すべてのファイルがデフォルトでプロジェクトに含まれ、これらの各ファイルを明示的に含める必要はありません。 大規模なプロジェクト（ファイルのI平均数千人）で、マージプロセスがあるため、XMLの、だけでなく、ためにcsprojに記載されているされているすべてのファイルの本当に苦痛でした。

こちら側に改善があるかどうかわかりますか？

@pierrusすべてのファイルがcsproj内にリストされていた時代に戻りたくないと言われました。

@MaximRouiller OKはそれを知りませんでした、素晴らしいです！

@MaximRouillerですが、MSBuildがいます。 😉

_ash nudertogvegaldurbatulûk、ash nudertog vegal gimbatul、
ashnudertogvegalthrakatulûkaghburzum-ishikrimpatul._

@shedermanニュースに対する最初の反応以来、私は自分の視点をモデレートしてきました。

私の考えでは、彼らは当初project.json形式を出荷したいと考えていましたが、csproj / Xamarinを使用してモデルを正規化するには、フレームワークをさらに長くプッシュする必要があります。 より迅速な利益は、csprojにマージして戻すことでした。 csproj内に純粋な「データのみ」を保持しながら、新しい方法を別のファイルに保持することができます。 それは私にとって、行われたRC2の大規模な作業を説明しています。

ほとんど変更されないプロパティを移動し、クールな新機能を別のファイルに保持する場合はどうなりますか？ 私たちは本当に何も失うことはありません。 はい、私たちはモンスターに戻ります...しかし、私たちはそれほど遠くありません。

私はこれについてインサイダーの知識を持っていません。 これは私の側の純粋な推測です。

とにかく...私たちはもう毎年のリリースサイクルで終わることはありません。 Project.jsonからcsprojpost-RTMに移行する準備ができている場合は、RTM後にも大きな変更がリリースされる可能性があると思います。

MSチーム以外の誰もが気付いていない変更。

@MaximRouiller私は「可能性のある」変更を処理することはできません。

私は発表された変更を処理し、軽量ビルドからすべてにMSBuildとxprojを使用するように移行しています。

はい、私たちはモンスターに戻ります...しかし、私たちはそれほど遠くありません。

ええと、ユースケースの90％で機能しているものを_非推奨_にして、それらのユースケースでは非常に複雑なものに_戻る_場合、質問は1つだけです。

どうして？

msbuildすでにこれを非常にうまく行っているのに、 dotnet buildがMSBuildを呼び出すのはなぜですか。 なぜ単純なビルドを廃止するのですか？ なぜ余分な仕事をするのですか？ 唯一の理由は単純です。私たち全員が、いつまでもすべてにMSBuildを使用しなければならないという決定が下されました。

ユースケースの90％で機能しているもの

[要出典]

ユースケースの90％であると仮定しても、1/10の確率で失敗したものを処理しますか？

過度に複雑なものに戻る

繰り返しになりますが、[要出典]、これまでにわかっていることは、それがXML-csprojであり、ファイルリストが含まれないことだけです。 システムがどのように機能するかについては他に何も知りません。ここにいる全員が単に「ドットネットビルド」と呼んでいて、ビルドがどのように達成されても、それは変わらないので、知る必要があるとは確信していません。

msbuildがすでにこれを非常にうまく行っているのに、なぜdotnetbuildがMSBuildを呼び出すのですか。

MSBuildが「過度に複雑」であるということから、「MSbuildはすでにこれを非常にうまく行っている」ということから、私たちは変わったのでしょうか。 現在、 dotnet buildは、バックグラウンドで発生するすべてのものがあなたから隠されているため、単純なように見えます。 MSbuildに切り替えても、これは変更されません。ただし、懸念がある限り、 dotnet buildです。

プロジェクトシステムとビルドシステムを区別する必要があると言い続ける人にとって、プロジェクトシステムとしてMSBuild XMLファイルを使用することと、ビルドシステムとしてMSBuildを使用することには、実際には違いがあることを受け入れたくありません。すでに分離です。

ユースケースの90％で機能

@shedermanすべてがASP.NETであると想定するのはやめてください…このスレッドでは_意図的に無知_として外れます。 すべてが運命にあると仮定するのではなく、新しいプロジェクトシステムに関する詳細情報が実際に得られるまで、今は落ち着いてください。

@shederman何かの上にシムを作る理由は、それを交換したいときです。 実装を変更できるように抽象化します。 私たちは毎日それをします。 これはリファクタリングと呼ばれます。

交換されることを願っています。 XML以外にも、正しく覚えていれば、他のものに比べて遅いと思います。

dotnet buildのような場合、問題は、アンダースコアのビルドプロセスを変更するのがどれほど難しいかということです。 msbuildを別のものに置き換えることは可能ですか？ どのくらいのダクトテープが必要になりますか？

ダクトテープの1つまたは2つのかせにそのような変更を加えることができれば、それは許容範囲内です。

@neoKushan MSBuildは「非常に複雑」であるということから、「MSbuildはすでにこれを非常にうまく行っている」ということから変わったのでしょうか。

いいえ。 コマンドmsbuildはMSBuildを非常にうまく実行すると言っていたと思います。 私はツールとしてのMSBuildについて何の判断もしていませんでした。 それは明確ではありませんでしたか？

@neoKushanユースケースの90％であると仮定しても、1/10の

失敗したことについては誰も何も言っていませ

@neoKushan MSbuildに切り替えても、これは変更されません

ええと、それはビルドプロセスを変更しません。 ただし、ビルドプロセスが機能するために必要なもの（つまり、csprojファイル）と、それが実行される速度は変更されます。

@neoKushanプロジェクトシステムとして

申し訳ありませんが、1つのツールで2つのことを実行する方法がわかりません。

@pokeすべてがASP.NETであると想定するのはやめてください

私は違います。 提案されたソリューションは、単純なビルドではうまく機能しないと言っています。 そのうちのいくつかはASP.NETビルドです。 個人的には、単純なコンソールアプリにMSBuildのような強力なものが必要な理由もわかりません。

@pokeあなたはこのスレッドで故意に無知なように外れます。

そうだといいのですが。 私が故意に知らないのは、MSBuildのユーザーにもたらされる素晴らしいメリットだからです。

@pokeすべてが運命にあると仮定するのではなく、新しいプロジェクトシステムに関する詳細情報が実際に得られるまで、今は落ち着いてください。

おい、私は落ち着いている私はあなたに約束します。

私は、私が反対する見方に異議を唱えないようにしているだけではありません。 私はそれが動揺の兆候ではないことをあなたに約束します。 善のために、私は私を無知と呼んでいる小さなtwerp_person_に興奮することさえありませんでした😉

この同じ小さなtwerp_person_が私に落ち着くように呼びかけているとき、これは皮肉なことです。

本当に面白い。

@MaximRouiller @shederman何かの上にシムを構築する理由は、それを交換したいときです。 実装を変更できるように抽象化します

はいああ、それは私がMSBuildのを交換する意図はありません聞いたから除き、それを行うための十分な理由でしょう。 これは、予見可能な将来に選択されたビルドシステムです。 プロジェクトがMSBuild固有のアイテムなしで立つことを許可し、 dotnet buildが既存のライトビルドを実行するか、またはconfigなどの何かに基づいてビルドツールを選択する場合は、それを希望します。 MSBuildを使用する場合は、必ずmsbuildファイルを作成してmsbuild 。

いいえ。 コマンドmsbuildはMSBuildを非常にうまく実行すると言っていたと思います。

これをコンテキストに入れるには：

dotnetbuildがMSBuildを呼び出すのはなぜですか

dotnet buildよりもはるかに多くありません「だけ」、コンパイラを呼び出すDOTNETビルドの現在のCLIの実装を見てみましょう。 1つのプロジェクトの構築は、 dotnet buildプロセスの一部にすぎません。 最終的に、そのプロセスの_part_はmsbuildを呼び出すことですが、それはあなたの仕事ではなく、CLIの仕事です。

私はツールとしてのMSBuildについて何の判断もしていませんでした。

このスレッドで行ったのは、MSBuildをツールとして判断することだけです。 あなたがそのようなことをしていないと主張することは、率直に言って、ばかげています。

それは明確ではありませんでしたか？

あなたが言うことのほとんどは明確ではないか、少なくともよく考えられています。

失敗したことについては誰も何も言っていません。 一部のツールは、他のツールよりも目的に適しています。

そのため、一部のツールは目的に適合しません。

MSBuildのパワーと複雑さは、ビルドの約10％の目的に適していると言えます。

Visual Studio .netの開発者全員が意見を異にする必要があるため、これは興味深いことです。 あなたは事実上、MSBuildはユーザーの90％にとって良くないと言っています（あなたがあなたの尻から数字を引き出しているという事実を無視して）、それは-再び-ばかげています。

ええと、それはビルドプロセスを変更しません。

プロセスが変更されていない場合、唯一の議論は、プロジェクトの構造が気に入らないということです。つまり、MSbuildであるという事実や、内部にあるものはまったく関係ありません。

ただし、ビルドプロセスが機能するために必要なもの（つまり、csprojファイル）は変更されます。

人々が見る限り、それは文字通り実際に変化している唯一のものです。

そしてそれが実行される速度。

[要出典]

現在存在しないので、新しいプロセスがどのように速くまたは遅くなるかを教えてください。

申し訳ありませんが、1つのツールで2つのことを実行する方法がわかりません。

1つのツールが2つのことを実行していないため、MSBuildがビルドシステムである可能性がありますが、変更はプロジェクトシステムに関係しています。 必要に応じて、別のビルドシステムを使用することを妨げるものは何もありません。それは簡単なことではありません。

私は違います。 提案されたソリューションは、単純なビルドではうまく機能しないと言っています

dotnet new
dotnet restore
dotnet build

提案されたソリューションが「シンプルビルド」シナリオについてどのように変化するかを教えてください

そのうちのいくつかはASP.NETビルドです。

yo asp-net web
dotnet restore
dotnet build

個人的には、単純なコンソールアプリにMSBuildのような強力なものが必要な理由もわかりません。

あなたはしません。 必要なのはdotnet buildです。 あなたはまだ持っているでしょう。 そこでは何も変わりません。

落ち着いて約束します。

少しtwerp

：-1：

@neoKushan引用された抜粋への回答と、ディスカッション全体についてのコメントとの間の概念を理解していただければ幸いです。 私はあなたがそれをすることが_可能_であると仮定しているので、唯一の結論はそれが意図的であるということです。 もしそうなら、それが知的に不誠実な戦術であることをあなたに知らせるだけです。 私はあなたがそれを知っていることを望みます、しかし私はここで疑いの利益を与えています。

また、必ずチルピルを服用する必要があると思います。 私たちは、フレームワークに最適であると個人が信じていることについて話し合っているだけであり、お互いに_戦う_ことはしていません。 人ではなく、議論を攻撃します。 ええと、それは私が今かなりの数日間_しようとしている_ことです（最近の1つのケースを除いて、以下を参照してください）。

Visual Studio .netの開発者全員が意見を異にする必要があるため、これは興味深いことです。

おかしい、私は何か違うことを言う証拠を集めました。 どこで手に入れたの？

1つのツールが2つのことを実行していないため、MSBuildがビルドシステムである可能性がありますが、変更はプロジェクトシステムに関係しています。 必要に応じて、別のビルドシステムを使用することを妨げるものは何もありません。それは簡単なことではありません。

うん。 だから私たちは同意します。 それは些細だった場合、私は本当にそれのように、本当に思います。

それは本当にそんな不合理な要求ですか？ 本当に？

あなたはしません。 必要なのはdotnetビルドだけです。 あなたはまだ持っているでしょう。 そこでは何も変わりません。

そして、 dotnet buildは正確に何をしますか？ msbuildシェルアウトしますか？ MSBuildを使用したいのに、なぜmsbuildだけを使用できないのですか？ そのような状況でのdotnet buildの目的は正確には何ですか？ それはツールに何を追加しますか？

小さなtwerp👎

面白くしようとしますが、おそらくあなたは正しいでしょう。

@pokeご遠慮なくお詫び申し上げます。

引用された抜粋への回答と議論全体についてのコメントとの間の概念を理解していただければ幸いです。 私はあなたがそれをすることができると仮定しているので、唯一の結論はそれが意図的であるということです。 もしそうなら、それが知的に不誠実な戦術であることをあなたに知らせるだけです。 私はあなたがそれを知っていることを望みます、しかし私はここで疑いの利益を与えています。

文字通り、あなたが何を指しているのかわかりません。

また、必ずチルピルを服用する必要があると思います。

..。

人ではなく、議論を攻撃します。

：InsertRolleyEyeEmoticonHere：

おかしい、私は何か違うことを言う証拠を集めました。 どこで手に入れたの？

かっこいいですが、10％/ 90％の数字はどこから来たのですか？

うん。 だから私たちは同意します。 些細なことなら本当に、本当に好きです。

それらがmsbuildに変更することとは何の関係もありませんが、現在のビルドシステムをdotnet buildから変更するのにすでに問題があります。

そして、dotnetビルドは正確に何をしますか？ msbuildにシェルアウトしますか？

dnxやroslynの代わりにmsbuildを呼び出すdotnet buildとは何が違うのですか？

MSBuildを使用したいのに、msbuildだけを使用できないのはなぜですか？

だから、今のMSBuildを使用したいですか？ 何もあなたを止めていません、それは最近のnugetパッケージです。 怒る。 あなたがmsbuildをどれほど嫌っているのかを考えると、あなたが尋ねていることすら驚いています。

そのような状況でのdotnetビルドの目的は正確には何ですか？ それはツールに何を追加しますか？

dotnet buildのメリットについて実際に話し合っていますか？ dotnet buildが気に入らない？ dotnet buildの目的がわかりませんか？ それはありそうもないようです。 あなたが尋ねようとしているのは何ですか？

@neoKushanは彼に敵対するのをやめてください。 これは建設的ではありません。

かっこいいですが、10％/ 90％の数字はどこから来たのですか？

それは私の個人的な経験から来ました。 私のチームと私が過去数年間に作成したビルドの約90％は、RC1 dotnet buildよりも複雑なものを必要としないことがわかりました。

それらがmsbuildに変更することとは何の関係もありませんが、現在のビルドシステムをdotnetビルドから変更するのにすでに問題があります。

明確にしてください、ここであなたが何を意味するのかわかりません。

では、今すぐMSBuildを使用しますか？ 何もあなたを止めていません、それは最近のnugetパッケージです。 怒る。 あなたがmsbuildをどれほど嫌っているのかを考えると、あなたが尋ねていることすら驚いています。

_はぁ_。 私の質問は、 msbuildがすでにうまく機能しているのに、なぜdotnet buildをMSBuildにシェルアウトする必要があるのか​​ということです。 なぜ2つのコマンドが1つのことをするのですか？

私はこれまでにこれを約3回尋ねましたが、毎回あなたはそれを誤解したり誤解したりしました。

2つの異なるコマンドラインコマンドのアクションについて質問しています
なぜ両方が同じことをするのかと私は尋ねています
私は、彼らが両方とも同じことをするのなら、なぜ1つのコマンドを持っていないのかと尋ねています
両方が同じことをする場合、2番目のコマンドが状況に何を追加するかを尋ねています
他の場所で行った可能性はありますが、そのコンテキストでの基盤となるツールの品質については判断を下していません。
他の場所での上記の判断は、質問される質問に影響を与えません。質問される質問は、コマンドラインコマンドとそのアクションに関するものであり、基盤となるツールにはまったく影響しないためです。
私は、ツールが過去に行った可能性がある、または行っていない可能性があると述べた他のことについて話し合うのではなく、単に将来的に行うことを意図しているだけです。

一文の質問を説明する長い解説で申し訳ありませんが、それは明らかに必要です。

InfoQの記事：
「Microsoftは、project.jsonの実験が失敗し、.csprojファイルの使用に戻るという結論に達しました。」 ：残念だった：

私が言ったように、知覚は重要です。

私の質問は、msbuildがすでにそれを本当にうまく行っているのに、なぜdotnetビルドシェルをMSBuildにアウトする必要があるのか​​ということです。 なぜ2つのコマンドが1つのことをするのですか？

彼らはただ一つのことをしないので？

cscがすでにものを構築するという素晴らしい仕事をしているのに、なぜMSBuildはcscにシェルアウトする必要があるのですか？ なぜ2つのコマンドが1つのことをするのですか？

dotnet testがxUnitテストランナーに対して、それ自体でテストを実行する際にすでに正常に機能しているのに、なぜシェルアウトする必要があるのでしょうか。 なぜ2つのコマンドが1つのことをするのですか？

NuGetが既にパッケージをインストールするというすばらしい仕事をしているのに、なぜdotnet restoreをNuGetにシェルアウトする必要があるのですか。 なぜ2つのコマンドが1つのことをするのですか？

あなたはアイデアを得る...（私は：wink :)を願っています

@sandorfr

@neoKushanは彼に敵対するのをやめてください。 これは建設的ではありません。

私は故意に誰かに敵対しているのではなく、 @ shedermanの議論をポイント

人ではなく、議論を攻撃します。

現時点では、 @ shedermanの引数が何であるかは完全にはdotnet buildが悪い状態になっているようです。

続けましょう。

それは私の個人的な経験から来ました。

これはあなたの「証拠」ですか？ 覚えておいてください、あなたは太字で書いています：

おかしい、私は何か違うことを言う証拠を集めました。 どこで手に入れたの？

そして今、それは「個人的な経験」です。 それが私たちが_逸話的_証拠と呼んでいるものです。

私のチームと私が過去数年間に作成したビルドの約90％は、RC1dotnetビルドよりも複雑なものを必要としないことがわかりました。

そして、この点で、RC2 dotnet buildまたはRTM dotnet buildまたはポストRTM dotnet buildは何が変わると思いますか？

明確にしてください、ここであなたが何を意味するのかわかりません。

あなたの議論は、「マイクロソフトがプログラムした以外のことをするためにdotnet buildを取得するのは簡単ではない」という線に沿ったもののようです（そして私が間違っている場合は私を訂正してください）。 私たち全員がDNXを気に入っていたので、DNXの時代には問題ありませんでしたが、MicrosoftはMSBuildを内部で使用したいと考えており、MSBuildは好きではありません。MSbuildを別のものに変更するオプションが必要です。私のポイントは、これは何も新しいことではありません。DNXで問題が発生した場合は、それを変更することもできません。したがって、 dotnet build 「問題」が何であれ、新しいものではないため、関連性はないと思います。ここでの_actual_ディスカッションに移動します。これは、 project.json移動する構造です。 csproj

はぁ。 私の質問は、msbuildがすでにそれを本当にうまく行っているのに、なぜdotnetビルドシェルをMSBuildにアウトする必要があるのか​​ということです。 なぜ2つのコマンドが1つのことをするのですか？

@khellangはすでにこれに答えているので、特に繰り返したくはありませんが、それはまた、違いが何であるかをすでに非常に簡潔に述べているためです（私は自分自身を引用するのは嫌いですが、実際にこれを読んだとは思いません）：

dotnet buildよりもはるかに多くありません「だけ」、コンパイラを呼び出すDOTNETビルドの現在のCLIの実装を見てみましょう。 1つのプロジェクトの構築は、 dotnet buildプロセスの一部にすぎません。 最終的に、そのプロセスの_part_はmsbuildを呼び出すことですが、それはあなたの仕事ではなく、CLIの仕事です。

したがって、少なくとも3回目は、 dotnet buildを呼び出すことは、 msbuildを呼び出すことと同義ではあり

実際に重要なのは、project.jsonの構造と、それを.csprojにマージする方法です。 常にdotnet buildがあるだけなので、単純なものが必要な場合は、基盤となるビルドシステムはほとんど関係ありません。

では、msbuildが行うこととdotnetビルドが現在行うことをどのように区別できますか？ それらの動作の違いは何ですか？ 私はそれがこの議論に欠けていると思います。 おそらく誰もがすでに知っているでしょうが、多分それをテーブルに置くことはある程度の明確さを生み出すかもしれないと思います。

@khellang私はあなたがそれを表現した方法が好きです、しかしそれから続けて、私はdotnet testが何をするかを構成することができます。 Project.jsonにxunitとは異なるテストランナーを配置すると、 dotnet testがそのテストランナーを呼び出します。

しかし、それでも、今後の変更について聞いたところによると、 dotnet buildは同様の機能はありません。 ビルドを実行するために常にMSBuildを使用します。 その理解は正しくありませんか？

@neoKushan私は意図的に誰かに敵対しているのではなく、 @ shedermanの議論をポイント

少なくとも、私たちはあなたが何をしているのかを_考えている_ことがわかりました。 あなたが_実際に_していることは、不実表示、立場の混乱、故意に物事を誤解していること、そして一般的には少し厄介なことです。 あなたの口調は戦闘的であり、あなたは故意に鈍感です。 あまりにも多くのことを、一度に1つの考えに分解しようとしなければなりませんでした。 これは、陽気に、あなたは位置を変えると誤解しました。

@neoKushan現時点では、 @ shedermanの引数が何であるかは完全には

XMLが悪いです。 MSBuildが悪いです。 dotnet buildがMSBuildのみを使用している場合、それも悪いことです。 どうぞ、ついていきましょう。 それほど複雑ではありません。 もしあなたがそれほど故意に鈍感でなかったら、あなたはそれを何年も前に把握していて、実際に建設的なインプットを加えることができたでしょう。

@neoKushanこれはあなたの「証拠」ですか？ 覚えておいてください、あなたは太字で書いています：

それは私の個人的な経験であり、証拠ではありません。 私の証拠は、.NETCoreをMSBuildに戻すのは悪い考えだと信じていた383人のうち281人の回答者です。 そして、MSBuildが根本的に壊れていると信じていた回答者の85人。 それが私の証拠です。 あなたは正確にどこにいますか？

「..._すべてのシングル_Visual Studio .net開発者は同意しない必要がある」というステートメントをバックアップするには、ご存知ですか？ 【強調追加】

@neoKushan実際に重要なのは、project.jsonの構造と、それを.csprojにマージする方法です。

私は実際にあなたに_同意します_。 しかし、背景は非常に重要です。 MSが表明した計画は、MSBuildがビルドユニバースの中心になるというものです。 私はそれが好きではありませんが、先に進みましょう。 それを考えると、簡単な質問があります：

「ウィルMSBuildのは、永遠に、.NET Frameworkの主なビルドシステムのこと？」

その場合、必要なのはmsbuildコマンドだけで、 dotnet buildコマンドは必要ありません。これは、まったく不要です。

ただし、ある時点でMSBuildが_One True Build System_ではない可能性があることを認めた場合、私たちはより興味深い領域にいます。 次に、 dotnet buildを持つことは理にかなっています。 しかし、それはマージcsprojとproject.jsonを議論するときに我々は念頭に置いて、将来を保つこと、その後非常に重要です。

私が（おそらく不十分に）指摘しようとしてきたことは、（私の考えでは）より良いオプションは、_projectdefinition_ファイルと_builddefinition_ファイルを明確に分離することです。 これにより、複数のビルドエンジンをサポートできるdotnet build設定が改善されます。 代わりに、すべてをcsprojに移動すると、MSBuildの世界に閉じ込められます。

そして、はい、私はこの「唯一の真のビルド」状況がDNXに存在したことを理解しています。 しかし、私はそれを尋問しませんでした。なぜなら、私は私たちが持っていたビルドが「好き」だったからです。 ああ、私たちが不当を快く受け入れるときに私たちが置かれる状況は、私たちが_好き_😉です。

したがって、構成に応じて、 dotnet buildがいくつかのビルドツールのいずれかを使用できる状況を考えてみてください。 dotnet testがいくつかのテストランナーの1つを使用できるのと同じように。 さて、今あなたがcsprojとproject.jsonをマージする方法を、そのような架空の世界与えられましたか？ それが私がしたい議論です。

@rhires非常に高いレベルからdotnet build ：

1. プロジェクトファイルを収集します
2. インクリメンタルビルドの前提条件が満たされているかどうかを判断します
3. project.jsonを読み取ります
4. ターゲットフレームワークを決定します
5. プロジェクトごとに：
   
   
   
   1. ビルドは依存関係です
   
   
   2. インクリメンタルの場合、再構築が必要かどうかを確認します
   
   
   3. 出力ディレクトリを決定します
   
   
   4. ソースファイルを収集します
   
   
   5. コンパイルオプションを決定します
   
   
   6. プリコンパイルスクリプトを実行します
   
   
   7. ソースファイルとオプションを使用してコンパイラを実行します
   
   
   8. コンパイル後のスクリプトを実行します
   
   
   9. レポート出力
   
   

@shedermanありがとうございます！ この時点から、msbuildはこのプロセスで何を追加/減算/置換しますか？

少なくとも、私たちはあなたが何をしていると思うかを知っています。 あなたが実際にやっていることは、不実表示、立場の混乱、故意に物事を誤解していること、そして一般的には少し厄介なことです。 あなたの口調は戦闘的であり、あなたは故意に鈍感です。 あまりにも多くのことを、一度に1つの考えに分解しようとしなければなりませんでした。 これは、陽気に、あなたは位置を変えると誤解しました。

ポット->ケトル

あなたは何度も自分の立場を変えたので、自分自身に追いつくことさえできませんでした。あなたはビルドチェーンの文字通りすべての側面について議論しました。あなたがそうするように一緒に_考えます_、それでも私はあなたの議論がどこに落ち着くのかをあえて指摘するので、私はお尻です。 私が上で上げたポイントの半分に応答するのをまだ待っていますが、あなたがすることは、ビルドプロセスの他の側面を選択することだけです。

XMLが悪いです。 MSBuildが悪いです。 dotnetビルドがMSBuildのみを使用する場合、それも悪いことです。

_あなた_以外の誰もこのようなことを主張していdotnet buildはMSBuildを呼び出すだけではない、と繰り返し言ってきましたが、 dotnet buildとmsbuildは完全に同義ではないと言いましたお互いに、そしてそのdotnet buildは、コンパイラを呼び出す多くのことを行います。 私はあなたをfrigginソースコードにリンクしました、そして他の人が来て同じことを言いました、それでもあなたはこれが何らかの形で何が起こっているのかを主張していますか？

どうぞ、ついていきましょう。

_あなた_はどうですか？ dotnet buildはmsbuildのみを呼び出すというこの考えをどこで得たかを教えてください。 誰があなたにそれを言ったの？ どこで読んだの？

私の証拠は、.NETCoreをMSBuildに戻すのは悪い考えだと信じていた383人のうち281人の回答者です。 そして、MSBuildが根本的に壊れていると信じていた回答者の85人。 それが私の証拠です。 あなたは正確にどこにいますか？

そして、あなたはそれらの数字から10％を引き出しましたね？ これがあなたの主張であることを忘れないでください：

MSBuildのパワーと複雑さは、ビルドの約10％の目的に適していると言えます。

後であなたは言った：

おかしい、私は何か違うことを言う証拠を集めました。

では、この証拠はどこにありますか？ あなたがその数字をあなたの「証拠」からどのように引き出したか知りたいです。

「...そこにいるすべてのVisualStudio .net開発者は同意しない必要がある」というあなたの声明を裏付けるために、あなたは知っていますか？

簡単： https ：

Visual StudioはMSBuildをホストして、管理対象プロジェクトをロードおよびビルドします。

Visual Studioを使用してプロジェクトをビルドする場合は、MSBuildを使用します。 今日.netコアを使用している場合でも、RC1VSを使用している場合でも内部でMSbuildを使用していました。 MSbuildは気に入らないかもしれませんが、私が言ったように、ほとんどすべてのVS開発者は、MSbuildを認識しているかどうかに関係なく使用しています。

MSが表明した計画は、MSBuildがビルドユニバースの中心になるというものです。

私はこれに同意しません。 彼らはそれが中心になるとは決して言いませんでした、彼らが言ったのはproject.jsonのいくつかの部分が.csprojに戻ることになるということだけです-これを超えて、彼らはこれがどの程度dotnet build変えるかについて一言も言いません

「MSBuildは.NETFrameworkのメインビルドシステムになるのでしょうか？」

もしそうなら、msbuildコマンドだけが必要であり、dotnetビルドコマンドは必要ありません。それはまったく不要です。

これまで何度も述べられてきたように、 dotnet buildとmsbuildは完全に別のものです。 dotnet buildだけコンパイラツールチェインを呼び出すだけではありません。 dotnetビルドの目的は、ビルドプロセスを人々にとってシンプルに保つことです。 また会おう：

dotnet new
dotnet restore
dotnet build

msbuildがdotnetCLIのコアコンポーネントになったとしても、dotnetビルドがかなり複雑なシステムである（そして常にそうなる）もののクリーンでシンプルなラッパーであるという事実は変わりません。 地獄、dotnet CLIが存在する理由の半分（そしてその前のDNX）は、MSBuildが最終的に存在するコマンドライン引数の地獄から逃れるためです。 あなたの議論は、「パッケージをcurlできるのに、なぜnpm installコマンドが必要なのですか？」と少し似ています。 もちろん、本当に必要な場合はすべて手動で行うことができますが、それからはほとんど何も得られません。 では、 dotnet build内部でmsbuildを使用するとどうなるでしょうか。 あなたはほぼ確実にそれを見ることはないでしょう、あるいはそれについて知る必要があるでしょう。

以前の経験をMSBuildと比較することはできません。まったく異なります。 VSを開いてプロジェクトを作成し、ビルドするのに慣れているので、私たち全員が（一見）その人に火傷を負っていますが、同じプロジェクトをビルドサーバーでビルドしようとすると、突然、たわごとについて不平を言います。それは_うまくいくはずです_。 おそらく、MicrosoftがTFS 2015で行った最高のことの1つは、「正常に機能している」状態に戻ったため、_MSBuild_ではなく_VisualStudio_に関連付けられたビルド定義を作成することでした。 これがまさにこのビルドツールチェーンです- dotnet buildは、ビルドシステム全体を置き換えることを意図したものではなく、内部でMSBuild使用している場合でも、プロジェクトのビルドにのみ関係します。 TeamCityやJenkinsのようなものを使用したい場合は、 dotnet buildだけで電話をかけることができ、残りはdotnetが行います。 _どのように_それはあなたにとって何の心配もありません。

唯一のこと-そして私はこれを完全に意味します、あなたのために実際に変わる唯一のことはproject.json / csprojファイルです。 それでおしまい_。 だからこそ、 dotnet build実際に何をするのか、そしてMSBuildが良いことと悪いことについて議論することは、絶対に無意味です。

@neoKushan停止します...

@neoKushan停止します...

私の一部は、ASP.NETチームがショーを楽しんでいたためにスタンドアップを意図的にキャンセルし、回答を提供することですべてが終了することを想像するのが好きです。 ：笑顔：

私の（今はしっかりと）不可知論者の立場から、双方はしばらくの間、相手の主張に故意に鈍感であるように見えました。 あなたは、.NETCoreコミュニティの私の精神的なイメージを非建設的でより悪いものとして設定することに成功しています。 知覚について話す...

NuGet以外のもののほとんどはcsprojにマージされます。 project.json（nuget.json？）がない場合、NuGetのものはどうなりますか？

NuGetは.netコミュニティで十分に確立されているため、ユーザーが依存関係を好きなように管理する方法を提供し、デフォルトでdotnet nuget提供する可能性があります。

ただし、すべてのdotnetコアを依存関係を管理する唯一の方法にハード結合しないでください（ dotnet restoreはdotnet nuget restoreと等しくないはずです）。多くの人にとって、nugetは単なるパッケージリポジトリであり、依存関係マネージャー、人々は「依存関係マネージャー」のユースケースにより生産的/適切であると思うかもしれない他の選択肢を持っています。

依存関係管理のためにIntelliSenseを維持しますか？ これは基本的に、project.jsonで使用できる最高のデモ機能の1つです。

ロジックを再利用できます。これは大したことではありません。たとえば、nuget.orgにアクセスしてパッケージを検索し、URLからIDをコピーすると効率的です。

シェル補完も提供することをお勧めします。これにより、 bashまたはzshを使用している人々から多くの称賛を得ることができます。

dotnet nuget add S[tab]は、 S始まるプロジェクト識別子の完了リストを提供します

msbuild * projファイルにインテリセンスを含めることは、そこで<NuGet>タグを焼き付けたい場合にも実行できるはずですが、同じように、エコシステム全体にnugetをハード結合しないでください。つまり<Package>NuGetPackageId</Package>すべきではありません。 <NuGet>NuGetPackageId</NuGet>相当するか、これをオーバーライドするための非常に単純な（そして非常によく文書化されサポートされている）方法が必要です。

Paket Visual Studioプラグインにはnugetのオートコンプリートがありますが、動作しますが、nuget.orgからの応答を返すのに時間がかかると思うので、とにかく遅いです。

依存関係管理のためにJSON形式を維持していますか？ XMLはそのようなものにとって恐ろしいものです（Mavenを参照）。 JSONは、これらの依存関係を表すために簡単に受け継がれます。

フォーマットのアイデアを探しているなら、 paket.dependenciesを見ることができます。そうでなければ、それほど重要ではないと思います。 project.json編集は、 packages.config編集とほぼ同じくらい良かったです。

ちなみに、それでもlockファイルが必要な場合は、ユーザーが読み取り可能にし、リポジトリでチェックされ、差分を簡単に作成できるようにできますか？

@rhiresこの時点から、msbuildはこのプロセスで何を追加/減算/置換しますか？

まあ、それは彼らがそれをどのように統合するかに依存します。 彼らが「ハードロック」を行い、msbuildをdotnetビルドに深く統合する場合、公開情報は彼らの好ましいアプローチであることを示しているように見えますが、全体がmsbuildに置き換えられます。

ただし、 dotnet build構成可能にすると、次のように機能すると思います。

1. プロジェクトファイルを収集します
2. project.jsonを読み取ります
3. ターゲットフレームワークを決定します
4. 使用するビルドツールを決定する
5. ビルドツールにシェルアウト
6. レポート出力

@neoKushanだからこそ、

👍

私が_discuss_したいのは、 dotnet buildが_多くの可能なビルドツール_の1つとしてMSBuildにシェルアウトできる世界でproject.jsonとcsprojがどのように見えるかです。 それは大丈夫ですか？ それを前提として、project.jsonとcsprojに何が含まれるかについて話してもらえますか？

なぜなら、私たちが話し合うことができれば、このスレッドは実際に建設的になる可能性があると私は信じているからです。

@jmmあなたは建設的でより悪いものとして設定することに成功しています

申し訳ありません。 ただし、時間があれば、他の巨大なオープンソースプロジェクトのチャットアーカイブをいくつか読んでみることをお勧めします。

議論は、実際には、人生と同じように、健全なコミュニティのしるしです。 誰もが盲目的にリーダーのセットをフォローするとき、まあ、物事は通常それほど良くありません。 決定、証拠、および意思決定は、尋問に対して開かれている必要があります。

@shederman生産的な議論を続けるために、提案された変更の影響について議論するために線を引きたいと思います。

ここでの中心的な議論は、「新しい」.csprojのレイアウトと形式、およびproject.json（具体的には「プロジェクト」構造全体）に何が起こるかについてである必要があると思います。 ビルドシステムは、msbuildであるかどうか、dotnetビルドがどのように機能するかなど、_this_問題の範囲内ではないと思います。 それは、それに関する議論が歓迎されない、または無効であるということではなく、単にこの_特定の_問題に属していないということではなく、別々の問題である必要があります。 経験豊富な開発者なら誰でも証明できるように、バグレポートに複数の個別のバグが含まれていると非常にイライラします。通常、最初に行うことは、それらを複数の問題に分割して追跡することです。これが本当にここに欠けていることだと思います。

私自身の_個人的な_観点からは、ビルドシステムが何であるか、またはそれがどのように機能するかは気にしません。 私は、そうする人に無知または否定的に聞こえるという意味ではありません。つまり、開発者の観点からは、プロジェクトの構造が正しい限り、「dotnetbuild」がアセンブリを吐き出すことを知りたいだけです。私が懸念しているように、 dotnet build ->プロジェクト->->アセンブリ。 私にとって本当に重要なのは、この議論の範囲がどうあるべきか（そして私たちはここで最終的に合意したと思います）、そのプロジェクトがどのように見えるか、そしてそれが私の日常のワークフローにとって何を意味するかです。

.csファイルを追加したという理由だけでマージ地獄を扱いたくないし、_私が気にしない_システムがそれに依存しているという理由だけで1000行の長さのXMLファイルを扱いたくない-私は '私たちの誰もがそうだと思います、そしてそれは何年もの間VS開発のバグベアでした。 今日のproject.json形式は、以前よりも_はるかに優れていた_ため、希望がちらりと見えました。そのため、私は完全に理解し、気性がすぐにほつれた理由を理解しました。 「古き良き時代」ですが、同時に、自分自身をからかうべきではないことを述べる価値があります-project.jsonは、今日は決して_完璧_ではありませんが、独自の問題があり、 「古い」csprojの問題については、客観的で、どこを改善できるのか、何を改善できるのかを議論する価値があります。

確かに_両方の世界の最良の_可能性があります。

ここでの中心的な議論は、「新しい」.csprojのレイアウトと形式、およびproject.json（具体的には「プロジェクト」構造全体）に何が起こるかについてである必要があると思います。

ご存知のとおり、このスレッドでは何度か言及されていますが、今朝、私自身の「個人的なアハ」を共有するために、もう一度言及したいと思いましたが、 Roslynベースのプロジェクトシステムでは他の取り組みが進行中Readmeからより正確に言うと、 Central Project System（CPS）です。 そのドキュメントを閲覧すると、プロセスというよりもプロジェクト定義の作業のように見えます。 たぶん、これは.jsonと.csprojの間のすべての魔法が統合されている場所ですか？ そして、MSBuildはプロセスエンドポイントとして降格されますか？ それはいいことではないでしょう。 ：笑顔：

とにかく、私はそのリポジトリを開始/監視して、そこで起こっていることに関する最新情報を入手し始めました。 ：+1：

（私はまた、この議論をそこで新しい問題に移すべきかどうか疑問に思っています。）

@neoKushan確かに、msbuildが関係しているという事実自体は問題ではありません。 そして、msbuildの力を利用しながら、人間が読み取れる/編集可能な単純なファイル形式を維持できるようにする道があると思います。

私が心配しているのは、「msbuildはバトルテスト済み」のような議論です。通常のmsbuildはそうですが、現在のxplatはそうではないようです。 関連するgithubリポジトリの問題を見ると、まだ完全にはありません。 さらに、msbuildチームは、新しい/改善されたシリアル化形式のサポートは、msbuildのターゲットではなく、新しいビルドシステムのターゲットになるとすでに述べています（これはすぐには発生しません）。

また、私たちが行っているのは依存関係の削除を追加するだけだと人々が思っているときも心配です。 たぶん、彼らは「helloworlds」アプリをやっているだけだからです。 しかし、buildOptionsやmonikerによるオーバーライドなどの他のオプションは、非常に強力で便利です。 言うまでもなく、現在のjsonスキーマベースのエディターエクスペリエンスは素晴らしいものです。

1つのパスは、代わりにproject.jsonをロードするmsbuildタスクを持つことです。 次に、開発者がプロ​​ジェクト設定で、そのタスクをcsprojに追加するproject.jsonを有効にするかどうかを選択できるようにします。

@ Mike-EEEはい、希望があります:)

現在の傾向は、project.jsonをnuget.jsonにすることであると確信しています。これにより、依存関係の問題が解決され、既存のproject.json機能のほとんどがそのまま残ります。

私が理解できない唯一のことは、これがマルチターゲティングにどのように影響するかということです。csprojとnuget.jsonは、それぞれが何をターゲティングしているのかを認識して理解する必要がありますか？ 最終的にすべてのターゲットに対してcsprojが作成されますか（うん！）、それを説明するのに十分なほど.csprojを拡張できますか？

project.jsonはnuget.jsonになります

ここで興味があります..._ this_会話はどこで起こっていますか？ 私は以前、特定の形式でロックインするためにnugetチームに参加しました。 project.jsonに関して、彼らはそれがVisual Studioツールの懸念であり、対処できないことであると述べました。 今では、ダイナミクスが変化し、同じ種類の問題をコピー/貼り付けしたようです。 ：stuck_out_tongue：

私の懸念を明確にするために、現在、JSONとXMLを混合しているため、少なくとも非効率が生じています。

ここで興味があります...この会話はどこで起こっていますか？

さて、それはもともとここに述べられていました： https ：

project.jsonファイルが残っている可能性があり、NuGetのすべてのパッケージ参照が含まれており、名前がnuget.jsonに変更されています。

そして、これが本当にここでの議論の内容だと思います。project.jsonからどれだけ取り出して、.csprojに入れますか？ 私のプロジェクトでは、特に複数のフレームワークをターゲットにしている場合、project.jsonの大部分はパッケージ参照です。 上記は、これらすべてが残り、「他の」ビットのみが取り出されることを示唆しています。 私の（再び：個人的な）経験では、これらの「その他の」ビットはプロジェクトの存続期間を通じて実際にはあまり変化しないため、XMLであっても、多くのXMLではなく、かなり静的である必要があります... 。

異なる構成でXMLとJSONを混合して一致させるのは少し臭いことに同意しますが、JSONがどのように使用されているかについてはあまり好きではないため、JSONには多少偏っています。 しかし、それは間違いなく個人的な好みです。

さて、それはもともとここに述べられていました...

ああそうだ...もちろん！ わかった。 念のため。 うまくいけば、明日は私たちが最終的にこれについていくらかの明確さを得る日になるでしょう（良くも悪くも！）。

異なる構成でXMLとJSONを混合して一致させるのは、少し臭いことに同意します

これを見て、このように感じているのは私だけではありません。 :) .JSONがプロジェクトに忍び寄るのを見て悲しみと最初に戦ったとき、しばらくの間そこは孤独に見えました。 web-appdevのバックグラウンドからは完全に理にかなっていますが、ネイティブのappdevは似ていません。また、XMLに関してはその逆です。

ははは...そういえば、上記を書くことで私は古いアーカイブを引き出すことができました。 これが2014年の私です（そう、あなたはそれを推測しました！）JSONの代わりにXamlハハハああ私がどれほど若くて完全に素朴だったか見てください！ とてもキュートで気取らない！ 少年、私は学ぶべき世界を持っていましたか？ ：stuck_out_tongue：しかし、私はいくつかの進歩があったと言います。 結局のところ、Webサーバーの構成に使用されていた.iniを削除しました。 ：笑顔：

@neoKushan両方の可能性の中で間違いなく最高のものがあります。

👯👯👯

@neoKushan現在の傾向はproject.jsonを

開始点としてproject.jsonスキーマを使用すると、私の観点からは、次の項目はおそらくビルド定義ファイルに含まれていないはずです。

• ソースファイルのリスト
• プロジェクトの依存関係
• ターゲットフレームワーク
• プロジェクトコマンド（例：Web、テストなど）
• ウェブルート
• メタデータ
• 言語バージョン

次のことは、ビルド定義ファイルにあるべきではありませんが、もしそうなら、私はそれについて_meh_するでしょう：

• 構成の定義
• スクリプト、前後

ビルド定義ファイルには、おそらく次のものが含まれている必要があります。

• コンパイルオプション（言語バージョンを除く）

上記は単に議論を引き起こすためのものです。 個々のポイントについて喜んで議論します。 今のところ、ファイルの名前と形式は無視することをお勧めします。

@shederman 「ビルド定義」の意味を明確にする必要がありますか？ おそらく私の用語は間違っていますが、現在のproject.jsonを_builddefinition_ファイルではなく_projectdefinition_ファイルと呼びます（新しいcsprojファイルについても同じことが言えます）。 セマンティクスの可能性もありますが、私にとってビルド定義は、_どのようにビルドされるか_を定義することを示唆していますが、プロジェクト定義は、プロジェクトを構成するものを定義し、ビルドステップを別のものに任せます。

_これは私のプロジェクトです。これらのアイテムで構成され、これらの依存関係があります。 それをどのように構築するかは私の仕事ではありません。_

プロジェクトの多くは、アセンブリ名が最上位のフォルダーからどのように取得されるかなど、慣例に従って決定できます。 この考え方に沿って進むと、_nuget.json_はnugetと関係があります。したがって、パッケージ/依存関係がそこに入り、私たちは皆それに満足していると思います。

私が完全に決めることができないのは、ターゲットフレームワークです。 Nuget.jsonが依存関係の解決のみに関係している場合、さまざまなフレームワークをターゲットにするときに参照がある程度分離される可能性がありますが、実際にターゲットにするフレームワークを決定するのはそれであるかどうかは完全にはわかりません。 Definition_（最終的には何でも）。

繰り返しになりますが、nugetにはパッケージ参照だけでなく、ライブラリがnugetパッケージになったときのパッケージ_definition_とバージョンも含まれています。 nuget.jsonが少なくとも2つの異なることを行っているように見えますが、それは少し臭いがし始めています。 おそらく（ここで唾を吐くだけですが）、csprojはパッケージ、ターゲットフレームワークなどの詳細を定義し、各ターゲットフレームワークは基本的にnugetパッケージである.jsonファイルを指すことができます。 つまり、1つのnuget.jsonの代わりに、フレームワークごとに個別の.jsonファイルがあります。 それはひどい考えかもしれません、私は特にそれを考え抜いたことはありません。

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ ：

2つの選択肢がありました。 1つは、すべての.NETプロジェクトをproject.jsonを使用するように移動することでした。 これには、Visual Studio、Xamarin、およびUnityなどのパートナーのすべてのプロジェクトタイプに対応するツール作業を行う必要があります。 これらの各プロジェクトタイプに必要なすべてのビルドシナリオをサポートし、移行ストーリーを提供するには、project.jsonを拡張する必要があります。 もう1つの選択肢は、.xprojプロジェクトが.csprojプロジェクトを参照でき、.csprojプロジェクトがVisualStudioおよびXamarinStudioの.xprojプロジェクトを参照できるようにブリッジを構築することでした。 ブリッジにも課題があります。たとえば、顧客がプロジェクトを作成するときに、.xprojまたは.csprojを選択する必要があります。これにより、選択肢が増え、複雑さが増します。

と

私たちの選択を検討した後、すべての.NETプロジェクトが同じツールとビルドシステムを使用するように、.NETCoreプロジェクトを.csproj / MSBuildに移動する方が簡単であることが明らかになりました。

不足している機能をサポートするために.csprojを拡張する予定です。

• プロジェクトシステムにファイルのリストがありません
• プロジェクトファイルに対して操作を行うためのCLIツール。ほとんどのシナリオでは、ファイルを編集しません。
• プロジェクトから直接パッケージをビルドする
• マルチターゲティング

また、すべての.NETが同じツールを使用しているため、MSBuildの拡張を検討できます。 XMLの代わりにJSONをサポートし、ツールが過度に冗長なファイルなどを生成しないようにすることで、顧客やコミュニティからのフィードバックを求めます。 また、すべてが同じツールを使用しているため、これらの拡張機能はすべての.NETプロジェクトで機能する可能性があります。

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485：

.csprojがまだC＃プロジェクトを意味すると仮定すると、もちろん、C＃以外のプロジェクトには他のターゲットもありますよね？ [ベン]

はい。 【スコットH】

.netがmsbuildとしてcomplex-legacy-justForToolingビルドシステムで立ち往生するのではないかと少し心配しています。dotNetCoreを稼働させるためにそれから始めて、新しい最新のビルドシステムを計画する必要がありますか？
.netcoreを急いで出荷することなく、すべての人に希望を与え、物事を行うこと。

私は頻繁にmsbuildファイルを編集する必要はありませんが、それが非常に難しい場合、宣言型のアプローチではフローに没頭します。私の例をhttps：// githubのような単純な問題を解決できる人はいないようです。
6か月後、誰もタスクを実行できなかった場合（2つの異なるタスクがそれぞれお互いを知らない）、汚いハッキングなしで、または追加的な方法で次々にタスクを実行できなかった場合、おそらくそこに修正するものがあります。

ありがとう

プロジェクトファイルに対して操作を行うためのCLIツール。ほとんどのシナリオでは、ファイルを編集しません。

：-1：

私はすべてあなたの仕事を支援するCLIツールを求めていますが、参照とパッケージを管理するためにCLIツールを使用する必要がある場合、私は腹を立てるでしょう。 Install-packageは素晴らしいですが、パッケージ名の半分を入力するだけで、すべてのバージョンとともに可能性のリストをポップアップ表示できるのは素晴らしいことでした。

cliツールは自動化には最適ですが、 npm installやdotnet restoreなどの基本的なツールを除いて、タスクを実行するには不十分な方法です。 dotnet buildoptions define add --framework net451 SOME_DEFINEようなことを学ばなければならないのなら、それは間違いなく大変なことです。 これは大きな損失です。

良い開発ストーリーは次のとおりです。

• 簡単に編集可能なプロジェクトとビルドファイル
• 構成可能なビルドシステム
• シンプルで適切に設計された完全なCLIツール
• Great Gui、IDEツール

それらの1つを（以前は実際には素晴らしかった）他の1つを受け入れられるようにすることは、ばかげています。

団結とxamarinの議論は実際にはかなり悪いです。 彼らがすぐに.netコアに移行することはないと思います。また、.netの将来に向けて設計する場合、利便性のために後戻りするのは不十分です。

また、すべての.NETが同じツールを使用しているため、MSBuildの拡張を検討できます。

強制される前にMSBuildを拡張することはできません...

この記事は実際には私たちが待っているブログ投稿ではなく、.netコアがそこで誤った方向に進んでいることを確認しています。

cliツールは自動化には最適ですが、npminstallやdotnetrestoreなどの基本的なツールを除いてタスクを実行するには不十分な方法です。

繰り返しますが、この問題は文化/好み/哲学の衝突だと思います。 途中のどこかで、CLIをGUIに置き換えることをお勧めします。実際に両方が必要な場合は、開発者が（もう一度）アプローチを好むことがわかります。 常に問題であるように思われるため、この分野では確かにいくつかの革新が必要です。CLIは作成されますが、GUIは作成されません。その逆も同様です。

私には、APIを作成するためにある種のフレームワークが必要であり、CLIとGUIのバージョンが自動的に作成されるように思えます。

私たちはそれを呼ぶことができます... CLIGUIAPI！ ：+1 ：： + 1 ：： + 1：#problemsolved

この問題は文化/好み/哲学の衝突です

間違いなく、これは、可能な限り最善のアプローチで各アプローチに取り組むことを除いて、解決できないものです。 node.jsと私はこのスタックの最大のファンではありませんが、これで素晴らしいCLIツールnpmとpackage.jsonを使用して素晴らしい仕事をしました。 Guiの部分は、さまざまなベンダー（Webストーム、vsコード、ビジュアルスタジオ）によって対処されています。 gulpのようなファンシービルドシステムは100％オプションです。

私はこれについては少数派かもしれませんが、そうではないかもしれませんが、project.jsonは好きですが、理由はここで説明されていますhttps://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json /私には

しばらく前に読むのをやめましたが、 project.jsonについての決定的な答えが得られたら、すぐにこの問題を閉じます。

project.jsonと.csprojの両方を保持するのはどうですか。.csprojはコマンドdotnet restoreによって生成され、デフォルトではバージョン管理で同期されません。 違いは、 dotnet restore 「project.lock.json」を生成する（および他のことを行う）代わりに、「。csproj」ファイルを生成（または更新）することです。 「project.lock.json」と「.csproj」の両方が自動生成されているため、どちらもそのままにしておくことができます。 フラグは、.csprojを生成するためにdotnet restoreで使用できます。 発表の中で、Microsoftはすでに「プロジェクトファイルに対して操作を行うためのCLIツールです。ほとんどのシナリオではファイルを編集しません」と述べています。 私見ですが、 dotnet restoreは、project.jsonを入力として受け取るCLIツールに最適です。 利点は次のようになります-

• project.jsonと.csprojの両方の形式は変更されません。 つまり、新しく生成された.csprojは、以前のバージョンのVisualStudioやその他のツールと互換性があります。 dotnet restoreは、プロジェクトファイルの明示的な「インクルード」リストを.csprojファイルに挿入できます。
• .csprojは自動生成されており、バージョン管理されていないため、開発者は.csprojを手動で編集およびマージする必要はありません。

ええ...いいえ。

閉鎖。 言えることはすべて言われています。

それがどのように作られるべきかを考え出し、それについて話し合うデザインチームに参加したいのなら...して

そうでなければ、それは無駄なスペースであり、特に...それは受信箱を埋めています。

@MaximRouillerは、ノイズが多いにもかかわらず、最初の質問に答えることに焦点を当てたコメントを集めてくれることを願っています。

昨日投稿：

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan 「ビルド定義」の意味を明確にする必要がありますか？ おそらく私の用語は間違っていますが、現在のproject.jsonをビルド定義ファイルではなく、プロジェクト定義ファイルと呼びます（新しいcsprojファイルについても同じことが言えます）。 おそらくセマンティクスですが、私にとってビルド定義は、物事がどのように構築されるかを定義することを示唆していますが、プロジェクト定義は、プロジェクトを構成するものを定義し、ビルドステップを他のものに任せます。

私の考えのほとんどのスポット。 プロジェクト定義は、プロジェクトが何であるかを純粋に宣言的に説明するものになります。 メタデータ、バージョン、ファイル仕様など。ビルド定義は、プロジェクトを実行可能コードに変換するために実行されるステップです。 ビルド定義には、それを表現するためにかなり豊富なものがほぼ確実に必要です。私のお気に入りはコードです。

しかし、それはすべて議論の余地があるようです。 @ MaximRouillerとMSはすべてを閉鎖しました。 お電話いただきありがとうございます。フィードバックは無視され、killfileされました。

全体として、csproj-> project.json-> csproj全体は、.NET採用IMHOでMSに出没する一連の悪い決定でした。 より環境に優しい牧草地のために.NETを放棄する開発者の傾向は衰えることなく続くでしょう。

とても悲しい。

@shederman C＃のTiobeインデックスの低下と、csprojに戻すという決定との間に相関関係はありません。 また、Tiobeインデックスの低下は、C＃エコシステムの健全性の低下を示すものではありません。 市場に参入する言語が増えると、1つの言語で大きな市場シェアを維持することが困難になります。

全体としての影響については明確ではありませんが、ここでは関心の分離の評価が必要であることを指摘しておきます。 私がファイルを追加しているという理由だけでcsprojが意味する場合、私のチームメイトはビルドプロセスに関連する他の影響を懸念しており、ボートを逃しています。

csprojは私が許容するものであり、好まないものです。

@jerometerry私はこれ自体が衰退を引き起こすとは言っていませんでした。 しかし、.NET Coreの革新的な変更の多くは、AWSの衰退と損失を阻止することを目的としていました。 これらの変更は徐々に1つずつ削除されているため、.NETCoreが開発者をプラットフォームに誘導する可能性はますます低くなっています。

さらに、project.jsonを導入するという決定から今日までさかのぼることができる、不十分な意思決定は、良い前兆ではありません。

MSが過去に焦点を合わせると決心した場合、将来負けても驚かないでください。 あなたを問題に巻き込んだ思考があなたを問題から解放する可能性は低いです。

市場に参入する言語が増えると、1つの言語で大きな市場シェアを維持することが困難になります。

本当ですが、私の経験では、.NETで必要以上のダメージはフレンドリーファイアによって引き起こされます。

ところで...昨日はスタンドアップもありましたか？ live.asp.netにサインインしましたが、カウントダウンがリセットされ、ビデオ/フィードなどがありません...

@ Mike-EEE彼らはあなたが来ると聞いた：stuck_out_tongue_winking_eye：

彼らがこれをしたことにイライラする。 私はそれについてブログを書きました： http ：

今日のスタンドアップから： https ： = 38m45s

彼は具体的にここでproject.jsonに取り組んでいます： https ：//youtu.be/YJsQ3tnS7Ew

project.json形式は（あなたがドラッグ＆ドロップデータセット-猿であることの.NET DEVのその段階でもない限り）編集にはるかに簡単ですが、私にとって最大の問題は、誰もに自分たちのライブラリを更新するために悩まれていないです。ネットコア。 これまでのところ、Restsharpの1つのブランチを機能させることができましたが、これはproject.json形式を使用しています。 JSON.NET、Structuremap、NUnitなどはすべて、開発者が希望を捨てたように見える古いDNXブランチを持っています。

したがって、プロジェクト形式のdotnetコマンドラインツールが削除されているときに、.NET Core RC1 / 2をリリース候補と呼ぶのは少し奇妙です。 それは実験的なものなので、私にとってはまだベータ版またはアルファ版のソフトウェアです。

vNextに移行する主な動機は、安価なLinuxホスティングとDockerを利用することです。 ほとんどの人は、.NET Coreバージョンがないnuget参照を介してライブラリによって完全に障害を負っているので、プロジェクト移行ツールはできるだけ早く賢明です。

@yetanotherchris dnxはrc1の概念でしたが、rc2ではdotnet cliに変更されたため、現時点ではほとんどのdnxプロジェクトまたはブランチが古くなっています。

project.jsonはまだここにあり、rc2に必要です。これについては、RTM後に今後なくなる予定です。

json.net別名newtonsoft.jsonは機能し、フレームワーク自体によって使用されます。プロジェクトでも使用しています。
nunitは互換性がなく、誰もがxunitafaikを使用します
構造マップには、rc2互換ライブラリがあります

まだrc2に移植されていないサードパーティのものはまだたくさんありますが、Microsoftは他のプロジェクトのタイミングや、互換性のあるライブラリを作成する時期を管理していません。

@yetanotherchris project.jsonでインポートを使用する場合は、古い非ネット標準のモニカを指定でき、それらを使用します。

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

おそらくこの理由で、まだ多くの人がライブラリを更新するのに苦労していません。実際のRTMの前に別の移動するターゲットをヒットする必要はありません。

@joeaudetteコマンドラインツールdotnetではなく、ブランチ名（DNX）について話していました。 多くの人がNUnitを使用していますが、これはMsTest以外の事実上のテストスイートです。 私はDNXとNewtonsoft枝と呼ばれるのStructureMapの非公式版があります、必ずからJSON.NETかのStructureMapパッケージを見つけている場所ではないよ、ここで.NET標準は現在冗長であり、nuget.org上の.NET標準の1.0ベータ版は、（私の知る限りでは）。

@neoKushanありがとう、調べてみます。

私の主なポイントは、最終バージョンで完全に変更されるため、リリース候補と呼ぶのは少しばかげていることだと思います。 たぶん1か月以内に、ビルドシステムが新旧と完全に異なるわけではないので、活発な活動が行われるでしょう。ただし、主にWeb開発者である私は、 project.json方がはるかに好きです。

@yetanotherchris

（私が知る限り、.net標準は冗長になっています）。

どうしてそんなことを言うの？ Netstandardはプロジェクトの変更によってなくなることはなく、ここにとどまります。 将来のcsprojファイルでnetstandardsをターゲットにできるようになります。 Netstandardは絶対に不可欠です。 彼らがproject.jsonを捨てる主な理由の1つは、.netエコシステム全体を統合することであり、それがnetstandardもテーブルにもたらしているものです。

私の主なポイントは、最終バージョンで完全に変更されるため、リリース候補と呼ぶのは少しばかげていることだと思います。

私はこれにある程度同意しますが、人々が思っているほど変化しているとは思いません。 まず、project.jsonはまだRTMのためにここにあり、その後すべての変更が行われます。 次に、変更されるのになぜ「最終」と呼ぶのかと疑問に思うかもしれませんが、最終的にはすべてのコードとライブラリ、および変更されないものはすべて、プロジェクト_definition_にすぎません。 これは、最初に考えたほど大きな変化ではありませんが、移行を楽しむことは間違いなくあります。

@yetanotherchris rc2はプレビューであるため、サードパーティのプレビューパッケージも探す必要があることを覚えて
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

NUnitが後でサポートされるかどうかはわかりませんが、今のところ.NETCoreおよびASP.NETCoreプロジェクトではxunitを使用しています。
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris rc1にはbeta9というラベルを付ける必要があり、rc2は最初の実際のrc品質リリースであることに同意できると思います。
project.jsonなどは、フレームワーク自体の一部ではないツールです。ツールはプレビューのままであり、フレームワークがRTMの場合でもしばらくの間変更される可能性があります

持ち帰っても驚かないでしょう。おそらくproject.jsonを保持していて、限られたシナリオでしか機能しません。 それが人々が望むものであるならば、私たちはその考えを楽しませます。

スコットハンター、 dotnetConf 20161日目基調講演12分24秒

ハンター氏がGitHubに参加しているかどうか誰か知っていますか？ そして、製品フォーラムでおしゃべりを監視していますか？ その音から、彼はここでのフィードバックを見逃しています。

.NETとVisualStudioのプログラムマネージャーとして、 思えませ

彼が与えられたフィードバックに気づいていないなら、私はかなり恐ろしいでしょう。 すべての詳細ではないかもしれませんが、確かに大きな反発がありました。

皆さんのチャンスは次のとおりです。
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

いわばチップジャーにドルを入れました。 ：stuck_out_tongue：

tugberkugurluは、「突然、暗黒物質の企業開発者が密室でフィードバックを提供し始めた」というコメントで何かに取り組んでいた可能性があります。 別の言い方をすれば、「私たちの企業顧客は、互換性と、私たちの製品への現在の投資について、いくつかの正当な懸念を提起した」ということです。 「コミュニティ」は、すべてにおいて、発言権の大部分を占めていないことに不満を感じていますが、企業の顧客はかなり大きな棒を持っています。プラットフォーム、ツール、およびサポートへのアクセスに多額のお金を払っています。 彼らの懸念は無視されることはなく、無視されるべきでもありません。 結局、MSが狙っているように見えるのは、最大数の開発者が自分たちが構築したいものを簡単に構築できるようにすることです。また、ほぼすべての定義可能なドメインで相互運用性と共有を可能にしようとしています。 彼らは、csprojの操作をはるかに簡単にし、はるかに機能的にすることを約束しています。 だから、今、彼らはそれを実現するためにバットにかかっています。

何度も言ってきたように、私は大手銀行のエンタープライズ開発者であり、企業顧客です。 これらの変更については相談を受けませんでした。 では、誰がまさに「暗黒物質の企業開発者」だったのでしょうか。 その情報は明らかに極秘です。 007レベルのもの。

企業の顧客が大きな棒を持っていることを主張することはすべてうまくいっていますが、そうすることができるのは明らかに彼らの一部だけです。 どれ？ どのような基準に基づいていますか？ どうすればその特権リストに入ることができますか？ それはどのパートナーレベルですか？ 年間の支出はいくらですか？ 質問者は、実際に私たちの意見を聞く前に、MSに支払う必要がある正確な金額を知りたいですか？

@shedermanは、エンタープライズモバイル開発者ですか？ またはEnterpriseUnity Dev？

上記のどれでもない。 資産管理と銀行統合のためのコアシステムを作成します。 いくつかのオンラインのものも。

@shedermanそれがあなたが尋ねられなかった理由かもしれないと私は思う？

どうか明らかにしてください？

MSが現在サポートしている企業開発者は、市場の1％でモバイル作業を行っている開発者、UWPアプリ、気にかけているユーザーの5％、ゲーム開発だけだとそれ以外のすべてに背を向けていますか？

うーん。 いいえ。

変更は_それらの_グループと話し合った後に起こったと言っているので、あなたは尋ねられなかったのです。 Microsoftは、asp開発者だけでなく、すべての開発者をサポートする

はい。したがって、すべての開発者をサポートする場合は、すべての開発者と話し合う必要があります。 たぶん、選択したサブセットと話すだけでは、エンタープライズ開発者の5％は、エンタープライズ開発者全体の意見を測る良い方法ではありません。

では、大手銀行の意見を聞くには、すべての開発をUWP / Unity / Mobileに切り替える必要がありますか？

それはばかげています。

多分彼らはすべての開発者と話をするべきです。

それは彼らが過去2年以上やってきたことではありませんか？

@shedermanそれで、_あなたが個人的に_尋ねられなかったという理由だけで、あなたはあなたの開発範囲をカバーする他の誰も関与しなかったことを意味していますか？

また、それらの数字を作るのをやめましょう–それはばかげています。

@poke誰が関わったのか聞いていますか？ 私は企業の暗黒物質開発者に相談されたと聞いて、私は銀行にいると指摘しましたが、私たちはそうではありませんでした。

実際、数字はかなり寛大だと思いましたが、大丈夫です。

@shedermanあなたはこのすべてを調べすぎていると思います。 過去2年間は、asp.net側に焦点が当てられていましたが、.netコアの言葉が広まり始めると、多くの人が「これをどのように使用できますか？」と尋ね始めました。 それは裏部屋の取り決めではなく、文字通り何年も求めている人々でした。 多くの人が.netCoreからもっと欲しがっているのを見るだけです。

また、既存のものをクロスプラットに移植する方法を知りたがっている大企業からの実際のエンタープライズサポートリクエストの問題もあります。Microsoftの誰かにそのことを言わせる必要がなかったので、おそらく「尋ねられた」わけではありませんでした。あなたがやろうとしていることは、プロジェクトの範囲を超えています。

それを見る別の方法-そして私が個人的にそれを見る方法-はあなたが尋ねられたということです、あなたは数ヶ月前に発表がなされた2番目に尋ねられました。 マイクロソフトは、誰にも相談せずに決定が下されたと言う人々のすべての叫びに対して、彼らはまだ詳細を検討している、彼らはまだ最終的な部分をまとめていない、そして今があなたの意見を表明する時だと繰り返し述べています。 スコットハンターは、人々が_本当に_project.jsonをオプションとして欲しがっているなら、それを維持することを検討するとさえ言った。 信じられないなら、dotnetconf基調講演を見に行ってください。

@neoKushanスコットがそれを維持することを検討すると言って少し後退したことを感謝しますが、これが彼らが望むものであることを人々が表現するための単一の集中化されたポイントが本当に必要です。どこでも議論。 それはまた、それが持ち上がったときに、誰もが同じように返信できることを意味します。

project.jsonは良いステップでした。 しかし、それは私の意見では素朴でした。 人々がハイブリッドプロジェクトをC ++またはF＃で記述したいと思うことは認識されていません。 dnxやアセンブリの単位としてnugetを使用するなど、初期の設計上の決定の一部は、ドットネットエコシステム全体では実現可能ではありませんでした。 あなたが見ているのは、ドットネットに調和をもたらす過程で、彼らはこれらの難しい選択をしなければならないということです。

私の意見では、フォークと再発明はドットネットエコシステムを助けません。それはそれを傷つけるだけです。 NodeとGo（特にGo）は、均質で一貫性のあるプラットフォーム/ツールを備えているため、初心者にとって非常に魅力的です。

XML対JSONの議論全体がばかげていると思います。これは、今後5年間で、JSON対YAMLになり、その後YAML対Groovy（たとえばgradle）になるためです。 XMLは、皆さんが考えているほど悪ではありません。 MSBuildは非常に成熟しており、すべての人に利益をもたらす多くの投資があります。

それは仕事のA LOTは必ずcsprojファイルを使用して編集の苦痛が少ない方法で同じまたは非常に少なくともいずれかを取得することができます作るためのMSBuildで行われる必要がある、と述べました。 次に、nugetの依存関係をnuget.jsonファイルに移動します。 設定より規約を利用して、「ハッピーパス」にいる場合、csprojがほとんど空になるようにします。これは、今日のweb.configと少し似ています。 次に、csprojを微調整するCLIオプションがあります

私にとっては、project.jsonが恋しいですが、あなたが思う理由ではありません。C＃プロジェクトは問題ありません。 私はmsbuildを編集するよりも、コンパイル順序としてproject.jsonを編集する方が好きだったので、それを見逃します。 繰り返しますが、xmlが悪であるためではなく、fsprojファイルにmsbuildによってもたらされる多くの肥大化があるためです。

この決定に関する私の問題は、主にcsprojファイルがxml / jsonに関するものではなく、csprojファイルに含めることを選択した方法に関するものでした。 プロジェクト定義、IDE設定、ビルドステップ、参照が含まれていました...

そのことにならないことはあまりありません。 これはそれをひどくし、msbuildが時々かなり難解であることに対処しなければならないときにのみ複雑になります。 .NET Coreを優れたものにすることに正直に興味があり、単に機能するだけではない場合は、プロジェクトファイルをツールの構築に依存しないようにしてください。 私のプロジェクトが何であるか、そしてそれがどのように構築するかとは別に、それが何に依存するかを指定することができるはずです。 言うまでもなく、これにより、最初のオプションが現在msbuildによってサポートされている場合でも、ツールを選択できるようになります。

私はこれに賛同する。 結局のところ、csprojの重要な問題は
それはすべてを行います。

PatriotBobが提案している中間点が好きです...

13:28で火、2016年6月21日にPatriotBob [email protected]書きました：

この決定に関する私の問題は、主にcsprojファイルが少ない方法でした
xml / jsonについて、そしてcsprojに含めることを選択したものについての詳細
ファイル。 プロジェクト定義が含まれ、IDE設定が含まれ、
ビルドステップが含まれ、参照が含まれています...

そのことにならないことはあまりありません。 これはそれを作りました
ひどいし、msbuildが存在することに対処しなければならないときにのみ複雑になります
時々かなり難解です。 .NETCoreを優れたものにすることに正直に興味がある場合
単に作業するだけでなく、プロジェクトファイルをビルドツールに依存しないようにします。 そうするべきです
私のプロジェクトが何であるか、そしてそれが何に依存しているかを個別に指定することができます
それを構築する方法。 言うまでもなく、これは私たちに選択を可能にし始めます
最初のオプションが現在msbuildによってサポートされている場合でも、ツール。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911、またはミュート
スレッド
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
。

XML全体が悪く、JSONは素晴らしいフープラであり、誇大宣伝されていました。 私はパトリオットボボが言っていることが好きです。

npmのpackage.jsonから完全にas / wプロジェクトを管理することは、プロジェクトの宣言、プロジェクトの構築、プロジェクトのアップグレード（例：グリーンキーパー）、データの読み取り/書き込み/解析をこれほど単純かつ簡潔に行ったことはありません。私のプロジェクトについて、そして私のプロジェクトをとても簡単に公開します。 _とても簡単。 私たちの多くと同じように、私の歴史はc ++ / java / python / nodeにあり、他の人にも遊んでいます。 私は今、私のすべてのプロジェクトでnpm経験を望んでいます。

project.jsonは、これらの同じ特性を生み出すことを約束しました。 シンプルさとパワーを犠牲にするのではなく、エミュレートする価値のあるモデルだと思います。

チーム.netコアチームが、他のソリューションがこれらの特性、優れた機能、およびパワーを提供できると考えている場合は、 ただし、進歩するにつれて、シンプルさの美しさを損なうことのないようにしてください。

また、私は巨大なスレッドのこの時点でただのノイズであることを理解しています。 おそらく、モデレーターはそれを閉じて、より制御された方法で試練を処理することを検討する必要があります。 たくさんの良いフィードバック。 多分少しトローリングも：$ :)