.NET Core,.NET Framework和Xamarin有什么区别?


361

Microsoft现在在其.NET系列中具有.NET Core,.NET Framework和Xamarin(Mono)。

这里似乎有很多重叠之处。这些类型的.NET有什么区别?什么时候应该选择在项目中使用.NET Core而不是.NET Framework或Xamarin?


2
好问题!这是有关.net框架和.net核心的补充文章。 pogsdotnet.blogspot.sg/2017/11/… 谢谢!
艾伦·蔡

Answers:


268

根据此处的文档,在以下6种典型方案中,应使用.NET Core而不是.NET Framework或Xamarin 。

1.跨平台需求

显然,如果您的目标是拥有一个应能够在各种平台(Windows,Linux和MacOS)上运行的应用程序(Web /服务),则.NET生态系统中的最佳选择是使用.NET Core作为其运行时(CoreCLR )和库是跨平台的。另一个选择是使用Mono项目。

这两种选择都是开放源代码,但是.NET Core受Microsoft直接和官方支持,并且将有大量投资向前发展。

在跨平台使用.NET Core时,Visual Studio IDE在Windows上具有最佳的开发经验,该版本支持许多生产力功能,包括项目管理,调试,源代码控制,重构,丰富的编辑(包括Intellisense),测试等等。但是在Mac,Linux和Windows上使用Visual Studio Code也支持丰富的开发,包括智能感知和调试。甚至Sublime,Emacs,VI等第三方编辑器也能很好地工作,并且可以使用开源Omnisharp项目使编辑器具有智能感知能力。

2.微服务

当您构建一个由多个独立的,可动态伸缩的,有状态或无状态的微服务组成的面向微服务的系统时,这里的最大优点是可以在微服务级别使用不同的技术/框架/语言。这样一来,您就可以在系统的每个微区域中使用最佳方法和技术,因此,如果您要构建性能卓越且可扩展的微服务,则应使用.NET Core。最终,如果您需要使用任何与.NET Core不兼容的.NET Framework库,都没有问题,您可以使用.NET Framework构建该微服务,并且将来您可以用.NET替代它。核心。

您可以使用的基础架构平台很多。理想情况下,对于大型和复杂的微服务系统,应使用Azure Service Fabric。但是对于无状态微服务,您还可以使用其他产品,例如Azure App Service或Azure Functions。

请注意,自2016年6月起,Azure中并非每种技术都支持.NET Core,但由于.NET Core已发布RTM,因此Azure中对.NET Core的支持将大大增加。

3.最佳性能和可扩展系统

当您的系统需要最佳的性能和可伸缩性,因此无论您有多少用户,您都将获得最佳的响应能力,那么.NET Core和ASP.NET Core真正发挥作用的地方。使用相同数量的基础架构/硬件,您可以做的事越多,您可以以更低的成本为最终用户带来更丰富的体验。

摩尔定律对单个CPU的性能改进不再适用。但是,在系统不断发展的同时,您还需要做更多的工作,并且对于每天数量呈指数增长的日益苛刻的用户,还需要更高的可伸缩性和性能。最终,您需要提高效率,在各处进行优化并在计算机,VM和CPU内核的集群之间更好地扩展。这不仅仅是用户满意度的问题;这也会在成本/总拥有成本上产生巨大差异。这就是为什么追求性能和可伸缩性很重要的原因。

如前所述,如果您可以将系统的一小部分作为微服务或任何其他松散耦合的方法来隔离,那将更好,因为您不仅可以独立地发展每个小组件/微服务,而且可以长期发展敏捷性和维护性,但是如果您需要做的与.NET Core不兼容,您还可以在微服务级别使用任何其他技术。最终,您将能够对其进行重构,并在可能的情况下将其引入.NET Core。

4. Mac,Linux或Windows的命令行样式开发。

使用.NET Core时,此方法是可选的。当然,您也可以使用完整的Visual Studio IDE。但是,如果您是想要使用轻量级编辑器并大量使用命令行进行开发的开发人员,则.NET Core专为CLI设计。它提供了所有受支持平台上都可用的简单命令行工具,使开发人员可以在开发人员,实验室或生产机器上进行最少的安装即可构建和测试应用程序。像Visual Studio Code这样的编辑器使用相同的命令行工具来获得开发经验。和像Visual Studio一样的IDE使用相同的CLI工具,但是将它们隐藏在丰富的IDE体验之后。开发人员现在可以选择他们想要与从CLI到编辑器再到IDE的工具链进行交互的级别。

5.每个应用程序级别并排需要.NET版本。

如果您希望能够安装依赖于.NET框架不同版本的应用程序,则需要使用.NET Core,它可以100%并排提供,如本文档前面所述。

6. Windows 10 UWP .NET应用程序。

此外,您可能还需要阅读:

  1. 我应该什么时候使用.NET的核心?
  2. 什么时候仍应使用.NET Framework 4.x而不是.NET Core?
  3. 什么时候应该使用Xamarin而不是.NET Core?

17
为什么asp.net Core的性能更高?为什么在构建微服务时会更好?
Juan Zamudio

4
现在,Visual Studio for Mac也可用。因此,.NET Core还有一个积极的方面。visualstudio.com/vs/visual-studio-mac
Husyn

8
您的链接已损坏
shaneparsons

2
@JuanZamudio框架的版本是独立的层,每个层都依赖于紧接在前的版本,位于依赖链中,可以追溯到2.0版,该版本完全取代了1.1版。结果,如果您使用4.5之前的任何内容,则隐含地依赖于2.0之前的所有内容。与重写API相比,Core框架更多地是关于重构依赖关系以消除无关紧要的行李,这主要是但并非完全不变。一些事情也得到了极大简化,例如EF Core。
Peter Wone

感谢您的描述性回答
Tolga Kartal

171

微软是这样解释的:

.NET Framework,.NET Core,Xamarin

.NET Framework是随Windows分发的.NET的“完整”或“传统”风格。在构建桌面Windows或UWP应用或使用较旧的ASP.NET 4.6+时,请使用此功能。

.NET Core是可在Windows,Mac和Linux上运行的跨平台.NET。当您要构建可在任何平台(包括Docker容器内部)上运行的控制台或Web应用程序时,请使用此选项。当前不包括UWP /桌面应用程序。

Xamarin用于构建可在iOS,Android或Windows Phone设备上运行的移动应用程序。

Xamarin通常运行在Mono之上,Mono是.NET的一个版本,该版本是为跨平台支持而构建的,在Microsoft决定正式使用.NET Core跨平台之前。像Xamarin一样,Unity平台也可以在Mono之上运行。


一个常见的混淆点是ASP.NET Core的适合位置。ASP.NETCore可以在.NET Framework(Windows)或.NET Core(跨平台)之上运行,如以下答案所述:ASP之间的区别。 NET Core(.NET Core)和ASP.NET Core(.NET Framework)


3
每当有人说.NET Core是跨平台的时,新开发人员就会感到困惑。“ .NET Core” 仅支持UWP + ASP.NET Core,而ASP.NET Core是跨平台的,而UWP不支持。
哈桑·塔雷克

@HassanTareq不太正确。.NET Core是指可以在Windows,Mac或Linux上运行的运行时和库。ASP.NET Core是跨平台的,因为.NET Core是跨平台的。
Nate Barbettini

如果您提到尽管.Net核心(运行时和库)是跨平台的,但对于Mac / Linux,我们不能使用UWP应用,这对Greenhorns很有帮助。UWP不是跨平台的,我希望UWP是WPF(Xamarin.Forms是)的跨平台替代品
Hassan Tareq

@HassanTareq好的建议,我已经编辑了答案。
Nate Barbettini

1
Xamarin Forms现在几乎可以在一个代码库中的所有内容上运行。Windows UWP桌面,WPF桌面,MacOS,iOS,Android和Tizen(TV)。默认值为从Core实现中定位.NET Standard。美好时光!
肖恩·安德森

35

您可以在此行中引用-ASP.NET Core(.NET Core)和ASP.NET Core(.NET Framework)之间的区别

.NET Framework,.NET Core,Xamarin

Xamarin根本不是辩论。当您想使用C#构建移动(iOS,Android和Windows Mobile)应用程序时,Xamarin是您唯一的选择。

.NET Framework支持Windows和Web应用程序。今天,您可以使用Windows窗体,WPF和UWP在.NET Framework中构建Windows应用程序。ASP.NET MVC用于在.NET Framework中构建Web应用程序。

.NET Core是新的开源和跨平台框​​架,可为包括Windows,Mac和Linux在内的所有操作系统构建应用程序。.NET Core仅支持UWP和ASP.NET Core。UWP用于构建针对Windows和移动应用程序的Windows 10。ASP.NET Core用于构建基于浏览器的Web应用程序。

您想要更多详细信息请参考此链接
https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/ https://docs.microsoft.com/zh-cn/dotnet/articles / standard /选择核心框架服务器


12
  1. .NET是基于C#语言的生态系统
  2. .NET标准.NET生态系统的标准(换句话说,规范)。

.Net核心类库基于.Net标准构建。.NET标准可以使不能独立执行,并应被另一只引用类库项目.NET核心或 .NET框架可执行project.If要实现一个库,移植到.Net框架净CoreXamarin,选择.Net标准

  1. .NET Framework是基于.NET的框架,它支持Windows和Web应用程序

(您可以使用.NET Framework创建可执行项目(例如控制台应用程序或ASP.NET应用程序)

  1. ASP.NET是基于.NET Framework构建的Web应用程序开发技术
  2. .NET Core也是基于.NET的框架。

它是新的开源和跨平台框​​架,可为所有操作系统(包括Windows,Mac和Linux)构建应用程序。

  1. Xamarin是使用C#开发跨平台移动应用程序(iOS,Android和Windows Mobile)的框架

.NET Standard [蓝色]的实现支持和对.NET Standard的全面支持的最小可行平台(最新:[ https://docs.microsoft.com/zh-cn/dotnet/standard/net-standard#net-implementation-支持]


对“版本历史记录”表进行否决。它不是您复制的.net / standard或内核的“版本历史”。如果要匹配特定的.Net标准版本,这是可以使用的最低可行平台版本。EG:如果要在Full .NET上支持.NET Standard 1.4,则可以使用的最低版本是4.6.1
糟糕的

Down Vote已删除,因为您已经正确更新并记录了答案:-)
shawty

认为我会改用Apple开发...
Richard Hammond

7

.NET 5将是2020年11月发布的所有.NET变体的统一版本,因此不再需要在变体之间进行选择。 在此处输入图片说明


1
这是一个谎言。.NET Core在Linux上不支持WPF / WinForms!
文森特

没错,但是.NET的其他变体也不支持。.NET变种的选择不再存在,这是一件好事。
yanlend

1

.NET Core是您现在应该使用的.NET的当前版本(更多功能,已修复的错误等)

Xamarin是一个平台,为使用C#编码的跨平台移动问题提供了解决方案,因此您无需将Swift分别用于IOS和Android。


2
我想说,如果必须在Linux或Linux和Windows上运行,则应使用.Net Core。但是,我认为您也可以为Mono辩护。它当然没有更多的功能。根据定义,它只是“核心”位,没有Windows专用位,因此功能较少。我只是在猜测,但.Net Core似乎很少出现错误。.Net框架已经问世了近二十年。我想在这一点上,它已经相当艰难。但这只是一个猜测。
詹森·博伊德

它肯定具有更多新功能,他们最近添加了不会添加到.NET 4.8中的新类。他们还移植了WPF和WinForms。实际上,.NET Core似乎可以替代.NET Framework。似乎也更有表现。
asdf

0

Xamarin用于电话应用程序(均为IOS / Android)。.NET Core用于设计可在Apache和IIS上运行的Web应用程序。

那是两个句子的区别。


嗯..除了缺少第三个选项(.net框架)外,它也不是完全正确的。.NET核心几乎可以用于所有内容(Web,桌面,移动,云,游戏,IoT等)。.NET Framework以Windows为中心,并且已完全关闭。Mono是Xamarin使用的.NET Framework的开源版本(社区驱动),它将跨平台移动工具置于Mono之上。Xamarin最终将被Blazor取代(目前是pwa,但后来的混合动力是路线图的一部分)。
shox

是真的。Xamarin适用于移动应用程序。我认为它不会很快被替换。ASMX仍用于Web服务,并列入2019年视觉
user10868910

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.