Jexus web server V5.1 安装配置要点

一、Jexus简介:
Jexus web server for linux 是一款基于.NET兼容环境,运行于Linux/unix操作系统之上,以支持ASP.NET为核心功能的高性能WEB服务器。
Jexus V5.1有如下功能特点:
01、支持ASP.NET。这是Jexus的核心功能。无论是稳定性、易用性还是并发承载能力、并行处理速度,Jexus对ASP.NET的支持都是非常优秀的;
02、支持Fast-CGI。通Fast-CGI,Jexus能支持包括PHP在内的所有拥有Fast-CGI服务功能的WEB应用;
03、具备基于正则表达式的强大的URL重写功能;
04、具有强劲的反向代理功能。支持多目标负载均衡,支持本地网站与远程网站无缝整合;
05、拥有强大的流媒体支持能力,支持FLV/F4V视频文件拖动播放,支持微软平滑流媒体技术;
06、支持“服务器推送”技术,配备了相应的服务器端、客户端开发接口,是开发现代WEB应用的利器;
07、具备可控的“ASP.NET前置缓存”,能最大限度地提高ASP.NET网站的承载能力和响应速度;
08、支持Https,具有SSL加密数据安全传输能力;
09、具有基础而实用的入侵检测功能,能自动终止已被识别的非法请求;
10、安装部署非常简便,操作使用极为简单。
二、安装前的准备工作:

1、系统已经安装好mono 2.10.8 或更高版本,至于如何在linux上安装mono,请参考www.linuxdot.net上的相关文章。
2、请确认Linux系统中存在 libc.so.6、libdl.so.2两个库文件,如果需要启用https,系统中还需要具备libssl.so.x.x.x库文件,比如libssl.so.0.9.8,如果没有,请安装OpenSSH。
三、下载并解压Jexus安装包:
1、下载:
地址:http://www.linuxdot.net/down/jexus-5.1.tar.gz,可以用wget下载,如:wget http://www.linuxdot.net/down/jexus-5.1.tar.gz

2、解压:
tar -zxvf jexus-5.1.tar.gz

3、安装:
Jexus安装非常简单,仅仅就是一个复制、粘帖和注册全局程序集的过程,但要特别注意:需要用root身份进行操作。
A、复制文件,建议把jexus安装到/usr/jexus中:
sudo cp -rf jexus-5.1 /usr/jexus
B、注册全局程序集:
cd /usr/jexus
sudo ./jws.regsvr
C、请查看 jws.start、jws.stop、jws.restart、jws.regsvr这几个脚本文件的权限,确定是否具有可执行权限。
四、运行测试
复制完Jexus的文件后,Jexus就可以正常工作了,甚至连进一步的配置也完全不需要。
强调:如果你服务器安装有其它的WEB服务器,而且该服务正在运行,请停止它,以免造成端口冲突而造成Jexus无法启动。

如果是最新安装,请首先建立一个默认的网站文件夹:/var/www/default,并在里面放一个首页文件,如index.htm或default.htm
进入jexus工作文件夹,启动jexus,命令如下:
cd /usr/jexus
sudo ./jws.start
启动后,请尝试访问一下这个网站,看看是否能看到你放的首页或者jexus的欢迎页,网址是:“http://服务器IP地址”或者“http://服务器IP地址/info”。
五、Jexus 系统配置
Jexus按默认配置就能很好的工作,进一步配置是为了Jexus更适合自己的需要。
Jexus最核心的一个配置文件,固定文件名是jws.conf,这个文件与jexus的其它工作文件在同一个文件夹中。
jws.conf有如果基本配置内容:

SiteLogDir=log    #网站日志以及Jexus系统日志的存放位置,必填项。可以使用基于jws.exe文件的相对路径
SiteConfigDir=siteconf     #网站配置文件存放的位置,是必填项。可以使用绝对路径,也可以使用基于jws.conf文件的相对路径
Runtime=v4.0.30319    #设定Jexus工作进程运行于哪个.NET版本
httpd.processes=1     #工作进程的数量,建议每6-8核CPU用一个进程,最多可设4个进程
httpd.user=www-data     #工作进程以什么用户身份和对应权限工作,默认为root
php-fcgi.set=/usr/bin/php-cgi,6    #如果需要Jexus同时充当PHP FastCGI服务器,这一句就是fast-cgi设置,分两个部分,逗号前为php-cgi这个文件的路径,逗号后是php进程数
CertificateFile=/xxxx/xx.crt    #SSL证书路径(如果需要使用https协议才填)
CertificateKeyFile=/xxxx/xx.key    #SSL密钥文件路径(如果需要使用https协议才填)

注:jws.conf 中,SiteConfigDir 和 SiteLogDir 两项是必填项。
六、网站配置

Jexus支持多站点,可以用不同的端口、域名、虚拟路径设置任意多的网站,配置时,首先要注意如下三个规则:
1)必须把所有网站配置文件放到jws.conf指定的网站配置文件夹内,这个文件夹除了网站配置文件,不能有其它任何文件,因为jexus会认为这儿的任何一个文件都代表着一个不同的网站。
2)每个网站有且只有一个配置文件,配置文件的文件名就是这个网站的名称,比如 www.mysite.cn这个网站,配置文件名可以写成“mysite”,当然也可以写成其它文件名,以便管理员容易记忆和识别,但要特别注意:文件名不能有空格!
3)一个网站可以拥有任意多的域名,不同网站不能有相同的域名,没有域名的网站只能有一个,这个没有域名的网站叫做“默认网站”,而一台服务器最多只能有一个默认网站。
下面以www.mysite.cn为例,说说网站的配置
在网站配置文件夹中建立一个文件,这个文件的名称应该有一些意义(至少要能让服务器管理员了解这个配置文件是属于哪一个网站的)
设这个网站的配置文件的文件名为:mysite

sudo miv mysite

A、网站配置的基本内容:
port=80                          # jexus WEB服务器侦听端口(必填。当然可以是其它端口)
root=/ /var/www/mysite           # 网站URL根路径(虚拟目录)和对应的物理路径,两个路径字串之间必须用空格分开(必填。既使这个网站是一个纯粹的反向代理站,也得填)

#可选项
hosts=mysite.cn,www.mysite.cn    # 网站域名(建议填写),可以用泛域名,比如:*.mysite.cn(不填此项或只填一个“*”号表示这是默认网站,一个端口只能有一个默认站)
indexs=index.aspx,index.htm      # 首页文件名,可以写多个,用英文逗号分开(可以不填。因为JWS系统含有常用首页名)
aspnet_exts=mspx,ttt             # 添加新出现的或自定义的ASP.NET扩展名(不建议填。多个扩展名用英文逗号分开,不加点号。系统含有常用扩展名)
B、最简配置示例
port=80
root=/ /var/www/default

C、网站配置的高级选项
网站配置的高级选项全是可选项,应该根据网站的实际需要选填。
灵活使用高级选项,可以架设出一台与众不同的、功能强大的服务器平台或者服务器群组。

1、使用“URL重写”功能
URL重写是指WEB服务器将访问者的请求URL路径资源按指定的匹配规则解释和匹配为另外的一个真实RUL路径资源。

比如,希望别人访问“.php”类型的文件时,服务器返回 /404.html 这个文件:
rewrite=^/.+?\.(asp|php|cgi)$ /404.html
# 格式:
# “rewrite=”的后面是两部分阻成,两部分之间由一个空格分开。
空格前是匹配的条件:用正则表达式描述URL的匹配条件。
空格后是匹配的目标:指的是如果用户访问的路径合乎前面的匹配条件,服务器将以哪个规则回应。

又如:
把“/bbs”解析为“/bbs/index.aspx”,把“/bbs/file-1” 匹配为 “/bbs/show.aspx?id=1”:
rewrite=^/bbs$ /bbs/index.aspx
rewrite=^/bbs/file-([0-9]{1,6})$ /bbs/show.aspx?id=$1
格式解释:rewrite的等号后含有两部分内容,用空隔分开。前半部分是一个正则表达式,用于描述需要URL重写的(用户浏览器中的)url路径样式,后半部分是当用户的URL合乎前面的正则表达式时,JWS应该重写和访问的真实URL路径。

2、禁止某IP或IP段访问本网站
denyfrom=111.222.111.*
denyfrom=101.202.111.*
denyfrom=101.201.1.132

3、禁止访问某文件夹及其子文件夹中的内容
DenyDirs=网站文件夹路径的URL路径,如 “/abcfiles”或 “~/abcfiles”,多个路径,用英文逗号分开

4、是否对请求的URL等进行安全检测
本选项默认是true,即需要检查,除非你的确需要关掉这个选项,否则可以不填,格式如下:
checkquery=false
(关掉本项可以提高服务器速度,但就安全而言,不建议关掉它)

5、NOFILE(无文件)功能
nofile=/mvc/controller.aspx
(注:这是Jexus特有的功能,指的是如果服务器不存在用户要访问的文件,服务器将使用什么文件应答。)
(提示:路由后,原RUL路径会存贮在Jexus特有一个服务器变量“X-Real-Uri”中)
(技巧:用这个功能,或者再加上URL Rewrite功能,你完全可以把URL路径与真实路径隔离开来,达到信息隐藏和简化URL的作用。)

6、NOLOG(无日志)功能
nolog=yes
(注:禁用网站日志功能会提高WEB服务器系统的的处理速度,但不足也是明显的,就是你无法详细了解网站的访问情况了)

7、长连接开关
keep_alive=true
注:V5.1版默认值是true,即默认使用长连接,可以不填。

8、反向代理功能
reproxy= /abc/ http://www.xxxx.com:890/abc/
参数的值由本站RUL根路径和目标网站URL根路径两部分组成,之间用空隔分开。
*技巧:反向代量的目标地址可以有多个,用英文逗号分隔,如:
reproxy=/abc/ http://192.168.0.3/abc/,http://192.168.0.4/abc/
这时,当用户访问/abc/时,jexus就会随机选择一台服务器进行访问,达到负载均衡或服务器集群的效果。

9、接受FAST-CGI提供的服务
对于TCP连接:
fastcgi.add=需要fast-cgi处理的文件扩展名|tcp:fast-cgi服务的IP地址:端口
如:fastcgi.add=php,php3|tcp:127.0.0.1:9000
对于unix sockets:
fastcgi.add=需要fcgi处理的文件扩展名|socket:路径
如:fastcgi.add=php,php3|socket:/tmp/phpsvr

10、启用gzip压缩功能
usegzip=true    #即UseGzip
解释:启用这个功能后,当用户访问“.htm”“.js”等文件时,Jexus会将这些文件进行GZIP压缩后发送给用户浏览器,这样,可以节约更多的网络带宽。

11、启用HTTPS进行SSL安全传输
本功能是对服务器与客户之间的数据进行加密传送,提供数据的保密性。具体方法请访问www.linuxdot.net的专题讲解。
七、Jexus操作:

1、基本的启动命令的格式(仅作例子,不建议使用)
mono /usr/jexus/jws.exe
如:mono /usr/jexus/jws.exe
这个命令运行后,用 Ctrl+c 组合键退出程序

2、以“服务”方式进行后台运行, 只需要基本命令后加一空格再加一“&”号(仅作例子,不建议使用)
mono /usr/jexus/jws.exe &

3、开机自动启动:
在/etc/rc.local 或类试的开机启动脚本中加入下面这一行命令:
mono /usr/jexus/jws.exe >/dev/null 2>&1 &
或者
/usr/jexus/jws.start  #推荐方式
(注意:不同的Linux系统可能有不同的启动方式,用户应根据不同系统的特点灵活定制)
(提示:jws.start是脚本文件,用户可以根据自己系统的特点去适当修改它,以便其启动)

4、使用脚本操作Jexus(推荐使用):
Jexus自带了三个脚本,分别是:jws.start、jws.restart、jws.stop。

功能1,对Jexus服务器操作:
jws.start     #启动JEXUS服务,可以写入rc.local文件中,从而达到开机自启动的目的;
jws.stop      #停止Jexus的运行。
jws.restart   #重启Jexus;

功能2,对某个指定的网站操作:
jws.restart 网站名     #加载/启动/重启一个指定的网站
jws.stop 网站名        #停止一个指定的网站
注意,这些脚本需要具有可执行权限,同时操作者也必须拥有管理员(root)权限。
八、卸载:
1、在rc.local文件中删除你手工添加的开机自动启动Jexus的命令行(如果本来就没有添加过,这步操作就不必做了)
2、删除jexus文件夹及全部内容(建议只删除*.exe和*.dll,其它的,比如网站配置文件等不必删除,以便将来重新启用)。
九、信息反馈与技术交流:
网址:www.linuxdot.net
十、重要声明:
Jexus V5.1 是免费软件,可以自由下载、传播和使用。但Jexus作者、发布者、维护者不对Jexus的用途、作用、效果、技术支持以及其它相关内容作任何明确或暗含的承诺,不负担任何直接或间接的责任。

迁移到.NET Core上

[原文发表地址]:Porting to .NET Core

[原文发表时间]:February 10, 2016

迁移到.NET Core

.NET Core离RTM 发布版越来越近了。仅仅两个月之前,我们宣布了.NET Core 和 ASP.NET Core的RC 发布版

作为我们验证的一部分,我们正在和内部还有外部客户一起把他们的代码移植到.NET Core上去。我们收到了很多要求都是关于你们应该怎样把已存在的代码合并到.NET Core,以及怎样继续面向.NET Framework工作。在本贴中,我想提供给你们一个大概的流程那就是以此把已存在代码移植到.NET Core上, 什么样的应用程序才是理想的,我们提供什么样的工具能帮助你移植你的程序,我们怎样把更多的API放到.NET Core中去帮助你们更好地用已存在的代码工作在.NET Core上。

我们很愿意和你谈谈!

你有把一个应用程序或者类库迁移到.NET Core上去吗?你有试着在.NET Core和其他平台,例如.NET 框架之间共享代码吗? 如果是这样,我很乐意同你谈谈你的经历,是否有什么事我们可以去做帮你把事情做得更好。如果你感兴趣,请在微软的网站上的immol上联系我,我会给你打电话。

你想迁移什么东西?

在你迁移任何资源到.NET Core之前,你应该知道你当前代码以什么为基础,即它的结构和外部依赖关系。想一想功能性要求,就是.NET Core必须提供,并且你想使之发挥作用。然后你可以反向地思考什么资源适合迁移,什么不应该被迁移,应该为.NET Core去写什么样的单独的代码。

让我们来看看.NET Core必须提供什么。RTM 版本的.NET Core 将会遵循以应用程序下模式:

· ASP.NET Core 应用程序和服务

· 通用的Windows 平台(UWP)应用程序

· 控制台应用程序

让我们快速看一下每一个模式然后了解下迁移在他们的语境下意味着什么。

ASP.NET Core 应用程序和服务

迁移的原因?主要原因是迁移已存在的的程序使之可以跨平台运行。例如,这可以使得在Mac上运行OS X同时运行也可以把你的网站运行到Linux 上(我们非常乐意这能实现,但是这确实是你的选择)。但是如果你还停留在Windows操作系统上,你也许想要看一下ASP.NET Core,因为它提供了新的功能并且不需要广泛安装框架的机器,这就避免了一些问题,例如需要机器变化,部署过程中需要管理员权限,GAC政策等等。

好的移植选择?

ASP.NET 的基础是使用MVC 并且/或者 WebAPI的网站。

太适合移植吗?如果你的大部分网页程序正在使用WebForms,移植到ASP.NET Core和重新实现是等价的,因为WebForms不被支持。然而,如果你认为使用这样的方法是一个在某种方式上重构你的程序的机会,那么这就不是一个瓶塞,因为MVC/WebAPI以更简单更现代的方式来编写web应用程序。

通用的Windows 平台(UWP)应用程序

迁移的原因?UWP统一了Windows设备系列, 范围从PC到平板装置,手机,还有Xbox。现在还包括无头式外设物联网(IoT)相关的设备。UWP 提供了很多非常棒的功能,例如一个应用程序商店允许你的应用程序更容易货币化。并且Windows运行时(WinRT)提供了丰富可用的完全本地化和强大的操作系统APIs,例如XAML和DirectX组件。

好的移植选择?如果你正在面向Windows 8或者Windows Phone 8.1, 那么你已经准备做这些了:这些是.NET Core应用程序。 入果你是在维护Windows Phone Silverlight 应用程序,那么你已经非常接近了。实际上,任何Silverlight应用程序都是一个好的选择,因为那些API设置是以Silverlight上可用的API 为基础的:大部分API在.NET Core上可用,并且可以变为WinRT APIs, 在这种情况下,你会经常接触触摸式窗口,例如更改命名空间。实际上,有一个桥梁可以帮汉族我们做这个转换。

太适合移植吗?丰富的桌面应用程序利用了Windows Forms 或者WPF 的优点,是非常合适移植的,因为两种技术都支持.NET Core。然而,WinRT 提供了一种本地化的基于XAML UI的技术,它和Silverlight, WPF非常相似。所以如果你打算重新设计你的程序使之可以跨越各种平台,那么这就不会成为你的一个阻碍。

控制台应用程序

迁移的原因?你应该看看对于控制台应用程序使用.NET Core最重要的原因之一是它允许面向各种操作系统(Windows,OS X, 还有Linux)。另一个重要原因是控制台程序的.NET 本地化将最终会支持生产自足,单个文件使用最小的依赖项去执行。

好的移植选择?几乎任何控制台应用程序都是公平的游戏,依靠你的依赖项。例如,如果你的控制台程序是用COM实现Windows 或者Office,那么也许迁移起来比较困难,也就是说,一个控制台程序解析一个CSV文件并且调用一个一个WCF服务。作为一个数据点,C#和VB编译器就是.NET Core控制台程序,即就是dotnet命令行工具集

太适合移植吗?没有一个标准的很适合迁移的例子;它是你的依赖项的一个功能。

.NET Core和.NET Framework的关系

在我们开始迁移之前,知道.NET Core和.NET Framework怎样联系是很有用的,尤其是可用的API.这样可以帮助你获得一张API是怎样的演化并且反过来能让你计划你的程序和类库的图片。

很多人认为.NET Core是.NET Framework的一个子集。你必须了解这个观点是错误的。正确的是:.NET Core在API这方面是更加简单化,我们计划并且将继续保持,.NET Core有它独有的API和技术。这包括工具式安装,例如不仅是.NET Native,而且包括类库。

然而,要知道庞大数量的.NET Core API和.NET Framework是共享的。这就使得我们可以非常容易的去写同时可以在.NET Core和.NET Framework上工作的类库。实际上如果你的目标不是.NET Framework 4或者Silverlight,那么所有的portable类库都是.NET Core类库。如果你想知道这是怎么被设计并且.NET Core是怎样简单地被portable类库写成的,那么可以看一下这篇博客

当然,数量庞大的已知代码是面向.NET Framework的,把已存在的.NET Framework类库转换成.NET Core是非常有挑战性的,那么现在让我们花些时间来看看两者之间的主要不同之处吧。

.NET Core和.NET Framework之间的不同之处

两者之间的不同之处可以总结成以下三点:

1. 基于NuGet. .NET Core是分布式的一种NuGet包,允许本地部署。相反,.NET框架总是安装在全系统的位置。这种区别对类库来说没什么;但是对于那些要部署关闭依赖项的应用程序来说是很重要的。但是我们希望这个模型来更改怎样使类库的所有者可以利用新功能的优势。因为应用程序可以简单的部署到一个新版本的.NET Core上(不必像.NET Framework一样必须等着被广泛适用),所以只是比较少的那些类库的所有者会利用最新的功能的优点。

2. 好地层次性 .NET Core是以特殊方式设计成具有分层式的。目标就是创建一种可以容纳多种功能和系统约束条件并且不强制用户去重新编译他们的类库或者说产品新特性的.NET。那么这就意味着我们必须移除一定的API,因为他们是把低等级的组件绑定到了高等级的组件上。在这种情况下,我们会提供一种可替换的方法,那就是采用扩展的方法。

3. 疑难技术的免费 .NET Core不包括一定的技术,所以我们决定不继续因为我们发现他们是有问题的,例如AppDomain和沙盒技术。如果对.NET Core来说,这个方案是可以理解的,那么我们的计划将会有替代品。例如,对于加载并且分离程序集来说AssemblyLoadContext替代AppDomains 。

第一个观点是指我们现在全然接受对于核心的开发经验来说,NuGet是第一等级的概念。我们相信这个一个自然的发展就像现在你们很多人已经开始使用NuGet去获得第三方的依赖项了。

第二和第三个观点是指当面向.NET Core时,一定数量的API并不可用。那么让我们来看下你应该注意哪些方面。

映射

随着.NET 本地化的到来,我们有了一种技术可以静态地连接你的应用程序在.NET 框架和第三方依赖项之间。要这个链接可行,识别出你没有正在使用的框架部分是非常重要的。在其他技术上,例如C++, 在某种程度上来说是很简单的,因为这些系统没有映射。当然,.NET本地化依然支持映射,但是我们想要这个平台发挥更好地收益,那就意味着你不需要为你没有使用的功能付费。这对于反射来说尤其真实,因为它规定了运行时和编译器可以基于静态信息。

所以最好的方式就是,映射在.NET Core中是一种可选择的组件,那你也许就一点也不想使用你的应用程序了。比较棘手的部分是System.Objec 在映射上通过Object.GetType()有一个依赖项。为了打破这种依赖,我们决定 System.Type不再代表全面反射类型信息,只保留类型名称。这就意味着System.Type不再包含诸如GetMembers()这类的API,但是继续公开诸如Name这些API。

为了获得额外的类型信息,你必须要调用一个名叫GetTypeInfo()扩展方法,这个方法存在于System.Reflection上。它会返回Type常用的类型信息。换句话说,就行下边的一行代码:

C#
var members = obj.GetType().GetMembers();

变为:

C#
using System.Reflection;
...
var members = obj.GetType().GetTypeInfo().GetMembers();

如果你有使用过.NET Core上的映射的经验,那么你可能已经注意到一定的API概念,例如BindingFlags也被移除了。基于您的反馈,我们最近决定把这些API再加进来。

不继续使用的.NET Core技术

.NET平台是一种非常成熟的技术,已经有15年的历史。我们已经在这个平台开发了一系列的技术。在过去的几年里,我们已经学到了很多关于这些技术的知识,诸如他们怎么被使用,创建的结构,以及有什么限制等总而言之,我们已经确定了一套我们不再提升现代.NET 程序的技术,因此,不会把他们放到.NET Core上去。

当然,我们并没有从.NET 框架上移除任何技术。如果你正在使用它们,那你可以不用改变任何东西。我们将会继续在.NET框架上支持这些技术。但是,我们鼓励你避免在你的新的应用程序上使用那些依赖项,因为这会使你在移植你的程序到.NET Core上时非常困难。并且我们也不会在那些方面增加新的功能,所以你最好不要使用首选的代替品。

让我们看一下其中的一些。我会解释他们为什么有问题,你应当使用什么去代替。更多的信息和不继续使用技术的列表,请读我们的迁移指南

应用程序域

为什么不被继续使用了?AppDomains需要运行时的支持并且费用昂贵。在被CoreCLR执行的同时,在.NET本地化并不是可用的,并且我们也不打算增加这种功能。

我应该用什么代替?AppDomains是用作不同的目的。对于代码隔离来说,我们建议使用进程或者容器来代替。对于动态加载的程序集,建议使用新的AssemblyLoadContext 类。

远程处理

为什么不被继续使用了?.NET远程处理的思想 – 透明的远程过程调用 – 已经被确定为问题性的体系结构。在外围场所,常被用于跨AppDomain交流。最重要的是,远程处理需要运行时的支持,并且是非常重量级的技术。

我应该用什么代替?对于跨进程的通信来说,进程间的通信(IPC)应该被使用,例如管道或者内存映射文件。跨机器时,你应当使用基于解决方案的网络,最好是一个低开销纯文本的协议,例如HTTP.

二进制序列化

为什么不被继续使用了?经过十年的服务,我们已经知道序列化是异常的复杂和强大的兼容性,已经成为支持它的类型的负担。因此,我们决定序列化应该是一种可以在最要的公共API上使用的协议。然而,二进制序列化需要直接的知识类型,因为它允许序列化图表,包括私有的状态。

我应该用什么代替?选择满足你目的序列化技术,在格式化和占用空间方面。最受欢迎的选择包括数据协议序列化XAML序列化JSON.NET,还有protobuf-net.

沙盒技术

为什么不被继续使用了?沙盒,依靠运行时或者框架限制一个托管的应用程序可以进入,被认为是一个无目标的.NET Core。沙盒应用程序和组件确实是很难搞定的,建议用户不要太依赖它。它也会使得执行起来更加复杂,并且影响并没使用沙盒技术的应用程序的性能。因此,我们不在.NET Core上提供沙盒功能。

我应该用什么代替?使用提供安全边界的操作系统,例如运行进程的账户使用最小的权限。

考虑迁移

理所当然,只是因为有些东西在.NET Core上不可用并不意味着我们就停止使用。在大多数情况下,知识意味着我们并没有时间去调查移植是否有道理或者不认为它是有关.NET Core提供的应用程序模型。因此,我们在这方面非常乐意得到你的反馈。

那些API的一些将会在社区中有代替品。请在注释中让我们知道你正在使用哪些,并且用的高兴吗。这样我们就可以让类库的所有者确保这些都可以在.NET Core上正常工作。

你们一些人已经在GitHub上填写问题要求一些特殊的组件被迁移。我们当前正在关注这些:

· System.Data. 尽管基本层是.NET Core的一部分,例如提供者模型和SQL客户端,一些功能当前是不可用的,比如schema的支持和DataTable/DataSet。

· System.DirectoryServices. 现在在.NET Core上并不支持与LDAP或者Active Directory的通信。

· System.Drawing. 尽管严格意义上讲,它是一个客户端API,但是许多开发人员使用服务端上的绘画API去提供缩略图或者水印。我们现在在.NET Core上不支持这些API.

· System.Transactions. ADO.NET 不支持事物处理的同时,也不支持分布式的事物处理,包括环境交易和登记的概念。

· System.Xml.Xsl and System.Xml.Schema. .NET Core支持XmlDocument以及Linq’s XDocument, 包括XPath。然而,当前并不支持XSD (XmlSchema) 或者 XSLT (XslTransform)。

· System.Net.Mail. 现在并不支持使用这些API从.NET Core发送邮件。

· System.IO.Ports. .NET Core现在并没有能力和串行端口进行通信。

· System.Workflow. Windows 工作流基础(WF)现在在.NET Core上是不可用的。

· System.Xaml. 当创建UWP应用程序的时候,开发人员会使用WinRT XAML APIS, 因此,.NET Core现在不包括托管的XAML框架,其中包括解析XAML 文件的能力还有实例化被描述的对象图。

有关完整列表,请看标记为port-to-core的CoreFX问题。请注意这不代表着我们对所有这些组件的开源化的承偌,甚至把他们迁移到.NET中去 – 仅仅是这都是从社区的人员愿望出发而这样做。也就是说,如果你关注上边列表所列的任何组件,你可以考虑加入GitHub的讨论组,那么你的意见有可能被采取。如果你认为缺了什么,填写你的新问题

你有兴趣帮助我们迁移一个组件吗?在很多情况下,.NET源代码的执行情况在MIT下已经是可行的了,作为参考代码的一部分。我们正在寻找方法使得社区可以帮助我们在迁移上有些成绩。如果你想参加,在microsoft.com上的immol给我发邮件。

并且,我们正在研究用户发现的在迁移时特别具有挑战性的方面。例如,我们已经有好几次会议关于最小化映射的不同

知道你的代码有多方便迁移

在你尝试迁移之前,应该在你的进制文件上运行API端口。这将会产生一份可以提供两块有用信息的报告:

· 高级别总结。这份总结给了你每一个程序集的百分比,可以告诉你的迁移的花费。可以表现出你的哪部分组件很难迁移,哪部分组件容易迁移。

· 不可迁移API列表。它提供了一份表格,列出了不可迁移的可用API。同时也包括了建议可以改变的,调用替代品。

有的时候,这个高级别的总结可能会造成误导。要确保浏览一下不能迁移的API – 有时候,很多问题可以用这种方法修好。例如,许多映射API已经移走了,但是修理的方法很简单,就是插入一个调用函数到GetTypeInfo()

我们非常鼓励你使用API移植。不仅这个工具可以很有效的帮助你,它也可以帮助帮助我们在迁移的时候确定API的优先次序,因为它会给我们把遥测数据发送回来。我们收到的数据仅仅是你在你的代码中调用的框架API的列表。那么通过这种方法,我们可以知道,哪些API经常被客户使用,这些API是要迁移到.NET Core上的。我们的目标是确定这些API的优先次序。别担心 – 我们不会收集你的代码的任何信息。你不必相信我的话:API 迁移是开源的并且被贴在GitHub上

如果你想学习API Port是怎么工作的,你应该在Channel 9看一下关于API Port组的访谈:

迁移到.NET Core上去

现在你已经对这个功能提供的并且它与.NET 框架的不同有了很好的理解,那么让我们谈一下关于迁移的东西吧。

在你开始迁移之前,你应该知道你的应用程序结构,并且知道你想迁移那一部分。你大概可以用三种方法:

1. 协同进化. 在你想保留你的已有的.NET 框架资产时(例如桌面应用程序)而且也想利用.NET Core 程序模型,例如面向移动端设备的UWP。另一个通用的方法就是基于桌面应用程序的.NET 框架和基于服务的ASP.NET之间通信。在这两种情况下,目的就是分享一些.NET Core和.NET 框架的功能。

2. 迁移。在这种情况下,你有一个已有的应用程序,例如一个ASP.NET 4 MVC 应用程序,你想把这个程序全部移植到ASP.NET Core上去。因此,目的不是把.NET 框架和.NET Core作为目标,二是可以快速的适应你的代码以便于它可以为.NET Core成功编译。

3. 从零开始。在这种情况下,你不必关心已存在的程序因为你要在.NET Core上从零开始一个程序。但是最终你可能喜欢用到一些样例或者说纳入.NET 框架的一些代码片段。所以你依然需要知道怎样使这些代码能在.NET Core上工作。

我将会集中注意力到第一种和第二种方法上因为第三种只是别人所讨论的技术。

一般方法

永远要记住,每个代码库都是不同的。因此,代码迁移的过程会发生变化并且很大程度上依赖你代码库的状态,所以我不能提供给你一个可覆盖所有情况的方法。下面所列的方法和技术可能不会按照期待的工作。你必须在这种情况乱下适应他们。

下面是迁移时一些简单的方法

1. 标识你想迁移到.NET Core上的工程。

2. 知道这些工程存在外部依赖项并且确保他们既和.NET Core兼容,有等效替代,或者可以被分解。

3. 使得那些工程面向.NET 4.6.1的框架。这使得你可以使用API备选方案,即就是我们针对这些方案所介绍的.NET Core不支持哪些已存在的APIs。记得要更新所有的消费的工程,否则由于.NET 框架不一致的问题,在编译时会出现错误。

4. 重新编译

5. 运行API Port

6. 更改你的代码以便处理API Port的问题

重复4-6步知道所有的API Port问题被处理。然后创建新的.NET Core工程并且把你的代码放进去。如果没有很多API Port不能发现的问题,那么你的代码应该能编译成功

协同进化的.NET Core和.NET 框架应用程序

在这种情况下你想在已有的.NET 框架程序和即将被创建的.NET Core程序之间分享你的代码的话。有两种方法你可以采用:

· 共享资源。共享工程允许你链接工程级文件:当引用一个共享的工程时,所有的资产文件都变成这个工程的一部分。这个允许你使用条件编译和局部类使你的代码适应其他平台。

· 共享进制文件。你可以把你想共享的代码拆成块,放进一个可迁移的类库,这个类库可以被.NET 框架和.NET Core应用程序引用。

在你想通过使用#if来是适应你的代码的情况下,共享资源是非常简单的。如果你想确保你不会创建很乱的代码通过使用#if条件句。试着集中处理尽可能多的不同代码。另一个比较好的窍门是使用分部类其中的一个类的一部分是在共享的项目而另一部分是由平台待定的项目。

取决于你们组合应用程序的大小,使用共享进制文件也许是一个更好并且更合理的方案。原因就是类库正在创建可以被部署并且作为鼓励测试模块的的单元。在源代码中分层也是明显可行的,但是需要更多的约束条件,因为它是基于一定的公约。

为了共享这些文件,你要创建完全可以在.NET 框架和.NET Core之间移动的类库。为了实现这个,你必须标识你想共享的组件。我建议你最好先确定你想迁移的组件和你不想迁移的组件不在同一个工程中。换句话说,一个工程要么完全可以共享,要么就不能共享。一旦这个确定了,那么就开始创建迁移类库并且移动代码。

作为一个经验法则,我会说共享二进制文件非常适合您的业务逻辑和核心层,同时对于在目标平台上可以高效部署的组件来说,共享资源是非常合适的,例如,你需要与UI API交互或者调用操作系统的特殊组件。值得指出的是.NET Core和.NET 框架的交叉口都是非常巨大的。实际上,几乎所有的.NET Core提供的API在.NET 框架上都是可用的,第二种方法并不像说的那么多限制。

关于这两种方法的详细比较,请看博客

把代码迁移到.NET Core

为了使得迁移更容易,我建议你在迁移的过程中把.NET 框架作为目标的时间尽可能放长点,使用API Port去标识迁移遇到的问题,大部分问题解决时才使用这个大的转换。用这种方式,你就不会在代码库并没有建立很长世间的担忧了。

当在计划你的迁移工作的时候,你应该也要考虑一下测试并且把测试当作你产品迁移的一部分。迁移往往导致很大的代码变化,所以如果你要确保中途没有引进新的bug。

需要最多的工作区可能还需要应用程序模型,无论是桌面应用程序或者ASP.NET:

· 对于桌面应用程序来说,很值得使用协同进化的方法因为它避免不具有任何临时版本的应用程序。

· 对于APP.NET应用程序来说,好方法是去编译这个应用程序,当作.NET 框架程序。第一个步骤,用ASP.NET Core代替ASP.NET 4。你可以决定舍弃你的程序,然后从新的.NET Core程序模型上获益。或者,你想全部移到.NET Core上去,运行API Port并且指出问题。一旦这两个完成了,你就可以把整个程序放到.NET Core上去了。

但是如果你的程序比较小,也许可以使用大铁锤方法:简单地创建新的工程,复制&黏贴已有的代码并且修复所有的编译错误。

更多的细节?

对于更多的细节,请看以下这些资源:

.NET Core发展

· 宣布.NET Core RC版

· Road to RTM for CoreFX

· 迁移到.NET Core上

· 迁移哪些API/技术到.NET Core上?

· 社区要求被移植的技术

API Port

· Channel9:.NET Portability Analyzer(API Port)概览

· 下载API Port

· GitHub上的API Port

总结

在这篇博客中,我概述了.NET Core带来的好处,还有就是哪类应用程序和组件可以从它获益。我们也在关注可以平衡.NET Core和已有程序的方法,既可以通过增加.NET Core基础经验到你的文件夹中或者在.NET Core顶端完全移植你的程序。我已经展示了你可以怎样使用API Port并且帮助你了解你的组件还有它们可迁移的程度。

如果你有任何问题或者关注,请留言让我们知道。如果你有把代码迁移到.NET Core上的经验,并且愿意谈谈这些,我非常高兴在Microsoft.com的immol上收到你的来信。我非常想知道我们可以做什么帮助你提高你的迁移经验。

祝你迁移快乐!

那些将在 .NET Core 中被废止的技术

虽然有一部分现有的.NET应用程序,尤其是基于ASP.NET MVC的应用程序将能够比较简单地迁移至.NET Core,但另一部分.NET应用在迁移过程中可能会遇到某些问题。有一些问题是显而易见的,例如从WinForms或WPF应用迁移至 Universal Windows Applications(UWP),而另一类些问题则更加微妙,这关系到.NET Framework核心功能中更底层的实现。

反射

反射API在.NET Core中产生了很大的变化。正如在WinRT中的应用方式一样,反射功能被分成一种轻量级的版本以及一种开销更大的版本。来自微软的Immo Landwerth写道:

在推出.NET Native时,我们利用了一种技术,它允许我们将应用与框架和第三方依赖进行静态链接。要使这种链接功能可行,它必须能够找出在你的应用没有使用的那部 分框架功能。对于其他技术,例如C++来说,这一过程并不复杂,因为这种系统并不具备反射这样的动态能力。当然,在.NET Native中仍然支持反射,但我们希望让这个平台尽可能地降低开销,也就是说不必为你所不需要的特性增加开销。这一点对于反射来说尤其明显,因为它对于 运行时以及编译器能够基于静态信息进行哪些操作施加了极大的限制。

因此,在理想的情况下,反射应当作为.NET Core中一个可选的组件,你可以选择在自己的应用中完全放弃使用它。麻烦在于,System.Object在进行Object.GetType()操作 时将对反射产生依赖。为了打破这种依赖,我们决定让System.Type不再展现整个反射类型信息,而仅仅展示类型的名称。这也意味着在.NET Core中的System.Type不再包括GetMembers()等API,但仍然会暴露Name等API。

通过一个名为GetTypeInfo的扩展方法,可以得到在一般情况下能够从Type对象中获取的信息。TypeInfo类所包含的信息没有原来那么丰富,但微软最近决定在.NET Core中重新引入一部分反射API,这部分变更是超出原先计划之外的。

为了使代码更容易进行移植,.NET 4.5及之后的版本提供了对TypeInfo的某种支持,它与在.NET Core中使用的版本相类似。

App Domain

App Domain在CoreCLR中得以实现,但没有在.NET Native中实现。由于对App Domain的实现需要大量的运行时特性支持,因此目前还没有任何对它的支持计划。“对于代码的隔离,我们建议通过进程或容器实现。而对于程序集的动态加 载,我们建议使用新的AssemblyLoadContext类。”

Remoting

现如今,已经很少有开发者还能够记起Remoting库的存在,更不要说如何使用它了。即使还有人在使用,他们也一直在抱怨它的性能、高复杂性以及总体表现的脆弱性。

如今,多个.NET应用在同一台机器上的通信基本都被WCF所取代,后者能够带来更好的性能,可用于管道或内存映射文件。对于跨机器的通信,微软推荐“使用一种低开销的纯文本协议,例如HTTP”。因此,微软并没有在.NET Core中支持Remoting的计划。

序列化

.NET Core将支持大多数序列化器,例如数据契约序列化XML序列化JSON.NET以及protobuf-net。而一个被排除在外的重要角色是二进制序列化。

通过这十年来的经验,我们终于了解到序列化是一项非常复杂的任务,支持序列化的类型在兼容性方面要面对沉重的负担。因此,我们已经决定让序列化 成为一种协议,它将在可用的公开API的基础上实现。然而,二进制序列化的实现需要对类型本身的深入了解,因为这种方式可以对整个对象图进行序列化,甚至 包括私有的状态信息。

沙箱

从理论上说,沙箱是一种优秀的思想,它允许部分信任代码以安全的方式执行。但在实践中,要想正确地应用它非常困难,哪怕是一点点微小的错误,也会导 致安全性方面的漏洞。Immo Landwerth还表示,它“使实现变得更加困难,并且经常会给未使用沙箱的应用的性能带来负面影响。”

推荐的替代方案是使用独立的进程,通过一个具有有限权限的用户帐号运行这些进程。通过这种方式,运行时不必重复进行一些开销较大的权限检查工作,因为操作系统已经为你完成了这方面的任务。

其他组件

微软正考虑将下表中列举的组件进行开源,并移植到.NET Core。

  • System.Data。虽然它的基础层功能,即提供者模型与SQL client 已经成为了.NET Core的一部分,但某些特性目前仍不可用,例如对于schema、DataTable和DataSet的支持。
  • System.DirectoryServices。.NET Core目前并不支持通过该组件与LDAP或活动目录进行通信。
  • System.Drawing。虽然从严格意义上来说,它应该属于一种客户端API,但还是有大量开发者在服务端通过绘图API实现缩略图或水印的生成。我们目前还不支持在.NET Core中使用这些API。
  • System.Transactions。虽然ADO.NET支持事务,但并不包括对于分布式事务的支持,后者包括氛围事务(ambient transaction)及资源征集(enlistment)的概念。
  • System.Xml.Xsl与System.Xml.Schema。.NET Core支持XmlDocument以及由Linq引入的XDocument,包括XPath在内。不过,目前还不支持XSD(XmlSchema)及 XSLT(XslTransform)。
  • System.Net.Mail。目前还不支持在.NET Core中通过这些API实现电子邮件的发送。
  • System.IO.Ports。.NET Core目前还不支持与串行化端口的通信。
  • System.Workflow。Windows Workflow Foundation(WF)目前在.NET Core中尚不可用。
  • System.Xaml。在开发UWP应用时,开发者将使用WinRT XAML API。因此,.NET Core目前并不支持托管XAML框架,后者包括解析XAML、并实例化描述对象图的功能。

你是否有兴趣帮助我们移植某个组件?.NET Framework实现的部分源代码已经通过MIT许可进行了开源,作为Reference Source的一部分。我们正在设法让社区能够对我们的移植工作提供支持。如果你愿意参与这一项目,请发送邮件至immol@microsoft.com。

查看英文原文:Discontinued Technology in .NET Core

 

Your First ASP.NET 5 Application on a Mac

ASP.NET 5 is cross-platform; you can develop and run web apps on Mac OS X, Linux and Windows. This article will show you how to write your first ASP.NET 5 application on a Mac.

Setting Up Your Development Environment

Scaffolding Applications Using Yeoman

Follow the instruction in Building Projects with Yeoman to create an MVC 6 project.

Developing ASP.NET Applications on a Mac With Visual Studio Code

  • Start Visual Studio Code

../_images/vscode-welcome.png

Note

If Visual Studio Code is not installed, see Install ASP.NET on your Mac with OS X.

  • Tap File > Open and navigate to your ASP.NET app

../_images/file-open.pngFrom a Terminal / bash prompt, run dnu restore to restore the project’s dependencies. Alternately, you can enter commandshift p and then type >d as shown:

../_images/dnx_restore.pngThis will allow you to run commands directly from within Visual Studio Code, including dnu restore and any commands defined in the project.json file.

At this point, you should be able to host and browse to this simple ASP.NET web application, which we’ll see in a moment.

This empty project template simply displays “Hello World!”. Open Startup.cs in Visual Studio Code to see how this is configured:

../_images/vscode-startupcs.pngIf this is your first time using Visual Studio Code (or just Code for short), note that it provides a very streamlined, fast, clean interface for quickly working with files, while still providing tooling to make writing code extremely productive.

In the left navigation bar, there are four icons, representing four viewlets:

  • Explore
  • Search
  • Git
  • Debug

The Explore viewlet allows you to quickly navigate within the folder system, as well as easily see the files you are currently working with. It displays a badge to indicate whether any files have unsaved changes, and new folders and files can easily be created (without having to open a separate dialog window). You can easily Save All from a menu option that appears on mouse over, as well.

The Search viewlet allows you to quickly search within the folder structure, searching filenames as well as contents.

Code will integrate with Git if it is installed on your system. You can easily initialize a new repository, make commits, and push changes from the Git viewlet.

../_images/vscode-git.pngThe Debug viewlet supports interactive debugging of applications. Currently only node.js and mono applications are supported by the interactive debugger.

Finally, Code’s editor has a ton of great features. You should note right away that several using statements are underlined, because Code has determined they are not necessary. Note that classes and methods also display how many references there are in the project to them. If you’re coming from Visual Studio, Code includes many of the keyboard shortcuts you’re used to, such as command k c to comment a block of code, and command k u to uncomment.

Running Locally Using Kestrel

The sample is configured to use Kestrel for the web server. You can see it configured in the project.json file, where it is specified as a dependency and as a command.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 {
   "version": "1.0.0-*",
   "userSecretsId": "aspnet5-MyWebApp-a1b07c55-6f20-4aaf-9852-9c964160a00c",
   "compilationOptions": {
     "emitEntryPoint": true
   },
   "tooling": {
     "defaultNamespace": "MyWebApp"
   },

   "dependencies": {
     "EntityFramework.Commands": "7.0.0-rc1-final",
     // Dependencies deleted for brevity.
     "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final"
   },

   "commands": {
     "web": "Microsoft.AspNet.Server.Kestrel",
     "ef": "EntityFramework.Commands"
   },

   // Markup deleted for brevity.

   "scripts": {
     "prepublish": [
       "npm install",
       "bower install",
       "gulp clean",
       "gulp min"
     ]
   }
 }
  • Run the dnx web command to launch the app
  • Navigate to localhost:5000:

../_images/hello-world1.png

  • To stop the web server enter Ctrl+C.

Publishing to Azure

Once you’ve developed your application, you can easily use the Git integration built into Visual Studio Code to push updates to production, hosted on Microsoft Azure.

Initialize Git

Initialize Git in the folder you’re working in. Tap on the Git viewlet and click the Initialize Git repository button.

../_images/vscode-git-commit.pngAdd a commit message and tap enter or tap the checkmark icon to commit the staged files.

../_images/init_commit.PNGGit is tracking changes, so if you make an update to a file, the Git viewlet will display the files that have changed since your last commit.

Initialize Azure Website

You can deploy to Azure Web Apps directly using Git.

Record the Git URL for the Web App from the Azure portal:

../_images/azure-portal.png

  • In a Terminal window, add a remote named azure with the Git URL you noted previously.

    • git remote add azure https://Rick-Anderson@rickmac.scm.azurewebsites.net:443/rickmac.git
  • Push to master.

    • git push azure master to deploy.

      ../_images/git-push-azure-master.png
  • Browse to the newly deployed web app.

How to upload a file to a Web server in ASP.NET by using Visual C# .NET

https://support.microsoft.com/en-us/kb/323246

 

Upload larger files

By default, ASP.NET only permits files that are 4,096 kilobytes (KB) (or 4 MB) or less to be uploaded to the Web server. To upload larger files, you must change the maxRequestLength parameter of the <httpRuntime> section in the Web.config file.

Note When the maxRequestLength attribute is set in the Machine.config file and then a request is posted (for example, a file upload) that exceeds the value ofmaxRequestLength, a custom error page cannot be displayed. Instead, Microsoft Internet Explorer will display a “Cannot find server or DNS” error message.

If you want to change this setting for all of the computer and not just this ASP.NET application, you must modify the Machine.config file.

By default, the <httpRuntime> element is set to the following parameters in the Machine.config file:


<httpRuntime 
executionTimeout="90" 
maxRequestLength="4096"
useFullyQualifiedRedirectUrl="false" 
minFreeThreads="8" 
minLocalRequestFreeThreads="4"
appRequestQueueLimit="100"
/>
				

The Machine.config file is located in the \System Root\Microsoft.NET\Framework\Version Number\CONFIG directory.