簡析 .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>\bin \Product\Windows_NT.x64.Debug\packaging\publish1

編譯生成 C++ 代碼

dotnet restore dotnet build --native --cpp --ilcpath <repo_root>\bin\Product\Windows_NT.x64.Debug\packaging\ 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 raw aspnetapp.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