Bower、Grunt 和 Yeoman 等工具最近大受欢迎。
每当我读到它们或在一篇文章中遇到它们时，我都会将它们视为用于基于 Mac 的前端开发人员或基于 PC 但不在 Microsoft 堆栈中的工具 - Sublime Text 等。
Visual Studio 有 NuGet、项目模板、MSBuild、MSDeploy、TeamCity/TFS Azure 等，我通常认为 VS 是一个高度自动化的生态系统（有人说它让我们以理解为代价提高生产力）。
ASP.NET 开发人员在 VS 上如何使用这些工具？
注意：这不是一个基于意见的问题，我正在寻找如何使用这些工具的真实示例。
【问题讨论】：
标签： asp.net-mvc gruntjs web-deployment yeoman bower
Visual Studio 有一个 Package Intellisense 扩展，它添加了 bower 和 npm 包支持
Grunt/Gulp launcher 用于启动 grunt/gulp 任务的扩展
阅读 Scott Hanselman 撰写的这篇精彩文章了解更多信息：
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
更新：
这些功能现已完全集成到 Visual Studio 2015： http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
约翰爸爸的好建议： http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
【讨论】：
根据 Scott Hanselman 的博文，他谈到了 VS 开发人员可能希望支持这些工具的原因：
有些人可能会问，为什么不使用 NuGet for JavaScript？为什么不延长 用于构建 CSS/JS 的 MSBuild？简单的。因为已经有钱了 这种东西的生态系统。 NuGet 非常适合服务器端 库（和一些客户端），但还有更多的 CSS 和 JS npm 和 bower 上的库。 MSBuild 非常适合服务器端构建，但可以 在构建客户端应用程序时过于矫枉过正。
所以，两者都用。这些是您工具包中的工具。添加支持 Gulp、Grunt、Bower、npm（以及其他东西，如果需要，将来会用到） 意味着前端开发人员使用 ASP.NET 和 它为 ASP.NET 开发人员引入 JS 和 CSS 打开了大门 图书馆社区每天都在使用。
尽管我仍然会对其他人对这些工具如何适应 VS 开发人员的“工作流程”的看法感兴趣。例如，“在我安装 Grunt 之前，我无法轻松地......等等。”
更新
我会在学习的过程中在这里贴上一些更新。
所以，新的学习 1：Yeoman 搭建前端、客户端代码。 VS 搭建服务器端的东西和项目模板（几个月/几年都不会改变），而 Yeoman 可以帮助为快速变化的 JS MV* 框架提供样板。
新知识 2：工具还没有为黄金时段的企业开发做好准备。
第一个问题是 npm 将依赖包下载到嵌套的子文件夹中，并详尽地递归此模型，因此您最终会得到 100 个字符长的文件夹路径。 Windows 和一些工具发疯了。有一些变通方法，但这是一个严重的缺陷。
最新的节点和一些添加的命令行选项现在使其表现更好。
运行 Windows 的开发人员通常处于企业设置中，这意味着代理过滤器和身份验证。对我来说，我需要安装 Cntlm 本地代理来让 NPM 和其他工具通过我们的代理工作，这违反了我们的 IT 政策，我只是没有告诉他们。
一些 NPM 包似乎想使用 SSH 克隆 Git 存储库！ 22端口未打开；因为这个社区非常不以 Linux/Mac 为导向，所以会出现此类问题，因为它们对这么多创意机构开发人员来说不是问题，然后可以闲逛数月。
关于学习 3 的更新，我们创建了一个仅转换配置文件的构建，然后我们使用 MSDeploy 命令行将文件单独复制到目标服务器。如果我一个人工作，我不会做任何事情，它需要数周时间才能将这一切自动化。
【讨论】：
使用 Bower，更新速度更快。每次发布新版本或更新时，我们都可以在 Bower 中轻松找到它。您不再需要像我们使用 NuGet 时那样等待。
因此我们可以说 NuGet 继续成为服务器端的王者，但 Bower 是客户端领域的新王。
查看这篇文章了解更多详细信息，并查看一个简单示例： http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
【讨论】：
从企业和休闲开发的角度回答最初的问题......
历史
Visual Studio 一直是用于高效构建桌面、移动和 Web 的大型企业应用程序的标准开发工具。这包括使用 Forms、MVC 和 .NET Framework 构建的客户端和服务器端 Web 应用程序。当然，让 Visual Studio 如此吸引人的是它背后的强大功能，它使开发人员能够通过项目模板快速生成或支架通用解决方案 - 让开发人员能够专注于解决业务问题。
对于使用少量库并需要最少数据交互的简单客户端网站，WebMatrix 等工具通常就足够了，因为它是轻量级的并且能够轻松地为网站提供服务。
其中许多工具和技术可以在 Microsoft /web 找到。
分歧
与此同时，已经存在一个新兴的开源社区，该社区一直在开发许多库和框架，这些库和框架在构建现代网站和 Web 应用程序方面越来越受欢迎。
对于使用“Microsoft Stack”技术的开发人员，最初通过将NuGet 集成到 Visual Studio 中来弥补这一差距。许多（但不是全部）库和框架都以 NuGet 包的形式提供；微软为使用这些技术提供了大量支持。微软还创建了自己的开源迷你生态系统CodePlex，以支持项目的开发和共享，通常以某种方式专注于他们的技术。
不幸的是，虽然技术的可用性对于 Microsoft 开发人员来说是最新的，但要跟上技术变得越来越具有挑战性，因为它不仅关乎库和框架，还关乎工作流程和这些技术的方式提供、集成和使用。
此类工作流程包括：
不幸的是，其中大部分是手动过程，例如为工作确定正确的包或编写最终可以自动运行的不同任务。每一个都是真正的主题！最终简单地查找包或命令以查找最终可能（Visual Studio 开发人员会说应该）自动化的东西并不罕见。
收敛
微软一直在慢慢地从不仅支持开源开发，而且拥抱它。它通过GitHub 以及它自己的.NET Foundation 运动向开源社区提供了许多核心技术。
Microsoft 进行融合的一项主要工作是为多个平台引入 Visual Studio Code - 提供简化的开发体验，以迎合开源社区中流行的工作流程。
不过，对于习惯了 Visual Studio 通过其任务和项目模板的自动化提供的强大功能和简单性的开发人员来说，Visual Studio Code 可以被视为一个重大的退步。微软为2010 和2013 版本推出了Web Essentials 以跟上步伐；但正如许多人所观察到的那样，这只是为了表示支持，而不是完全集成到开发人员工作流程中。
在幕后，微软希望将其 .NET Framework 放到其他平台上，并建立了 .NET Core。从 Visual Studio 2015 开始 - 特别是 Update 3 和 Node Tools - 通过集成 NPM 和 Bower 以及任务运行，对开源开发工作流的支持更加深入。这些仍然需要手动干预，但它与 Visual Studio 之外的工作流相当。它仍然感觉很陌生，但它正在到达那里。
未来
凭借 Microsoft 的所有投资，很明显，下一步是通过为 Visual Studio 开发人员提供更加可视化和自动化的体验，整合为拥抱开源开发而采取的许多步骤。这将包括生成富 Web 应用程序的模板，这些应用程序不仅定义了所有必要的包和依赖项，而且能够捆绑分发。
与此同时，我认为这是让 Visual Studio 开发人员了解当前工作流程的好时机，如果只是为了欣赏“其他人”的工作方式。用不了多久，大部分内容只需点击一下即可。
【讨论】：