绿野项目通常充满了乐趣和激动人心的元素。这是一个全新的事物，没有遗留代码的拖累或不必要的挫折。终于有机会以正确的方式做事。然而，这种兴奋感也有其另一面：新绿野项目的趣味性和灵活性也伴随着在项目初期做出艰难的技术决策的无与伦比的责任。任何参与过长期项目的开发人员都会告诉，有些东西不能在项目开发过程中随意更改。至少，没有投入数百小时的努力去修正。应该使用ORM还是手写ADO.NET？选择ASP.NET Core 1.0还是经过验证的ASP.NET 4.6？MVC还是WebForms？在项目开始时做出的艰难技术决策可能会影响多年！
为了选择ASP.NET技术栈提供一些指导，请观看这个关于选择正确的技术栈的点播网络研讨会。
因为这是一个挑战，许多开发人员会专注于选择堆栈的技术方面，而完全忽视了开发人员本身。如果是项目的技术总监，不能在没有充分了解团队会如何接受的情况下宣布“将使用这个堆栈”，或者甚至只是了解项目需求是什么。
罗伯特·弗罗斯特有一首诗，每个美国高中生都必须背诵。黄色树林里分出两条路，可惜不能同时涉足。* 技术栈也是如此。有两条路：一条是走得很熟的路，一条是杂草丛生的路。选择哪一条？
首先，可以检查走得很熟的路。ASP.NETWebForms已经存在了十五年多。有成千上万的博客文章涉及WebForms的各个方面。随着它多年来的成熟，大多数文档仍然相关。尝试谷歌搜索“(something) webforms”，将得到成千上万的结果。所有这些结果可能仍然值得检查和使用！
ASP.NET MVC 5是经过验证和前沿之间的中间地带。随着ASP.NET Core1.0的出现，使用ASP.NET 4.6上的MVC 5有点像在新车下周发货时购买一辆比一款车型年老的车。然而，就像汽车一样，文档和开拓性的工作已经发生了。从以前的早期采用者的所有辛勤工作中受益。
ASP.NET Core 1.0是杂草丛生的路。如果朝下看，会看到一些开发人员绊倒了。有些人可能卡在洞里。路的尽头是个谜，因为从站的地方看不到。问问自己，“有多冒险？”
有严格预算和截止日期的项目不适合使用前沿技术。那场对话进行得并不好。
"下周的发布都准备好了吗？"
"不。原来ASP.NET Core还不支持SmtpClient，所以不得不推迟几周。"
就个人而言，喜欢保持在中间，倾向于前沿。工作要求解决业务问题，并不要求特定的技术栈。对于当前客户的项目，正在冒险进入ASP.NET Core，遇到的障碍比预期的要多。
开拓者需要意识到并花时间。通过他们的努力，其他跟随的开发者的道路将会更清晰。
当过去雇佣开发人员时，指标并没有太关心一个人知道什么，而是他或她能多快地学习。
在选择堆栈时，评估负责实施堆栈的团队是很重要的。一个专注于开发WebForms的开发人员可能很难转向ASP.NETMVC或WebAPI暴露的更复杂模式。
一个同事讲述了他以前的一个老板的故事，他有过期的软件开发背景。在故事中，老板花了几个月的时间试图了解C#的工作原理，他试图根据书籍和在线教程中复制的知识拼凑出一个WinForms应用程序。有一天，老板叫同事到他的办公室，让他解释什么是类。
目标不是疏远开发人员。每个人以不同的方式和不同的速度学习。在选择技术栈时，需要保持意识，谁会实施解决方案，如果他们心理上能够承受处于前沿的压力。
什么更好？一个在旧技术上的完整解决方案，还是一个在前沿上的不完整解决方案。
项目需要什么？
所有项目都是独一无二的雪花。客户的需求会从“只需要比这个电子表格更好的东西”到“想要像Facebook那样的东西”。
简单的“表单上的数据”应用程序不需要用Angular 2或React构建的单页应用程序。一个小团队的开发人员需要几周时间来实现的复杂解决方案，一个开发人员在几个小时内就可以用WebForms完成。
大型单体Web应用程序有一套不同的需求。希望这些项目以最少的功能启动，但最终会膨胀到大小和复杂性。在更前沿的方法上投入的时间将来会得到回报。
作为决策者的目标是权衡项目的需求和可用的工具 - 甚至在某些情况下，看看地平线上的工具。如果项目只是表单上的数据，也许坚持使用像ASP.NETWebForms这样简单的东西。如果预见到项目随着时间的推移会变得复杂，也许从ASP.NETMVC和WebAPI堆栈开始，以后可以集成前端框架，如Angular或React。
在寻找完美技术栈的过程中，另一个需要考虑的重要因素是构建项目的团队规模。
有幸在小型团队（一两个人）工作过，也参与过遍布世界各地的多人团队。
作为一家初创公司的CTO，团队接触到了能找到的最前沿的技术。在一天的过程中，会将十几个版本部署到生产中。有一个相互协议和对项目的尊重，团队凝聚力允许在工具、库或框架上做出快速、不计后果的决策。如果工具不起作用，没关系 - 扔掉它，试试另一个。
如果再次走上创业之路，会引导团队采用ASP.NET Core。即使在它的初期，这个平台也有潜力让比以前的ASP.NET版本更灵活。
大学毕业后参与的第一个主要开发团队是一家大型安全公司，为防病毒软件开发组件。这个团队的进展要慢得多。要求是每季度部署一次，软件支持十几个操作系统。使用的框架和工具的变化影响了世界各地的几十个开发人员。
如果实施了变化，团队也需要准备应对反弹。如果没有考虑每一个角度会发生什么？如果遇到障碍，B计划是什么？谁做出如何导航障碍的决定？
请不要误会；有些大型团队完全能够快速部署，并在项目需要时迅速改变方向。论点是，参与过的大多数大型团队绝对无法以这种能力工作。如果有一个30人的团队，告诉他们使用ASP.NET Core 1.0，这是ASP.NET开发人员可以使用的最前沿，那么需要预期他们每两周调整一次API破坏性变化。在没有发疯或最终推迟时间表的情况下，很少有大型团队能够做到这一点。
有时希望决策只是一个位和字节的问题，但有许多人为因素需要考虑。
可以给出的最好建议是讨论团队中每个选择的利弊。如果团队完全参与到做出技术决策的过程中，产品结果会因为这一点而更好。
那么ASP.NET堆栈中有哪些工具呢？Jeremy Likness有一篇关于ASP.NET开发工具当前状态的优秀文章。使用Jeremy文章中讨论的工具开始与团队对话。