难以接受你的改变:从project.json到.csproj
Posted dudu
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了难以接受你的改变:从project.json到.csproj相关的知识,希望对你有一定的参考价值。
自从微软做了一个艰难的决定——.NET Core彻底放弃project.json,全面改回.csproj——至今,虽然赞美之声不断,但我依然不喜欢也难以接受这样的改变。
难以接受主要有两方面的原因:
1)由繁入简易,由简入繁难
习惯了json格式的简洁,很难再适应xml格式的繁琐。无论微软怎么简化.csproj,与project.json天生的简洁相比也是望尘莫及。简单对比一下,立马就能体会到。
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0"> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.DataProtection" Version="1.2.0-*" /> </ItemGroup> </Project>
{ "dependencies": { "Microsoft.AspNetCore.DataProtection": "1.2.0-*" } }
用 project.json 的时候经常喜欢直接在 project.json 文件中修改,可是面对 .csproj 却少了直接修改的欲望。
2)xml与json配置文件的混杂带来不一致的编辑体验
改变的只是project.json,其它的配置文件依然是json格式,比如appsettings.json,两者混杂在一起更显.csproj的格格不入,仅仅这个不一致的编辑体验就让人难以适应。
那微软为什么要做这样一个打自己脸的艰难决定?我想根本原因是为了 .NET Core 能用上历史悠久的 MSBuild 作为 Build工 具,.NET 平台上的很多工具都依赖 MSBuild ,继续使用 MSBuild 有很大的连锁效益。但让 .NET Core 用上 MSBuild 并非只有这一条路,比如让 MSBuild 支持 project.json ,微软为什么选择放弃 project.json 的下策呢?要么微软偷懒,要么因为 MSBuild 的本身设计问题造成很难实现对 project.json 的支持?后者的可能性非常大,因为 MSBuild 过于依赖 xml 配置文件(build任务都是通过xml配置定义的),要它支持另外一种格式的配置文件改动可能非常大,微软选择这样的下策可能处于无奈。虽然理解微软的难处,但站在用户的角度,我还是更喜欢 project.json,难以接受 .csproj。
以上是关于难以接受你的改变:从project.json到.csproj的主要内容,如果未能解决你的问题,请参考以下文章
.NET Core 工具从 project.json 移动到基于 MSBuild 的项目后的使用
.NET Core项目从xproj+project.json向csproj迁移简介