简析 .NET Core 构成体系

简析 .NET Core 构成体系

出处： http://www.cnblogs.com/vipyoumay/p/5613373.html

https://github.com/PrismLibrary/   Prism是一个用于在WPF，Windows 10 UWP和Xamarin Forms中构建松散耦合，可维护和可测试的XAML应用程序的框架。

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff648465(v%3dpandp.10)   Prism在线文档

https://github.com/xceedsoftware/wpftoolkit   WPF的扩展控件库

http://avaloniaui.net/   跨平台 .net UI 框架

https://github.com/AvaloniaUI/Avalonia   源码地址

================================================

• 简析 .NET Core 构成体系
  • Roslyn 编译器
  • RyuJIT 编译器
  • CoreCLR & CoreRT
  • CoreFX(.NET Core Libraries)
  • .NET Core 代码开发、部署、运行过程
  • 总结

前文介绍了.NET Core 在整个.NET 平台所处的地位，以及与.NET Framework的关系(原文链接)，本文将详细介绍.NET Core 框架的构成和各模块主要功能，以及如何实现跨平台。

上图描述了 .NET Core的系统构成，最上层是应用层，是开发基于UI应用的框架集，包括了ASP.NET Core(用于创建web app)，和 UWP(用于创建Windows10 app)。

中间层是公共库(CoreFX),实现了.NET Standard Library ,囊括了常用系统级操作例如（文件、网络等）。

在CoreFx下是运行时环境，.NET Core 包含了两种运行时(CoreCLR、CoreRT),CoreCLR是一种基于即时编译程序(Just in time compiler,JIT)的运行时,它使用了跨平台开源的编译器RyuJIT,而CoreRT是使用提前编译器(Ahead of time compiler,AOT)的运行时,它既可以使用RyuJIT来实现AOT编译也可以使用其他的AOT编译器。由于AOT提前编译IL成了机器码，在移动设备上也具有更好的启动速度和节能性。

最后还要提到一个开源的跨平台源代码编译器Roslyn，它有别于刚才两个编译器，JIT和AOT编译器主要用于将IL编译成本机机器码，而Roslyn是将C# 或 VB.NET 代码编译成程序中间语言(intermediate language,IL)。

Roslyn 编译器

Roslyn编译器用于将C#或VB.NET代码编译为程序集(assembly)，它的编译过程是一个管道式的处理过程一共包含4个步骤，具体过程见下图。

A. Parser(解析)

根据语法对源代码进行解析。

B. Declaration (声明)

为代码生成元数据(metadata),元数据是一个数据表的集合，描述了在当前代码中定义的数据类型和成员，同时也描述了引用的类型及成员。

C. Bind(绑定)

将生成的IL代码与描述它的元数据绑定在一起，生成托管模块(managed module)。

D. Emit(生成)

将一个或多个托管模块合并生成程序集(assembly)。

RyuJIT 编译器

在程序运行中需要执行某一个方法，首先需要将已经编译好的IL转换本机的机器码，而这个任务就交给了RyuJIT。它是新一代JIT编译器，第一次实现了AMD64的架构，RyuJIT能够比JIT64(上一代编译器)更快地生成代码，以提高程序运行效率(测试详情链接)。

CoreCLR & CoreRT

CoreCLR 和 CoreRT 都是.NET Core的运行时(Runtime),
它们提供了与.NET Framework CLR 类似的核心功能(内存管理、程序集加载、安全性、异常、线程管理等)，可由面向于运行时的所有语言使用。

CoreRT 和 CoreCLR 不同的是，CoreRT 提供了一套
AOT 的机制,可以将.NET Core程序编译成原生代码，不依赖 .NET 运行时而运行在宿主机器上。除此之外两个运行时大部分功能代码是共享的，比如GC。AOT的优化带来不少好处：

• 编译后生成一个单文件，包含所有的依赖，包括 CoreRT，无需安装Framework

• 启动时是机器码，不需要生成机器码，也不要加载JIT编译器

• 可以使用其他优化编译器，包括 LLILC ,IL to CPP

CoreRT有两个方式生成机器码，第一个使用是直接编译IL成机器码，默认情况下，RyuJIT 作为一个 AOT 编译器将IL编译成机器码，另一个方式是将C#代码编译成C++代码，然后调用对应平台的C++编译器优化编译成机器码。

使用 RyuJIT 编译成机器码

dotnet restore
dotnet build --native --ilcpath <repo_root>in
ProductWindows_NT.x64.Debugpackagingpublish1

编译生成 C++ 代码

dotnet restore
dotnet build --native --cpp --ilcpath <repo_root>inProductWindows_NT.x64.Debugpackaging
publish1 --cppcompilerflags /MTd

CoreRT也有不足之处，它需要为不同平台编译一次；但凡事有但是，它允许工程师可以不发布到不想支持的平台（比如某游戏仅支持桌面，不支持手机）。

注：这两个命名在.NET Core RC2 版本中均无法使用，按照官方说法是在当前版本中已经移除这个命令了，具体等6月27日正式版发出后才知道最后的情况

CoreFX(.NET Core Libraries)

CoreFX主要包含数个公共库，例如 System.Collections, System.IO, System.Xml等。CoreFX是 .NET Standard Library 的实现，同样的.NET Framework 4.6.3也是基于.NET Standard Library的实现。它们目前都是基于.NET Standard Library1.6版本，具体见下表：

.NET Core 代码开发、部署、运行过程

从上图可以看到使用JIT编译和使用AOT编译源代码并运行程序是两种不同的流程。

如果使用JIT编译器部署程序时只需要将程序打包为IL的assemblies，在方法第一次执行前编译器将IL编译为目标机机器码(Native code)，而AOT编译会在编译时将源代码直接编译为目标机机器码。

AOT将源代码编译为机器码，拥有如下特性：

• 用静态代码替换反射，例如如果一个值类型(value type)没有重写 ValueType.Equals 的equals的方法，默认情况判断相等，会使用反射找到filedinfo以确定type是否相等，然后再比较value是否相等。而在AOT编译中由于替换了反射因此只能比较value是否相等。

• 依赖的第三方类库以及.NET Libraries均打包至最终编译的程序中。

• 打包后的程序运行在一个精简版的运行时上(CoreRT)主要包含垃圾回收器，而运行时也会打包在app文件中。

• 虽然编译时会替换反射代码，但遇动态反射代码无能为力，运行时若遇动态反射调用则会因找不到对应的元数据及实现而抛出异常。解决办法是编译前配置运行时指令文件(Runtime directive file)指定需要用到的程序集。

总结

本节介绍了.NET Core的构成体系，包括新增的多个编译器以及遵循.NET Standard Library的CoreFX,总体来说.NET Core较之前的.NET Framework 从性能和开发效率上都有很大的提升。关键是首次实现了.NET的完全跨平台能力的基础技术栈。

.NET Core 基于跨平台能力，并没有将与 GUI 高度相关的 API 移植到 .NET Core 内，因此像是 Windows Forms 或是 Windows Presentation Foundation (WPF) 并未移植到 .NET Core。.NET Core 支持控制台应用程序 (Console Application) 以及类库 (Class Library) 类型的项目。

不过微软在其 Universal Windows Platform (UWP) 开发平台使用了 .NET Core，并且利用 .NET Native 技术将其性能提升至十分接近原生码的速度。

ASP.NET Core 则以控制台应用程序驱动其托管环境 Kestrel Server 以支持 ASP.NET Core 程序的运行。

---

作者：帅虫哥 出处： http://www.cnblogs.com/vipyoumay/p/5613373.html

参考链接

【1】https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

【2】https://github.com/dotnet/corefx

【3】https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/glossary.md

【4】https://www.microsoft.com/net/core#windows

【5】https://msdn.microsoft.com/en-us/library/dn807190(v=vs.110).aspx

【6】https://blogs.msdn.microsoft.com/dotnet/2013/09/30/ryujit-the-next-generation-jit-compiler-for-net/

【7】https://zh.wikipedia.org/wiki/.NET_Core

 

===========================

https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/

.NET Core 3 and Support for Windows Desktop Applications

At Microsoft Build Live today, we are sharing a first look at our plans for .NET Core 3. The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core and enjoy all the benefits that .NET Core has to offer.

We are planning on releasing a first preview of .NET Core 3 later this year and the final version in 2019. We will be looking for developers to partner with us, to give us feedback, and to release versions of your applications in the same timeframe as our releases. We think that .NET Core 3.0 will be one of the most exciting .NET releases we’ve ever released.

ASP.NET Core will continue to move forward in parallel and will have a release with .NET Core 3.0. Our commitment to web and cloud applications remains unchanged. At the same time, it’s time to add Windows desktop applications as another supported workload for .NET Core. We have heard many requests for desktop applications with .NET Core and are now sharing our plan to deliver on that. Let’s take a look at that.

Benefits of .NET Core for Desktop

There are many benefits with .NET Core that are great for desktop apps. There are a few that are worth calling out explicitly:

• Performance improvements and other runtime updates that will delight your users
• Super easy to use or test a new version of .NET Core for just one app on a machine
• Enables both machine-global and application-local deployment
• Support for the .NET Core CLI tools and SDK-style projects in Visual Studio

We’re also announcing a set of improvements that we’ll be adding to both .NET Core 3.0 and .NET Framework 4.8:

• Access to the full Windows 10 (AKA “WinRT”) API.
• Ability to host UWP XAML controls in WPF and Windows Forms applications.
• Ability to host UWP browser and media controls, enabling modern browser and media content and standards.

.NET Framework 4.8

We’re also announcing our plans for .NET Framework 4.8. after shipping .NET Framework 4.7.2 only a week ago. We expect the next version to be 4.8 and for it to ship in about 12 months. Like the past few releases, the new release will include a set of targeted improvements, including the features you see listed above.

Visualizing .NET Core 3

Let’s take a look at .NET Core 3 in pictorial form.

Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud. We have lots of improvements planned for those scenarios that we’ll share later.

From a 1000-meter view, you can think of WPF as a rich layer over DirectX and Windows Forms as thinner layer over GDI Plus. WPF and Windows Forms do a great job of exposing and exercising much of the desktop application functionality in Windows. It’s the C# code in Windows Forms and WPF that we’ll include as a set of libraries with .NET Core 3. Windows functionality, like GDI Plus and DirectX, will remain in Windows.

We’ll also be releasing a new version of .NET Standard at the same time. Naturally, all new .NET Standard APIs will be part of .NET Core 3.0. We have not yet added Span<T>, for example, to the standard. We’ll be doing that in the next version.

C#, F# and VB already work with .NET Core 2.0. You will be able to build desktop applications with any of those three languages with .NET Core 3.

Side-by-side and App-local Deployment

The .NET Core deployment model is one the biggest benefits that Windows desktop developers will experience with .NET Core 3. In short, you can install .NET Core in pretty much any way you want. It comes with a lot of deployment flexibility.

The ability to globally install .NET Core provides much of the same central installation and servicing benefits of .NET Framework, while not requiring in-place updates.

When a new .NET Core version is released, you can update one app on a machine at a time without any concern for affecting other applications. New .NET Core versions are installed in new directories and are not used by existing applications.

For cases where the maximum isolation is required, you can deploy .NET Core with your application. We’re working on new build tools that will bundle your app and .NET Core together as in a single executable, as a new option.

We’ve had requests for deployment options like this for many years, but were never able to deliver those with the .NET Framework. The much more modular architecture used by .NET Core makes these flexible deployment options possible.

Using .NET Core 3 for an Existing Desktop Application

For new desktop applications, we’ll guide everyone to start with .NET Core 3. The more interesting question is what the experience will be like to move existing applications, particularly big ones, to .NET Core 3. We want the experience to be straightforward enough that moving to .NET Core 3 is an easy choice for you, for any application that is in active development. Applications that are not getting much investment and don’t require much change should stay on .NET Framework 4.8.

Quick explanation of our plan:

• Desktop applications will need to target .NET Core 3 and recompile.
• Project files will need to be updated to target .NET Core 3.
• Dependencies will not need to retarget and recompile. There will be additional benefits if you update dependencies.

We intend to provide compatible APIs for desktop applications. We plan to make WPF and Windows Forms side-by-side capable, but otherwise as-is, and make them work on .NET Core. In fact, we have already done this with a number of our own apps and others we have access to.

We have a version of Paint.NET running in our lab. In fact, we didn’t have access to Paint.NET source code. We got the existing Paint.NET binaries working on .NET Core. We didn’t have a special build of WPF available, so we just used the WPF binaries in the .NET Framework directory on our lab machine. As an aside, this exercise uncovered an otherwise unknown bug in threading in .NET Core, which was fixed for .NET Core 2.1. Nice work, Paint.NET!

We haven’t done any optimization yet, but we found that Paint.NET has faster startup on .NET Core. This was a nice surprise.

Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.

There are many design decisions ahead, but the early signs are very good. We know that compatibility will be very important to everyone moving existing desktop applications to .NET Core 3. We will continue to test applications and add more functionality to .NET Core to support them. We will post about any APIs that are hard to support, so that we can get your feedback.

Updating Project Files

With .NET Core projects, we adopted SDK-style projects. One of the key aspects of SDK-style projects is PackageReference, which is a newer way of referencing NuGet packages. PackageReference replaces packages.config. PackageReference also make it possible to reference a whole component area at once, not just a single assembly at a time.

The biggest experience improvements with SDK-style projects are:

• Much smaller and cleaner project files
• Much friendlier to source control (fewer changes and smaller diffs)
• Edit project files in Visual Studio without unloading
• NuGet is part of the build and responsive to changes like target framework update
• Supports multi-targeting

The first part of adopting .NET Core 3 for desktop projects will be migrating to SDK-style projects. There will be a migration experience in Visual Studio and available at the command line.

An example of an SDK-style project, for ASP.NET Core 2.1, follows. .NET Core 3 project files will look similar.

	<Project Sdk="Microsoft.NET.Sdk.Web">
	<PropertyGroup>
	<TargetFramework>netcoreapp2.1</TargetFramework>
	</PropertyGroup>
	<ItemGroup>
	<PackageReference Include="Microsoft.AspNetCore.App" />
	</ItemGroup>
	</Project>

view rawaspnetapp.csproj hosted with 

by GitHub

Controls, NuGet Packages, and Existing Assembly References

Desktop applications often have many dependencies, maybe from a control vendor, from NuGet or binaries that don’t have source any more. It’s not like all of that can be updated to .NET Core 3 quickly or maybe not even at all.

As stated above, we intend to support dependencies as-is. If you are at the Build conference, you will see Scott Hunter demo a .NET Core 3 desktop application that uses an existing 3rd-party control. We will continue testing scenarios like that to validate .NET Core 3 compatibility.

Next Steps

We will start doing the following, largely in parallel:

• Test .NET Framework desktop application on .NET Core to determine what prevents them from working easily. We will often do this without access to source code.
• Enable you to easily and anonymously share dependency data with us so that we can collect broad aggregate data about applications, basically “crowd voting” on the shape of what .NET Core 3 should be.
• Publish early designs so that we can get early feedback from you.

We hope that you will work with us along the way to help us make .NET Core 3 a great release.

Closing

We have been asking for feedback on surveys recently. Thanks so much for filling those out. The response has been incredible, resulting in thousands of responses within the first day. With this last survey, we asked a subset of respondents over Skype for feedback on our plans for .NET Core 3 with (unknown to them) our Build conference slides. The response has been very positive. Based on everything we have read and heard, we believe that the .NET Core 3 feature set its characteristics are on the right track.

Todays news demonstrates a large investment and commitment in Windows desktop applications. You can expect two releases from us in 2019, .NET Core 3 and .NET Framework 4.8. A number of the features are shared between the two releases and some others are only available in .NET Core 3. We think the commonality and the differences provide a great set of choices for moving forward and modernizing your desktop applications.

It is an exciting time to be a .NET developer.

============================ End