在站立会议中，Damian 提到可能与 Nuget 相关的内容将转移到将替换当前 packages.config 的内容中。 显然，这些决定是一条公平的道路，我怀疑您此时会得到任何具体的答案。

而且我不同意“JSON 可以更简单地表示这些依赖项”。 有利有弊。 看到这个https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

我同意 _if_ 正在转移到 nuget.json 的变化。 这是 project.Json 的唯一部分，我认为无论如何都需要开发人员编辑。

就冗长而言， @darrelmiller Yaml 可能是更好的选择。 你用逗号分隔的字符串而不是数组作弊;)。

@sandorfr是的。 然而，我怀疑回到基于 XML 的项目系统的原因之一是因为 .net 生态系统中现有的基于 XML 的项目系统的重要工具。 我的评论不是试图确定最佳格式，只是指出 XML 本质上并不坏。

是的，这是本周最糟糕的消息。 这就像被带回了过去...... :( 实际上 Xml 还不错，但是 msbuild ......并且 msbuild xml 基础项目不会像你描述的那样圆滑。

然而，我怀疑回到基于 XML 的项目系统的原因之一是因为 .net 生态系统中现有的基于 XML 的项目系统的重要工具。

我只是不明白为什么所有的东西都以“核心”为后缀来表明它是一个全新的东西，如果它的意图也是像 msbuild 一样向前推进包袱的话。

两年多来，这个过程太痛苦了，但很多人都没有问题，因为所有新增和改进都使生态系统与其他生态系统保持一致，而且所有这些变化都是有充分理由的。 然而，突然间，暗物质企业开发人员开始闭门提供反馈，我们看到有很多包袱需要推进。

没有多少生态系统具有基于 XML 的配置。 事实上，所有新设计的生态系统都在采用其他格式（YAML、JSON 等）。 看看社交媒体上所有人的反应，我没有看到很多人喜欢这种变化。 然而，私下提供的反馈对团队来说似乎更重要。 这不是一件坏事，我理解其中的原因，但它只是展示了在这个生态系统中处理决策的方式。

+1 本周最坏消息。 关于这个的讨论在哪里？ 我找不到任何东西，只是一个单方面的决定。

我没有看到任何社区支持这个决定，而且很多人反对（最后一次统计为 85% 到 15%）。 讨论如何进行，谁做出了决定，基于什么信息？

这是我们在 .NET Core 中做事的方式吗？ 因为我们想要支持未公开的遗留技术列表而在闭门造车时妥协质量？

无论如何，让我们做一个 VS 扩展，从 project.json 创建一个 .csproj，使用那些旧技术的人可以使用。

但是不要让我们回到基于 XML 的项目文件的噩梦中。 当它们被引入时，它们是一个坏主意，十多年来，我们一直在为糟糕的合并和难以阅读的问题付出代价。 够了。

我认为你太悲观了——我想这主要是因为我们都对此感到惊讶。 让他们分享有关他们计划的更多信息，然后我们会看到。 @DamianEdwards明确表示他们希望保留 project.json 模型的优秀部分。

在我看来，这将是：

• 不必指定每个 cs 文件
• 无需卸载项目即可修改文件
• 能够直接在文件中修改 nuget 依赖项（使用 IntelliSense）
• 能够通过 global.json 用本地源替换 nuget 包

在编译方面，我只是认为应该可以在没有安装Visual Studio的情况下编译它。 对我来说，实际命令是“dotnet build”还是“msbuild”并不重要。 重要的是应该有一种方法来编译整个解决方案，顺便说一下，“dotnet cli”中尚不存在（至少据我所知）。

如果这可以实现，我可以接受他们使用的任何语法。 XML 不是很好，但 JSON 显然也有它的缺点。

编辑：我认为这不会改变 .NET Core 等的任何基本（和伟大的）想法。

恕我直言，主要问题是在 RTM 之前这些类型的剧烈变化并不好。 如果这种情况发生在测试阶段，那么开发人员/团队可能不会那么惊讶。 想想人们自过去两年以来所做的project.json 系统考虑当前的产品/库/框架。 Asp.Net 处于 RC 而非预览/alpha/beta，这些类型的更改破坏了开发人员/团队的信任:(。

恕我直言，主要问题是在 RTM 之前这些类型的剧烈变化并不好。

一开始我也是这么认为的，但据我所知，这不会导致对您的应用程序代码进行任何更改。 它只会影响您的 project.json/xproj/csproj 文件，并且他们说更改可能是自动的 - 因此这将类似于升级 Visual Studio 时已经多次发生的旧项目迁移步骤。

顺便说一句，我一直认为拥有一个 project.json 和一个 xproj 文件（其中包含 Visual Studio 模板的默认命名空间和一些输出路径，因此有时您也必须对其进行编辑）很奇怪。

顺便说一句，我一直认为拥有一个 project.json 和一个 xproj 文件（其中包含 Visual Studio 模板的默认命名空间和一些输出路径，因此有时您也必须对其进行编辑）很奇怪。

也许这很奇怪，但他们回答不同的事情 project.json 是构建 .net 核心项目所需的唯一文件，而 xproj 与专有工具 aka 视觉工作室有关。 如果您使用 webstorm 处理您的节点项目，它与 package.json 和 .idea 非常相似。 只是关注点分离。 如果他们愿意，Visual Studio 可以将 project.json 隐藏在 Properties 下，如果他们愿意，可以提供合并的策划 gui 体验，而无需将所有内容混合在一起。

我一直在 VS Code 中的 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

现在，当每个人都认为 JSON 可以解决所有问题时，正在构建 .NET Core。 我不相信 JSON 是比 XML 更长期的解决方案，但我知道合并 JSON 冲突比合并 XML 冲突更容易。

我一直在为项目文件处理 XML 垃圾而不用为项目文件处理一些新鲜空气，我发现读取 JSON 文件更容易，我发现 JSON 文件在 Visual Studio 之外更容易使用，而且我不想回到 XML/MSBuild。

是的，这些是我的个人感受，是的，它们是主观的，但根据 Twitter 和其他地方的评论，我不认为它们是孤立的。 老实说，这个决定让我完全怀疑 .NET Core 的整个方向，尤其是做出这样重要决定的方式。

@DamianEdwards明确表示他们希望保留 project.json 模型的优秀部分。

在我看来，project.json 模型最好的部分是它不是 csproj、不是 MSBuild，也不是 XML。 那些“好”的部分会保留吗？ 显然不是。 在我们被吸引到相信他们终于得到了草皮之后，结果证明这一切都是误导。 我们被告知新的构建系统、Gulp 和 project.json 以及现在的情况会如何不同，然后结果证明这一切都是假的，而且它又是糟糕的旧 MSBuild。

我认为 JSON 和 XML 格式在合并方面几乎相同 - 两者都有结束标记（尽管它只是 JSON 中的一个大括号），这意味着您在使用空/一个/多个场景时会遇到问题。 只需将一个空的 JSON 数组更改为一个包含项目的数组。 我认为 JSON 甚至还有结尾逗号的额外缺点，如果您将项目添加到列表中，它会更改两行。

如果您想避免这种情况，您将不得不转向 YAML 等。

IMO csproj 的问题不在于 XML，而在于 Visual Studio 如何处理它以及它包含每个 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也是如此。 如果.csproj文件成为未来，我更愿意看到 Core 团队一路走下去并删除project.json或 nuget.json 或者它最终被称为 _entirely_ 并添加一种更具声明性的方式来添加对.csproj格式的引用。 我可以忍受必须编辑 XML 文件而不是 JSON 文件（尽管我当然更喜欢 JSON），但是失去project.json的声明性质将是一种真正的耻辱，而且我不需要两个我需要指定依赖项的不同地方。

请在https://www.surveymonkey.com/r/H6Q88PP提供反馈

为了清楚起见，在阅读 Standup 说明时，它提到一个选项是使用 nuget install --save 类型的选项（请参阅 https://blogs.msdn.microsoft.com/webdev/2016/05/11/ Notes-from-the-asp-net-community-standup-may-10-2016/)。 虽然我认为这是一个好主意，但我认为用智能感知替换“编辑 .json 文件”是一个坏主意。 我认为对于我们中的一些不想切换到 shell 来做所有事情的人来说，留在编辑器中是一个好主意。 就个人而言，我的偏好是同时拥有这两种体验。 用于添加依赖项的命令行 + UI 还不够好。

我是编码员，我不想离开编辑器。

我认为这是一个可怕的决定。 你们说你想让 .NET Core 真正简单，但是你做出了这个改变。 我不在乎你在 MSBuild 上涂了多少口红，它仍然是 MSBuild，外人会看到它并立即关闭。 它永远不会是一种简单的手动可编辑格式。 也许有一些棘手的技术问题，但听起来这些问题与试图使项目系统不仅仅是一个简单的项目系统有关。 如果人们想在他们的构建中做更复杂的事情，那么他们可以编写一些脚本或使用 msbuild 来做到这一点。 project.json 是一个非常简单的东西，我现在真的很沮丧。

我最喜欢的 MSBUILD 文件名言？

我最近不得不花很多时间处理 csproj 文件。 它们的外观和行为很像 Ant/Maven。 这对他们不利。
Ant/Maven 被很多 Java 开发人员喜爱，随后又被讨厌。 XML 是一种必须处理的极其冗长的语法。
但真正的杀手是锁定之一。 是的，您可以使用 msbuild 来处理它们，但语法实际上不是为开发人员设计的，而是用于读取/编辑它们，而是用于 IDE 将状态序列化到。 仅仅因为有命令行运行程序并不意味着该格式对开发人员友好。 只要您留在 VS，您就不会真正注意到。 一旦你离开，虽然它不再舒服。 csproj 文件是我希望 .Net 采取与 java in 不同的路径的一件事。

来源

我认为区分 MSBuild 和 Visual Studio 当前使用 MSBuild 的方式很重要。 我多年来一直手工编辑 MSBuild 文件，并将它们用于我的所有项目。 例如https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

Visual Studio 创建的 csproj 文件非常糟糕，但将其归咎于 MSBuild 就像说 C# 是垃圾一样，因为您曾看到代码生成器使用它创建了丑陋的代码。

@darrelmiller我同意。

让我们将时间向前移动 6 个月，看看它是“告诉过你”的时刻还是更多的“躲过了一劫”。

跟随@shawnwildermuth在他的博客上的电话，我将投入我自己的 2 美分：

我不明白为什么这是一个大问题。 我很高兴回到基于 XML 的 csproj，因为：

• 手动编辑 JSON 并不比 XML 更自然/更容易。 恕我直言，它实际上是相反的。 每个愚蠢的编辑器都给我 XML 标记补全，手动发现格式错误更容易等等。 如果我必须手动编写它，JSON 并不容易。 这么说让我想到了第 2 点......
• 为什么一开始用编辑器编辑项目文件会如此大惊小怪？ 作为开发人员，编辑项目文件不是我想花时间的地方。 这应该是一个新项目开始时的一次性事情，但在那之后不应该经常发生恕我直言。 如果我必须用 JSON、XML、YAML、TOML 或当时任何人喜欢的任何东西来编辑它，这与我完全无关。
• 我想避免的一件事是将 NuGet 与 ASP.NET 紧密结合。 NuGet 很棒，我喜欢它，我希望我的 ASP.NET 能够很好地使用它，但它不是运行 ASP.NET 所必需的。 是的，我可能需要从 NuGet 提要中提取二进制文件以获取 MVC 等功能，但是无论是通过官方 NuGet 提要执行此操作，还是提取源代码，请在本地编译并将其复制粘贴到文件夹应该是一种灵活性，我仍然可以使用。 我不希望 ASP.NET、csproj 或其他任何东西与那些“支持”的 3rd 方系统紧密耦合。 我希望它们能够实现出色的集成，但要为定制敞开大门！ 因此，我希望 NuGet 包不会在 .csproj 文件中声明，并且 nuget.json 不会紧密集成到 MSBuild 中。
  良好定义的接口背后的紧密集成==很棒。
  紧耦合，假设这是每个人的标准== BAD。
• 最后，我想说 project.json 与 .NET Core 和 ASP.NET Core 关系不大。 Core 提供的功能远不止 project.json 文件。 Project.json 不是一个新功能，它是一种尝试重新设计已经存在的不同格式的东西。 我不太关心这个，因为作为开发人员，我更愿意关注 .NET Core 提供的新功能和可能性，以在云中开发出色的应用程序，而不是我必须偶尔进行的无聊配置。

我认为回到 MSBuild 是一个很好的举措，因为作为开发人员，我更关心兼容性，我认为这是关键。 MSBuild 有效，而且公平地说，它在大多数情况下都运行良好，而不是用新的东西替换它，这会带来新问题并导致兼容性问题，我宁愿有人改进已经有效的东西，并随着时间的推移让它变得更好。 每个人都认为他们可以重写东西并使它变得更好，直到你意识到你只解决了当时对你很重要的一个小问题空间，然后当你想要扩展时，你发现自己重新构建了同样的旧东西你一开始就试图更换。 更好地改进已经有效的东西。

这也是为什么我可能更愿意让 Mono 变得更好并缩小差距而不是实现新的跨平台运行时，但这是一个不同的讨论。

最终调查结果：100 份回复，针对 900 万 .NET 开发人员群体，在 95% 的置信度下为 ±10%。

你喜欢迁移到 project.json 吗？
是的，这是我最期待的功能之一 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 万开发人员吗？

UserVoice 上的 800 票将 project.json 扩展到 VS 的其余部分不是也显示出趋势吗？

如果我们要做一个真正具有代表性的样本，那么也许微软应该这样做。 因为他们一次也在来自多个方向的反复投诉

他们会比我做私人调查有更好的影响力。 我需要升级我的 SurveyMonkey 计划才能访问 100 多个结果，我需要付出一定的代价，所以我可以运行 Microsoft应该自己完成的调查！

好吧，如果您想获得有意义的数字，那么您的目标是公平地代表 900 万开发人员。 如果我有 100 个 Twitter 关注者，他们关注我是因为我们有相同的兴趣，并且我要求每个人都参加调查，那么您就有 100 人持非常片面的观点，只代表一个特定的开发人员群体。

复活 MSBUILD 的站会中给出的理由是使现有工具之间的集成成为可能，并使现有项目更容易使用 .NET 核心。 然而，在将一个相当大的项目迁移到 .NET 核心之后，老实说，项目系统是我面临的最少挑战。 所以用它作为唯一的理由对我来说似乎不是一个很好的理由。 我还使用 csproj 系统工作了多年，包括手动编辑文件。 那总是很痛苦。 基于 project.json 的系统更简单，更容易为所有人（包括新手）所接受。 我认为这是目标。 然而，现在我们通过复活 MSBUILD 向后退了一步。 我个人的看法是，这是一个很大的错误。 我投票支持保留 project.json。

实际上，我几乎没有 Twitter 关注者，这些关注者主要是我在其 Twitter 上发布的 .NET Core 开发者的关注者。

再说一次，进行此类调查的正确人员肯定是 Microsoft 吗？ 为什么让我成为唯一一个真正问人们他们想要什么的人？

为什么 MS 不在乎人们的想法？

TBH 我直到 30 分钟前才知道有一项调查，而且我不知道您正在私下进行调查。 我同意……如果 Microsoft 对开发人员对此更改的反应感兴趣，那么他们应该进行这样的调查。 但也许他们已经做好了功课，这就是他们做出这种改变的原因。 我不知道，但我不会总是这么消极地看待事情，因为毕竟这些人正在为我们构建这些东西，所以我确信他们只为我们谋取最大利益。

如果他们做好功课，他们就会知道 60% 的开发人员反对这一举措，并会相应地进行沟通和参与。 他们没有，这意味着他们不知道反应，这意味着他们没有参与。

我是 VS 企业许可证的付费客户。 我什么也没看到。 我在四家蓝筹金融服务公司工作，也是付费企业客户。 他们什么也没看见。 那么到底是谁？他们从事与？ 我从昨晚开始就一直在问这个问题，但没有收到任何答复。

我对事情的看法是消极的，因为这是对 .NET Core 故事的一个基本部分的大规模、晚期突破性的改变，这个部分被传达给我们作为未来的核心，我们（也许是愚蠢地）把它们当作了他们的词，并建立了基于这项技术的 CD/CI 管道，现在完全没有价值。 我也有消极的看法，因为在询问决策细节的一整天里，无线电中完全没有声音。

听起来，据我所知，他们把用户扔到了巴士底下，以帮助工具制造商。 如果是这样，请他们可以从工具制造商而不是我那里收取我的 VS 许可费。

@shederman虽然我同意你的调查结果，但它的问题显然偏向于保持 json 格式的首选方向，这并不能真正使它成为一个好的调查。 我把它当作乐趣，我不会认真对待它的结果（抱歉）。 我确实想知道为什么我们不能同时拥有 - 以一种或另一种方式使其成为可选，因为我不喜欢 msbuild 或其他东西。 我喜欢 json，它是我的朋友。

我同意你的看法，这不是一个理想的调查。 我在 5 分钟内创建了它。 关键是：我为什么要创造它？

为什么微软对了解人们的想法不感兴趣？

我只期待大约 30 条回复，我希望这足以说服他们重新开始讨论，公开分享他们的想法并与我们正确互动，而不是对意见置之不理。

现在有 138 条回复，但仍然没有微软的迹象，即使考虑到他们的决定可能是一个错误的决定。 只是非常模糊的挥手解释没有事实支持。

我想要的只是适当参与这个决定。 不是基于秘密信息和反馈在闭门造车的情况下做出的重大决定。 这应该公开透明地进行，这个词在这个过程中特别缺失。

哦，伙计们来吧。 微软拥有这个框架，让他做他想做的事。 但是想一想，人们从 2014 年 3 月到 4 月就在为此努力，就在发布前 1 个月，这种戏剧性的变化是荒谬的。 它破坏了开发人员的信任。 浪费人们的时间。 如果您不能信任社区，则无需制作开源框架。 立即去关闭它，这样当你在黑暗的房间里做这些类型的改变时，没有人会打扰你。

我请求微软的道歉者和同情者（MVP 或社区成员）在这个时候现实一点。

@谢尔曼

如果他们做好功课，他们就会知道 60% 的开发人员反对这一举措，

如果 .net 生态系统中超过 20% 的开发人员甚至知道 project.json 的存在，我会感到惊讶。 我们有时会忘记，我们生活在一个开发者泡沫中，处于新技术发展的最前沿。

我相信 project.json 的大部分吸引力在于它的简单性。 但是，如果您自 3 年前在 ASP Net Insiders 日首次推出以来一直关注它的发展，那么它已经开始积累更多的复杂性，因为它试图支持更多的用例。 为了支持整个 .net 生态系统，我担心很多深受喜爱的简单性会丢失。

这并不是说 project.json 没有带来一些很棒的新功能，我相信让项目格式更容易被人接受是一件好事。 但是，我认为将这种优势带到 MSBuild 中更容易实现，并且比试图将 project.json 带到任何地方更快地使更多人受益。

如果 .net 生态系统中超过 20% 的开发人员甚至知道 project.json 的存在，我会感到惊讶。

我敢打赌，.net 生态中只有不到 20% 的开发人员了解 MVC 和 Web Api。 70 多人正在使用 WebForms、WCF、WebService。 我再次请求微软的道歉者和同情者请现实一点

@shederman你对调查结果的任何信心的报告对于整个 .NET 开发人员来说可能是不正确的，它甚至可能不是一个很好的代表性样本......“这些人主要是 .NET Core 开发人员的追随者我在谁的推特上发布了信息。” 您的样本不是随机样本，您绝对需要说明任何此类置信区间，正如您对总体而言暗示的那样。 即使它是 .NET 开发人员的随机样本，您也无法报告每个答案的 95% 置信度，因为您未能针对同步推理进行调整。

根据您对整个人口的调查，无法得出有用的统计结论。 但是，我很高兴您进行了调查。 你提出了许多优秀的观点。 我认为结果确实表明许多人对这种变化感到不安或担忧。 但是，请不要发布错误的统计结论……

那么，如果我们要打扰 70% 以上的市场基础，那么改变任何东西有什么意义呢？ 让我们原地踏步，继续进行渐进式进化。 如果它没有坏就不要修理它，对吧？

我知道 project.json 已经积累了复杂性。 我100%同意这一点。 是合并回 csproj 的解决方案吗？ 我之前告诉过人们，我完全支持微软做正确的事情而不是匆忙发货。 迁移到 csproj 看起来很仓促。

为什么在RC2之后这样做？ 这个是从哪里来的？ 收购 Xamarin 是否与此有关？ 是dotnet-cli集成吗？ 是大客户吗？ 谁知道...

我可以向大众解释 RC1 -> RC2 是最好的。 与 dotnet cli 统一。 但是 project.json 改变了吗？ 我无话可说来解释它。 只是我不知道。 人们很困惑，我没有说服他们的论据。

为什么在RC2之后这样做？ 这个是从哪里来的？ 收购 Xamarin 是否与此有关？ 是 dotnet-cli 集成吗？ 是大客户吗？ 谁知道...

这是思想的重点。 我们不知道迁移到 csproj 背后的完整故事。 现在每个人都在诅咒微软并假设最坏的情况，而不是向后靠，放松，观察和理解为什么会发生这种情况。 这没有任何意义。 这些人正在为我们和我们自己建造这些东西。 他们绝对不会因为一位大客户而做出这样的改变，因为如果您冒着失去整个社区的风险，一位大客户就毫无价值。 Microsoft .NET 生态系统是 HUUUUUUGE，让 .NET Core 很好地融入其中显然是一项复杂的任务，所以我建议每个人都冷静一下，并假设这些人背后有一些聪明人，做出正确的决定，以便我们可以从中受益最大 - 长期。 我离开这里，因为所有这些负面的过早猜测让我感到厌烦。

@darrelmiller抱歉，当我说 60% 时，我指的是 60% 的受访者做出回应。

@GuardRex你说得对。 唯一能让我们得到正确结果的组织是 MS，他们似乎并不关心。

我的调查只是为了衡量一个模糊的支持水平，而不是提供具有统计意义的样本。 我相信我已经表明有足够的不满来公开这个决定，但微软似乎不同意，如果他们的无线电沉默有任何迹象的话。

这里的问题是：MS 究竟需要什么才能承认他们可能犯了错误？ 怎样才能让他们重新开始讨论？ 因为在这个时间点，答案似乎是“我们不在乎你的观点，我们的决定是有效的，我们不会分享原因”

我建议每个人都冷静一下，并假设这些人背后有一些聪明人，做出正确的决定，以便我们可以从中受益最大 - 长期

这就是我所说的将其关闭源代码，因为它背后的聪明人，他们总是正确的，而开源社区是傻瓜。

@shederman “不要提供具有统计意义的样本”......很好，但我希望你让调查站在它自己的优点上并删除这条线......

最终调查结果：100 份回复，针对 900 万 .NET 开发人员群体，在 95% 的置信度下为 ±10%。

这就是真正危险的部分。 60% 的 .NET 开发人员讨厌或不喜欢这种变化可能是准确的； 但是，你不能用那个样本来展示它。 让我们说，是的，很多开发人员都非常关注变化及其处理方式。 这很清楚，调查确实很好地突出了这一点。

@abcplex ：开源并不意味着每次有 16 人在 GitHub 上打开一个问题并尖叫跳跃时你都必须跳。

@MaximRouiller 站会笔记很好地解释了更改的动机。 正如我所读到的，现实是 xproj 正在被 csproj 取代，project.json 很可能会被重命名为 nuget.json，并且 _some_ 东西将从 project.json 中移出。

从站会中的评论来看，这是一个相当近期的决定，社区几乎立即被告知，project.json 在 RTM 之后不会去任何地方，因此更改可能会再次发生。

对我来说，这似乎是可能发生的最具包容性和透明度的过程。

@darrelmiller那，我不得不同意你的看法。 相当透明。

如果他们想要反馈，我认为他们得到了。 在任何情况下，都没有对抗它。 人们说话了。 微软听了。 让我们看看这是不是他们可以做些什么，或者他们的手是否被束缚了。

现在只有时间会告诉我们。

我认为问题不在于它们的透明度。 他们在透明方面做得非常出色。 我认为问题在于他们在不知道社区对此有何看法的情况下做出重大决定。 我知道由委员会设计是不可能的，但也许他们应该记录他们查看的利弊列表，并将其提交给社区，以进行与此更改一样重要的事情。 希望他们能尽快发布此类信息，但即便如此，听起来似乎已经做出了决定。

这对早期采用者的影响比其他任何人都大。

JSON 读起来不错，但前提是它很简单。 在我看来， </system>比]}更容易理解。

这里最合理的评论呼应了我自己关于卸载/加载项目和依赖管理不需要 XML 中固有的冗长性的想法。

它真的应该是关于 JSON 与 XML 的讨论吗？ 恕我直言并不重要
（当然，我个人更喜欢 JSON 而不是 XML，但这并不重要）

我真正喜欢 ASP.NET Core 的是，它非常开放并且独立于 Visual Studio 和任何其他 IDE。 如果仍然如此，我对这个决定没有异议。

在这个问题上有很多有害的讨论，我觉得这让很多人失去了视线。 一般的论点似乎是“MSBuild 很糟糕！” 但对这两种方法的好/坏没有足够的了解。

对于表示这是“倒退”的每个人，请注意，虽然它会回到“csproj”，但它不会与我们多年来拥有的 csproj 文件_相同_。 首先，他们明确表示您不会看到“新”csproj 格式

马上，这是一个直接的区别。 看看今天的 xproj，您就会大致了解“新”csproj 会带来什么。 它会大一点，但这仅仅是因为它将从 project.json 中获取一些额外的属性。 真正的讨论不是也不应该是关于“MSBuild 有多糟糕”，而是你想在新的 csproj 中看到什么，以及你想要在 .json 文件中留下什么。

@dustinmoris你不公平，我认为社区欢迎大多数变化，但这个变化。 这个让我们倒退，他们已经在谈论他们将如何做到这一点，而没有任何关于原因的见解。 他们听起来像是最终决定，因此社区没有地方可以提出更好的提案。

是的，我们确实直接编辑了项目文件，而且在 project.json 之前我们做得很痛苦。 Msbuild 是关于部落知识的，这使得掌握它有点困难。

并且“它将简化从 .net 4.5 到 .net core 的迁移”似乎有点不诚实。 这绝对不是痛点……

它不会与我们多年来拥有的 csproj 文件相同。

会是 XML 吗？ 是的，我是这么想的。

大多数人喜欢 project.json 格式的主要好处和主要原因在于没有这个文件列表。

你是根据什么信息说这话的？ 我的意思是，没有文件列表是主要的优点，但对我来说绝不是唯一的。

看看今天的 xproj，你就会对“新的”csproj 有什么期望

我今天没有 xproj。 为什么我需要这样的东西？

真正的讨论不是也不应该是关于“MSBuild 有多糟糕”

为什么_不应该_讨论？ Turfing MSBuild 是我采用 .NET Core 的一个主要优点。 在我的（显然）不科学、回声室、有偏见的调查中，20% 的受访者同意它从根本上被打破了。

@shederman你的回答正是我所指的那种有毒的讨论。 您只是在提出一般性声明（例如“MSBuild 很糟糕！”），但您并没有通过任何形式的建设性讨论来支持它们。

会是 XML 吗？ 是的，我是这么想的。

是的。 和？ 如果您的问题是您不喜欢 _XML_，那么就足够了。 如果您认为 JSON 优于 XML，那么请继续说出您的理由，但这与 _project 结构_ 无关，而与语法有关。 对您来说不幸的是，XML 和 JSON 都在世界上占有一席之地，两者都有明显的优缺点，对于哪个更好，永远不会有明确的“正确”答案。 再说一次，如果我是你，我会专注于_项目结构_与搬家的区别。

你是根据什么信息说这话的？ 我的意思是，没有文件列表是主要的优点，但对我来说绝不是唯一的。

我从来没有声称这是唯一的好处，我只是说这是迄今为止 _main_ 的好处。 回顾几个月前关于 project.json 格式的任何讨论，人们谈论的第一件事就是它更小、更简单。 这不是因为 JSON 在语法上更清晰，而是因为删除了项目文件列表。 人们提到的最大优点是它合并得很好并且合并得很好，因为它没有在其中列出一堆文件引用。

我今天没有 xproj。 为什么我需要这样的东西？

整个讨论都是关于较新的项目文件格式，如果您不愿意比较当前的情况，那么您的意见将是不知情的。

为什么不应该是这样的讨论？ Turfing MSBuild 是我采用 .NET Core 的一个主要优点。 在我的（显然）不科学、回声室、有偏见的调查中，20% 的受访者同意它从根本上被打破了。

因为您实际上并不是在讨论 _MSBuild_，所以您在讨论 Visual Studio 历来处理 MSBuild 项目的方式——微软自己也承认这种方式很糟糕。 MSBuild 实际上已经支持几乎所有需要的东西——包括不必列出项目中的每个文件。

更重要的是，到目前为止，您在本次讨论中所做的只是尖叫和大喊您不喜欢 XML，但我还没有看到您提出任何支持或反对的真正论据，“它只是没有合并为好吧”，正如我现在多次说过的那样，这通常取决于“旧”csproj 中列出的文件数量。 如果您费心查看 xproj 格式，您会发现它非常小，Daniel 在站立会议期间说“新”的 csproj 格式将与当前的 project.json 文件大小相同 - 再说一次，什么是问题？ 你提出了大胆的主张，但你根本不支持它们。

@neoKushan你应该很快就会从微软那里获得某种奖励，无缘无故地为他们辩护。 实事求是，这是在后门中做出的最糟糕的决定。 我建议再次使 asp net 关闭源代码，并允许 Microsoft 及其像您这样的支持者在不询问开源社区成员的情况下决定他们想要什么

@abcplex 除了辱骂和指责之外，您是否会为对话做出任何贡献？

到目前为止，您除了抱怨更改之外什么也没做，而没有列出您的实际问题是什么原因。

@neoKushan最重要的一点是，现在不是进行这种更改的时候，就在一个月前的 RTM。 在这个时间做这个改变没有任何意义。

@abcplex RTM 没有发生这种变化。 这将是一个渐进的、 RTM 后的变化。 在 RTM 中发生的所有事情就是您的 xproj 被重命名为 csproj - 实际上没有其他更改并且更改将分阶段进行，工具会为您迁移您的更改。

同意 JSON 与 XML（与 XAML，正如在 Standup 博客文章中有些人要求的那样）分散了对与以前的工具具有任何类型的向后兼容性的优点的分心。

我认为这是一种高度误导的思维方式。 不管喜欢与否，csproj 和 MSBuild 都遵循 ant 的传统，即指导工具链如何构建项目，而不是定义它。 这些是非常不同的东西，但这种遗产似乎赋予了项目“定义”的权力，因为现在我们可以将逻辑应用于它，等等。 这样做会使事情变得异常复杂。

在旧世界中，我多次看到项目文件被破坏，仅仅是因为“需要在底部”的一行被向上移动，或者有人弄乱了环境变量，突然我们拉入了错误的 .targets 文件。 在声明式语法中，一级元素（根的子元素）依赖于顺序的概念完全被打破了。 那是 MSBuild 和 csproj 的土地。 这是我们带回这里的遗产。 现在要理解 csproj 必须“运行”它，并完全像 MSBuild 一样运行它。 是的，MSBuild 是开源的，但这实际上并没有解决任何问题。 它仍然引入了单一的、强制的依赖。 它仍然依赖于位于......某处的魔法目标文件。

项目文件应具有多种特性，使其与给定商店决定使用的工具链的形状无关：

• 它应该是人类可编辑/可读的
• 它应该允许评论
• 它应该是声明式的
• 应该是独立的
• 如果可能，它应该旨在减少合并冲突/简化合并
• 它应该是完全可记录的（自包含原则适用于文档）
• 它应该独立于工具

并且“它将简化从 .net 4.5 到 .net core 的迁移”似乎有点不诚实。 这绝对不是痛点……

同意 100%。 让我明确一下我们面临的挑战：到目前为止，迁移代码库的唯一困难是丢失了某些 .NET 类库（看看 System.Drawing），Microsoft 团队在支持 .NET 核心方面的沉默（看着您的 DocumentDB）以及主要版本之间可以预期的标准重大更改。

project.json 在任何时候都不是问题。 事实上，这就是好处之一。 同样能够将 MSBuild 转储到一个不可见的细节，当 Ctrl+Shift+B 神奇地发生时。

@neoKushan

1. 我不喜欢 XML。 这是项目和配置文件的错误格式。 当它在“适用于一切的 XML”阶段被引入时是一个坏主意，现在它是一个坏主意。
2. 我发现 JSON 文件的合并比 XML 文件要好得多。 我接受这是一种意见，但它是我的，并且基于我的经验。
3. 我正在使用不需要也不使用 xproj 文件的 vscode。 _that_ 是我目前的风景，我不想要或不需要一个对我来说毫无意义的 xproj 文件。
4. 不，我在讨论 MSBuild。 我已经用 MSBuild 和 Team Build 做了很多事情。 他们从来都不是很有趣，也从来都不是一件容易的事，而且总是与泥泞中的猪摔跤。 我_讨厌_ MSBuild，我肯定不是一个人。
5. MSBuild 使简单的任务变得困难。 我建议你看看替代方案，不要被 MSBuild 所迷惑。 特别是，看看 gulp 和 sbt 的工作方式。

@谢尔曼

我不喜欢 XML。 这是项目和配置文件的错误格式。 当它在“适用于一切的 XML”阶段被引入时是一个坏主意，现在它是一个坏主意。

这些都不能解释_为什么_这是一个坏主意。

我发现 JSON 文件的合并比 XML 文件要好得多。 我接受这是一种意见，但它是我的，并且基于我的经验。

我经历过噩梦般的 .json 合并和噩梦般的 .xml 合并，在合并方面我并不是特别喜欢。 根据我的经验，有问题的合并的可能性会随着文件的大小而增加，而不管格式如何。

我正在使用不需要也不使用 xproj 文件的 vscode。 这就是我目前的情况，我不想要或不需要对我来说毫无意义的 xproj 文件。

这并不意味着您不能查看当前的 xproj 文件以了解它是什么。 如果不这样做，你就相当于把手指放在耳朵里，闭上眼睛说“啦啦啦”。
换句话说，你可能会对正在发生的变化感到沮丧并抱怨它，一无所获，或者你可以参与实际对话并帮助指导结果。

例如，仍然未定的一件事是 nuget 依赖项是否会成为 csproj 的一部分，或者是否会成为 nuget.json - 这就是您的偏好。 在 .json 文件中拥有依赖项列表后，csproj 中还剩下什么？ 多久会改变一次？ _那个_合并有多难？

我个人更愿意将其全部包含在单个项目文件中，但我可以看到将 nuget 与项目本身分离的吸引力和好处。 两者都有利有弊，也许最好的解决方案是允许两者兼而有之，拥有一个包含依赖项列表的 csproj，但也让您指向一个包含依赖项的 .json 文件。 两全其美，每个人都赢了，代价是 MSbuild 本身增加了一些复杂性。

不，我在讨论 MSBuild。 我已经用 MSBuild 和 Team Build 做了很多事情。 他们从来都不是很有趣，也从来都不是一件容易的事，而且总是与泥泞中的猪摔跤。 我讨厌 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 中？

我建议你不要把玩具扔出婴儿车

不想:-)

不，我完成了。 和 Immo 聊了很久，我已经结束了这场战斗。 每个人都有自己的片面看法，没有人愿意听听他们的方式可能并不适合所有人的荒谬观念。

[编辑以消除暴躁]

@shederman ：你在这里展示构建定义文件； 我想摆脱构建定义作为项目定义。 有空间来定义关于一个项目/要生成的工件的静态细节，独立于如何生成它的指令。 将两者混为一谈是使用 MSBuild 文件作为项目文件的主要问题之一。

我希望能够仅指定描述要生成的工件和要使用的依赖项和工具链所需的信息，以及构成磁盘上项目的各种元素的布局。 其他一切都应该分开。 如果您想在幕后使用 MSBuild，请继续。 如果您更喜欢 gulp、babel 或 what-have-you，同上。 对我来说，这就是 project.json 的目的。 （不过，我不喜欢在那里定义命令的能力）

是的，这是有道理的。 这是我喜欢 project.json 的原因之一。 它定义了“什么”，而不是“如何”。 通过在一个文件中放置太多东西，我们会使文件变得过于复杂，尤其是当我们的 IDE 很愚蠢时。 编辑器和简单的 IDE 不需要这些东西。

从像 VS Code 这样的低级 UI 来看，对项目系统的需求并不大。 都是建的很多都是声明性的，说明应该构建什么和元数据。 有些可能是必要的，说明应该执行哪些步骤。

是的，MSBuilds 最大的问题是它试图在一个系统中完成所有工作。

我想我没有理解的是：向我展示一些通过使用 MSBuild 作为项目系统而不是仅仅使 project.json 工作而得到改进的用例。 我没有看到。 也许我的用例太简单了，所以给我看看。

@shederman站立笔记提到需要能够跨项目共享源文件

所以......这是一个开源项目，我知道微软是“强大的力量”，但如果这对人们如此重要，那么 - 我知道我在这里问了一个无知的问题 - 多少时间/effort/energy 需要消耗以允许 .NET Core 继续使用 project.json 作为 MSBuild 的替代方案吗？ 如果有足够多的人贡献，并且代码足够好，那么为什么 MS 不接受它进入这个项目？ 开源的部分优点（和垮台）是如果主要维护者拒绝太多其他人提供的东西，就会威胁到代码分叉。 代码开源的部分意义不仅在于查看，还在于修改和改进。

我个人对更改的看法是它确实与 Xamarin 有关，因为它与未来计划有关。 此外，在最近的站立会议中，我相信我听到他们说他们希望构建控制台应用程序成为一流的公民。 请记住，最初，新的 .NET (ASP.NET 5 + DNX) 专注于构建 Web 应用程序，现在更多。 所有这一切都发生在最近，.NET 和 ASP.NET 团队合并，以及 Xamarin 的购买。 他们得出的结论是，他们需要一个更好的项目系统来支持这些多种场景（以及我不会在这里推测的未来新场景），并且他们也希望尽快发布 .NET Core。 该怎么办？ 完全忽略已经可以处理所需内容并从头开始的预先存在的 MSBuild？ 对不起，我知道我会选择的道路。

如果项目文件不包含项目中文件的名称，并且如果将依赖项推送到单独的配置文件中，合并问题应该会消失，因为项目文件应该然后更改相对较少。

只是我的观点

合并问题只是一个问题。 远离 MSBuild 是另一回事。 这种情况的一个疯狂结果是，他们现在将花费时间和精力将 MSBuild 移植到 Linux 和 OSX！ 想象一下。

我明白他们的理由，但他们的理由根本不适合我，也不适合很多人。 我们根据对他们所采取的方向的坚定保证进行投资，他们以零责任重新开始投资，无非是表明他们可能应该更好地_传达_决策。 他们正在根据 MSBuild 支持的边缘情况以及支持这些边缘情况的难度对 project.json 做出决定。 嗯，这意味着它_永远_不会停止使用，因为没有人会支持所有这些边缘情况。 当然，没有人做 ASP.NET 项目需要那些边缘情况。

分叉是一种可能性，但考虑到所有内容的规模和集成度，即使考虑学习相关代码也是一个令人生畏的前景。 现实情况是，这并不是一个真正的开源项目，而是一个微软项目，他们在没有我们参与的情况下做出了公司决策，我们必须接受并接受它。 我已经清楚地表明，无论有什么反对意见，他们基本上都不可能_永远_重新考虑。

所以，要么我们花精力分叉 project.json 构建系统，要么我们切换到另一个构建系统（FAKE？），要么你把它搞砸，要么你使用另一个平台。 我相信我已经列举了那里的所有选择。

@shederman MSBuild 自 2015 年初以来一直是开源的，并且构建正在 OSX/Ubuntu 上传递，所以我认为它的工作量没有你想象的那么多（https://github.com/Microsoft/msbuild） ，浏览存储库，例如，OSX 在 3 月份就可以正常构建。

哦亲爱的。 我担心我们是否_应该_这样做，而他们已经去做了......

感觉有点像有人看着弗兰肯斯坦怪物冲向远方。 感兴趣，好奇，关心，甚至有点反感:-)

@darrelmiller站立笔记提到需要能够跨项目共享源文件

真的吗？ 人们还这样做吗？ 我的意思是我曾经为 AssemblyInfo.cs 做这件事，回到黑暗时代，我们将强名称键放在共享源文件中。

好的，这是一个用例，但现在我真的很想听到用例的用例。 很好奇。

@谢尔曼

嗯。 好的，所以我必须想象一个我不想要的未来并向你解释它是如何运作的？ 嗯，不，我不这么认为

您所要做的就是接受 XML 而不是 JSON，看看有什么好处，但是您不愿意玩那个游戏，因为您只想谈论 XML 有多糟糕而不实际说明原因。

哦亲爱的。 我担心我们是否应该这样做，而他们已经去做了......

他们已经“开始做这件事”了_年_了。 几年前，他们谈到了开源 .net，他们给出了路线图，并明确表示它最终会在任何平台上运行，适用于任何用例。

你对这个变化感到非常不安，我怀疑大多数对变化感到不安的人都是 Web 开发人员，但这只是 .net 生态系统的一小部分，有一个巨大的服务生态系统，移动和云开发人员拥有巨大的他们希望能够移植到 .net 核心的代码库。 不管喜欢与否，project.json 目前并不适用于所有这些模型。 你说“让它工作”，但你最终会得到另一个凌乱的项目文件，除了一个没有明显和明确定义的结构——更糟糕的是——没有评论。 最后一点足以让我们重新思考 project.json。

哦，是的，您链接的那个 xproj 好多了。 漂亮，清晰，简洁。 和表现力，不要忘记表现力。

至少你终于看过了。 在你甚至打扰之前，只花了什么，在这个问题上 72 条评论？ 我一直在告诉你这个，但你没有明白：与其抱怨 MSBuild 有多糟糕，不如谈谈为什么它很糟糕。

合并问题只是一个问题。 远离 MSBuild 是另一回事。

为什么这甚至是一个问题？ 您讨厌 MSBuild，我们明白这一点，但是除了它_敢_使用 XML 的事实之外，您还讨厌 MSBuild 什么？

这种情况的一个疯狂结果是，他们现在将花费时间和精力将 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 没什么大不了的，但几乎在最后一刻关起门来做这件事会立即扼杀“希望”。

突然间，这不再像是一个开源项目。

仅供参考：“Asp.Net Core”有很多很棒的功能。 我主要是喜欢它。
Asp.Net 团队很棒，作为一名 Asp.Net 开发人员，我感到无比自豪。

但我受伤了。 也许我不是唯一的。

只有我的 2 美分。

我认为我们几乎都同意 msbuild（尤其是 VS 如何使用它）并不完美，虽然我对 project.json 感到兴奋，但更多的是关于 MS 解决了我的很多痛点，老实说，只要他们这样做，我可能不太关心他们是如何做到的。

• csproj 合并效果不佳，我发现自己需要每隔一周手动修复一次损坏的合并。 从 csproj 中删除文件列表在这里会有很大帮助。
• NuGet 引用和项目引用并不总是对齐，同样可能是由于合并中断。 无论哪种方式，诊断和纠正都很烦人。
• 有时我需要插入构建过程（不确定这在 project.json 中是如何工作的）但整个需要卸载/加载使得构建脚本的调试成为一个痛苦的过程。

如果他们找到修复这 3 个项目的方法，那么我可能不会抱怨 csproj 文件。

@neoKushan

您要做的就是谈论 XML 有多糟糕而不实际说明原因

不完全公平，我还想谈谈 MSBuild 的糟糕之处:-)

我确定我实际上_have_ 说为什么我不喜欢用于构建文件的 XML，但让我再试一试。 XML 冗长、丑陋，它更适合工具而不是手动编辑，而且我不喜欢合并它的体验。 它被用于 MSBuild，因为当时业界认为 XML 可以用于一切。 从那以后我们就继续前进了。 嗯，在某些地方。

更糟糕的是 - 没有评论

我相信有几个人在这里提供了替代方案。 HJson 只是一种选择。 耶！ 毕竟我们不必重新考虑它;-)

你对这个变化很不高兴

公平地说，我对如何在一个封闭的房间内进行这种更改感到非常不安，而没有考虑或与社区互动，社区从表面上看是非常坚定地支持 project.json。 男孩，不会再犯那种错误了！

不要误会我的意思，不喜欢 XML，不喜欢 MSBuild。 但是讨厌被告知采用我真正喜欢的东西，然后在最后一刻被告知它被带走了。 别动我的奶酪！

我怀疑大多数对更改感到不满的人都是 Web 开发人员

嗯，是的，那是因为他们是您提供 project.json 的唯一开发人员。 在其他新闻中，Swift 开发人员也不会对这个决定感到不安。 我的意思是想想你在这里说什么：

1. 只有 Web 开发人员才能获得此新功能
2. 当我们把它拿走时，他们中的许多人真的很不高兴
3. 没有其他人必须使用它
4. 没用过的人不会因为被拿走而难过
   因此，所有其他开发人员都不会想要它。

我认为你需要看看你的思维质量，这就是我试图审问了很长一段时间，但一无所获。 缺乏有关该想法的信息，以及有关方面一直闭口不谈的事实，向我表明该想法可能受到怀疑。

你所说的“网络开发人员”是什么意思？ 您正在考虑为一家小公司创建一些小网站吗？ 一堆微服务，支持管理数百亿美元的资产管理业务如何。 当然，那里也有一个网站。 但这大约是系统的 10%。 哦，是的，它实际上也针对云，所以也许我们实际上是在谈论“云开发人员”。

听起来您甚至不了解您草率决定的技术是如何使用的，或者由谁使用。

除了敢于使用 XML 的事实之外，您还讨厌 MSBuild 什么？

太复杂了
这是一种阻抗不匹配，将基于推理的逻辑推入人们主要处理命令式或声明式逻辑的情况。
天哪，你真的_看过_MSBuild 文件吗？ 好的，抱歉，您说除了使用 XML 之外；-)
属性和项目的声明方式对于不经常使用它的人来说是违反直觉的
它被用作一种适合所有尝试执行应在脚本中完成的任务的工具。 锤子，钉子。
在很多情况下，它在一个大文件中所做的一切最多只能用3行脚本来表达
被喷入其中的 VS 垃圾。 我听说这将被修复。 带着一些恐惧等待，看看它是否也会被削减。 如上所述，我现在对 Promise 有点不以为然。

你这么爱什么？ 最重要的是，您是否愿意接受其他人可能不同意您的观点？ 如果是这样，您能承认“一刀切”可能不是正确的方法吗？

你指的是什么方向

project.json 是我们新项目方法的基础，是交流的内容。 我们在这一承诺的基础上投入了真正的金钱、时间和痛苦。

但也许他们为比你多得多的人工作？

也许他们确实如此。 但如果是这样，证据在哪里？ 我试图询问其中使用的思维、决策和证据，但我从任何人那里都没有得到任何信息。 对于所提供的所有证据，据我们所知，您可能已经动摇了魔术 8 号球。

没有人知道有多少人以一种或另一种方式思考。 我实际上是我所知道的唯一一个真正试图找出答案的人。

除了你自己，你不关心任何人，一个 asp.net 开发者

不是很好。 我实际上是说，断言是新方向适用于所有用例，我举手说它对我不起作用。 你是那个在所有反对者面前粗暴对待的人。 我是问人们他们的想法的人，MS 不是。

我从来没有说过“完全摆脱 MSBuild，并在所有其他开发人员上执行我的构建过程”。 您是说“完全摆脱 project.json，并对所有开发人员强制执行 MSBuild”的人。 我们在所有预览中都有两个构建系统，我们很高兴。 Web 开发人员很高兴，非 Web 开发人员也很高兴。

我们可以讨论它的可行性，也许它不是，但我们不知道，因为我们从未被咨询或参与过。

你真的很喜欢你的排中论。

他们接受拉取请求

真的吗？ 如果我们发出拉取请求，在主要工具功能中留下一个非基于 MSBuild 的构建工具，即只读 project.json，您会将它包含在框架中吗？ 真的吗？

好的，所以我基本上是这样读的......

哇，你读了很多。 天哪，如果我像你一样阅读，我永远不会完成一本书。 而且这与作者所写的完全不同。

而是尝试，“我不完全了解更大的图景，我正在考虑这样做所涉及的精力和时间。如果我们有现有开发人员的帮助来交付如此重要的一部分，那就更好了的社区想要，但我想如果他们不关心用户想要什么，我们可能不得不走那条路。”

该死！ 我和你一样读书！ 除了它确实比你有些歇斯底里的解释更适合原文。

你可以尝试为对话实际贡献一些建设性的东西。

好吧，我以为我实际上是有建设性的。 在我克服了最初的震惊之后，我试图找出这个决定的基础是什么。 我试图找出决策过程是什么。 我试图询问它背后的思想质量。 当我被告知大多数开发人员想要这个，但没有提供任何证据来支持这个断言时，我实际上问他们，团队中_没有人_做过 BTW。

我得到了什么？ 阻挠、侮辱和逃避。 所以告诉我，为什么你认为询问一个做出影响数百万人的重大决定的人是否做了功课是没有建设性的？ 当这些人拒绝出示作业簿时，您认为这是有建设性的还是可疑的？

我的意思是，实际上，这些是可能的情况：
1) 您是根据一整套反馈和信息做出的决定，而该决定确实是迄今为止继续前进的最佳选择。 如果是这样，我会闭嘴，我保证。 我发现这种情况不太可能发生，因为你收到的反对程度很高，而且你隐藏了证据和决策。
2）您根据部分观点做出决定，但这是当时最好的决定。 我会说正确的回应是重新开始决定并征求您遗漏的意见。 我发现这是最有可能的情况。
3) 你做出的决定很糟糕或基于错误的信息。 在这种情况下，您应该再次重新做出决定并征求社区意见。 我真的不认为这是这种情况，因为尽管您可能不相信我，但我确实非常尊重 DotNetCore 开发人员。 他们都是。

而且你知道吗，如果你重新开始决定，征求意见，并且决定以同样的方式做出，那么有什么危害？ 如果在征求意见后，你意识到你的一些决策有缺陷，你纠正它，那实际上不是更好吗？

哇，认真的。 我们可以结束这一切吗？

简单的问题：您是否会接受反对意见并根据新信息重新考虑决定？

或者你会继续暗示那些不同意你的人是疯狂的、愚蠢的、不熟练的、_不知情的_，或者无法持有明智的、有效的意见？

建议：微软fork支持msbuild csproj老客户。 #carryOnAsNormal

我也是 .Net 的长期开发人员，在营销甚至发明 .Net 名称之前，我一直在使用 1.0 的预览版。 不要迷失在杂草中，这是我的两分钱。

我可以在没有看到另一个 xml 配置文件的情况下度过我的余生并且非常高兴。

我不想要 xml 配置。 任何地方。 曾经。

我不在乎团队是否修复了 csproj 的每一个痛点； 如果完成后它仍然是一个xml配置文件，那么我不感兴趣。 您也可以只保留 .net 4.5 项目系统。

至于 MSBuild ...... MSBuild 可能会死在火中。

我知道它很强大，并且围绕它存在很多工具，但是在 MS 之外，只有真正深入了解 MSBuild 的专家才真正知道它的作用或工作方式。 每次我必须在构建过程中插入任何自定义内容时，我最终都会失去 3 到 5 天的职业生涯。 我很少能同时在 VS、VS 发布和我的 CI 服务器中获得任何东西，即使是一些微不足道的东西，例如只在输出中包含一个空文件夹。

我明白了......如果你没有时间为 asp.net core 1.0 时间框架构建一个很好的 MSBuild 替代品，那么肯定......想出一种方法来继续利用 MSBuild，直到 asp.net core 2.0循环; 但至少要继续朝着用我们其他人可能能够使用的东西替换粪便的方向努力。

同时，尽量在 json 中保留尽可能多的配置。 我并不特别关心它是 project.json 还是新的更好的东西。 如有必要，让工具在/如果需要时即时生成遗留的 MSBuild 文件——将它们粘贴在某个子文件夹或某处。

我不想要的是我的文件系统看起来像这样：

• 凉亭.json
• 包.json
• nuget.json
• 一切-else.json
• microsoft-old-ass.xml.csproj

另外，你能不能修复 260 个字符的路径长度限制......拜托......是的，我知道这与 Windows 有很大关系，但说真的......它是 2016 年......

附注。 如果你要进行无视反对，能否请您提供以下内容：

• 我们如何访问构建工具开发人员的空闲渠道
• 当前体系结构和代码的高级视图，以及将在何处迁移到 MSBuild/xproj 的更改，以便我们可以计划我们的方法以保留我们想要的位并很好地集成。
• 保证在满足质量标准的情况下，将接受在基于 project.json 的工具中烘焙的拉取请求
• 保证如果质量标准得到满足，我们可以包括对完整 project.json 的“dotnet build”支持，以及 ASP.NET Simple 模板，以及一些适用于更标准项目类型的潜在模板。

“要有建设性”，“不要贡献，不要发表意见”。 好吧，你得到你所要求的......

@Mike-EEE，想为 SimpleUseCaseBuild 做 Xaml 序列化吗？

阅读完所有这些后，我得出了以下结论：

• project.json 带来了很多改进。 如果 .net 和 asp.net 核心与遗留代码和工具相关联，这一切都不可能实现
• project.json（和 json）并不完美
• xml vs json vs anyserializationlanguage 是无意义的。 关于如何利用它们来回答 .net 核心挑战的讨论会更有趣
• 回到 msbuild 会带回遗留系统，这可能意味着我们不会再看到项目系统的改进，因为 .net 团队可能会失去一些自由

我希望 .net 团队深吸一口气，稍微拖延一下，收集反馈（并考虑对这个新堆栈的采用和看法），并挑战 msbuild 方法（这可能不像我们中的一些人想象的那么糟糕）一些替代方案。 我认为有必要急于求成。

大声笑@shederman你现在把我拉到什么地方了？！ :smile: 什么讨论！ 真的很棒。

xml vs json vs anyserializationlanguage 是无意义的。 关于如何利用它们来回答 .net 核心挑战的讨论会更有趣

是的，对我来说，重要的是用于描述项目和/或他们所做的事情的支持模型，其中一些对话涉及到了这一点。 我希望看到一个改进的项目模型/api，它更容易描述和使用（无论它描述的格式如何——尽管是的，我是：心：我的 Xaml！）。 我在这里 (https://github.com/Microsoft/msbuild/issues/613) 和 Roslyn 的项目系统 (https://github.com/dotnet/roslyn-project) 上对 MSBuild 的 repo 进行了公开讨论-system/issues/37) 以及，如果有兴趣。

这里有很多非常好的观点，我个人正在挖掘能量，“非建设性”或其他方式。 我认为这里的每个人都致力于改进 MSFT 并充分利用正在生产的产品。 ：+1：

我的 2 美分：

我相信有两种人在讨论这个变化：

• 一直使用 VS 和 .NET 构建 _various_ 类型项目并且必须长期支持这些项目的开发人员
• 没有这种包袱并想要新的、干净的、花哨的、跨平台的 ASP.NET Core 框架的开发人员

就我个人而言，我属于第一类，所以我希望新的 ASP.NET Core 尽可能与其他 VS 项目类型兼容，并且转向“旧”的 csproj/msbuild 解决方案对我来说是一个胜利（+我的团队，可能还有许多其他开发人员）。 这样过渡会更加顺畅和清晰。 也许第二类人不会同意我的观点（或者他们根本不在乎）。

我现在看到的唯一主要问题是如何定义和引用 NuGet 包。 必须同时维护packages.config 和csproj 文件（正如@JulianRooze在https://github.com/aspnet/Home/issues/1433#issuecomment-218606377 中已经提到的那样）是一种痛苦。 这必须重构。 理想情况下，它应该像 https://github.com/aspnet/Home/issues/1433#issuecomment-218519705 中建议的@cwe1ss那样完成）。 这是这个话题中最具建设性的评论之一 BTW...

至于 XML/JSON 圣战……恕我直言，XML 比 JSON 更适合手动编辑。 XML 支持注释并在您查看时具有更多上下文信息。 JSON 更适合数据，而不是配置文件。 合并对这两种格式来说是好是坏，这完全取决于内容。 如果项目引用与当前的 csproj 文件分开，合并也会变得容易得多......

@Funbit试图对人进行分类无济于事。 我不属于你的任何类别。 从 v1 测试版开始，我就是一名 asp.net 开发人员。 2 年前我几乎不再是一个人，但是 .net core 把我带回来了，因为它是干净的石板和最好的 .net 和节点世界。

我希望 .net core 取得成功，而不是一个没有采用和社区的旧企业技术。

就我而言，我并不真正关心这个决定，我不太关心 XML，并引用一句名言：“大括号比尖括号更好”，但它并没有真正困扰我回到csproj/msbuild - 我很灵活，我可以应付。

不过，我想回应一些@shederman 的评论：

现实情况是，这并不是一个真正的开源项目，而是一个微软项目，他们在没有我们参与的情况下做出了公司决策，我们必须接受并接受它。 我已经清楚地表明，无论有什么反对意见，他们基本上都不可能重新考虑。

和

公平地说，我对如何在一个封闭的房间内进行这种更改感到非常不安，而没有考虑或与社区互动，社区从表面上看是非常坚定地支持 project.json。 男孩，不会再犯那种错误了！

这_确实_困扰我，微软已经做了大量的开源 .NET 并希望真正参与社区并与社区合作，获得他们的反馈并成为社区的好“成员”（合作伙伴？）。 但这种事情确实阻碍了整个努力，并让 .NET 生态系统感觉 /. 社区标记它多年。

公平地说，微软并不是唯一一个用企业赞助的项目做这种事情的人。 还记得 nodejs 社区的分裂（导致 io.js 分叉）吗？ 但我认为当它是微软时，情况要糟糕得多。

这超出了最初的预期。

这超出了最初的预期

@MaximRouiller你是开发人员吗，兄弟？？？ ：微笑：

@Mike-EEE 我愿意。 我期待着一些激烈的争论，但我看到了太多的人身攻击。 ：失望的：

需要能够跨项目共享源文件

@darrelmiller这对我来说听起来很可怕，因为这似乎意味着 .csproj 中的列表文件又回来了。

@lokitoth链接文件可能也没有理由不能使用通配符全局。

@MaximRouiller我也因@shederman知道如何扔掉！ 哈哈。 顺便说一句，我想说@shederman代表了我内心的编码动物，但那是在我知道有 @CodingGorilla 之前。 ：笑：

我认为我们需要提醒自己，我们所做的工作真的很辛苦，这才是真正有效的时候！ 到达那里更加困难。 在我使用 Silverlight 的经验中（是的，我被那个烧伤了 baaaaaaad，所以我知道@shederman来自哪里），它帮助我看到也许我不知道 _everything_（有时甚至是 _anything_，感觉！）并对事物保持开放的态度。 我还是失败了。 即使当我看到 project.json 计划时，我也尽力指出它所造成的分歧，但对 repo 中的人这样做可能有点过于粗暴了。

无论如何，最好深吸一口气，（尽量）保持谦虚的精神，并提醒自己我们在同一个团队中，即使该团队现在已经分为“网络”和“本地”阵营。 它可能会持续一段时间，但我们在这里谈论的是可以为我们服务很长时间的东西——甚至十年或更长时间。 让我们专注于长期方法，同时也要对他人及其来源有同理心。

好的...足够的讲道和 rah-rah 一天。 :stuck_out_tongue: 回到我们定期安排的 slugfest！

这对我来说听起来很可怕，因为这似乎意味着 .csproj 中的列表文件又回来了。

另外，顺便说一句，我是这个星球上唯一欣赏此功能的人吗？ :stuck_out_tongue:

这对我来说听起来很可怕，因为这似乎意味着 .csproj 中的列表文件又回来了。

另外，顺便说一句，我认为这个星球上只有人欣赏这个功能吗？ :stuck_out_tongue:

@Mike-EEE 是的，我认为你是。 ：眨眼：

链接文件的主要用例是针对多个平台。 这是我非常想保留的 project.json 的一项功能。 我认为我没有看到有关此功能的任何具体评论，但如果团队能够确认他们打算在 msbuild 中重新创建此功能，那就太好了。

@shederman知道如何扔掉！
😆

我试试。 不过我希望我没有侮辱任何人。 我非常努力地只追求争论。

我特别容易被冷嘲热讽的个人侮辱激怒，所以任何反对我的人，这不是让我闭嘴的方式。 😉而且有很多这样的。

我对编辑 csproj 文件的用例很好奇。 我的经验是，当 nuget 搞砸了某些东西或提示路径被破坏时，我只需要编辑 csproj 文件。 为了向构建过程添加新步骤，我一直使用由我的 CI 系统运行的更高级别的 build.proj 文件。 我从来没有在我的 CI 设置中使用 .sln 文件。

人们想要编辑 csproj 文件以添加他们在 Visual Studio 中调试时想要执行的 BeforeBuild 和 AfterBuild 步骤的主要目的是什么？

@Mike-EEE 也许吧； 我主要记得在处理包含大量文件（例如 Expression Blend、Visual Studio XAML 设计器等）的项目时，我们将其换成通配符选择，这是一种非常痛苦的事情 - VS 确实如此不知道如何正确使用，这意味着每次添加文件时我都必须重新加载项目（或在构建时遇到“此文件已添加”错误）

你真正喜欢这个“功能”的什么（不是跨项目共享文件，这显然很有用，但只有当每个文件都单独列出时，VS 才能正常工作）？

你真正喜欢这个“功能”的什么（不是跨项目共享文件，这显然很有用，但只有当每个文件都单独列出时，VS 才能正常工作）？

诚然，这是一个坏习惯，但我喜欢在重构时能够从我的项目中删除文件。 甚至从历史的角度来看。 如果我知道我正在做一些我以后可能想要的东西，我会将它保存在磁盘上，但从项目中删除它。 当然，这会污染 repo/源代码控制（请参阅：坏习惯），但我喜欢这种控制。 因为现在，当我想要那个文件时，我不必到处乱看 repo 的历史记录（如何找到已删除文件的历史记录？？？太多工作了！），我只是“显示所有文件”并将其重新添加回我的解决方案中。 即时历史。 ：微笑：

我对编辑 csproj 文件的用例很好奇

对于 .csproj（我已经完成了其中的每一个，并且对于大多数人来说，多次）

• 如果需要从桌面应用程序引用 UWP 类型
• 如果你需要用 NuGet 修复 VS 破坏性的东西（特别是在添加 a.targets 文件和 .proj/.props 包括）
• 如果您需要更改生成的输出的布局
• 如果您正在重构项目和重命名程序集
• 如果您正在进行影响大量文件的大型重构
• 如果由于多人在同一个项目中工作而发生合并冲突，并且您没有使用通配符
• 如果您需要了解为什么构建突然不起作用（编辑：我应该指定 - 这更像是“为什么我需要它是可读的，并且‘自包含’”）
• 如果因为烦人的依赖需要调试程序集版本冲突
• 如果您尝试添加“链接”（共享）文件

对于 project.json

• 手动从头开始创建文件（非常重要）
• 添加/删除 NuGet 包
• 改变目标框架
• 更改输出包版本

@shederman我意识到你很沮丧，但是当你回复

真的吗？ 人们还这样做吗？ 我的意思是我曾经为 AssemblyInfo.cs 做这件事，回到黑暗时代

你在定调子。 面对面的谈话是好的，但在这种环境中，它往往会打开一整套基于情感的评论的大门，这往往会使谈话两极分化，并且很难专注于重点。 我知道很难将情绪排除在这些讨论之外（我的舌头上满是咬痕；-)）但我们真的必须尝试以保持讨论有用。

@Mike-EEE 难道你不能使用Exclude属性/模式完成同样的事情（不列出每个文件）吗？ 为了记录，我经常做同样的事情，当您只想快速消除某些内容而不必执行提交/回滚循环时，它非常方便。

作为记录，我实际上喜欢@Mike-EEE 的提案，它使用 Roslyn 并将项目文件作为序列化的 AST。 但前提是我们能够设法使仅使用记事本也同样容易工作。 （是的，我的意思是记事本，而不是记事本++或其他更高级的东西：这是人类可编辑文件格式可用性的“冒烟测试”）

@CodingGorilla我对此态度。 我更愿意看到工具帮助我解决这个问题（为我定义模式而不是弄清楚如何去做——如果我觉得我又在使用 DOS 了，那么每个人都会失败！！）。 我应该能够拥有与现在完全相同的体验。

所以基本上，着眼于“选择退出”模型而不是“选择加入”。

对于那些想要在不卸载的情况下编辑项目文件的人...... https://twitter.com/migueldeicaza/status/730978470734401536

对于那些想要在不卸载的情况下编辑项目文件的人......

@darrelmiller我在这里看什么...建议改用 Xamarin Studio？ 是的，卸载/装载业务/工作流程/经验是最糟糕的！ 从2003年就开始了，呵呵。

我赞同最终文件应该可以使用标准文本编辑器（即记事本）轻松编辑和读取的概念，无论格式如何。

我还认为更好的工具会消除当前 csproj 背后的许多痛点。 VS 不是最好的例子，我认为 VS 给你的体验是很多人实际上讨厌 MSBuild 项目系统的地方。

@Mike-EEE 对 Miguel 评论的回复来自从事新项目系统工作的 David Kean。 团队知道 VS 也需要能够做到这一点。

@Mike-EEE 我想我的事情是，我可以处理他们提出的任何问题。 MSBuild 项目系统足够强大，几乎可以做任何事情（除非@shederman说，它只是_不能_是 XML）。 我认为有些人只是在强调“这一定是我的方式，否则它就会失败”，正如其他人所说的（对不起，忘了是谁，这个帖子是 YUUUUUUGE！）“我尽量保持开放的心态......”和只是适应。

此外，你可能会学到一些新东西，这总是一件好事。 ：咧嘴笑：

@neoKushan我曾经从头开始编写 msbuild 脚本，它确实比 vs 风味的 msbuild 更强大。 但这也不是很好，我很高兴我不再这样做了。 我认为我们可以找到比这更好的方法。

@CodingGorilla实际上，我的主要目标是 MSBuild。 XML 是一个问题，但不如 MSBuild 严重。

我已经提出自己做这项工作，以保持 project.json 支持与 xproj 并行运行。 谁最在乎，工作，对吧？

而这实际上是症结所在。 团队会允许我做出这样的贡献吗？ 如果没有，为什么不呢？ 毕竟是OSS，不是吗？

然后，如果您喜欢 MSBuild 并且想要它的强大功能，您可以使用 xproj。

如果您喜欢为 ASP.NET 核心构建的工具，您可以继续使用它。

它们使用相同的底层编译器。

无论如何，它甚至不应该做那么多工作。 我所要做的就是将他们弃用的代码重构为另一个命令。

理想情况下，我希望能够使用“dotnet build”并查看目录并根据那里的文件决定使用哪个。 但是构建上的选项标志甚至新命令都可以。

@sandorfr我同意编写完整的 MSBuild 文件来定义您的 _整个_ 构建过程，这简直是一种巨大的痛苦，但如果我没记错的话，这不是我们真正在这里谈论的内容 - 我们正在谈论 _just_ 项目结构体。

换句话说，MSBuild 是一个庞大、强大的系统，随之而来的是很多复杂性——但前提是你使用它。 默认情况下，VS 扔了很多你不需要的废话，看看 xproj，很明显 MSBuild 也不需要它。 如果 donet 团队专注于最小化 csproj 中的需求，那么它对于大多数人来说应该是相对最小和干净的。 唯一应该遭受“合并地狱”的人将是那些想要额外功能的人（我怀疑是推动这种变化的人，在他们头上）。

仍然没有什么能阻止您使用您选择的构建系统，无论是 CAKE 还是 TFS Team Services 或其他什么。

同样，这是规定团队做“正确”的事情。

VS 不是最好的例子，我认为 VS 给你的体验是很多人实际上讨厌 MSBuild 项目系统的地方。

@neoKushan这就是我对 TFS Build 和 Xaml 的感受。 Xaml 非常棒（并且仍然希望看到它用作 MSBuild“脚本”的可能格式），但它在 TFS Build 中的使用给它起了一个坏名声。

我认为将这个 github 问题用作聊天窗口是没有效率的。 我想保留此线程的电子邮件通知，以防有人从 MS 回复，但邮件数量变得太烦人了。

MSBuild 项目系统足够强大，可以做任何事情

这是问题的一部分，是什么使得在阅读 csproj 文件时很难理解它发生了什么，这使得它成为项目文件格式的糟糕选择（不要与构建定义文件格式混淆）

（编辑：添加）

仍然没有什么能阻止您使用您选择的构建系统，无论是 CAKE 还是 TFS Team Services 或其他什么。

不幸的是，这意味着如果我们希望 VS 能够与 MSBuild 对话（并且在有托管代码和本机代码并且我们想要调试时正常工作），我们就会试图将我们的构建系统硬塞进 MSBuild。 这就是为什么，实际上，我认为将项目文件从构建文件中分离出来是一个 _feature_ 。

哈哈，是的@cwe1ss （说到工具改进！）我只是在想，当事情在谈话中爆发时，GitHub 很糟糕。 我们这里有 3 个线程。 而我刚刚开始了另一个。 ：失望的：

我可以建议我们都参加周三的下一次社区站会吗？ 我怀疑它主要是在一两天前谈论 RC2 的发布（一个人可以希望！）但它会让我们有机会向他们提出必要的问题，并与现场观众进行坦率的讨论这实际上可以给出答案。

我可以建议我们都参加周三的下一次社区站会吗？

仅当@shederman代表时。 我想看到他实时粉碎开发人员和他们的想法。 就像 WWE PPV 赛事！

我认为 project.json 相对于 [projectName].csproj 的优势不在于格式。 这是关于不需要向后兼容所有旧东西。 这使它变得非常简单。 假设 Damian Edward 和团队可以实现他的所有指定目标，我并不真正关心 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 长篇大论”怎么样？

@谢尔曼

如果我们让 MSBuild 接受 JSON 文件会怎样？ :laughing:（忍不住）

@shederman很难认真对待任何长篇大论，我宁愿微软认真对待这个_discussion_。

未来 5 年的发展趋势是，您将编写 Swift、Java(!!)、Node.JS 或 Elixir 编程。 ;)

如今在 .NET 项目/解决方案/任何东西中有两种糟糕的技术。 Nuget 和 .csproj 文件。 如果您在使用 Git（例如 GitFlow）的 5+ 团队中工作，那完全是一场噩梦。 “哦，废话，如果忘记将文件包含在 .csproj 中”越来越烦人。 工具应该解决这个问题，工具也应该警告我我有冲突的 DLL 版本，工具应该帮助我合并。

废话少说。 Project.json 一开始看起来不错，但后来政治和感情发生了。

MS Team 应该称其为 beta，而不是 RC。
看起来即使 RTM 何时发布，我也无法相信，'万一 MS 团队决定发布 RTM2，这再次破坏了一切。
我不是悲观主义者，但围绕 .NET Core 的这种运动非常奇怪。

@neoKushan我会尽量保持文明，而不是长篇大论。 也就是说，我不相信任何 MSBuild 选项是好的，我也不相信 XML 是一个好的选择。

我不同意我必须放弃我所持有的职位才能进入讨论的讨论条款。 我一直听说我们这些支持 project.json 的人必须基本上完全接受 MS 的决定，也许只是一两个小的修改。

我不明白接下来会如何。 我只想要承诺并承诺的构建系统。 如果 MS 不愿意维护和继续它，我已经提供了。

那么问题出在哪里呢？ 我不是要 MS 退出他们的计划，我不是要他们增加工作。 我只是要求他们允许我履行他们单方面背弃的承诺。

几乎不是革命性的要求。

我的 2 美分：

我相信有两种人在讨论这个变化：

一直使用 VS 和 .NET 构建各种项目并且必须长期支持这些项目的开发人员
没有这种包袱并想要新的、干净的、花哨的、跨平台的 ASP.NET Core 框架的开发人员
就我个人而言，我属于第一类，所以我希望新的 ASP.NET Core 尽可能与其他 VS 项目类型兼容，并且转向“旧”的 csproj/msbuild 解决方案对我来说是一个胜利（+我的团队，可能还有许多其他开发人员）。 这样过渡会更加顺畅和清晰。 也许第二类人不会同意我的观点（或者他们根本不在乎）。

我现在看到的唯一主要问题是如何定义和引用 NuGet 包。 必须同时维护packages.config 和csproj 文件（正如@JulianRooze在#1433 (comment) 中已经提到的那样）是一种痛苦。 这必须重构。 理想情况下，它应该像 #1433 (comment) 中建议的@cwe1ss那样完成。 这是这个话题中最具建设性的评论之一 BTW...

至于 XML/JSON 圣战……恕我直言，XML 比 JSON 更适合手动编辑。 XML 支持注释并在您查看时具有更多上下文信息。 JSON 更适合数据，而不是配置文件。 合并对这两种格式来说是好是坏，这完全取决于内容。 如果项目引用与当前的 csproj 文件分开，合并也会变得容易得多......

我也属于第一类（开发多个项目/类型并需要长期支持它们的开发人员）。 我的雇主拥有数百万行代码的 csproj 格式项目，我们还有在 ASP.NET RC1 和 RC2 dev 分支上运行的更新产品。 公平警告，我们还将 MSBuild 与自定义 MSBuild 任务程序集等一起高级使用。

两者之间在现实世界中的集成一直很糟糕（出于多种原因），特别是考虑到诸如生成包装、包装依赖项更改时重新生成包装、源代码控制中的情况（我们内部支持并使用 Git 和 TFVC） )，项目在设计时在 VS 中的解决方案中如何相互引用，以及它们在构建/部署时如何被引入。 系统从未感觉_正确_。 我可以有两个单独的项目，每个项目都只有 .cs 文件是没有意义的，但这两种项目类型不能很好地混合在一起。

就此而言，我完全理解为什么支持迄今为止编写的应用程序和代码很重要。 我认为现在不是引入这种变化的合适时机，因为所有其他变化都在进行 - 感觉一下子发生了太多事情。

也许未来可能的解决方案是我们从其他人那里得到提示并考虑 LTS 版本或类似的东西？ 这是一个更大的对话，但随后可以引入一些诸如项目系统替换之类的功能，并让人们有时间吸收它。

另一种可能的解决方案是一个更可插拔的构建系统，但这是一个长期的解决方案，对当前的对话没有帮助。 基本上，允许任何一方/或第三方。

关于项目依赖，我们已经有大量的packages.config 文件，将它们移植到packages.json/nuget.json 没什么大不了的。 与依赖项的存储格式相比，不一致的程序集绑定重定向问题更多。

@shederman您对 MSBuild 的看法已广为人知，但您尚未明确说明的是您对 MSBuild 的实际_issue_。 这就是我感到非常沮丧的地方，我只想知道您在使用 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 个月。
当我第一次看到这个时，我以为这是一个笑话。 但遗憾的是事实并非如此。
这对社区来说是一个很大的耳光。 这样的决定在通过之前应该有很长的对话线索，而不是之后。

@laskoviymishka （和其他一些人）正如@neoKushan在这里指出的

@laskoviymishka在 RTM 之前不会发生这种变化

RTM 仍会像今天一样使用 project.json（我相信 RC2 的架构正在发生变化，但无论如何都在发生）。 向“新”csproj 的迁移计划在 RTM 之后进行，并且将逐步完成。 RTM 没有任何变化（除了 xproj 被重命名）。

@CodingGorilla这是 RC2，一个月后将转移到 1.0 版本。 在现实世界中，这意味着您停止开发一切并专注于稳定。 这种变化并不能真正稳定任何东西。

@neoKushan如果它会在 RTM 之后发生，为什么不 asc 社区呢？ 在 github 上发起讨论。 开始指出论点等。为什么要在不与开发人员进行任何对话的情况下强制进行？

恕我直言，这种从project.json到project.csproj应该在通过之前进行讨论。 现在这不是一个好的决定，至少对我来说。

@laskoviymishka来自社区站起来的笔记：（强调）

在 RC2/Preview 1 中，不会有任何变化。 在 RTM / 预览版 2 中，_唯一的变化是您将看到 xproj 文件是否会被 Visual Studio 重命名为 csproj_。 从那时起，project.json 将位于 csproj 旁边。 然后，团队将开始将功能从 project.json 迁移到 csproj 文件。 可能会保留 project.json 文件，并包含 NuGet 的所有包引用并重命名为 nuget.json。 该团队已经测试了一些工作，表明您不需要列出项目文件中的所有文件，这是 project.json 模型的主要优势之一。

因此，这主要是工具更改，并且在很短的时间内（即 RTM+），project.json 文件仍将存在，并且功能仍与现在相同。 我认为，好消息是，如果我们能够保持文明和建设性，社区仍有时间对此产生影响。

@laskoviymishka好吧，我真的不想代表微软说话，我不知道他们的最终计划是什么，但我认为他们也不知道。 很多人都说地毯已经从他们身下撤掉了，微软应该在决定之前咨询我们，但实际上什么都没有改变，几个月后也不会改变——而且当改变真的发生时，它会一个渐进的变化，希望工具或多或少会为你做。

微软，或者至少是 asp.net 团队，已经要求对此提供反馈，毫无疑问他们正在阅读这些线程，但也许我们缺少的是微软的权威公告或帖子说“如果你想讨论它，在_这里_做”。 但是，我确实认为过渡比人们想象的要早得多。 到目前为止，他们唯一知道自己正在做的事情就是将 xproj 重命名为 csproj。

我个人觉得，虽然这样做有点废话，但我确实理解他们这样做的原因。 我没有更好的答案，所以我的看法是，如果我们必须处理 csproj 风格的项目，那么我们不妨利用这段时间来展示我们所能提供的最好的 csproj。 它不会是 project.json，但如果我们能够两全其美，那么从长远来看，我们都会过得更好。 不是每个人都同意，这没关系。

@neoKushan这是个好点子，希望 MS 能看到。 很高兴看到核心团队的任何反馈。

@CodingGorilla好吧，最终版本仍然有变化，这是

@neoKushan

让我们实际讨论一下 MSBuild 的问题

我很难找到足够的信息来形成意见。 project.json 和删除 .csproj 文件_似乎_启用了很多更改。 我不希望这些改进消失，但我不知道转向“新的和改进的”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 的更改 _not_ 易于人类阅读。）

我希望看到进行此更改的人员针对他们需要考虑的场景（比如我的！），并围绕这些场景展开讨论。 我希望“嘿，我们在没有任何讨论的情况下移动你的奶酪”之类的事情不会成为 .net core 的 SOP。

该工具或多或少会为您服务

这就是主要的症结所在。 _required_ 工具越少越好。 我目前可以使用文本编辑器和命令行，而不会觉得我在逆流而上。 我希望这不会改变。 在 .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 年或更长时间里，我没有遇到一个 C# 开发人员对 MSBuild 感到兴奋或喜欢使用 MSBuild。 看看这几天Github上的一些评论。 不喜欢 MSBuild 的绝不是我一个人。 十年来，MSBuild 一直被视为 .NET 开发人员脖子上的磨盘。 这种看法在很大程度上是不公平的吗？ 是的，很有可能。

但那又怎样？ 从我作为软件工程主管的角度来看，我需要能够产生我想要的结果的工具。 我没有通过 MSBuild 得到这些结果。 我确实从 project.json + gulp.js + powershell 得到了这些结果。

_Can_ MSBuild 能给我这些结果吗？ 当然可以，但前提是开发人员在 MSBuild 中完成工作以获得这些结果。 他们只是不这样做。 当我们强迫他们时，他们会这样做，然后不维护它。

我不能依赖开发人员讨厌的工具。 这就是简单的现实。 考虑到我是多么喜欢自己不使用它，我实际上不能责怪他们。

让我们实际讨论一下 MSBuild 的问题，看看是否有一个解决方案，不涉及分叉所有内容或放弃数以万计复杂的关键业务项目。

好的，那么，有什么办法呢？

大约5年前，如果现在讨论的一些变化已经引入，我认为感觉会更好。 但事实并非如此，现在它在大量开发人员中产生了重大的负面影响。 我记得当时 MSBuild 提出了一些相同的问题，但被拒绝了。 就像当前的问题被提出和拒绝一样。

我不知道它是如何恢复的，我真的不知道。 我认为必须有一些重大的干净休息。 你如何在不破坏那里的东西的情况下制作它们？ 太少了，太晚了。 所以我看不到 MSBuild 的前进道路，不适合我，不适合为我工作的开发人员，不适合我的合作伙伴，或为_them_ 工作的团队，不适合我们咨询的客户。 这些受众都不想使用 MSBuild，他们在工具中使用它，因为他们必须这样做，并且他们反复发誓。 诚然，通常在合并时间附近。

所以_现在_你想让合并更好吗？ 10 年过去了。 后工具在很多方面都是脏话？

从根本上说，您使用的是 90 年代后期专为 Build Masters 设计的工具，该工具实际上在 2010 年之后被开发人员使用。一种使用推理的工具，其逻辑被用于命令式工作的开发人员使用，以及命令式工具。 一种使用非常灵活但不明显的设置属性方式的工具，开发人员认为属性集是一个简单的赋值运算符，并且不明白为什么您甚至想要执行PropertyGroup并且不这样做不想知道。

这就是我想要的讨论。

当然，我明白了。 不过我想要的讨论是不同的，它是“给我们你承诺给我们的东西，或者让我们给自己，因为我们不喜欢你的旧想法，我们喜欢承诺的东西”。

我可以分享一些悲伤的事情吗？ 在我的商业伙伴中，他们拥有与我相似的经验（更实际），我是当时最支持 MSBuild 的人。 我实际上_使用_它。 我学会了。 我建造了大管道。 但那是 5 年前的事了，从那时起，桥下已经流了很多水。

伙计，我发现自己在阅读@shederman的评论和历史时

想想：Visual Studio 扩展 (.vsix)。 没有人想接触这些，因为它们与当今其他所有事物相比有多么传统/古老/不同。 嗯，您有一些开发人员想要，因为他们在学习其神秘系统方面付出了应有的代价——就像 MSBuild 一样。

我也可能是我认识的任何曾经处理过 MSBuild 的专业人士中最有经验的。 大多数开发人员不想花时间学习它（因为你肯定会这样做）。 它几乎就像是它自己的语言一样。

如果它“更像 .NET”（并且与 VS 有更好的集成），那么我想我们都会同意它将是一个更好的产品，并且是值得考虑的有吸引力的提议。

@Mike-EEE & @shederman 就Mike 的观点而言，它是陈旧的、过时的并且“与任何其他 (.NET) 开发人员必须使用的东西不同……”。 但它是无法修复的吗？ 他们承认存在他们想要修复的问题，所以问题是：它可以修复吗？ 我想我知道@shederman 的回应，我什至大部分同意他的推理（我同意构建和项目系统是一个奇怪的混合问题的主题）。

再说一次，我在这场比赛中没有马，我不介意他们选择走哪条路。 我真的很喜欢得到竖起大拇指的反应并听到自己说话（在谈话中带有实际的智力兴趣：笑：）

我真的很喜欢得到竖起大拇指的反应并听到自己说话（在谈话中带有实际的智力兴趣：笑：）

乐于帮助！ ：微笑：

但它是无法修复的吗？ 可以修复吗？

取决于你问谁，真的。 正如@shederman 所暗示的那样，在他们的 repo 上提出问题一直是困难和具有挑战性的（是的，我在那里审查了我的话：stuck_out_tongue:）。 似乎他们已经按照自己的方式设定了。 但是，正如您所知道的软件的性质，只要有足够的时间和精力，一切皆有可能。 ：眨眼：

@PhilipRieck你问了一些非常好的问题！ 不幸的是，我没有对所有这些问题都有明确的答案，但让我们看看：

目前，我们对每个构建任务都使用 gulp。 那会改变吗？ 我的 gulpfile 只是执行到 dnu 或 dotnet-cli 以实际将 .cs 文件集合转换为程序集。 我可以保留它，对吗？

我不_认为_这会改变，我有 95% 的信心我们在这里谈论的内容只会影响项目 _definition_，而不是项目的实际构建方式（至少超出了调用 dotnet build 的范围）。 dotnet CLI 可能会在某个时候调用 MSbuild，但到那时它是一种底层的东西。

msbuild 是单独安装的吗？ 它是否会与 dotnet cli 或运行时分开进行版本控制？ 这如何改变我的 CI 构建服务器上需要可用的最小值？ 在开发环境中安装的最低要求？

我对此的明确答案为零，但我会_想象_MSBuild 作为 dotnet CLI 的一部分作为完全独立的安装出现，即使您已经安装了 MSBuild（例如使用 VS）。 纯属我的猜测。 我知道整个“.net 无处不在”项目的一个巨大目标是尽量减少人们的发展。 字面上应该是 apt-get dotnet-cli（或其他）、dotnet new、dotnet build。 您永远不必调用 MSBuild 来构建项目，这是 dotnet-cli 的工作。

如果我使用文本编辑器添加 nuget 依赖项或 .cs 文件，我现在必须添加哪些额外步骤（如果有）？

对于 .cs 文件，绝对没有别的，就像今天一样 - 他们非常清楚的一件事是，在您的项目中指定每个 .cs 文件的日子已经过去了（尽管如果您愿意，您仍然可以这样做，看着你@Mike-EEE）。 至于依赖项，当然在短期内（短期是几个月），它们将保留在 project.json 中并完全像以前一样工作。 project.json 有可能变成 nuget.json，因此除了名称更改之外，没有其他任何更改，但是还有其他可能性，这似乎是 Microsoft 非常不确定的主要事情之一 - 让您的声音听取您对此的偏好。
（我个人的偏好是能够做类似的事情.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 用户混合是一场噩梦。

我完全同意这一点，但微软在他们的跨平台工作上投入了太多资金，以至于突然间变成了一场噩梦。 通过“工具”，我怀疑这将归结为 .net CLI 而不是 VS 或类似的东西。 不要忘记，.net 核心的终极“终极目标”是成为一个非常敏捷、发展非常迅速的平台，但又不会迫使您每隔几周就必须花时间升级。 我_非常确定_如果你在 6 月份编写一个 dotnet 1.0 应用程序，它仍然会在几年后构建和运行，但是当你准备好时，更新的版本将是运行“dotnet upgrade”或类似的东西. 即使当 RTM 命中时，RC2 项目仍将构建和运行 RC2 位，直到您实际进入并将目标更改为 RTM（我认为在 global.json 或某处？）。

:laughing: 当我读到这样的帖子时，我不得不怀疑微软是否有后悔的时刻。 我真的很尊重那些已经并且正在尽最大努力彻底改变 Microsoft 的人，他们的目标是为开发人员打造一个透明、开源、具有社区意识的避风港。 这种转变背后的人确实关心。 他们是好人。 他们现在必须在岩石和坚硬的地方之间； 不那么有建设性的社区情绪（在娱乐我的同时）对他们的案子没有帮助。

我想指出的是，将 IDE 中当前存在的一堆魔术项目创建功能替换为执行大量魔术 csproj 操作的命令行应用程序是一个坏主意。 使项目定义文件尽可能简单是必须的。 project.json 最好的部分是我可以阅读和理解它。

@shederman你对 MSBuild 的问题是，在一个庞大而复杂的系统中，它既庞大又复杂......

我也与 Team Builds 合作过，我也非常讨厌它（Ping @Mike-EEE，因为我们都谈到过这种体验有多糟糕），我明白了，但你所描述的完全不同设想。 MSbuild _可以_大而复杂，默认情况下VS _使_变得大而复杂-但这就是变化。

较新的 csproj 文件应该小得多，这意味着“调试”应该大大简化。 没有（或很少）杂物。 你仍然可以使用任何你想要的 _build system_，你可以调用一个只在 *.csproj 上调用“dotnet build”的 .bat 文件，你会得到你想要的输出，就像今天一样。 让 dotnet cli 处理 MSbuild，您甚至不必接触它。

@neoKushan不，谢谢。

我想要承诺的东西，而不是在我们被告知要远离的东西上涂上口红。

如果你不想给我们承诺的东西，就让我们给自己吧。 这一切都已经存在了。 这应该只是保留重构的一种情况。 正如我之前所说的，我会做这项工作。

我怀疑没有胃口留下它的第一个原因是意识到这将是从 MSBuild 项目大规模迁移的开始。 抱歉，在生命支持方面保留过时的技术并不是.NET Core 的设计目标之一。 是吗？

ms build 的最大问题由谁来修复，以及需要多少时间。 现在整个 ASPnet 项目有 1000 多个未解决的问题，其中一些非常关键。 看看 SignalR。
距离发布还有一个月的时间，这个 bug 真的很接近最终状态。

现在他们说 ms build 可以改进。 MS 是否有足够的资源来管理所有这些遗留问题💩？ 社区能解决吗？ 我不太相信。

@谢尔曼

如果你不想给我们承诺的东西，就让我们给自己吧。

他们不会阻止你做任何事情。 继续分叉吧，没有什么能阻止你。 如果您正在等待 Microsoft 的许可，那么您已经获得了，当他们开源代码时您就获得了。

这一切都已经存在了。 这应该只是保留重构的一种情况。 正如我之前所说的，我会做这项工作。

然后去做？ 再一次，没有什么能阻止你。

我怀疑没有胃口留下它的第一个原因是意识到这将是从 MSBuild 项目大规模迁移的开始。

他们为什么会在意？ 如果您使用 MSbuild 或其他东西，这对 Microsoft 有什么影响？

真正的第一个原因是 ASp.net core 的项目结构只对 asp.net core 非常有用。 还有数百种其他项目类型不适合 project.json。 不用介意 project.json 有它自己的问题，我们显然都忘记了这一事实 - 缺乏评论是我最讨厌的（不，建议一些其他格式，只要它不是 - XML 没有帮助）。

抱歉，在生命支持方面保留过时的技术并不是 .NET Core 的设计目标之一。 是吗？

不，但帮助人们将旧的、现有的项目移植到 .net 核心是一个目标。 此外，我们谈论的是 MSBuild 的 .net 核心版本，而不是成熟的桌面版本，这是有区别的。

你唯一的问题是他们敢称它为 MSBuild。 如果他们想出了一种新的项目风格，碰巧是 XML 但被称为“CoreBuild”或其他什么，你就不会更聪明了，你所要做的就是“我讨厌 XML！”。

你在等待微软的许可，那么你已经得到了

不完全正确。 我不想分叉它，我想在主仓库中维护它。 有区别。 所以没有人需要下载一个全新的 .NET SDK。 我希望在工具中使用它，为此，是的，我确实需要他们的默许。

你唯一的问题是他们敢称它为 MSBuild

不，他们想_使用_ MSBuild。 细微但重要的区别。 将新的 project.json 构建系统重命名为 MSBuild，我会愉快地使用它。

你不会更聪明，你所要做的就是“我讨厌 XML！”

也许😄

反正就是兜兜转转。

要睡觉了。

我说留给站会吧。 没有人说服任何人。 我很确定我了解支持 MSBuild 的一面，但我不同意。 我很确定支持 MSBuild 的一方理解非支持 MSBuild 的一方，但不同意。

我只想说我们可以两者兼得。 MS 团队没有（或很少）额外的努力。 然后让选项在实际生产使用的眩光中下沉或游泳。

根据@neoKushan的问题：

还剩什么？

如果可以的话，我实际上想围绕我上面概述的“信条”来构建我的回应，我认为这是一个好的、可用的项目文件：

• 它应该是人类可编辑/可读的

将@neoKushan的上述声明

我假设摆脱 Guid ProjectType 是要解决的首要问题之一？

但我支持我上面的附录：对于简单的项目（例如 Angular 中的 ASP.Net Hello World），我可以在记事本中手动创建它的全部内容，这是一个硬性（不可协商的）要求。 如果我需要使用 Yeoman/VS/similar，我们未能提出一个人工可编辑的项目文件。

• 它应该允许评论

已经在 MSBuild 中工作

• 它应该是声明式的

改变 First-Level 的顺序（直接子级) 可以改变项目的整个含义，通常以难以调试的方式。 没有什么比将 .targets 导入意外带到顶部更值得注意的了。

• 应该是独立的

这是我使用 MSBuild 时遇到的最大问题。 静态地读取文件并不能为您提供足够的信息来实际了解那里发生了什么。 从来自 _environment variable_ 指定路径的 .targets 文件，以及环境变量支持事件的事实，到条件和导入，您一起获得了有效的图灵完备环境，但代价是非常高的复杂性，以及较差的工具能力。 我认为 VS 对 MSBuild 的糟糕集成是围绕此类构建工具困难的结果。

这类似于人类可读性/可编辑性问题。

• 如果可能，它应该旨在减少合并冲突/简化合并

MSBuild 在技术上以通配符的形式支持这一点。 VS 对通配符的支持比糟糕透了。 它积极地使工作变得更加困难。 如上所述，我愿意接受这将被修复 - 但它需要是 _proposal_ 到 _migrate_ 的一个项目（并且它是迁移到，因为到目前为止所有的消息传递都是关于 project.json）到 MSBuild - 基于项目文件。

• 它应该是完全可记录的（自包含原则适用于文档）

我相信 MSBuild 有文档。 该文档，特别是对于 MSBuild 的 VS _flavor_ 而言，还有很多不足之处。 我经常感到困惑，为什么不同的东西在它们所在的组中，VS“帮助”移动它们并不是很有帮助。

一个完美的例子是 Bond NuGet 包。 有多少人知道，如果磁盘上没有 BondInclude 文件夹（如果它在 csproj 中被引用），则构建将神秘地无法在生成的程序集中实际生成任何 Bond 类型？ （也没有错误喷出）。 然后创建一个具有该名称的空文件夹并重新加载项目修复它。

（是的，我知道，我要提交一个错误）

• 它应该独立于工具

假设我不想与 MSBuild 有任何关系（假设是因为我感觉逆势而上，没有进一步深入研究）； 我只想定义我的项目，并通过 nugget 拉入包。 为什么我被迫使用这个特定的构建系统？ 特别是如果我只想定义一个项目？

构建定义文件不是项目文件格式。 VS 设法让它工作（在某种程度上）并不是继续使用它的好理由。 我想要一个仅代表项目本身的真实文件，以及有关它生成的工件的信息（而不是如何构建它的说明）。 在这种情况下，即使 project.json 也失败了，因为它允许我们定义“命令”。 为什么会存在这些？ 只需定义输出的类型以及在哪里可以找到它。

我阅读了整篇文章，在project.json与project.csproj讨论中让我印象深刻的一件事是，只有其中一个文件名包含了完整的编程语言。 我更喜欢在 F# 中进行 ASP.NET 开发。 这在 ASP.NET Core 中甚至可能吗？ 在这一点上，我没有最微弱的想法，但我觉得它不是。 我什至不确定人们是否使用csproj作为csproj, fsproj, vbproj的简写，或者他们是否真的只表示csproj 。

更新：F# 人员正在研究 CoreCLR 支持，但还没有真正的 ETA。 我的观点是，现在决定的任何项目系统都会影响目前似乎还没有引起人们注意的编程语言。 尽管我更喜欢 JSON 而不是 XML，但如果 project.json 要将我锁定在 C#（编译中的文件顺序在 F# 中至关重要），那么我不赞成。

现在，对我来说，它似乎又回到了 FAKE 和 Paket ......

我从一开始就在使用 .NET，而且我从来没有遇到过任何值得注意的 MSBuild 问题。 这样做的主要原因是，除了开箱即用的解决方案编译之外，我从未将它用于其他任何用途。

这就是我不喜欢 MSBuild 的原因。 除了解决方案编译之外，没有人强迫任何人使用 MSBuild。 而且我认为，能够编译解决方案是一个非常有用的功能 - 顺便说一句，“ dotnet cli”中甚至不存在该功能（您现在必须手动遍历项目 - 如果我错了，请纠正我）。

您的实际构建系统不需要更改。 如果您正在使用 Nant，请继续使用 Nant。 如果您正在使用 psake，请继续使用 psake。 如果您使用的是 powershell 脚本，请继续使用它。 等等！ 最有可能的是，只有“dotnet build”部分必须替换为对 MSBuild 的调用。 （如果 dotnet build 调用 MSBuild，甚至可能不需要）

我认为这使得 MSBuild 成为一个非常不重​​要的实现细节。 这就是我在过去十年中的看法，而且我将继续如此看待它。

但是当然，正如我在本主题开头所说的那样，我们绝对需要的是 project.json 和 Visual Studio 的一些 _features_ 来更好地对待 csproj - 我不明白他们为什么不这样做能够交付。

@jtmueller绝对没有 _technical_ 原因为什么您不应该使用 F#（或者 VB.net，如果您愿意的话）。 如果转移到 MSBuild 项目文件的一部分是为了帮助促进这一点，我不会感到惊讶。 DNX 从未真正对它感到满意，但 CoreCLR 绝对支持 F#。 我不知道您是否能够使用 F# come RTM，但它肯定在筹备中。

@jtmueller project.json 几乎是一个带有依赖项清单和自定义命令的项目定义。 根本没有任何与特定语言相关的东西。

我梦想的构建系统（完全取代 MSBuild）将使用 Roslyn 来确定任务和目标，允许您使用 F# 来定义您的构建过程（或 C# 或 VB.NET，任何 Roslyn 支持的东西）。

当然，目前还没有人提出这个建议。 但是将我们锁回 MSBuild 几乎肯定会在很长一段时间内关闭这扇门。

好好休息，虽然有点关于“保存”MSBuild 需要做些什么的挑战。 我不相信我们可以也不应该将 MSBuild 变成一个完全不同的构建系统。 它是一个基于推理的、XML 定义的构建系统，适用于它，以及相当多的人的场景，尤其是一些更复杂的场景。

但并非所有人都有专门的 Build Masters 可以与 MSBuild 争吵。 并非所有人都需要 MSBuild 的复杂性带来的强大功能。 一些确实需要这种复杂性的人不想使用 MSBuild。 例如，在我的一个团队中，所有自定义构建逻辑都是在构建前和构建后步骤中完成的，Exec 本质上是对 Powershell 进行脱壳。 不是因为它不能在 MSBuild 中完成，它可以，在这种情况下可能_应该_。 但是因为他们不想在 MSBuild 中这样做。

第一步肯定是我们需要将项目定义从构建系统中分离出来。 对我来说，这是非常有意义的。 我们可以讨论从项目定义中分离依赖项，但我认为这不是必需的。

第二步是我们确实需要一个构建系统。 我们需要处理非常简单的用例，以及高度复杂的用例。 但是没有规则说一个构建系统必须处理_both_。 在我看来，最有意义的是拥有一个简单、轻量级的构建系统，它基本上只构建项目定义。 它执行restore 、 build 、 test和pack 。

我认为我们还应该寻找一种方法，使其能够在_没有_项目定义的情况下工作，使用目录结构作为定义。 显然，这种情况意味着它会使用默认框架和默认依赖项。 也许可能，也许不是。 但是我们可以查看定义中的每个元素并问“我们可以为此推断出一个智能默认值吗”？

但这对于 80% 的用例来说可能已经足够了，但对于其他 20% 的用例来说还不够。 他们需要更多的东西。 （警告：关于用例比例的意见可能会有所不同）。

第三步是我们允许对构建系统进行非常简单的可扩展性形式。 但是我们说的很简单。 基本上，它可以运行它的基本构建，也可以运行外部构建系统。 所述外部构建系统可以是MSBuild，或脚本，或其他一些构建系统。

我很高兴新的构建过程应该能够支持 MSBuild，但我不相信像（IMO）那样陈旧、脾气暴躁和臃肿的东西应该成为未来所有构建的基础。

对于 Web 框架之类的东西，我们看到 MS 团队疯狂地迭代。 因为他们有竞争。 例如，他们不得不担心南希会压低他们的脖子呼吸。 _容易_切换到别的东西。 它使 MVC/WebAPI 变得更好。

随着 MSBuild 融入整个 .NET 工具，使用其他工具变得很痛苦。 竞争在哪里？ 你可以在 MSBuild Github 板中看到它的效果。 只需查看所有已关闭的提案即可。 他们现在谈论进行这些“瘦身”更改的唯一原因是因为他们希望人们从 project.json 迁移到 MSBuild。

如果 MSBuild 从一开始就融入到 .NET Core 中，我相信我们会_none__从 MSBuild 团队看到我们现在看到的运动。 但是一旦我们被重新锁定会发生什么？ 一旦竞争基本排除？ 会发生什么？ 在没有竞争的情况下总是发生的事情，以及迄今为止多年来发生的事情：仅仅足以阻止大规模叛逃的改进，但没有什么特别有趣的。

人们问我如何“保存”MSBuild。 我相信向真正的竞争和选择开放是唯一的途径。 对所有开发人员强制执行它，即使是那些几乎不需要任何强大功能的开发人员（是的，我确实相信它很强大），只会滋生更多的怨恨。

这不是任何框架成功的秘诀。

请大家记住，我们都希望 .NET 取得成功。 我_爱_ .NET，我认为 C# 是目前最好的编程语言之一，并且很享受它向 Scala 的缓慢过渡 - The Good Parts™ 😉。
我不相信我们会从 .NET Core 重新开始，而是通过将自己束缚在（IMO）旧式 .NET 中最糟糕的部分之一来实现。 是的，MSBuild，但不，不受它的束缚。

一定要保留它，但不要将前端和中心内置到系统的核心中。

我梦想的构建系统（完全取代 MSBuild）将使用 Roslyn 来确定任务和目标，允许您使用 F# 来定义您的构建过程（或 C# 或 VB.NET，任何 Roslyn 支持的东西）。

啊啊啊啊啊啊！！！ 说起来……这是进行这种对话的合适场所吗？ 我们也有 Roslyn 和 MSBuild 存储库，他们似乎也应该参与其中。 我想我们正在 MSBuild 存储库中进行尝试，但它们（正如您提到的）非常僵化和不灵活。 我认为这里有更多的人喜欢这个线程产生的兴趣可能会对改革大有帮助。

第三步是我们允许对构建系统进行非常简单的可扩展性形式。

基于提供者的构建系统/模型？！ 天才！ 我同意这条消息。

顺便说一句，如果您如愿以偿并且可以访问自己的构建系统，我建议我们将其称为... BERSERKER BUILD！ 以“Berzerker @shederman”命名……我给你的新昵称。 ：微笑：

@Mike-EEE 不要太兴奋。 我绝不是提出任何像_yet_一样激烈的事情。

现在我认为它应该只是第 1 步和第 2 步，MSBuild 支持第 3 步。

但是这种可能性就是我认为我们在获得 project.json 时正在朝着的方向发展，将项目与构建分开，以便更容易更换构建提供程序。 在我看来，将 MSBuild 带回根目录会关闭这些可能性。 或者至少使他们不太可能获得牵引力。

现在自定义构建还没有被采用，因为根系统 _is_ 如此强大。 当 MS 构建系统实际上可以完成所需的一切（忽略痛苦）时，说服人们您想要使用非 MS 构建系统是一个艰难的对话。

这是进行这次谈话的合适场所吗

我不这么认为，不。 另外，不要认为现在是正确的时间。 在看到可能的方向之前，我们需要关闭这个问题。

狂战士打造！ 以“Berzerker @shederman”命名……我给你的新昵称。 ：微笑：

不知道是什么感觉😉

不试图成为一个狂战士。 当我们_是_向前移动时，我只是不想向后移动。

嘿伙计们，也许不是重新发明轮子（ nuget.json或任何名称），让我们使用现有的、社区驱动的解决方案来解决大多数依赖项管理问题 - Paket 。

1. 它有传递依赖的概念
2. 它与 MsBuild 集成良好
3. 它具有用于定义依赖项的人类可读文件格式
4. 它有很好的从packages.config迁移的路径
5. 还有许多其他功能（但显然这 4 个对每个人来说都是最重要的，所以我不会提到 Git 依赖项或更好的包解析策略之类的东西）

@Krzysztof-Cieslak 记得，微软推动 MSbuild 项目定义的最大原因是帮助那些在 MSBuild 上投入大量资金的人更容易迁移。 在这方面，Paket 并不比 project.json（或 project.yaml 或 project.cs 或其他什么）好。

话虽如此，我仍然没有看到您不能使用任何您想要的构建系统的任何理由。 最终，“dotnet build”不会改变，不管你的项目定义最终是什么格式，dotnet build 仍然会生成你的输出。

@neoKushan是的，但即使我们不使用 MSBuild，“dotnet build”是否需要 MSBuild 文件？ 如果根本没有 MSBuild 文件，它会构建吗？ 或者它会转入 MSBuild，然后转入任何其他使用的构建系统？

@shederman毫无疑问，“dotnet build”将在后台使用 MSBuild 来实际构建项目，但我们是否真的看到其中的任何一个都

正如我所说，只要我被允许做这项工作，就可以将轻量级构建保持到位，根本不需要任何MSBuild，我就很高兴。 你们可以在任何你想要的死胡同下建立你的自引用“MSBuild无处不在”管道。

但是，如果这行得通，那么 csproj 将需要像 RichiCoder建议的那样包含 project.json 。

这样“核心构建”和“MSBuild”可以并行工作，或者核心构建可以在没有 MSBuild 的情况下工作。 而且，显然，如果您不导入 project.json，您也可以在 csproj 中定义您的项目属性。

其实很容易改变。 在我的脑海里，我们需要：

• 保留现有的 dotnet-build 代码并让它在某些（待定）情况下运行。
• 根据 DotNet 核心团队的计划，在其他情况下运行 MSBuild
• 让 VS 能够读取 project.json 或 MSBuild 的项目属性
• 添加将 project.json 导入到 MSBuild 的功能

相当小的工作量，它允许 Microsoft 继续其“永远 MSBuild”的道路，它信守对 .NET Core 社区的承诺，它允许我们这些想要选择退出 MSBuild 的人这样做。

值得注意的是，asp.net 成员中没有人在这里说过任何话。

同时，我重新阅读了 ASP.NET Community Standup – May 10, 2016 中的一些

@rhires根据我的理解，“新”MSBuild 系统进行了一些调整，使 XML 更轻一些，例如将所有 cs 文件包含到构建中，并将依赖项卸载到 nuget.json 文件。 MSBuild 设计、体系结构或用法没有重大变化。

我喜欢你的 project.json 想法。 刚刚经历了 RC2 的变化，他们输入了“testrunner”，所以没有理由做不到。 _BUT_，看起来他们的心完全放在了完全删除 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 。

如果 .Net Core 仍计划使用project.json我们就不会进行 100 篇帖子讨论。 ;) 我要说的是，在许多地方建议使用“nuget.json”来处理依赖项的解决方案是重新发明轮子，因为我们有完全相同的产品。

@谢尔曼

“最终调查结果：100 条回复，对于 900 万 .NET 开发人员群体，在 95% 的置信度下为 ±10%。”

是的，在会议上询问猫玩具哪个是狗或猫的首选宠物，可能会给您类似的结果。

@达雷米勒

“我认为区分 MSBuild 和 Visual Studio 当前使用 MSBuild 的方式很重要。我多年来一直手工编辑 MSBuild 文件并将它们用于我的所有项目。例如https://github.com/tavis-软件/Tavis.home/blob/master/build/Build.proj ”

我们是否应该在 msbuild 无法从命令行运行的项目文件之上讨论 VS 特定的构建文件？

@gregoryyoung我们应该。 我之前已经完成了依赖 devenv 的构建文件，但还没有看到不能从命令行运行的文件。 有什么例子吗？

@gregoryyoung

是的，在会议上询问猫玩具哪个是狗或猫的首选宠物，可能会给您类似的结果。

这是一个有趣的比喻。 除了...

我在 Twitter 上发布了_支持_迁移到 MSBuild 的人的链接。 所以，其实一点也不像你的比喻。

而且我喜欢继续诽谤调查有偏见，在错误的论坛中，或不科学。 但是，这些问题并没有引导性，答案的回答范围很广，而且调查，是的，是自我选择的受众，但广泛的受众，至少在理论上，应该_远离_我的观点。

我也有印象，并且在某些情况下证实，提出这些指控的人只是在谷歌上搜索了一些调查。 我个人为健康研究设计了一个硕士水平的研究协议，虽然我不会声称调查是完美的，但它肯定没有微软员工所说的那么有缺陷。

它肯定_是_具有统计显着性，并且可以很好地表明意见所在。 GitHub、gitter、Twitter 和博客都在某种程度上支持它。

多个证据来源都在说同样的事情。 如果您想忽略重要用户的意见，请说出来。 不要试图挥舞他们的反对意见，好像如果你持有“错误”的意见，你就失去了发表意见的权利。

或者更好的是，正如我多次说过的那样，创建您自己的调查，以改善您认为我的错误的地方。

我做这个调查的原因是很明显微软不知道人们在想什么。 现在变得完全清楚的是，他们对人们的想法没有_兴趣_。

停止对自己和社区不诚实，并与反对派接触，而不是挥之不去。

不要试图改变事实，而是开始根据事实改变你的想法。

@shederman我不认为微软团队真的回答了这个

我认为我们可以给这个团队一些荣誉;)。

@gregoryyoung抱歉，根据您提供的类比，我假设您是 MS 员工，因为他们已经 2 天一直在小跑相同的近似路线。

@sandorfr

我想我们可以给这支球队一些荣誉

我以为我们可以，但我过去几天的经历并没有加强这种希望。

我不得不认为这不是“团队”的错，而是组织中更高层的某个人做出了这个决定并将其强加于人......然后“团队”必须吸收它并使其看起来很漂亮。 BTDT。 不好玩。

你们都意识到 project.json 最近已经发生了很大的变化，以使其与非 ASP.NET Core 应用程序更加兼容吗？ 如果你只看那个公告帖子中的例子，它已经因为所有的构建配置变得非常臃肿。

从那个到“经典”csproj 文件实际上对我来说似乎并没有那么远。 如果 csproj 本身也朝着我们从 project.json 中学到的更灵活的方向发展了一点，我实际上可以看到“新的和改进的”csproj 工作得非常好。 我认为我们可以有把握地假设，最近对 project.json 所做的那些更改不会是课程中使其可用于 _all_ 类型的 .NET 项目的最后更改——我认为重要的是我们不要忘记那里除了 ASP.NET（核心）之外，还有许多其他目标。

实际上，文件格式是 JSON、XML 还是其他格式并不重要。 是的，出于各种正当理由，一个人可能比另一个人更受欢迎，但最后您应该考虑您实际上想要在项目文件中花费多少时间。 是的，由于我们在当前格式上遇到的问题，我们花费的时间比我们想要的要多，但理想情况下，假设我们修复了这些原因，我们应该在这些文件上花费极少的时间。 那个时候，你真的不需要关心它是什么格式。特别是如果它最终都是工具辅助的（包括在编辑器中完全完成）。

我觉得当人们想到 project.json 时，他们主要想到的是早期阶段，很多是关于约定而不是配置。 是的，这非常好，但也非常特定于 ASP.NET Core，因此非常有限。 它不会真正适用于其他目标，因此使用已经运行多年的东西并对其进行扩展并在保持兼容性的同时以各种可能的方式对其进行改进是有意义的。

所以，tl;dr：是的，我真的很喜欢 project.json 并希望有一种方法可以为 ASP.NET Core 保留它（例如使用特殊的 MSBuild 任务）。 但与此同时，我完全理解为什么现在会发生这种情况，我认为他们所做的实际上并不是一件坏事。 当然时间有点奇怪，但考虑到变化不会与 ASP.NET Core 和 .NET Core 发布并行发生，我认为时间不是一个实际问题（假设以后过渡会顺利）。

需要能够跨项目共享源文件

@darrelmiller这对我来说听起来很可怕，因为这似乎意味着 .csproj 中的列表文件又回来了。

@lokitoth假设 csproj 对文件引用的工作方式与较新的 project.json 类似，则没有什么可以阻止您一般使用 globs 并将单独的文件引用与它们一起使用。

@shederman我不是 MS 员工，只是一个理性的人。 如果你用谷歌搜索我，我相信你会发现我对这个平台有长期的兴趣。

与更改相关的优点/缺点有很多，但是您提供的内容对任何理智的讨论都没有用。

这是一个令人失望的变化。 project.json、自动文件包含/globbing 和传递还原是有关 ASP.NET Core 的第一件事，让我“哦，太好了！” 一开始。

我意识到并非所有这些都会消失（我希望？）。 但是回到 XML 项目文件感觉很糟糕，因为从历史上看，这对人类来说意味着头疼。 我讨厌打开一个 csproj 文件来解决问题，因为它是一堵难以解析的文本墙。

只有我的两分钱。

看看@poke帖子中的变化，看起来他们基本上将 csproj 翻译成 json，老实说这也很糟糕。

基于他们想要支持 Compile、Embed、CopyToOutput、Exclude、Shared Files 等选项的事实，那么实际上 json 格式无论如何都不会比 XML 更好地工作。 我还怀疑 json 对于繁重的构建脚本自定义不会起作用。

我只希望这是团队尽量不要在生产中添加另一个半成品解决方案，直到他们有时间找出一种很好的方法。

@gregoryyoung您提供的内容对任何理智的讨论都没有用

伟大的。 好的，让我们看看，我提供了什么：

• 我和其他很多人一样抱怨转向 XML
• 我和很多其他人抱怨过迁移到 MSBuild
• 我试图了解该决定背后的原因和证据，除了一些非常手动的东西之外，并没有真正提供
• 我试图了解决定背后的潜在_思考_，而_也_并未真正提供
• 我已经询问了社区的意见，MS 根本没有费心去做
• 我试图提出替代方案，允许人们给出理由陈述的结果，但也允许社区保持他们喜欢的简单构建过程
• 我已提出做所需的工作以支持上述替代方案

出于兴趣，我可以问一下，疯狂的部分是什么？ 这年头审问别人的想法不理智？ 还是我在那里留下了什么？

我的意思是，我很生气，别误会我的意思。 我已经浪费了大量的工作、时间和金钱来围绕框架的核心承诺进行建设，该承诺在最后一刻被撤回，这似乎是一个草率且经过深思熟虑的举动。 我没有_权利_生气吗？

附注。 啊，你就是_那个_格雷格·杨。 尊重。 喜欢你的工作。 我真的。

@bzbetty我完全同意你的看法。 我最不希望看到的是将 MSBuild 重新构想到 project.json 中。 当前形式的 MSBuild 的最大问题之一是它将 _project definition_ 与 _build process_ 混为一谈。

因此，将构建过程添加到 project.json 将犯与 MSBuild/VS 完全相同的错误。

项目定义应该与构建过程分开，并被输入到构建过程中。

然后有人不得不问：如果你的项目很简单，只需要直接构建项目定义，你真的需要一个重量级的、可扩展的、可定制的、灵活的、反直觉的构建系统来做一个简单的构建吗？

换一种说法。 如果您_拥有_这样一个简单的项目定义，以及一个非常简单的构建工具，只能构建项目定义，那么您会选择安装和使用 MSBuild 或 NAnt 之类的吗？

不，可能不是，对吧？ 我的意思是为什么不必要地增加复杂性。 有效的软件工程实践的一个核心部分是让事情变得简单。

但是，一旦遇到简单的“构建定义”工具无法处理的情况？ 当然，_然后_你会的。

我的意思是，将这两种工具并排安装，这样我们就可以选择最适合我们需要的一种。 MS 说：不，您只需要复杂且违反直觉的工具，但我们将删除最糟糕的功能。

肥皂盒

我只想分享我一直在做的一些研究。 我一直在关注 Twitter、Slack、Github、Gitter 和 Jabbr。

我看到很少有人支持核心团队之外的举动。 我的意思是，有一些，但不多。 大多数人对这一举动感到非常不安。

我也对支持 MSBuild 阵营的许多人倾向于推断他们的对手被误导，或者更常见的是不合格的倾向感到非常沮丧。 这与 pro-project.json 阵营中推断不良动机的倾向相匹配（包括我自己，mea culpa）。

我想问以下问题：

• 人们假设持有不同意见的人有充分的理由支持他们。 他们没有受骗、无能、同谋或疯狂
• 人们攻击论点和证据而不是人
• 提供的任何证据都不应在没有确凿理由的情况下立即被驳回

的论据
我认为迁移到 MSBuild 的主要原因是：

• 工具支持 - 允许不同工具之间的往返，例如 VS、VSCode、Xamarin 等。
• 现有投资 - 大客户拥有无法丢弃的现有构建
• “肌肉记忆”——人们习惯了 MSBuild

反对的论点

• 现有投资 - 对 .NET Core 工具的投资：RC 后。 RC _should_ 意味着没有重大的突破性变化
• CSProj/MSBuild 讨厌 - 过去处理 csproj 和 MSBuild 的负面经验
• 倒退 - 转向 project.json 是转向一种新的工作方式，部分原因是为了吸引新一代的开发人员。 这正在撤消

观点
我已经支付了完整的 SurveyMonkey 订阅费用，因此我可以访问完整的结果集（而不是第 100 个）。 这是 321 个响应，这通常会转化为 ± 5.5% 的误差幅度，900 万人口的置信度为 95%。

我听到的反对这项调查的常见论点是：

• 问题/答案是有偏见的：我不相信，即使是，也不是很多。 存在范围广泛的答案。
• 该调查发布给有偏见的受众：Twitter？ 给各个团队成员时间线的追随者。 不知道这是一个有偏见的观众。
• 与科学无关：好的，让我了解这个。 我没有做完整的研究协议，所以它不会通过同行评审。 这是衡量对提案的支持所需的确定性水平吗？

他们来了：

我对任何喜欢 .NET 框架的人的呼吁是不要低估对这些变化的焦虑程度，并在他们的担忧是有效的并且来自知情的经验的基础上接受反馈并与社区进行互动.

如果决定无论如何都要继续下去，那么应该提供一套比目前更好的推理和证据。

当 Silverlight 吃它时， @shederman使我想起了我（和许多其他人），除了 x10 和更专注/更有经验。 这可能是我支持他的原因:100:%！ 哈哈。

当前形式的 MSBuild 的最大问题之一是它将项目定义与构建过程混为一谈。

因此，将构建过程添加到 project.json 将犯与 MSBuild/VS 完全相同的错误。

项目定义应该与构建过程分开，并被输入到构建过程中。

:+1: :+1: :+1: ... 解决问题的好方法！！！ 你知道，我已经对此深恶痛绝，以至于我从来没有真正想到过。 但是您（再次）100% 准确。

我讨厌打开一个 csproj 文件来解决问题，因为它是一堵难以解析的文本墙。

这需要在某处进行框定，@nbarbettini！ 也完美地抓住了我的情绪。

实际上，文件格式是 JSON、XML 还是其他格式并不重要。

是的，我不想试图提醒人们这一点，但似乎有些开发人员坚持格式的概念，这是一种误导。 “JSON”项目范式并不是真正的“JSON 事物”，而是使用 JSON 作为序列化的选择来描述其“模型”。 JSON 比 XML 简洁且不那么健谈的事实使其更具吸引力（对大多数人而言）。

相应地，MSBuild 本身并不植根于 XML，但它的设计方式是以这种格式描述其“模型”。 我说“模型”是因为这两个系统都存在（我认为的）设计缺陷，即将文档模型放在最终反序列化到内存中的实际模型/API 之前。 这意味着必须管理比真正需要的更多的工件和概念，并最终使系统复杂化。 将其硬编码为仅接受特定格式（XML 或 JSON）只会让情况变得更糟，我们应该再次探索减轻这种约束的方法。

无论如何，为每个人提供蹩脚的周日早上 PSA。 :stuck_out_tongue:

我在这个帖子的任何地方都看不到这个帖子，所以在这里...... https://youtu.be/N9MteJH-HsQ。 希望它更多地解释了为什么要进行更改。

@谢尔曼

“我能不能出于兴趣问一下，有什么疯狂的部分？现在询问某人的想法是不合理的？还是我在那里遗漏了什么？”

我指的是调查结果并试图推断一般的开发人员群体。 正如我所提到的，这大致相当于在猫玩具大会上进行一项民意调查，即狗与猫哪个更好，并假设它适用于整体人群，则存在大量且明显的样本偏差。

我手机上的 GitHub 不会让我 +1 @gregoryyoung ，而是 +1。

该团队解释说，更改的部分原因是收购了 Xamarin，这是一件大事。 在 .NET、ASP.NET 和 Xamarin mobile/x-plat 项目之间共享库的潜力是巨大的，如果这意味着妥协项目/构建文件格式，恕我直言，这是一个值得的交易。

在我形成最终意见之前，我将等待看看工具和最终文件设置是什么样子。

@gregoryyoung我指的是调查结果，并试图推断到一般的开发人员群体......有一个大而明显的样本偏差。

那会是哪个样本偏差？ 它主要发布在_喜欢_更改的人的 Twitter 提要上的那个？ 开发团队使用的松弛通道上的那个？

我看到的主要样本偏差是，受访者可能很投入、见多识广且充满热情。 当然，这可能不是一个具有代表性的样本，但我认为这是一个重要的样本。 即使有样本偏差，这是否意味着必须丢弃结果？ 受访者的观点不重要吗？

322 位专业 .NET 开发人员发表了意见。 你会完全忽略他们的意见，因为你相信（没有任何证据支持你）它没有代表性吗？

显然，下周将发布一篇博文，届时我们将有更具体的事情要讨论。

天啊人们需要冷静下来:)

我同意这个变化看起来很大，但我认为它对人们的影响比看起来要小得多。 请记住，当团队谈论“工具”时，也包括 cli。 任何需要发生的转换也将由 cli 完成，用于添加引用的“工具”，我认为这比将它们输入到 json 或 xml 中更好，将在 cli 中。 msbuild 中已经支持 Globbing。 Msbuild 显然将包含在 don't sdk 中，因此不会有额外的安装，新项目的故事也将相同，dotnet 命令只会在幕后做其他事情。 （我不是 microsoftie，但这似乎很有可能）

团队不是白痴，他们不会轻易做出这种改变。 他们_已经_给出了原因，主要是跨语言、本机引用和项目类型、nuget 包的粒度等与平台其余部分的兼容性和一致性。 才一周，他们说他们很快就会详细说明这些变化和他们的推理。

我希望人们在完全谴责这一举动之前，至少要等待这一点以及他们的实际计划。

是的，我已经手动调试了 csproj/tfproj 文件，并与文件包含和所有这些东西的条件规则作斗争。 哎呀，我什至编写了自定义构建任务。 但归根结底，用简单的工具（包括 cli）抽象出一个复杂的系统要容易得多，而不是让相对简单的 project.json 系统支持它需要支持的所有复杂场景。

换句话说，人们喜欢在 project.json 中的简单性已经一去不复返了，它需要去支持具有各种类型或项目和场景的广义 dotnet 环境的复杂现实。 如果他们将所有这些都实现到 project.json 中，您基本上会再次拥有 msbuild。 我更喜欢他们退后一步，将构建系统视为一个整体，而不是将一个又一个功能添加到 project.json 直到它变成一个大意大利面球

让我们看看他们的建议，然后在我们发现问题时提出具体问题:)

@aL3891

如果团队清楚地解释了他们的推理和考虑的替代方案，以及他们被拒绝的原因，并且还考虑并参与了此处提出的建议，那么我会支持这一点，并将支持任何合理的解决方案从这样的过程中走出来。

事实上，这正是我三天以来一直要求的。 洞察决策过程和支持它的证据。 迄今为止，在这方面提供的信息充其量只是平庸的。

如果我们得到它，我会+10。

@ aL3891快速提问。 有些人说我们应该参加周三的站立会议来解决这些问题。 你是说我们应该等待博客文章？

大家也应该记住，这都是开源的。 如果您强烈认为非 msbuild 更好，只需 fork 现有工具并继续使用。 与所有有趣的软件设计选择一样，争论的各个方面都有利有弊。 微软需要对他们的大付费客户做出回应，但为了他们的信誉，他们已经把所有这些东西都开源了。 如果其他东西对你有用，那就去做吧。

我观看了@khellang发布的那个 youtube 视频 - ASP.NET 的变化是 _revolutionary_，但看起来，最终，它太具有革命性了，现在混合使用 Xamarin，_revolutionary_ 不会削减它。

此外，重新发明轮子的想法似乎并不吸引人，虽然这似乎是正确的做法……但又是遗留问题。

我对使用 MSBuild 有一个新的批评，基于 .NET Standup - 虽然我们在很多地方有很好的关注点分离，但 MSBuild 没有。 粗略地说，根据站立会议，它必须以某种方式了解所有内容才能有效，仅仅协调不同的部分是不够的。

同时，我认为这应该放在另一个线程中 - 似乎有“内部工程决策”稍后会与社区共享。 这让我觉得 MS 并没有完全开源——如果他们公开讨论（并让人们意识到它们正在发生），那就不会那么令人惊讶了，我们可能已经有了答案，并且许多利益相关者（我的意思是那些会因离开 MSBuild 而受到负面影响的客户）本可以更早地明确表明他们的立场，并且社区本可以更及时地对问题/疑虑甚至解决方案做出反应出现的问题……相反，“这是我们唯一的选择”，这就是为什么您不仅要开源软件，还要开源开发过程。 这就是格言“只要有足够的眼球，所有的错误都是浅的”应该如何运作。 我不知道 MS 的工程团队有多大，但它比整个社区小，而且社区中有一些非常优秀的人才，他们可能会接受挑战，例如工程团队认为不可行的挑战......这可能是给他们的，而不是整个社区。 开源是关于使用尚未开发的资源和人才。

另一方面，也许我在某处错过了什么？

@shederman我建议那些既得利益者参加站立会议并留意博客文章（几乎肯定会在这里链接）。

对于那些不知道站会的人，请到这里： https :

您可以将它添加到您的日历中，即使您不关心项目定义的变化，它也值得一看。

@shederman我觉得我真的没有权力告诉任何人该做什么，但我可以告诉你我会做什么。 哎呀，我和其他人一样只是个局外人，我什么都不知道那些。 如果他们说我的博客文章即将发布，我至少会给他们一个怀疑的好处，看看他们要说什么。 但我可能会对两者发表评论/提问。

上面链接的最新on.net 剧集提供了一些很好的见解

还有roslyn 项目系统回购，它很可能会在未来几个月内看到很多行动

有人在 on.net 剧集中有 TL;DR 吗？

我认为我在_讨厌_观看有关编程的视频方面非常不寻常。 随时给我发短信😄

该死的地狱火！ 我什至在我的学习方法上都不是 IDE 😱

我认为我讨厌观看有关编程的视频是非常不寻常的。 随时给我发短信 :smile:

有什么问题？ 这是_only_你的时间。 ：咧嘴笑：

@rhires

伙计。 这很可能是我在过去 3 天里在这个问题上看到的最好的帖子之一！

保持在最前沿的 imo 需要付出很小的代价，但对每个人来说都是自己的 ;)

基本的 tl;博士：
该团队开始从 xamarin 等内部客户和外部客户那里获得反馈，认为将现有项目迁移到 project.json 很困难，并且让 project.json 与现有项目以及其他工具链（如原生项目和其他工具链）协同工作像 android 这样的平台意味着从 msbuild 引入大量代码（或概念）。 这将花费大量的时间和精力，并且会拖延不可接受的发布时间，并减慢未来的工作（包括其他产品，如 xamarin studio 和 mono development，以及visual studio 插件开发人员）。

因此，他们选择将构建系统建立在 msbuild 的基础上，但从新系统中引入人们喜欢的东西。 至于时间，即使在制作 RC1 时也不知道 xamarin 的收购，但现在它完成了它改变了很多东西。

他们还认识到人们非常喜欢 project.json 并且他们也非常喜欢，并且他们希望保留尽可能多的优点，甚至可能使 msbuild 也能够通过目标读取 project.json 文件。 Cli 和 VS-less 场景也是他们认为的核心场景。 他们还谈到了其他构建系统，目标是让人们可以根据需要使用 msbuild 以外的其他东西

然后他们谈了一点关于 RC2 以及其中的内容，他们还反思了他们可以在项目系统迁移方面做些什么不同的事情，更早地开放并在 GitHub 上进行更多的对话等等。

我确实建议观看它，我可能在这里遗漏了一些更好的观点。

@aL3891 - 感谢您的精彩总结。 浏览视频很费劲。 我同意他们应该写一个文本摘要。 我注意到他们正在“学习”，并且仍然对开放他们的过程感到不舒服，即使他们说这是一件好事。 所以希望这对他们来说是一次很好的学习经历，我们将看到变化并成为其中的受益者。

@aL3891感谢您的总结！

保持在最前沿的 imo 需要付出很小的代价，但对每个人来说都是自己的 ;)

啊，但我不是在流血的边缘，我留在那里一点点回来。 回到足够远的地方不会割伤自己，或者至少当我采用 .NET Core post-RC1 时我是这么想的 😢

@shederman考虑到“后RC1”基本上还是Nightlies版源，究竟你喜欢的牛排？

@neoKushan我的意思是我们只“采用* .NET Core _after_ RC1 发布。我们仍然使用 vanilla RC1。

所以，我们喜欢我们的牛排中等稀有。 但我们只是切了一块真正未煮熟的东西，并为服务员大喊大叫。

不过没关系，我已经不再叫服务员了，现在已经叫了maitre'd（我们的微软集团合作伙伴代表）来见我，我们可以讨论决策、信息传播和平台方向。

我们一无所知！

在这个问题上，我们没有得到足够的信息、太多的理论和猜想。 不想阅读此主题的懒人的快速摘要：

我们所知道的

1. xproj 将转换为 csproj。
2. 我们“可能”有一个 nuget.json 文件。
3. 我们正在使用msbuild 。
4. 这一切都将分阶段发生。
5. 图书馆不会改变。
6. 您不必在 csproj 中指定每个文件。

我们还不知道的

1. csproj 会编译为 .nupkg 吗？
2. csproj 是否会一次编译为多个架构和目标 x86/x64 dotnet/dotnetcore？
3. 会不会有单独的 nuget.config 文件。
4. 如何处理命令来执行 npm/gulp/bower/etc.？
5. 我们可以使用dotnet build和msbuild吗？ 我完全支持@shanselman渴望的“一个 .net”。
6. 项目参考的智能感知会保留还是消失？
7. VS 工具或命令行是否足够好以至于我们不必编辑 csproj.xml 文件？
8. 我们会得到dotnet add reference MyAssembly工具吗？

我认为这个问题应该关闭，直到我们有更多信息。

我完全支持@shanselman渴望的“一个 .net”。

这个？ :微笑: :+1: :+1: :+1:

我认为这个问题应该关闭，直到我们有更多信息。

但是但是但是……那我的人生该怎么办？？？ :cry: :grin:

@RehanSaeed

如果我对“我们所知道的”列表有疑问怎么办？

在提出我的疑虑之前，我是否必须等待“我们还不知道的事情”列表得到澄清？

还是我必须闭嘴吸干它？

正如我所知道的，很多人都想要... 😉

从我所看到的一切来看，决定是 100%，在以下方面不可改变：

那么我还需要从“我们还不知道的东西”中得到什么？

@shederman您可能真的想观看 On.Net 视频。 它给出了决定背后的一系列推理。

仅供参考：我通常将速度更改为 1.5 以更快地观看。 https://www.youtube.com/watch?v=N9MteJH-HsQ

如果我们将继续使用基于 XML 的项目文件，那么请您建议/鼓励/要求工具将文件内容按某种顺序排列。 “时间顺序”不是一个可接受的顺序。 我在 proj 文件中发现的最大痛苦是难以合并它们。 至少按字母顺序排列它们。 是的，我们仍然会偶尔遇到合并问题，但我会在任何一天将“偶尔”置于“无所不在”之上。

@MelGrubb我们知道的一件事是新的项目布局不会列出所有存在的文件，就像 project.json 一样

对于任何需要手动管理的东西，请 TOML。

JSON 对于配置没有任何意义。 它甚至比 XML 更没有意义。

对于任何感兴趣的人，看起来 RC2 位是可用的（我还没有看到博客文章）

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

和https://www.microsoft.com/net/download#core

我的两分钱，fwiw：

我喜欢 project.json 的简单性。 这是我希望（但不喜欢）在基于 MSBuild 的工具中看到的内容：

• MSBuild 不应绑定到 VS 或任何其他 IDE/编辑器。 它应该是一个可以单独安装的独立工具。 （或作为 dotnet cli 安装的一部分包含在内。）我这么说是因为我必须在构建代理上安装完整的 VS 实例才能获得 MSBuild。 这对我来说从来没有意义。
• MSBuild（或包含 MSBuild 的 dotnet cli）本身应该可以通过命令行安装——无论是 apt-get、chocolately、homebrew、powershell 还是 bash/curl。 如果我不能将它安装为构建代理的完全自动化设置的一部分（例如，在 circle.yml 或 Dockerfile 中），它将成为障碍和痛苦的根源。
• MSBuild 应该对命令行非常友好。 我应该能够从命令行做任何事情——因此能够在构建过程中自动化任何事情——在 circle.yml、bash 或其他脚本文件中。 我希望看到标准输入和标准输出的良好使用，以便我可以输入/输出 MSBuild 命令。
• 在 VS Code（或其他非 VS 编辑器）中处理 .NET Core 项目不应该需要 csproj 文件或其他任何地方的 VS 特定信息。 项目信息、nuget 包依赖项、平台目标、编译器指令等应该在使用不同 IDE/编辑器的开发人员之间共享。 这些在项目文件中是有意义的。 但是不使用 VS 的人不应该看到 VS 工具设置——那些属于单独的文件。
• 项目文件需要易于理解和易于手动编辑。 工具很棒，但我应该能够打开文件并了解这些工具为我做什么。 并轻松进行更改。
• 虽然我知道在功能/能力上没有区别，但我个人更喜欢 json 而不是 xml。 我还认为使用 json 将有助于吸引来自其他堆栈的开发人员。 吸引人们使用 .NET 已经够难的了，而不是让他们首先看到一个大的、难以破译的 XML 文件。 （这比逻辑更情绪化，但我确实认为这很重要。）请至少让 json 成为一个选项，并在自耕农生成器和其他新项目模板中使用该选项。 在最坏的情况下，请快速接受在 MSBuild 存储库中实现简单 json 格式的不可避免的拉取请求。
• 保留 npm 风格的“脚本”会很好，这样我就可以轻松地与我的团队共享用于开发、测试、调试、构建、运行、docker build/run 等的命令。 那些可以放在他们自己的脚本文件中，但它们作为项目文件的一部分（对我来说）是有意义的。

@jtbennett

“但不使用 VS 的人不应该看到 VS 工具设置——那些属于单独的文件。”

只是补充一下，现在其他文件中还有一堆可能应该放入 msbuild 文件的内容。 忽略的事情是一个很好的例子，提供仍然支持的项目文件。 我不知道有多少项目是在 VS 中构建的，但不是从命令行中看到的

@jtbennett

MSBuild 不应绑定到 VS 或任何其他 IDE/编辑器。

它根本不会绑定到 VS，它将通过 Nuget 交付，因此它不会绑定到任何东西。

MSBuild（或包含 MSBuild 的 dotnet cli）本身应该可以使用命令行安装

这一点从今天起没有改变，您仍然可以通过通常的包源安装 dotnet cli。

MSBuild 应该对命令行非常友好。

_MSBuild_ 将有效地成为构建本身的一部分，因此我认为您不需要传入命令行选项。 但是，donet（CLI）显然是命令行友好的，我认为这就是您想要/需要的。

在 VS Code（或其他非 VS 编辑器）中处理 .NET Core 项目不应该需要 csproj 文件或其他任何地方的 VS 特定信息。

我完全赞同这个。 希望“新”项目格式将更加简化。

项目文件需要易于理解和易于手动编辑。

他们说这也是他们的优先事项。

虽然我知道在功能/能力上没有区别，但我个人更喜欢 json 而不是 xml。 我还认为使用 json 将有助于吸引来自其他堆栈的开发人员。 吸引人们使用 .NET 已经够难的了，而不是让他们首先看到一个大的、难以破译的 XML 文件。

我觉得这很有趣，我个人认为 XML 比 JSON 更容易破译，但我认为这很大程度上归结为模式设计得有多好（对于任何一个）。 过去我不得不用非常糟糕的元素名称（如“元素”）破译一些糟糕透顶的 XML，虽然 MSBuild 绝不是这方面最糟糕的罪犯，但它肯定还有很多不足之处。 使用 JSON，键名可能会遇到同样的问题。

有趣的是，我最近不得不在一个项目上工作，有人试图将 JSON 嵌入到 XML 元素中:(

RC2 博客文章现已发布： https :

.net 核心帖子也已上线https://blogs.msdn.microsoft.com/dotnet/2016/05/16/annoucing-net-core-rc2/

谢谢@neoKushan ！

@michaelvolz如果可以相信，我认为该文件不会保留： https :

System.GC.Server（旧：gcServer） - 指示是否应使用服务器 GC（默认值：true）的布尔值。

和

我们可以为 deps 文件使用不同的格式，但如果我们已经将 JSON 解析器集成到主机中，那么在这里重用它似乎最合适。

对于他们来说，_project config_ 使用 XML 而 _runtime config_ 使用 .json 似乎有点奇怪？

对于他们来说，项目使用 XML 而运行时使用 .json 似乎有点奇怪？

现在有吗？ ：笑：

@Mike-EEE 好点！ 我已经更新，希望能澄清我的意思：亲吻：

@neoKushan不，你第一次是对的。 :smile: 我以我尖刻的、适得其反的方式同意你的看法。 :smirk_cat:

但是是的... 100% 同意在解决方案中使用不同的格式是令人抓狂的。 全面采用单一格式可降低复杂性、上下文切换，从而降低 _confusion_。 这是我希望看到MSBuild 启用不同格式并成为 format agnostic的原因之一。 哎呀，警告，无耻的插头。 ：咧嘴笑：

我想我将成为你神圣十字军 @Mike-EEE 的追随者，因为我们坚持使用 msbuild，让我们让它变得更好。

嘿，谢谢@sandorfr ...请随时为那里的线程做出贡献（即使这是一个反应/:+1:）。 我在那里感觉有点孤单，肯定会走进有争议的领域！ 从我的角度来看，如果有大量客户因任何原因被迫使用我的产品，我会非常愿意改进我的产品以提高采用率/好感度/可用性/喜爱度。 但我不负责，所以。 :stuck_out_tongue:

@Mike-EEE 我读了一些帖子，我现在很沮丧......你进入了遗留思想的遗留世界：D。

让我们希望 Microsoft 的人对您的想法更加开放，因为我实际上对 msbuild 没问题，前提是事情变得更加简单明了，而且我不需要 Gui 来编辑我的项目（是的，json 智能感知更好比通常的 Visual Studio 项目选项卡）。

你走进了遗留思想的遗留世界：D。

Wellllll-说@sandorfr ... wellllll-说。

对于那些不知道站会的人，请到这里： https :

好吧，我是个十足的懒鬼，现在终于检查出来了。 下一次站会好像是下周？ 球队这周要跳槽吗？

@Mike-EEE 有趣，它肯定是在今晚安排的，但我想知道它是否已经改变了。 我在推特上发了@shanselman ，希望这只是一个错误，但鉴于 RC2 昨天才发布，他们本周可能想跳过它。

好吧，很酷的@neoKushan ......只是确保我头脑清醒一次。 可以肯定的是，我也不想这么快处理我们所有的问题和不满。 ：眨眼：

来自松弛：

jongalloway [9:31 AM] 我很确定明天的 ASP.NET 社区站会被取消 - shanselman 和 damianedwards 都在 OSCON。
...
davidfowl [9:34 AM] damianedwards：回来了……但是 shanselman 在 oscon
...
jongalloway [9:46 AM] 是的，5/17 肯定取消了 ASP.NET 社区站会。 我更新了网站。

@Mike-EEE 处理我们所有的......不满

😆

如果有任何疑问： https :

必须跳过。 我在#vslive 和 OSCON

我非常喜欢 project.json 的一件事：默认情况下，所有文件都包含在项目中，无需明确包含其中的每一个。 随着大型项目（我的意思是数以千计的文件），在合并过程真的很痛苦的，因为XML的，而且因为每个文件中的csproj被列。

我们知道这方面是否会有任何改进吗？

@pierrus有人提到他们不想回到所有文件都列在 csproj 中的日子。

@MaximRouiller好吧不知道，太棒了！

@MaximRouiller但他们确实想回到 MSBuild 是 One Ring™ 的时代，我的意思是构建工具。 😉

_Ash Nurtog vegal durbatulûk, ash Nurtog vegal gimbatul,
ash Nurtog vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman自从我对新闻的第一反应以来，我已经缓和了我的观点。

我的想法是，他们最初想发布project.json格式，但是使用 csproj/Xamarin 规范化模型只会要求他们将框架推得更久。 更快的收益是合并回 csproj。 他们可以将新方式保留在单独的文件中，同时将纯“仅数据”保留在 csproj 中。 这对我来说解释了 RC2 所做的大量工作。

如果您移动几乎没有变化的属性并将很酷的新功能保留在单独的文件中？ 我们真的没有失去任何东西。 是的，我们要回到怪物身上……但我们离得不远了。

我没有这方面的任何内幕知识。 这纯粹是我的猜测。

无论如何......我们不再以年度发布周期结束。 如果他们准备好在 RTM 之后从 project.json 过渡到 csproj，我假设在 RTM 之后也可以发布更大的更改。

除了 MS 团队没有人知道的变化。

@MaximRouiller我

我只是解决了宣布的更改，他们正在从轻量级构建转移到对所有内容使用 MSBuild 和 xproj。

是的，我们要回到怪物身上……但我们离得不远了。

嗯，如果我们 _deprecated_ 一些适用于 90% 用例的东西将_back_移到那些对这些用例来说过于复杂的东西，那么我只有一个问题：

为什么？

当msbuild已经做得很好时，为什么dotnet build调用 MSBuild。 为什么要弃用简单构建？ 为什么要加班？ 唯一的原因很简单，我们已经做出决定，我们必须一直使用 MSBuild 做任何事情，永远。

适用于 90% 用例的东西

[需要引用]

即使假设它是 90% 的用例，你会处理 1/10 失败的任何事情吗？

回到过于复杂的事情上

同样，[需要引用]，到目前为止我们唯一知道的是它将是 XML-csproj 并且它不包含文件列表。 我们对系统将如何工作一无所知，我不相信我们甚至需要知道，因为这里的每个人都只是在调用“dotnet build”，无论构建是如何实现的，这都不会改变。

当 msbuild 已经做得很好时，为什么 dotnet build 调用 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 失败的任何事情吗？

没有人说任何失败的事情。 有些工具比其他工具更适合某些目的。 我会说 MSBuild 的功能和复杂性适合大约 10% 的构建。 我们可以争论确切的百分比，但绝对低于 100%。

@neoKushan切换到 MSbuild 不会改变这一点

嗯，它不会改变构建过程。 然而，它_确实_改变了构建过程所需的内容（即 csproj 文件），以及它的执行速度。

@neoKushan您不愿意接受实际上将 MSBuild XML 文件作为项目系统与将 MSBuild 作为构建系统之间存在差异 - 已经存在分离。

抱歉，但我不明白让一个工具做两件事是一种分离。

@poke请停止假设一切都是 ASP.NET

我不是。 我是说建议的解决方案对于简单的构建来说效果不佳。 其中一些是 ASP.NET 构建。 就我个人而言，我不明白为什么我需要像 MSBuild 这样强大的东西来制作一个简单的控制台应用程序。

@poke你在这个线程中故意无知。

我希望如此，是的。 因为我故意不知道 MSBuild 用户可以获得的美妙好处。

@poke我建议你

伙计，我很冷静，我向你保证。

我只是不会让我不同意的观点不受质疑。 我向你保证，这不是激动的迹象。 天哪，我什至没有被一些

当这个同样的小 twerp _person_ 呼唤我冷静下来时，这

真好笑。

@MaximRouiller @shederman在某物上构建垫片的原因是当您想更换它时。 抽象它以便您可以更改实现

啊，是的，这将是一个很好的理由，除非我听说没有打算替换 MSBuild。 在可预见的未来，它是选定的构建系统。 如果我们允许项目在没有 MSBuild 特定项目的情况下保持不变，并且dotnet build要么执行现有的 lite 构建，要么选择基于某些内容的构建工具，例如 config，我希望它。 如果你想使用 MSBuild，一定要创建一个 msbuild 文件并运行msbuild 。

不。 我相信我说的是命令 msbuild 可以很好地运行 MSBuild。

把它放在上下文中：

为什么 dotnet build 调用 MSBuild

dotnet build远不止“只是”调用编译器，看看当前 CLI 的 dotnet build 实现。 构建一个项目只是dotnet build过程的一部分。 该过程的最终_部分_将是调用msbuild但这不是您的工作，这是 CLI 的工作。

我没有对作为工具的 MSBuild 做出任何判断。

您在此线程中所做的只是将 MSBuild 判断为一种工具。 坦率地说，声称你没有做这样的事情是荒谬的。

那不是很清楚吗？

你所说的很少是清楚的，或者至少是经过深思熟虑的。

没有人说任何失败的事情。 有些工具比其他工具更适合某些目的。

因此，某些工具无法适用于目的。

我会说 MSBuild 的功能和复杂性适合大约 10% 的构建。

嗯，这很有趣，因为那里的每个 Visual Studio .net 开发人员都必须不同意。 您实际上是在说 MSBuild 对 90% 的用户没有好处（忽略了您正在从屁股中提取数字这一事实），这又是可笑的。

嗯，它不会改变构建过程。

如果过程没有改变，那么你唯一的论点就是你不喜欢项目的结构——事实上，它是 MSbuild 或幕后的任何东西，因此完全无关紧要。

然而，它确实改变了构建过程所需的内容（即 csproj 文件）

就人们所见，这实际上是唯一真正发生变化的事情。

以及执行的速度。

[需要引用]

请告诉我新进程如何更快或更慢，因为它目前不存在。

抱歉，但我不明白让一个工具做两件事是一种分离。

因为一个工具不能做两件事，所以 MSBuild 可能是构建系统，但变化与项目系统有关。 如果您愿意，绝对没有什么可以阻止您使用不同的构建系统，这很重要。

我不是。 我是说建议的解决方案对于简单的构建效果不佳

dotnet new
dotnet restore
dotnet build

请告诉我提议的解决方案如何改变有关“简单构建”场景的任何内容

其中一些是 ASP.NET 构建。

yo asp-net web
dotnet restore
dotnet build

就我个人而言，我不明白为什么我需要像 MSBuild 这样强大的东西来制作一个简单的控制台应用程序。

你没有。 你只需要dotnet build 。 你仍然会有。 那里没有任何变化。

我很冷静，我答应你。

小特卫普

:-1:

@neoKushan如果您能掌握对引用的摘录的回复和对整个讨论的评论之间的概念，那就太好了。 我假设你_有能力_这样做，所以唯一的结论是这是故意的。 如果是这样，只是让您知道这是一种智力上的不诚实策略。 我希望你知道这一点，但我在这里给出了怀疑的好处。

我也认为你绝对应该吃一颗冷静药丸。 我们只是在讨论我们个人认为最适合该框架的内容，我们并不是试图相互对抗。 攻击论点，而不是人。 好吧，这就是我_试图_做的事情好几天了（除了最近的一种情况，见下文）。

嗯，这很有趣，因为那里的每个 Visual Studio .net 开发人员都必须不同意。

有趣的是，我收集了一些不同的证据。 哪里拿你的东西了？

因为一个工具不能做两件事，所以 MSBuild 可能是构建系统，但变化与项目系统有关。 如果您愿意，绝对没有什么可以阻止您使用不同的构建系统，这很重要。

是的。 所以我们同意。 如果它是微不足道的，我真的非常喜欢它。

真的有这么无理的要求吗？ 真的吗？

你没有。 您只需要 dotnet 构建。 你仍然会有。 那里没有任何变化。

而dotnet build究竟会做什么？ 壳到msbuild ？ 如果我们想使用 MSBuild，为什么我们不能只使用msbuild ？ 在这种情况下dotnet build的目的究竟是什么？ 它为工具添加了什么？

小twerp👎

试图变得有趣，但你可能是对的。

@poke我毫无保留地道歉。

如果您能理解对引用的摘录的回复和对整个讨论的评论之间的概念，那就太好了。 我假设你有能力这样做，所以唯一的结论是它是故意的。 如果是这样，只是让您知道这是一种智力上的不诚实策略。 我希望你知道这一点，但我在这里给出了怀疑的好处。

完全不知道你指的是什么。

我也认为你绝对应该吃一颗冷静药丸。

...

攻击论点，而不是人。

:InsertRolleyEyeEmoticonHere:

有趣的是，我收集了一些不同的证据。 哪里拿你的东西了？

好吧，那么 10%/90% 的数字是从哪里来的？

是的。 所以我们同意。 如果它是微不足道的，我真的非常喜欢它。

这与他们更改为 msbuild 无关，您已经无法将当前的构建系统从dotnet build更改出来。

而 dotnet build 究竟会做什么？ 外壳到 msbuild？

dotnet build调用 msbuild 而不是dnx或 roslyn 有什么不同？

如果我们想使用 MSBuild，为什么不能只使用 msbuild？

那么您现在要使用 MSBuild 吗？ 没有什么能阻止你，这些天它是一个 nuget 包。 发疯。 考虑到你有多讨厌 msbuild，我很惊讶你竟然会问这个问题。

在这种情况下，dotnet build 的目的究竟是什么？ 它为工具添加了什么？

我们真的在讨论dotnet build的优点吗？ 你不喜欢dotnet build吗？ 你不明白dotnet build ？ 这似乎不太可能。 你想问什么？

@neoKushan请停止对抗他。 这不是建设性的。

好吧，那么 10%/90% 的数字是从哪里来的？

那来自我的个人经历。 我发现我的团队和我在过去几年中创建的大约 90% 的构建不需要比 RC1 dotnet build所做的更复杂。

这与他们更改为 msbuild 无关，您已经无法将当前构建系统从 dotnet build 中更改出来。

请澄清一下，我不确定你在这里的意思。

那么您现在要使用 MSBuild 吗？ 没有什么能阻止你，这些天它是一个 nuget 包。 发疯。 考虑到你有多讨厌 msbuild，我很惊讶你竟然会问这个问题。

_叹_。 我的问题是：当msbuild已经做得很好时，为什么dotnet build应该向 MSBuild msbuild ？ 为什么有两个命令做一件事？

到目前为止，我已经问了三遍，每一次你要么误解了它，要么误解了它。

我在询问两个不同命令行命令的操作
我在问为什么两者都会做同样的事情
我在问，如果他们都做同样的事情，为什么不用一个命令
如果他们都做同样的事情，我问第二个命令会增加什么情况
在这种情况下，我不会对基础工具的质量做出判断，尽管我可能在其他地方这样做过
在别处所说的判断不会影响所问的问题，因为所问的问题是关于命令行命令及其操作，根本与底层工具无关
我不是要讨论这些工具在过去可能会或可能不会做什么，而是要讨论它们将来打算做什么

很抱歉解释一个句子问题的冗长说明，但这显然是必要的。

InfoQ 上的一篇文章：
“微软得出的结论是，project.json 实验失败了，将转回使用 .csproj 文件。” ：失望的：

就像我说的，感知很重要。

我的问题是：当 msbuild 已经做得很好时，为什么 dotnet 还要为 MSBuild 构建 shell？ 为什么有两个命令做一件事？

因为他们不只做一件事？

当 csc 已经可以很好地构建东西时，为什么 MSBuild 应该向 csc 出售？ 为什么有两个命令做一件事？

当dotnet test已经在自己运行测试方面做得很好时，为什么还要向 xUnit 测试运行程序发出警报。 为什么有两个命令做一件事？

当 NuGet 已经可以很好地安装包时，为什么dotnet restore应该向 NuGet 转出。 为什么有两个命令做一件事？

你明白了......（我希望：眨眼：）

@sandorfr

@neoKushan请停止对抗他。 这不是建设性的。

我不是故意对抗任何人，我是逐点解构@shederman的论点，这正是他希望人们做的：

攻击论点，而不是人。

虽然在这一点上，我什至不完全确定dotnet build变坏。

让我们继续。

那来自我的个人经历。

这是你的“证据”？ 请记住，您用粗体表示：

有趣的是，我收集了一些不同的证据。 哪里拿你的东西了？

现在是“个人经验”。 这就是我们所说的_轶事_证据。

我发现我的团队和我在过去几年中创建的大约 90% 的构建不需要比 RC1 dotnet 构建更复杂的东西。

在这方面，您希望 RC2 dotnet build或 RTM dotnet build或后 RTM dotnet build有什么变化？

请澄清一下，我不确定你在这里的意思。

您的论点似乎是（如果我错了，请纠正我）类似于“让dotnet build执行 Microsoft 编程之外的其他操作并非易事”。 这在 DNX 时代是可以​​的，因为我们都喜欢 DNX，但现在微软想要在幕后使用 MSBuild 而你不喜欢 MSBuild，你想要选择将 MSbuild 换成其他东西 - 我的观点是不是什么新鲜事，如果你对 DNX 有一些问题，那么你也不能改变它，所以无论你对dotnet build “问题”是什么，都不是什么新鲜事，因此我认为它不相关到这里的 _actual_ 讨论，这是project.json移动到 . csproj

叹。 我的问题是：当 msbuild 已经做得很好时，为什么 dotnet 还要为 MSBuild 构建 shell？ 为什么有两个命令做一件事？

@khellang已经回答了这个问题，所以我并不特别想重复自己，但这也是因为我已经非常简洁地说明了区别是什么（我讨厌引用自己，但我认为你没有真正读过这个）：

dotnet build远不止“只是”调用编译器，看看当前 CLI 对 dotnet build 的实现。 构建一个项目只是dotnet build过程的一部分。 该过程的最终_部分_将是调用msbuild但这不是您的工作，这是 CLI 的工作。

所以，至少第三次：调用dotnet build与调用msbuild不是同义词。 正如你所说，它不是“两个命令做一件事”，而且从来都不是。 这甚至从未在整个讨论的范围内，但不知何故你已经结束了。

真正重要的讨论是 project.json 的结构以及如何将其合并到 .csproj 中。 如果你只是想要一些简单的东西，那么底层构建系统在很大程度上是无关紧要的，因为你总是只有dotnet build 。

那么我们如何区分 msbuild 的作用与 dotnet build 现在的作用呢？ 它们的工作方式有何不同？ 我认为本次讨论中缺少这一点。 每个人都可能已经知道了，但我认为把它放在桌面上可能会更清晰一些。

@khellang我喜欢你表达的方式，但是从那里开始，我可以配置dotnet test作用。 我可以在 project.json 中放置与 xunit 不同的测试运行程序， dotnet test将调用该测试运行程序。

但是，根据我对即将到来的更改的了解， dotnet build不会有类似的功能。 它将始终使用 MSBuild 来执行它的构建。 这种理解不正确吗？

@neoKushan我不是故意对抗任何人，我是逐点解构@shederman的论点

好吧，至少我们现在知道你_认为_你在做什么。 你_事实上_所做的是歪曲、混淆立场、故意误解事情，并且通常有点笨拙。 你的语气是好斗的，你是故意迟钝的。 如此之多以至于我不得不一次尝试将事情分解为一个想法。 可笑的是，您将其误解为改变立场。

@neoKushan虽然在这一点上，我什至不完全确定

XML 不好。 MSBuild 很糟糕。 如果dotnet build只使用 MSBuild，那也不好。 请试着跟上。 没那么复杂。 如果你不是那么刻意迟钝，你早就掌握了它并能够实际添加建设性的意见。

@neoKushan这是你的“证据”？ 请记住，您用粗体表示：

嗯，不，那是我的个人经历，不是证据。 我的证据是 383 名受访者中的 281 名认为将 .NET Core 移回 MSBuild 是个坏主意。 而这些受访者谁相信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时。

我一直在尝试（可能不太好）指出的是，更好的（在我看来）选择是尝试在 _project definition_ 文件和 _build definition_ 文件之间保持清晰的分离。 这将为我们提供更好的dotnet build支持，它可以支持多个构建引擎。 相反，如果我们将所有内容都移到 csproj 中，那么我们就会将自己锁定在 MSBuild 世界中。

是的，我确实了解到 DNX 中存在这种“只有一个真正的构建”情况。 但当时我没有询问，因为我_喜欢_我们拥有的构建。 啊，当我们愉快地接受我们_喜欢_ 😉的不公正时，我们将自己置于何种境地。

因此，请考虑这样一种情况，其中dotnet build能够使用多种构建工具之一，具体取决于配置。 就像dotnet test可以使用几个测试运行器之一。 现在，鉴于这样一个虚构的世界，现在您将如何合并 csproj 和 project.json？ 这就是我想要的讨论。

@rhires从非常高的层面dotnet build ：

1. 收集项目文件
2. 确定是否满足增量构建的前提条件
3. 读取 project.json
4. 确定目标框架
5. 对于每个项目：
   
   
   
   1. 构建它的依赖项
   
   
   2. 如果是增量，检查是否需要重建
   
   
   3. 确定输出目录
   
   
   4. 收集源文件
   
   
   5. 确定编译选项
   
   
   6. 运行预编译脚本
   
   
   7. 使用源文件和选项运行编译器
   
   
   8. 运行后编译脚本
   
   
   9. 报告输出
   
   

@shederman谢谢！ 从这一点来看，msbuild 会在这个过程中添加/减去/替换到/从/替换什么？

好吧，至少我们现在知道你认为你在做什么。 你实际上在做的是歪曲事实、混淆立场、故意误解事情，而且通常是有点笨蛋。 你的语气是好斗的，你是故意迟钝的。 如此之多以至于我不得不一次尝试将事情分解为一个想法。 可笑的是，您将其误解为改变立场。

锅 -> 水壶

你已经改变了很多次你的立场，你甚至无法跟上自己的步伐，你已经争论了构建链的每一个方面，这表明你显然没有很好地理解它是如何组成的正如你_认为_你所做的那样，但_我_是个混蛋，因为我敢于指出你的论点在哪里失败。 我仍在等待您对我上面提出的一半要点做出回应，但您所做的只是继续选择构建过程的其他方面。

XML 不好。 MSBuild 很糟糕。 如果 dotnet build 只使用 MSBuild，那也不好。

除了 _you_ 之外，没有人声称过这样的事情。 没有人。 甚至没有任何迹象表明此类事情会发生。 我已经反复对你说过dotnet build不是_只是_要调用MSBuild ，我已经告诉你dotnet build和msbuild并不完全是同义词彼此和dotnet build所做的不仅仅是调用编译器。 我什至把你链接到该死的源代码，其他人也来了，说同样的话，但你仍然坚持认为这在某种程度上是怎么回事？

请试着跟上。

_你_跟上怎么样？ 请告诉我们您从哪里想到dotnet build只会调用msbuild 。 谁告诉你的？ 你在哪里读的？

我的证据是 383 名受访者中的 281 名认为将 .NET Core 移回 MSBuild 是个坏主意。 85 名受访者认为 MSBuild 已从根本上损坏。 那是我的证据。 你的具体在哪里？

你从这些数字中提取了 10%，是吗？ 请记住，这是您的主张：

我会说 MSBuild 的功能和复杂性适合大约 10% 的构建。

后来你说：

有趣的是，我收集了一些不同的证据。

那么这个证据在哪里呢？ 我很想知道你是如何从你的“证据”中得出这个数字的。

您知道，要支持您的说法“......那里的每个 Visual Studio .net 开发人员都必须不同意”？

简单： https :

Visual Studio 承载 MSBuild 以加载和生成托管项目。

如果使用 Visual Studio 构建项目，则使用 MSBuild。 即使在今天使用 .net core 时，即使使用 RC1 VS 在引擎盖下使用 MSbuild。 您可能不喜欢 MSbuild，但就像我说的，几乎每个 VS 开发人员都使用它，无论他们是否意识到。

MS 表达的计划是 MSBuild 将成为构建领域的中心。

我不同意这一点。 他们从来没有说过它会成为中心，他们只是说 project.json 的某些部分最终会回到 .csproj 中——除此之外，他们没有说这在多大程度上改变了dotnet build过程。

“MSBuild 会永远成为 .NET Framework 的主要构建系统吗？”

如果是这样，我们只需要一个 msbuild 命令，而我们不需要 dotnet build 命令，这完全是多余的。

正如现在多次说明的那样， dotnet build和msbuild是两个完全不同的东西。 dotnet build并不仅仅是调用编译器工具链。 dotnet build 的目的是使人们的构建过程保持简单。 再看：

dotnet new
dotnet restore
dotnet build

即使 msbuild 成为 dotnet CLI 的核心组件，这也不会改变这样一个事实，即 dotnet build 是一个干净、简单的包装器，它是（并将永远是）一个相当复杂的系统。 地狱，dotnet CLI 存在的一半原因（以及之前的 DNX）是专门为了摆脱 MSBuild 最终是的命令行参数地狱。 您的论点有点像在说“当我只能curl包时，为什么我们需要npm install命令？”。 当然，如果您真的愿意，您可以手动完成所有操作，但您几乎不会从中获得任何收益。 那么如果dotnet build幕后使用msbuild呢？ 你几乎肯定永远不会看到它，或者需要知道它。

您无法将您的旧体验与 MSBuild 进行比较，它完全不同。 我们都（似乎）被那个烧伤了，因为我们习惯于打开 VS，创建一个项目并让它刚刚构建，但是当你在构建服务器上构建相同的项目时，它突然抱怨狗屎那应该_只是工作_。 微软在 TFS 2015 中所做的最好的事情之一可能是创建了一个与 _Visual Studio_ 而不是 _MSBuild_ 相关的构建定义，因为你回到它“只是工作”。 这正是这个构建工具链的含义 - dotnet build并不意味着要替换您的整个构建系统，它只关心构建您的项目，即使它确实在幕后使用了MSBuild 。 如果您想使用 TeamCity 或 Jenkins 之类的东西， dotnet build告诉他们调用

唯一 - 我的意思是完全，唯一真正为您改变的是 project.json/csproj 文件。 而已_。 这就是为什么所有关于dotnet build真正做什么以及MSBuild的好处和坏处的争论绝对是_pointless_。

@neoKushan停下来...

@neoKushan停下来...

我的一部分喜欢想象 ASP.NET 团队故意取消站立，因为他们很喜欢这个节目，而提供答案将使这一切结束。 ：微笑：

从我（现在坚定地）不可知论的立场来看，一段时间以来，双方似乎都对对方的观点故意含糊其辞。 您成功地将我对 .NET Core 社区的心理形象设定为没有建设性甚至更糟。 谈感悟...

大多数非 NuGet 内容将合并到 csproj。 如果没有 project.json (nuget.json?)，NuGet 的东西会怎样？

为用户提供一种以他们喜欢的方式管理他们的依赖项的方法，并且默认情况下可能会提供dotnet nuget ，因为 NuGet 在 .net 社区中得到了很好的建立。

但是不要将所有 dotnet 核心内容硬耦合到管理依赖项的唯一方式（ dotnet restore不应等于dotnet nuget restore ），对于许多人来说，nuget 只是一个包存储库，而不是一个依赖管理器，人们确实有其他选择，他们可能会发现更高效/适合“依赖管理器”用例。

我们会保留 IntelliSense 进行依赖管理吗？ 这基本上是我们为 project.json 提供的最好的演示功能之一。

你可以重新调整逻辑，我认为这没什么大不了的，例如，我去 nuget.org 搜索一个包并从 url 复制 id，它很有效。

您可能还想提供 shell 补全，这会让您从使用bash或zsh人那里获得很多钦佩：

dotnet nuget add S[tab]为以S开头的项目标识符提供完成列表

如果你想在那里烘焙<NuGet>标签，在 msbuild *proj 文件中拥有智能感知也应该是可行的，但同样，不要将 nuget 硬耦合到整个生态系统，即<Package>NuGetPackageId</Package>应该' t 等于<NuGet>NuGetPackageId</NuGet>或者应该有一种非常简单（并且有很好的文档记录和支持）的方法来覆盖它。

Paket Visual Studio 插件确实在 nuget 上有自动完成功能，它可以工作，但无论如何还是有点慢，因为我认为从 nuget.org 返回响应需要一些时间。

我们是否为依赖管理保留了 JSON 格式？ XML 对这类事情很糟糕（参见 Maven）。 JSON 可以更简单地表示这些依赖项。

如果您正在寻找格式的想法，您可以查看paket.dependencies ，否则，我认为这并不重要，编辑project.json大致与编辑packages.config在处理NuGet 方面，为选择NuGet 作为包依赖管理器的用户做任何方便的事情（不是100% 的用户也不必）

附带说明一下，如果您仍然需要一个lock文件，您能否使其用户可读，在存储库中检查的内容，并且易于进行差异化？

@rhires从这一点来看，msbuild 将在此过程中添加/减去/替换到/从/替换什么？

嗯，这取决于他们如何整合它。 如果他们进行“硬锁定”，将 msbuild 深入集成到 dotnet build 中，公共信息似乎表明这是他们的首选方法，那么它将被 msbuild 完全取代。

但是，如果他们使dotnet build配置，我希望它的工作方式如下：

1. 收集项目文件
2. 读取 project.json
3. 确定目标框架
4. 确定要使用的构建工具
5. 外壳到构建工具
6. 报告输出

@neoKushan这就是为什么所有关于 dotnet build 的真正作用以及 MSBuild 的优点和缺点的争论都是毫无意义的。

👍

我想_讨论_的是在dotnet build可以将 MSBuild 作为 _许多可能的构建工具之一_的世界中，project.json 和 csproj 应该是什么样子。 这样可以吗？ 鉴于此，我们可以谈谈 project.json 中的内容与 csproj 中的内容吗？

因为如果我们_可以_讨论，我相信这个线程实际上可以变得有建设性。

@jmm你成功地将我对 .NET Core 社区的心理形象设定为没有建设性和更糟

对于那个很抱歉。 但是，如果您有时间，我建议您阅读一些其他大型开源项目的聊天档案。

争论实际上是一个健康社区的标志，就像在生活中一样。 当每个人都盲目地跟随一组领导者时，情况通常不会那么好。 决定、证据和决策应该接受审讯。

@shederman为了继续进行富有成效的讨论，我还想划一条线来讨论拟议更改的影响。

我认为这里的核心讨论应该是“新”.csproj 的布局和格式以及 project.json（或者更具体地说，整个“项目”结构）会发生什么。 我不认为构建系统，无论是 msbuild 与否，dotnet 构建的工作原理等都在 _this_ 问题的范围内。 这并不是说对此的讨论不受欢迎或无效，只是它们不属于这个_特定_问题，而应该是单独的问题。 正如任何有经验的开发人员都可以证明的那样，当错误报告包含多个单独的错误时会非常令人沮丧，通常您要做的第一件事就是将它们分成多个问题进行跟踪 - 我认为这确实是这里所缺少的。

从我个人的角度来看，我不在乎构建系统是什么或它是如何工作的。 我并不是说对那些这样做的人听起来无知或不屑一顾，我的意思是从开发人员的角度来看，我只想知道只要项目结构是正确的，“dotnet build”就会吐出我的程序集 - 到目前为止就我而言， dotnet build -> 项目 ->-> 组装。 唯一对我来说真正重要的事情，以及这次讨论的范围应该是什么（我认为我们最终达成一致）是该项目的外观以及它对我的日常工作流程的意义。

我不想仅仅因为我添加了一个 .cs 文件而处理合并地狱，也不想仅仅因为某个_我不关心_的系统依赖于它而处理一千行长的 XML 文件 - 我不'认为我们中的任何人都不会这样做，而且多年来这一直是 VS 开发的麻烦事。 我们对今天的 project.json 格式抱有一线希望，因为它比以前的格式要好得多，所以我完全理解并理解为什么仅仅因为暗示我们会回到“糟糕的过去”，但同时值得指出的是，我们不应该自欺欺人 - 今天的 project.json 绝不是_完美_，它有自己的一系列问题，虽然与“旧” csproj 的问题，值得客观并讨论可以改进的地方以及可以更好的地方。

绝对有_两全其美_的可能性。

我认为这里的核心讨论应该是“新”.csproj 的布局和格式以及 project.json（或者更具体地说，整个“项目”结构）会发生什么。

你知道，在这个线程中已经提到了几次，但我想我会再次提到它，只是为了分享我今天早上的“个人啊哈”，但是基于 Roslyn 的项目系统正在进行其他工作- 或者从其自述文件中央项目系统 (CPS) 中更准确。 浏览它的文档，它似乎更像是一个项目定义工作而不是过程。 也许这就是整合 .json 和 .csproj 之间所有魔法的地方？ 然后 MSBuild 将被降级为进程端点？ 不会_那_很好。 ：微笑：

无论如何，我已经开始/观看了该 repo 以开始获取有关那里发生的事情的更新。 ：+1：

（我也想知道我们是否应该将这个讨论转移到那里的一个新问题上。）

@neoKushan当然，涉及 msbuild 的事实本身并没有问题。 我认为有一条前进的道路可以让我们在利用 msbuild 的力量的同时保持简单的人类可读/可编辑的文件格式。

让我担心的是诸如“msbuild 已经过实战测试”之类的论点，常规 msbuild 是，但当前的 xplat 似乎不是。 当我们查看相关 github 存储库上的问题时，还没有完全解决。 此外，msbuild 团队已经表示支持新的/改进的序列化格式不会成为 msbuild 的目标，而是一个新的构建系统（这不会很快发生）。

当人们认为我们所做的只是添加删除依赖项时，我也很担心。 也许这就是他们所做的，因为他们只是在做“hello worlds”应用程序。 但是其他选项，如 buildOptions 和 moniker 的覆盖非常强大和方便。 更不用说当前基于 json 模式的编辑器体验非常棒。

一种方法可能是让 msbuild 任务加载 project.json 作为替代方案。 然后，让开发人员在项目设置中选择他们是否要启用 project.json，这会将该任务添加到 csproj。

@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，因为我不是它的忠实拥护者是如何使用它的。 不过，这绝对是个人喜好。

好吧，它最初是在这里说明的......

啊，是的……当然！ 行。 只是确定。 希望明天将是我们最终对此有所了解（无论好坏！）的那一天。

我同意为不同的配置混合和匹配 XML 和 JSON 有点臭

真的很高兴我不是唯一一个看到这一点并有这种感觉的人。 :) 当我第一次看到 .JSON 渗入项目时感到悲痛时，在那里似乎很孤单。 从 web-appdev 背景来看完全有道理，但原生 appdev 不一样，反之亦然，当涉及到 XML 时。

哈哈……说起来，上面写的让我把老档案都翻出来了。 这是我在 2014 年提出的理由（是的，你猜对了！）Xaml 而不是 JSON哈哈哈哦，看看我是多么年轻和天真！ 好可爱又不张扬！ 男孩，我有没有要学习的世界。 :stuck_out_tongue: 但是，我会说已经取得了一些进展。 毕竟，我们确实摆脱了用于 Web 服务器配置的 .ini 。 ：微笑：

@neoKushan绝对有两全其美的可能性。

👯👯👯

@neoKushan我很确定当前的倾向是让 project.json 变成 nuget.json ......我唯一无法弄清楚的是这如何影响多目标，csproj 和 nuget.json 是否必须意识到了解他们各自的目标是什么？

使用 project.json 架构作为起点，从我的角度来看，以下项目可能_not_ 位于构建定义文件中：

• 源文件列表
• 项目依赖
• 目标框架
• 项目命令（例如 web、test 等）
• 网络根
• 元数据
• 语言版本

以下我不_相信_应该在构建定义文件中，但如果它们是，我会_meh_：

• 配置定义
• 脚本，前和后

以下可能_应该_在构建定义文件中：

• 编译选项（不包括语言版本）

以上只是为了引起讨论。 很高兴辩论任何个人观点。 建议暂时忽略文件的名称和格式。

@shederman我们是否需要澄清您所说的“构建定义”是什么意思？ 也许我的术语是关闭的，但我不会将当前的 project.json 称为 _build definition_ 文件，而是一个 _project definition_ 文件（对于新的 csproj 文件也是如此）。 可能是语义，但对我来说，构建定义表明它定义了_事物是如何构建的_，而项目定义定义了项目的组成部分，并将构建步骤留给了其他东西。

_这是我的项目，它由这些项目组成并具有这些依赖项。 你如何建造它不关我的事。_

很多项目都可以通过约定来确定，例如程序集名称如何来自顶级文件夹。 按照这种思路，_nuget.json_ 将与 nuget 有任何关系 - 因此包/依赖项将进入那里，我认为我们都对此感到满意。

我不能完全确定的是目标框架。 如果 Nuget.json 只关心依赖项解析，那么虽然它在针对不同框架时可能对引用有一些分离，但我不完全确定它应该是决定实际针对哪些框架的人，这对 _project 来说似乎更重要定义_（无论结果如何）。

再说一次，nuget 不仅仅是包引用，它还包含包 _definition_ 和版本以及当您的库 _ 成为 nuget 包时。 似乎 nuget.json 正在做至少两件不同的事情，而且开始有点味道。 也许（只是在这里吐槽），csproj 会定义包的详细信息、目标框架等，并且每个目标框架都可以指向一个 .json 文件，这基本上是 nuget 包。 换句话说，每个框架都有一个单独的 .json 文件，而不是一个 nuget.json。 这可能是一个糟糕的主意，我还没有特别想过。

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ ：

我们有两个选择。 一种是将所有 .NET 项目移至使用 project.json。 这将需要我们进行工具工作，涉及 Visual Studio、Xamarin 和我们的合作伙伴（如 Unity）中的所有项目类型。 我们必须扩展 project.json 以支持每种项目类型所需的所有构建场景，并提供迁移故事。 另一种选择是构建桥梁，以便 .xproj 项目可以引用 .csproj 项目，而 .csproj 项目可以在 Visual Studio 和 Xamarin Studio 中引用 .xproj 项目。 桥梁也面临挑战，例如，当客户创建项目时，他们现在必须选择 .xproj 或 .csproj，这只会增加更多的选择和复杂性。

和

在查看我们的选择后，很明显将 .NET Core 项目移动到 .csproj/MSBuild 会更容易，因此所有 .NET 项目都使用相同的工具和构建系统。

我们计划增强 .csproj 以支持缺失的功能：

• 项目系统中没有文件列表
• 用于对项目文件进行任何操作的 CLI 工具，对于大多数情况，您不会编辑文件
• 直接从项目构建包
• 多目标

由于所有 .NET 都使用相同的工具，因此我们可以考虑增强 MSBuild。 我们将征求客户和社区关于支持 JSON 而不是 XML 的反馈，让我们的工具不会生成过于冗长的文件等等。 并且因为一切都使用相同的工具，所以这些增强功能适用于所有 .NET 项目。

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485：

假设 .csproj 仍然表示 C# 项目，那么非 C# 项目当然会有其他目标，对吗？ [本]

是的。 [斯科特 H]

我有点担心 .net 会被复杂的遗留 justForTooling 构建系统卡住，如 msbuild，也许我们应该从它开始让 dotNetCore 运行，然后计划一个新的现代构建系统？
让每个人都充满希望，并在不急于交付 .netcore 的情况下做事。

我并不经常需要编辑 msbuild 文件，但是当我需要时非常困难，声明式方法让您在流程中迷失自我，我举个例子，似乎没有人能够解决这样的简单问题https://github .com/madskristensen/BundlerMinifier/issues/89
如果 6 个月后没有人可以在没有肮脏的黑客攻击或附加方式的情况下一个接一个地运行一个任务（两个不同的任务，每个任务都不知道另一个），那么那里可能有什么需要解决的。

谢谢

用于对项目文件进行任何操作的 CLI 工具，对于大多数情况，您不会编辑文件

:-1:

我完全支持 CLI 工具来帮助您完成工作，但是如果我_必须_使用 CLI 工具来管理引用和包，我会感到不安。 Install-package很棒，但是能够只输入包名称的一半并让它弹出所有版本的可能性列表，真是太棒了。

cli 工具非常适合自动化，但除了像npm install或dotnet restore这样的基本任务外，它是执行任务的一种糟糕方式。 如果我们必须学习dotnet buildoptions define add --framework net451 SOME_DEFINE东西，那肯定很难。 这是一个巨大的损失。

一个好的发展故事是：

• 易于编辑的项目和构建文件
• 可配置的构建系统
• 简单、精心设计和完整的 cli 工具
• 很棒的 GUI，IDE 工具

让其中一个穷人（以前真的很棒）让另一个人接受是愚蠢的。

unity 和 xamarin 的争论实际上很糟糕。 我认为他们不会很快转向 .net 核心，在为 .net 的未来进行设计时，为了方便而倒退是蹩脚的。

并且因为所有 .NET 都使用相同的工具，所以我们可以考虑增强 MSBuild

在我们被迫进入它之前，没有增强 MSBuild...

这篇文章真的不是我们等待的博客文章，它证实了 .net 核心在那里被误导了。

cli 工具非常适合自动化，但除了 npm install 或 dotnet restore 等基本任务外，它是执行任务的一种糟糕方式。

我再次觉得这个问题是文化/偏好/哲学的冲突。 在某种程度上，CLI 成为替代 GUI 的好主意，当你真的需要两者时，你会发现开发人员（再次）有他们偏爱的方法。 在这个领域肯定需要一些创新，因为它似乎一直是一个问题：创建了 CLI，但没有创建 GUI，反之亦然。

在我看来，创建 API 似乎需要某种框架，然后会自动为您创建 CLI 和 GUI 版本。

我们可以称之为... CLIGUIAPI！ :+1: :+1: :+1: #problemsolved

这个问题是文化/偏好/哲学的冲突

当然，这是一个你无法解决的问题，除非用最好的方法来解决每种方法。 node.js并且我不是这个堆栈的最大粉丝，我在这方面做得很好，有很棒的 cli 工具 npm 和 package.json。 Gui 部分由不同的供应商（webstorm、vs code、visual studio）解决。 像 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”都可以保留，因为它们都是自动生成的。 可以在dotnet restore使用标志来生成 .csproj。 在公告中，微软已经在说——“用于对项目文件进行任何操作的 CLI 工具，对于大多数情况你不会编辑文件”。 恕我直言， dotnet restore最适合作为 CLI 工具，它将 project.json 作为输入。 好处是——

• project.json 和 .csproj 两种格式都可以保持不变。 这意味着新生成的 .csproj 将与早期版本的 Visual Studio 和其他工具兼容。 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 已经关闭了一切。 您的反馈已被忽略并已被删除，感谢您的来电。

总的来说，整个 csproj -> project.json -> csproj 是一组错误的决定，这些决定将在 .NET 采用恕我直言中再次困扰 MS。 开发人员放弃 .NET 转向绿色牧场的趋势将继续有增无减。

好难过。

@shederman C# 的 Tiobe 指数下降与切换回 csproj 的决定之间没有相关性。 此外，下降的 Tiobe 指数并不表明 C# 生态系统的健康状况正在下降。 更多的语言进入市场，任何一种语言都很难保持较大的市场份额。

我不清楚整体上的影响，但我要指出，这里应该有关注点评估的分离。 如果 csproj 意味着仅仅因为我添加了一个文件，而我的队友担心与构建过程相关的其他影响，那么我们就错失良机了。

csproj 是我可以容忍的，而不是喜欢的。

@jerometerry我并不是说这本身会导致下降。 但是 .NET Core 中的许多创新变化旨在阻止衰退以及 AWS 的损失。 这些变化正在慢慢地被一一剔除，因此 .NET Core 越来越不可能吸引开发人员使用该平台。

此外，糟糕的决策 - 可以追溯到直到今天引入 project.json 的决定并不是好兆头。

如果 MS 决心专注于过去，那么当他们在未来失败时，他们不应该感到惊讶。 让你陷入问题的想法不太可能让你摆脱困境。

更多的语言进入市场，任何一种语言都很难保持较大的市场份额。

没错，但根据我的经验，在 .NET 中，友军开火造成了不必要的损害。

顺便说一句......昨天甚至有站立会议吗？ 我登录了 live.asp.net 但倒计时刚刚重置，没有视频/提要或任何东西......

@Mike-EEE 他们听说你要来了 :stuck_out_tongue_winking_eye:

令人沮丧的是，他们这样做了。 我写了关于它的博客： http :

从今天的站立： https ://youtu.be/YJsQ3tnS7Ew = 38m45s

他在这里特别提到了 project.json： https : =26m12s

尽管 project.json 格式的编辑要简单得多（除非您处于拖放数据集猴子的 .NET 开发阶段），但对我来说最大的问题是没有人费心将他们的库更新到 .网核。 到目前为止，我已经设法让 Restsharp 的一个分支正常工作，但这使用了 project.json 格式。 JSON.NET、Structuremap、NUnit 等都有陈旧的 DNX 分支，看起来开发人员已经放弃了希望。

因此，当dotnet命令行工具的项目格式被删除时，将 .NET Core RC1/2 称为候选发布版本有点奇怪。 对我来说，它仍然是测试版甚至是 Alpha 版软件，因为它是实验性的。

我迁移到 vNext 的主要动机是利用廉价的 Linux 托管和 Docker。 尽快使用项目迁移工具将是明智之举，因为大多数人将通过缺少 .NET Core 版本的 nuget 引用完全受到他们的库的影响。

@yetanotherchris dnx 是 rc1 中的一个概念，它在 rc2 中更改为 dotnet cli，因此大多数 dnx 项目或分支此时会过时

project.json 仍然存在并且需要用于 rc2，关于它在 RTM 之后将在未来消失的讨论

json.net aka newtonsoft.json 确实有效并且被框架本身使用，我也在我的项目中使用它
nunit 不兼容，大家都用 xunit afaik
structuremap 确实有和 rc2 兼容的库

仍然有很多 3rd 方的东西还没有移植到 rc2，但是微软没有控制其他项目的时间以及他们什么时候制作兼容的库

@yetanotherchris如果您在 project.json 中使用导入，您可以指定旧的、非网络标准的名字，它会使用它们：

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

可能是因为这个原因，目前还没有多少人费心更新他们的库，没有必要在实际 RTM 之前击中另一个移动目标。

@joeaudette我说的是分支名称（DNX）而不是命令行工具dotnet 。 很多人使用 NUnit，它几乎是 MsTest 之外的事实上的测试套件。 我不确定您是从哪里找到 JSON.NET 或 Structuremap 包的，这里有一个名为 DNX 的 Structuremap 非官方版本和一个 Newtonsoft 分支，还有 nuget.org 上的 .NET Standard 1.0 beta（.net 标准现在是多余的）我所知道的）。

@neoKushan谢谢，我会研究一下。

我认为我的主要观点是将其称为候选版本有点愚蠢，因为它会在最终版本中完全改变。 也许一个月后我们会得到一系列活动，现在构建系统与旧的和新的没有完全不同 - 尽管作为主要是 Web 开发人员的人，我更喜欢project.json 。

@yetanotherchris

（据我所知，.net 标准现在是多余的）。

是什么让你这么说？ Netstandard 不会随着项目的变化而消失，它会继续存在。 您将能够在未来的 csproj 文件中定位网络标准。 Netstandard 是绝对必要的。 他们放弃 project.json 的主要原因之一是统一整个 .net 生态系统，而这也是 netstandard 带来的。

我认为我的主要观点是将其称为候选版本有点愚蠢，因为它会在最终版本中完全改变。

我在一定程度上同意这一点，尽管我认为它的变化并不像人们想象的那么大。 首先，project.json 仍将用于 RTM，所有更改都将在此之后发生。 然后你可能会问，如果它会改变，为什么称它为“Final”，也许有一点，但最终你的所有代码和库以及所有没有改变的，只是项目 _definition_。 这并不像人们最初想象的那么大，尽管肯定会有一些迁移乐趣。

@yetanotherchris你必须记住 rc2 是预览版，所以你也必须从 3rd 方寻找预览包
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

我不知道 NUnit 是否会在以后支持，但现在在 .NET Core 和 ASP.NET Core 项目上人们正在使用 xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris我想我们都同意 rc1 应该被标记为 beta9，rc2 是第一个真正的 rc 质量版本
project.json 等工具本身不是框架的一部分，即使框架是 RTM，工具也将保持预览状态并可能会更改一段时间

如果我们带回来，我什至不会感到惊讶——也许我们确实保留了一个 project.json，它只适用于有限的场景。 如果这是人们想要的，我们会接受这个想法。

Scott Hunter， dotnetConf 2016 第 1 天主题演讲12m24s

有谁知道 Hunter 先生在 GitHub 上吗？ 并监视产品论坛中的喋喋不休？ 从它的声音来看，他错过了这里的反馈。

作为 .NET 和 Visual Studio 的程序经理，我怀疑@coolcsh 是否真的有空闲时间。

如果他不知道所提供的反馈，我会感到非常震惊。 也许不是所有的细节，但肯定有重大的阻力。

大家的机会来了：
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你是企业移动开发者还是企业 UWP 开发者？ 还是企业统一开发？

以上都不是。 我们为资产管理和银行整合编写核心系统。 还有一些网上的东西。

@shederman我怀疑这可能是你没有被问到的原因？

请澄清？

你真的是说 MS 现在唯一支持的企业开发者是那些为 1% 的市场做移动工作的人，嗯，UWP 应用程序，5% 的用户关心，以及游戏开发？ 走出发展的整个光谱，MS是把他们的一切但回来？

嗯。 不。

我是说这些变化是在与_那些_团体交谈后发生的，所以这就是为什么没有问你的原因。 Microsoft 必须支持所有的开发人员，而不仅仅是 asp 开发人员。

是的，所以如果他们要支持所有开发人员，也许他们应该与所有开发人员交谈。 也许仅与选定的 5% 的企业开发人员进行交谈并不是衡量整个企业开发人员意见的好方法。

那么，要听取大银行的意见，我们必须将所有开发切换到 UWP/Unity/Mobile 吗？

这是荒谬的。

也许他们应该与所有开发人员交谈。

这不是他们过去两年多一直在做的事情吗？

@shederman所以仅仅因为_你个人_没有被问到，你是在暗示没有其他人涉及你的开发范围？

另外，不要再编造这些数字了——_那_太可笑了。

@poke我在

我实际上认为这些数字非常慷慨，但还好。

@shederman我认为你对整件事看得太多了。 过去 2 年的重点一直集中在 asp.net 方面，但是随着 .net core 的消息开始传播，很多人开始问“我如何使用它？”。 这是不是有些回房的交易，这是人们要求从字面上年。 你只需要环顾四周，就会看到很多人想要更多来自 .net core 的东西。

还有一个来自大型组织的实际企业支持请求的问题，他们想知道如何将他们现有的东西移植到跨平台——你可能没有被“问到”，因为你不需要来自微软的人告诉你什么你试图做的事情超出了项目的范围。

另一种看待它的方式——以及我个人看待它的方式——是你被问到，你被问到几个月前宣布的第二个。 对于所有的人都说决定是在没有咨询任何人的情况下做出的呼声，微软一再表示他们仍在制定细节，他们仍然没有把最后的部分放在一起，现在是发表意见的时候了。 Scott Hunter 甚至说，如果人们_真的_想要 project.json 作为一个选项，他们会考虑保留它。 如果您不相信我，请观看 dotnetconf 主题演讲。

@neoKushan我很感激 Scott 后退了一点说他们会考虑保留它，但确实需要一个单一的、集中的点让人们表达这是他们想要的，否则 project.json 问题会不断出现到处讨论。 这也意味着当它被提出时，每个人都可以用同样的方式回答“嘿，如果开发人员真的想要它，他们会考虑保留它，这是你让他们知道的地方”。

project.json是一个很好的步骤。 但在我看来，这太天真了。 它没有考虑到人们希望使用 C++ 或 F# 编写的混合项目。 他们的一些早期设计决策（如 dnx 和使用 nuget 作为组装单元）对于整个 dotnet 生态系统来说是不可行的。 您所看到的是，在为 dotnet 带来和谐的过程中，他们必须做出这些艰难的选择。

在我看来，分叉和重新发明无助于 dotnet 生态系统，只会伤害它。 Node 和 Go（尤其是 Go）对初学者非常有吸引力，因为它们具有同质且一致的平台/工具。

我发现整个 XML 与 JSON 的争论很愚蠢，因为再过 5 年，它将是 JSON 与 YAML，然后是 YAML 与 Groovy（例如 gradle）。 XML 并不像大家所说的那样邪恶。 MSBuild 非常成熟，并在其中进行了大量投资，这将使每个人受益。

这就是说，工作有很多需要用的MSBuild做是为了确保你能获得相同或者在使用和编辑的csproj文件的最起码不那么痛苦的样子。 然后将 nuget 依赖项移动到 nuget.json 文件。 使用约定优于配置，这样如果您在“快乐路径”上，您的 csproj 将几乎是空的，有点像今天的 web.config。 然后有调整 csproj 的 cli 选项

对我来说，我会想念 project.json 但不是因为你认为的原因.. C# 项目会很好。 我会因为 F# 而错过它，我更喜欢编辑 project.json 以进行编译排序，而不是编辑 msbuild。 再次不是因为 xml 是邪恶的，而是因为 fsproj 文件有很多由 msbuild 带来的膨胀

我对这个决定的问题主要是 csproj 文件与 xml/json 的关系较少，而更多地是关于他们选择包含在 csproj 文件中的内容。 它包含项目定义，包含 IDE 设置，包含构建步骤，包含引用...

没有很多东西_没有_最终出现在那个东西上。 这让它变得很糟糕，而且只有在不得不处理 msbuild 有时相当神秘时才会变得更加复杂。 如果您真的对让 .NET Core 变得更好而不只是工作感兴趣，那么让项目文件与构建工具无关。 我应该能够指定我的项目是什么以及它依赖于如何构建它。 更不用说这开始允许我们选择工具，即使初始选项现在只是由 msbuild 支持。

我同意这一点。 归根结底，csproj 的关键问题是
它无所不能。

我喜欢中间立场 PatriotBob 建议...

在星期二，2016年6月21日在下午1时28 PatriotBob [email protected]写道：

我对这个决定的问题主要是 csproj 文件较少
关于 xml/json 以及更多关于他们选择包含在 csproj 中的内容
文件。 它包含项目定义，它包含 IDE 设置，它
包含构建步骤，它包含参考...

没有很多东西_没有_最终出现在那个东西上。 这使它
可怕，只有在必须处理 msbuild 时才会变得复杂
有时相当神秘。 如果你真的有兴趣让 .NET Core 变得更好
而不仅仅是工作使项目文件与构建工具无关。 我应该
能够指定我的项目是什么以及它依赖于什么
如何构建它。 更不用说这开始允许我们选择
工具，即使初始选项现在只是由 msbuild 支持。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911，或者静音
线程
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

整个 XML 很糟糕，JSON 很棒，大肆宣传过度。 我喜欢 PatriotBobo 所说的。

完全从npm的package.json管理 as/w 项目从未如此简单和简洁地声明我的项目，构建我的项目，升级我的项目（例如 greenkeeper），读/写/解析数据关于我的项目，发布我的项目如此简单。 _太简单。 和我们许多人一样，我的历史是在 c++/java/python/node 中，在其他人中发挥作用。 我现在渴望在我所有的项目中都有npm体验。

project.json承诺会产生这些相同的特征。 我认为这是一个值得效仿的模型，并且不牺牲简单性和功能。

如果团队 .net 核心团队认为其他解决方案可以为他们提供这些特质、优秀和力量！ 但是，请不要随着您的进步而破坏简单中的美感。

另外，我知道我现在只是一个巨大的线程中的噪音。 也许版主应该考虑关闭它并以更可控的方式处理这场考验。 很多很好的反馈。 也许也有点拖钓:$ :)