移植MSbuild到.NET core

[原文发表地址]:Porting MSBuild to .NET Core [原文发表时间]:February 23, 2016 这篇文章是由.NET团队的软件工程师Daniel Plaisted所创作。 对.NET来说,.NET核心的到来是个激动人心的时刻,我们正朝着一个开源跨平台的世界全速前进。.NET核心为app提供了一个现代化,app本地化并且一直开源的框架。但是,相对与.NET框架,.NET核心有一些变化,这意味着如果你想要把基于现有的.NET框架代码移植到.NET核心框架,需要做一些努力。 在我们最近移植到.NET核心的文章中,我们讨论了何种类型的代码移植到.NET Core比较有意义,并且对将代码移植到.NET 核心提供了一些建议,方法和工具。在这篇博客中,我将会分享一些将MSBuild移植到.NET 核心的经验。如果你正将代码移植到.NET 核心,它会有助于提高那些已经成熟的重点的移植经验。 MSBuild是.NET和Visual Studio的构造引擎。常用于建立许多开源的.NET项目,包括corefx(.NET 核心类库),coreclr((.NET 核心的运行环境)和Roslyn(.NET 的编译平台)。作为一个开源跨平台的项目,我们希望用户可以修改,构建并为这些项目贡献,而不需要他们用窗口去做。为了支持这些,我们在去年的三月开源MSBuild,并且在九月宣布,我们正致力于在.NET核心的顶端将它跨平台移植运行。现在我们已经基本完成了将MSBuild移植到.NET核心的工作并且正在研究将它集成到开源库的基础架构。 战略部署 在2015的五月,MSBuild最初是在GitHub上被开源的。最初他被运行Mono运行环境下的一个独立的linux分支上。这个分支是我们.NET核心端口的出发点。这一计划最终将这些变化合并到主分支,并且对拥有相同的源代码的.NET核心和.NET框架的MSBuild 进行编译。 MSBuild的.NET核心版本的目标是支持在Windows,Linux,和Mac OS构建.NET核心项目,不依赖于完整的.NET框架或是Mono。兼容全部MSBuild的.NET框架版本或者构建桌面.NET框架项目都不是我们的目标,因为构建这样的一个项目要依赖于那些.NET核心上不可用的一些功能(例如,全局程序集缓存)。 因为MSBuild的.NET核心版本不能完全与.NET 框架版本相兼容,但是我们最终想要合并代码库。在.NET核心版本与桌面版本不同的地方,我们使用条件编译。我们使用细粒度特征标识,例如用FEATURE_APPDOMAIN支持AppDomain或者是FEATURE_BINARY_SERIALIZATION. [fine-grained feature flags 细粒度特征标识] 比起我们使用如NETCORE一样的一些逐行编译的汇编语言,这有助于帮助我们更清楚地了解为什么这一部分的代码对.NET 核心是不可以的。它也意味着如果一些特性被添加到.NET 核心,这将会很容易返回和获取相应的MSBuild 的.NET 核心代码。 移植跟踪进度 我们使用ApiPort工具去找到那些在.NET核心不支持的正在使用的API MSBuild,去帮助我们获得我们将要移植到.NET核心的内容的一个最初的想法,紧接着,我们使用ApiPort追踪我们的移植进度需要多少工作量。 ApiPort分析编译管理程序集。所以你需要成功地编译代码从而去分析ApiPort.。因此,从定义上来说,只有完成移植,在.NET 框架上编译并运行ApiPort的代码,我们才能够将.NET 核心编译成功。我们不想改变正常.NET框架上的构建行为。因此,为了成功编译结果去分析,我们创建了一个适用于.NET框架但是同样适用于与.NET核心中相同的一些特性配置。 然而,我们发现我们无法使用ApiPort追踪我们距离成功编译这个项目还有多近,因为一旦这个项目被成功移植到.NET 核心时,ApiPort通常仍会报告它的可移植性仍然低于100%。这个主要原因是,在一些案例中,我们会将APIs从.NET框架复制到MSBuild代码库。即使我们自己通过添加实现到我们的项目里,使他可用,但是当我们用ApiPort分析可移植性的时候,这些APIs还是被报告成不可用。另一个原因就是ApiPort经常检测到APIs对一些反射并不支持(详情见GitHub上的bug)。下表是对MSBuild项目,以最小变化支持.NET 核心(初始分数)的可移植性分数报告和该项目移植到.NET 核心成功编译之后的分数(总分)。 有两个关于ApiPort的小问题:不分析调用原始APIs(通过PInvoke)并且它报道了基于不同数量上的APIs的可移植性得分,而不是基于API使用数量的实例。因此在项目中删除一个仅仅使用一次且不被支持的API将会提高可移植性的得分,同时,删除许多不被支持的API接口直到删除最后一个API也不会影响分数。 虽然在本例中的ApiPort可移植性分数报告可能会被误解,但我认为让它“更精确”并不是必要的。没有工具能够神奇的告诉你移植一些代码的时候将会有多大的工作量或者是它会花费多长时间。ApiPort像所有的度量一样,它仅仅是报告的度量,如果你理解它到底意味这什么,它将会非常有用。 构建.NET 核心 移植到.NET 核心的第一部分将建立在构建系统上使我们可以对.NET 核心进行代码编译。同时,唯一的不确定性方法是在.NET 核心上构建及运行的应用程序时DNX.DNX项目系统并不像MSbuild那样,支持大量的可扩展性及灵活性,这是为什么我们首先将MSBuild移植到的.NET…


迁移到.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…


.NET一周要闻 —— 2/17/2016

[原文发表地址]:The week in .NET – 2/17/2016 [原文发表时间]:February 17, 2016 关于.NET 上周, 我们在节目中邀请了Aaron Stannard, 讨论Akka.NET.相关的内容。 这周我很期待能和Joe Duffy 讨论关于Midori。 本周新闻汇总:Scientist 端口 无论你如何认真的测试重构,都很难100%确定你的更改将对实际数据和工作负载产生的影响,直到你将它们投入生产。 Scientist是一个由GitHub生成的非常整齐的Ruby库,使得它可以为已存在相同逻辑的代码部署重构。这将减少部署新代码产生的的风险, 因为旧的代码仍在运行,当结果与预期不一致时你可以选择正确的处理方式。 你也可以收集有关新代码没有完全部署产生的数据。 至少有两个Scientist端口是为.NET同时工作的。第一个是半官方的项目,Phil Haack 通过GitHub在Scientist.NET上工作,第二个像是一个已经完成的项目:Dave Zych’s Schience var publisher = new FilePublisher(@”C:\file\path\to\results.log”); var userCanRead = Shience.New<bool>(“widget-permissions”) .Test(control: () => UserPermissions.CheckUser(currentUser), candidate: () => User.Can(currentUser, Permission.Read)) .PublishTo(publisher.Publish) .Execute view raw Schience.cs hosted with ❤ by…


.NET一周要闻 —— 2/23/2016

[原文发表地址]:The week in .NET – 2/23/2016 [原文发表时间]:February 23, 2016 在.NET中 上周,Joe Duffy 谈论有关Midori的展出。这周我们把展出的时间放在星期四的下午四点,但对我们来说很荣幸的是我们可以对Scott Hanselman做一个采访。 这一周要做的东西: RestSharp 与REST资源交互的理论可能只需要使用标准的HTTP协议,但是在练习中还有一些要注意的包括和他相关的序列化,还有身份验证。RestShap是一个库,便于REST在.NET代码中交互。 以下的例子是你如何查询一个假设有关工作人员的目录服务信息: var client = new RestClient(“http://microsoft.com”); var request = new RestRequest(“people/{alias}”); var alias = “beleroy”; request.AddUrlSegment(“alias”, alias); var person = await client.ExecuteGetTaskAsync<Person>(request).Data; Console.WriteLine($”{alias} stands for {person.FirstName} {person.LastName}.”); view raw RestSharp.cs hosted with ❤ by GitHub 用户组的这一周:西雅图的移动.NET开发人员 在2月24日星期三的6:00,我们的Stacey Haffner会…