難以接受你的改變：從project.json到.csproj

標籤：選擇   微軟   sdk   code   簡單   mic   setting   自己   支援   

自從微軟做了一個艱難的決定——.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