什么是Asp.Net core
我相信很多C# Developer
已经对于.net core
不算陌生了,就算没有正式使用相信也应该有所了解。微软在推出来.net core
的同时为了方便一些原有的项目可以方便迁移,同时推出了Asp.net core
。那么.net core
和Asp.net core
是不是同一个东西呢?如果不是又有什么区别呢?
下面我们分别说明一下,首先Asp.net core
和.net core
肯定不是同一个东西(废话,如果是同一个东西还写这么多干啥!)。
Asp.net core
其实就是仍然基于.net Full Framework
(最低要求Framework 4.6.2
)的项目, 但同时保留了.net core
一些新的设置理念,比如Asp.net core
默认使用Kestrel
作为Http
请求的监听器,而不是使用原来庞大的Https.sys
。Kestrel
不仅仅是微软下一代的跨平台Http
请求监听器,同时还提供了比Https.sys
更轻量级以及更快速的Http
请求处理。另除此之外,Asp.net core
与原来的Web
设计另一个最大的区别在于Asp.net core
(及.net core
)完全抛弃了原来的使用管道模式来接收以及处理HttpRequest
。在Asp.net core
中允许处理中间件(Middleware
)来对所有的HttpRequest
来进行请求,当请求被接收到时,Asp.net core
会调用注册的中间件(按照注册的顺序)对HttpRequest
进行处理。这样做相比与原来使用HttpApplication
的管道方式而言,其优势在于完全由开发人员决定HttpRequest
需要执行怎么样的处理,没有多余的其他步骤。而原来的方式既使开发人员不希望对一个HttpRequest
进行任何处理,但HttpApplication
仍然会按照管道的设置依次创建HttpModel
-> 激活HttpHandler
-> 处理Session
等。据.net core
团队给出来的性能测试数据来看,Asp.net core
(.net core)相比与原来的Web(.net framework 4.6)程序性能提升了2300%.
而.net core
其实就是保留了上面所说的优势的同时支持跨平台运行。.net core
的系统是可以真正运行在除Windows以外的其他平台的。轻量级、跨平台、模块化是.net core
整体的设计理念,同时也是微软产品理念转变的一个体现。.net core
虽然有千般好,但是我们当前仍然没有直接使用它,因为它现在有一个致使的“缺陷”那就是生态环境,由于.net core
的API已经完全重写,虽然当前已经提供了.net farework
90%以上的API,但是仍然会造成一些开发上的不便,当然这还不是最大的问题,最大的问题在于一些第三方Nuget
包仍然不支持.net core
。这样就会造成一些项目无法直接迁移或是迁移成本太高的问题。
如何创建一个Asp.net core
的项目
说了这么多,我们来看一下在创建项目时Asp.net core
和.net core
有什么不同吧,我们以Vistual studio 2017
上创建项目为例,首先打开VS2017
后点击创建项目-> Asp.net core
web应用,这时会弹出模版选择的窗口。
在这个选择窗口中我们可以看到在左上角的那个下拉列表中可以选择.net framework
以及.net core
。当我们选择.net framewrok
时创建出来的项目工程即为asp.net core
。项目创建成功后可以在项目的属性中看到使用的Framework
版本是4.6.2。但是项目文件的组织结构已经和.net core
的项目结构一样了。
Asp.net core
项目的"坑"
近期在对新的项目进行性能测试时发现系统的内存占用似乎只能使用到1.5G。经过多次测试以及代码检查终于发现新创建出来的Asp.net core
的项目默认的目标平台是X86而不是AnyCPU。当尝试在VS中新目标平台改为AnyCPU时发现项目不能运行,抛出异常"无法加载 DLL“libuv”: 找不到指定的模块。 (异常来自 HRESULT:0x8007007E)。",无奈只能将项目的目标平台改为X64,然后发现在开发环境已经一切正常,但是当将代码部署到Azure App Service
上时系统仍然不能访问,异常和上面的相同。最后检查了项目的工程文件(*.proj
)然后发现虽然PlatformTarget
一项中已经改为X64
,但是在PlatformTarget
的属性中Platform
仍然是AnyCPU
,手动修改工程文件将AnyCPU
改为X64
后一切正常