What's going on with ASP.NET Core 1.0 RC2? Why is RC2 taking so long over RC1 and what's going to happen between now and the final release? I talked to architect David Fowler about this and tried to put together some clear answers.
ASP.NET Core 1.0 RC2怎么了？ 为什么RC2比RC1花费了这么长的时间，从现在到最终版本之间会发生什么？ 我与建筑师大卫·福勒(David Fowler)讨论了这一问题，并试图给出一些明确的答案。
This stuff is kind of deep and shows "how the sausage gets made" so the TL;DR version of this is "the guts are changing for the better and it's taking longer than we thought it would to swap out the guts."
这些东西很深，显示了“香肠的制作方法”，因此TL; DR版本是“胆量正在不断改善，而且换代所需的时间比我们想象的要长。”
That said, ASP.NET Core RC2 has some high level themes:
也就是说，ASP.NET Core RC2具有一些高级主题：
重新电镀在.NET CLI的顶部 (Re-plat on top of the .NET CLI )
This is the biggest one and there are quite a few changes and tweaks made to the hosting model to support this. The way your application boots up is completely different. I'd encourage you to take a look at the https://github.com/aspnet/cli-samples. Some of the changes are very subtle but important. We baked a bunch of assumptions into DNX specific for web applications and now we're building on top of a tool chain that doesn't assume a web application is the only target and we have to account for that.
这是最大的更改，并且对托管模型进行了许多更改和调整以支持此功能。 应用程序启动的方式完全不同。 我鼓励您看看https://github.com/aspnet/cli-samples 。 其中一些更改非常微妙但很重要。 我们在DNX中为Web应用程序特定了很多假设，现在我们在一个工具链的基础上构建，该工具链并不假定Web应用程序是唯一目标，因此我们必须考虑到这一点。
There were a couple of fundamental things affected by this move:
此举影响了一些基本方面：
Acquisition
取得
- How do you get the tool chain and shared runtime? 您如何获得工具链和共享的运行时？
Runtime
运行
- The API used to find dependencies at runtime ILibraryManager 用于在运行时查找依赖项的API ILibraryManager
- The API used to find compilation assemblies at runtime ILibraryExporter 用于在运行时ILibraryExporter查找编译程序集的API
Tooling
工装
The list goes on and on. I'd suggest watching the ASP.NET Community stand up as we're pretty transparent about where we are in the process. We just got everyone internally using builds of Visual Studio that have CLI support this last week.
清单一直在继续。 我建议观看ASP.NET社区站起来，因为我们对流程的位置非常透明。 上周，我们内部使用了具有CLI支持的Visual Studio版本，使每个人都在内部使用。
The new .NET CLI (again, replacing DNX) will be the most de-stabilizing change in RC2. This is a good intro to where things are headed https://vimeo.com/153212604. There's been tons of changes since then but it's still a good overview.
新的.NET CLI(再次替代DNX)将是RC2中最不稳定的更改。 这是关于https://vimeo.com/153212604的内容的很好的介绍。 从那以后发生了很多变化，但是仍然是一个很好的概述。
转向网络标准 (Moving to netstandard)
This has been a long time coming and is a massive effort to get class library authors to move to the next phase of PCL. This is critical to get right so that everyone can have their favorite packages working on .NET Core, and as such, working everywhere.
这已经是很长一段时间了，这是使类库作者转移到PCL下一阶段的巨大努力。 这对于确保正确无误至关重要，以便每个人都可以在.NET Core上使用他们喜欢的软件包，从而可以在任何地方使用。
https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Class-Libraries
https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Class-Libraries
https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
抛光 (Polish)
We're looking at all of the patterns that we have invented over the last 2 years and making sure it's consistent across the entire stack. One example of that is the options API. We went through the entire stack and made sure that we were using them consistently in middleware and other places. That is a breaking change but it's an important one.
我们正在研究过去两年中发明的所有模式，并确保在整个堆栈中保持一致。 选项API就是一个例子。 我们遍历了整个堆栈，并确保我们在中间件和其他地方始终使用它们。 这是一个重大的变化，但这是一个重要的变化。
Other examples of this include things like making sure we have the right extension methods in places and that it looks like they were designed in a coherent manner (logging is an example).
其他例子包括确保我们在适当的地方拥有正确的扩展方法，并且看起来它们是以一致的方式设计的(记录是一个示例)。
Other small things:
其他小事情：
- Remove the service locator pattern as much as we can. Some of this requires API change. 尽可能删除服务定位器模式。 其中一些要求更改API。
- Making sure we have the right set of DI abstractions so that DI vendors can properly plug into the stack. 确保我们拥有正确的DI抽象集，以便DI供应商可以正确地插入堆栈。
- Taking the time to look at feedback we're receiving to make sure we're doing the right things. This is ongoing, but if there are small changes we can make that solve a common issue people are having, we'll make that change while we still have this freedom. 花时间查看我们收到的反馈，以确保我们做正确的事。 这项工作正在进行中，但是如果有一些小的更改，我们可以做出解决人们遇到的常见问题的更改，那么我们将在仍然拥有这种自由的同时进行更改。
Change how we plug in and configure servers in our Hosting APIs https://github.com/aspnet/KestrelHttpServer/pull/741
更改我们在托管API中插入和配置服务器的方式https://github.com/aspnet/KestrelHttpServer/pull/741
基本原理-压力，安全性，性能 (Fundamentals - Stress, Security, Performance )
This is always ongoing but now that most of the features are done, we have more time to spend on making things like Kestrel (the web/app server) rock solid and secure.
这项工作一直在进行中，但是现在大多数功能都已完成，因此我们有更多时间花在使诸如Kestrel(Web /应用服务器)之类的东西坚固而安全上。
We're also doing more stress runs to make sure the stack is very stable memory wise and to make sure nothing crashes .
我们还在做更多的工作，以确保堆栈在内存方面非常稳定，并确保没有崩溃。
更高的性能 (More Performance )
This is part of fundamentals but deserves to be called out specifically. We're still making changes to make sure things are very "performant." Some of these are tweaks that don't affect consuming code, others are actual design changes that affect API. MVC is getting tons of love in this area (https://github.com/aspnet/Mvc/pull/4108). HttpAbstractions and other higher level APIs are also getting lots of love https://github.com/aspnet/HttpAbstractions/pull/556 to make sure we reduce allocations for things like file upload.
这是基础知识的一部分，但值得特别提及。 我们仍在进行更改，以确保一切都很“顺利”。 其中一些是不会影响使用代码的调整，其他是会影响API的实际设计更改。 MVC在这个领域越来越受欢迎( https://github.com/aspnet/Mvc/pull/4108 )。 HttpAbstractions和其他更高级别的API也受到了很多青睐，例如https://github.com/aspnet/HttpAbstractions/pull/556 ，以确保我们减少文件上传之类的分配。
We're also looking at higher level scenarios to make sure that not only focusing on microbenchmarks. You can see some of them at https://github.com/aspnet/Performance/tree/dev/testapp.
我们还在研究更高级别的方案，以确保不仅关注微基准测试。 您可以在https://github.com/aspnet/Performance/tree/dev/testapp中看到其中的一些。
Techempower is still on our radar and we're running the plain text benchmark on similar hardware now and comparing against the competition (we're in the top 10 right now!) and we'll hope to be there and official for RTM.
Techempower仍在我们的监控范围内，我们现在正在类似硬件上运行纯文本基准测试，并与竞争对手进行比较(我们现在在前十名中！)，我们希望能够在那里并正式成为RTM。
I hope this gives you some context. We'll cover this and more every week on the Community Standup as we move towards RC2, then on to RTM on three platforms!
我希望这能给您一些背景信息。 我们朝着RC2前进，然后每周在三个平台上转向RTM，我们将在Community Standup上每周介绍一次，以及更多。
Sponsor: Big thanks to RedGate and my friends on ANTS for sponsoring the feed this week! How can you find & fix your slowest .NET code? Boost the performance of your .NET application with the ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free
赞助商：非常感谢RedGate和我在ANTS上的朋友为本周的feed赞助！ 如何找到并修复最慢的.NET代码？ 使用ANTS Performance Profiler提高.NET应用程序的性能。 利用代码和查询的性能数据快速找到瓶颈。 免费尝试
翻译自: https://www.hanselman.com/blog/an-update-on-aspnet-core-10-rc2
扫一扫
1580
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
