10年前，当我开始使用.NET Framework 3.5（语言版本3.0）时，对我来说，它的功能非常有限，就像我从SharePoint 2010开始一样。逐渐研究更广泛的技术并随着.NET的发展，我我可以注意到它从可疑的竞争者到Java的巨大增长，到能够为Linux开发守护程序的酷跨平台（并且专门用于Windows）。 当然，当我第一次接触技术时，似乎一切就足够了：毕竟，有实现目标的方法。 但是现在，有了在不同平台及其不同版本上工作的经验，我们已经可以推测，在那个遥远的时代，生活是痛苦的。
总的来说，如果让我重新回到那个时代，并在“过去-它已经成为”的背景下共同思考.NET，那很有趣，那么我邀请你来关注。 我认为这对于那些最近编写代码并且不了解先前版本功能的人以及想要沉迷于怀旧之情的人来说都是很有趣的。
痛苦时代
当我开始开发时，SharePoint 2010在.NET Framework 3.5上工作，并且已经包含很多内容：LINQ出现了，并且有原始的AJAX。 但是它受到平台的限制，因为很难扩展它，那时根本没有足够的工具。
痛苦1：创建一个应用程序然后，用于开发“球” Web部件的技术是基于WebForms的，每个Web部件实质上是一个单独的应用程序。 就我个人而言，以这种方式创建单个应用程序是不现实的，因为在开发Web部件时，它们每个都初始化其自己的上下文以连接到数据库-结果证明无法创建单个上下文。 好吧，例如，为了在页面上显示数据库中的数据，我使用了SqlDataSource（通过分别连接到小部件中的数据库），并连接到3-4个表，我在小部件上拥有3-4个DataSource，当然，影响页面加载速度。 到那时，ADO.NET实体框架已经出现，但是在4.1版之前在SharePoint中使用它并不方便，因为 产品交互存在问题。
痛苦2：无法获得支持和模式我们针对SP 2010的Web部件撰写了有关创建Web部件SP 2007的技术的文章，因为 2008年工作室没有模板或支持。 随着Visual Studio 2010的发布，它们的模板逐渐出现，并且变得更容易工作：可以从Studio中创建列表定义并对其进行编码，从而创建网站模板（对所需的内容类型和列表描述进行编码）。 以前，所有这些操作都是通过手动编辑XML文件来完成的，对于那些只专注于.NET开发的人来说，这无疑是一个痛苦，因为该人员不了解自己正在编辑哪种文件以及出于何种目的，而只专注于叔叔在论坛上的话。
痛苦3：异步...在.NET Framework 3.5中，没有现在知道的异步形式-我们必须在另一个线程中运行某些代码，通过委托处理程序进行通信，并且在WinForms中可以使用工作人员的后台（即第二个进程）并行运行以执行工作）。 事实证明，已经存在异步应用程序的编程，但是对它们的实现令人难以理解。
在.NET Framework 4中，出现了任务并行库，因此任务也出现了，即 我们无法声明委托，而是执行任务，将操作传递给它，然后在并行线程中执行它，了解状态/状态，并在必要时接收有关其实现的信号。 当您需要处理大量数据时，并行开发已经取得了进展，因为在此之前需要进行更大的输入。
...和冷冻的窗户您需要了解，Web与控制台应用程序的开发有很大的不同（这里的意思不是全局命名，而是用于描述这些内容的名称：不是专门用于ConsoleApp，而是在OS界面中运行的所有应用程序）。 在控制台应用程序中，默认情况下所有操作都是同步执行的，并且如果处理时间较长，则界面将“冻结”，就像冻结应用程序一样。 为了不感到程序没有响应，我们在单独的线程中执行了所有操作，并输入了进度条：这样，用户可以看到应用程序的活动，并且可以通过委托从另一个线程进行控制。
痛苦4：部署即将来临同样在.NET Framework 3.5中，还有另一种痛苦的技术-MS AJAX。 UpdatePanel内容是从后端更新的，而其他所有内容则根本没有重建。 在SharePoint中，由于在页面生命周期中初始化控件的细节，他的工作非常弯曲。 在这里，它在第一次回发后（有时在第二次回发之后）为我们工作，并且通常很难使MS AJAX第一次正常工作，尽管它是从干净的WebForm UpdatePannel中非常简单地使用的。 在那个版本的“球”中不可能使用经典的AJAX（XMLHttpRequest），因为对于每个动作，必须在背面编写一个单独的处理程序并将它们挂在每个Web部件的包装中。 同时，并非总是可以关闭此功能。
当我与在WebForms上编写的其他应用程序并行处理“近球”任务时，令我惊讶的是，将项目部署到SP的问题仅是SP的问题。 目前，其余的应用程序已初始化：窗口已加载，并且可以正常运行（魔术！）。 在气球中，部署花费了2到3分钟，并且您处于一个恒定的周期中：
总的来说，每个人都知道这是一个漫长的部署和小型中断过程。 但是我为这种痛苦而感激-因此我学会了在一次开发迭代中生成更多的代码并减少错误。
痛苦5：Windows，仅Windows当时，.NET仍将自己定位为Windows的开发平台。 是的，有一个Mono项目，从本质上讲，它是.NET在Linux上的“自行车”，但它是主框架的替代版本，仍在项目页面
www.mono-project.com/docs/关于单声道/兼容性 ）列出了Framework版本未添加到其中的功能。 当您为Linux开发某些东西时，它远非友好的用户，因为Mono没有这种支持和社区，如果您转向一些未实现的东西，那么代码可能会被破坏。 也就是说，如果您最初不为Mono开发它，那么原则上就不能编写与平台无关的代码。 我不排除这个项目对整个.NET开发的重要性，因为没有它，Core不会出现，但就我个人而言，我没有任何战斗经验。
职业时代（止痛药）在他们的项目中完全使用纯.NET最新版本消除了几乎所有这些问题。 框架现在有很多优点，但是接下来我们将讨论绑定到Core的优势，因为 我和他一起工作。
加1：效果当.NET Core出现时，可以更轻松，更快速地执行熟悉的操作。 它上的最终应用程序根据某些数据的运行速度比.NET Framework上的同类应用程序快5000倍。 但是，编译和启动有时会花费更长的时间-“利用很长时间-加快速度”。
加2：跨平台.NET Core的主要优点是，编写的代码可同时在Windows，Linux和Mac上运行。 在这种情况下，您可以通过消息队列在异步日志记录服务的微服务架构上编写应用程序。 我还记得我主要是在Windows下编写程序的开发人员如何在Linux下编写恶魔（服务）的情况，并且它们第一次稳定，快速地工作，并且整个系统协同工作：在应用程序，API服务和消息队列本身中。 当您在通常不是为此操作系统设计的平台上使用惯用语言编写时，这仅仅是空间！
加3：一切异步现在可以不以并行，不是多线程的方式而是完全异步地写支持（！），这使您可以将主流中的各个任务删除为特殊的异步方法或代码块。 反过来，这使您可以编写美观，简洁的代码，而无需使用笨重的结构：这易于理解，异步方法被编写为同步方法，并可以按需工作。
Plus 4：卸载库并减少密集的内存消耗如果您看一下当前的C＃的第8版，那么它有很多糖，而且变化令人着迷。 首先，在我们没有能力动态卸载最初卸载的DLL之前（我们将库动态加载到项目中，但是它们仍然挂在内存中）。 随着3rd Core的发布，可以根据目标动态地加载和卸载库。 例如，如果我们要创建文件搜索应用程序，并且用户选择了XML扩展名，我们将动态加载XML解析器以获取文档并在其树中进行搜索。 如果我们要通过JSON进行搜索，那么我们就开始按其主体进行搜索-依赖于某些条件的库，无需将它们保存在RAM中。 是的 该应用程序已停止不断消耗内存。 卸载程序集时，我们将释放附着在该程序集上的所有资源。
加5：元组该语言还很年轻，充满活力并且正在积极发展。 最新版本增加了很多很棒的功能：例如，元组是一个活跃的话题。 是的，以前有元组，但是作为一个单独的类，其中包含许多元素。 现在，当我们可以创建一个不返回1对象，而是返回多个对象的方法时，它已转换为元组。 以前，要返回多个参数，必须声明一个输出/引用参数，或者发明一个单独的类并将其进一步拖动，但是现在您可以将其作为元组返回。
总结一下！许多开发人员对语言更改持这样的态度：直到做得好，我们才知道有什么不好。 .NET Core是一个开放源代码，因此任何人都可以自己添加功能，并在门户网站上写出他们的痛苦。 当然，存在许多有争议的问题：某人正在等待对其他人来说似乎完全不舒服的更改。 例如，该语言的版本8包含对Nullable引用类型的控制，到目前为止，便利性问题是有争议的：此创新是在2个以前的版本中宣布的，并且仅包含在最终的Core 3.0中，并且默认情况下，此功能是禁用的，因为它的包含可能导致重大项目的分解。 但是，从头开始编写应用程序时，它非常有用，它可以使您的应用程序更加干净透明。
以我的观点，现在该平台已经在开发世界中扮演了重要角色，入门门槛相当低（甚至更低，但在它们上进行开发更加困难）。 当然，选择一个平台意味着要考虑许多因素并取决于目标。 如果这是一个处理兆兆字节数据的复杂应用程序，并且需要在字节之前进行验证，那么这是一个复杂的编程。 但是您需要了解，对于开发来说这是半年，而对于修订版来说，则是两年，到发布时，它已经过时了。 此外，为加号编写代码的人并不多。 如果我们谈论的是企业发展，那么发布时间为2周，那么选择另一种有助于更快获得最终结果的技术（Java，.NET，php）是有意义的。