開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/09/09

Visual Studioや.NETのバージョンアップの度に苦しむビルド・システム問題

Tweet ThisSend to Facebook | by:nishino
 丁度、今、Visual Studio 2019と、.NET Core 3.0 の対応を行っていて、思ったこと。と言うか、バージョンアップ作業の度に思う事。を、今回と次回に渡って少々書かせて頂こうと思います。

 今回は、ビルド・システム周辺の変更についての話です。ハイパフォーマンスなプロダクト開発を行う上で、ビルド・システムの整備は欠かす事が出来ないキャパシティ向上施策の一つかと思います。しかし、M某社、Visual StudioやTeam Foundation Serverでマネタイズしているからか、MSBuildの単体使いとかしていると、バージョンアップの度に色々変わってて、毎回キツイですね。


 実際、私のTwilogを見ると、ひたすら、「ビルド通らない...。」とか、「MSBuildエラー出た...。」とか「NuGetエラー出た...。」つぶやいていますし、実感として、開発で一番シンドイの、期末のリリース時に、ビルド・システムを整える時だな。なんて、冗談半分で思ったりしています。実際、私のWikiを見ると、結構サポート技術情報が書かれていたりします。


 この現状は、Visual Studio(GUI)がワンストップで対応し過ぎる余り、1連のプロセスがブラック・ボックス化され、個々の技術情報が提供されない事に起因するのだと思います。

 ...しかし、前回、言及したように、

 「エコシステム形成のためにパワーユーザーに対する敷居を下げているようにも見える。

 と、情勢も変わって来ているので、

 この問題、.NET Core の dotnetコマンド(dotnet msbuild など)のみになったら解決するんですかねぇ?なんて、淡い期待を抱いていたりしています。
09:00 | 投票する | 投票数(0) | コメント(1) | ご報告
コメント
nishino2019/09/19 14:53:45
 後日談として、また、MSBuildでハマりまして、結論としては、MSBuildとプロジェクト・ファイル(*.csproj、*.vbproj)のフォーマットがセットになっていて、これらがバージョン・アップで変更になった際に、Visual Studioで上手いことラップされていてブラックボックス化されているので移行でトラブるのだろうな、と。

 今後のdotnetでは、簡潔になったプロジェクト・ファイルとdotnet msbuildになり、Visual Studioの依存も軽減されていくと思われます。と言うのも(、Language Server Protocol、Debug Adapter Protocolなど)、Visual Studio Codeの隆盛で、フリーのIDEが当たり前になって行くものと思われるため。