レガシー資産マニアのブログ

愛知県三河から、石川→新潟へととびまくってきたSEのブログ。長岡市を拠点に、もそもそ動いているプログラマー。 長岡の自称ジャニーズが合い言葉。そんな山P。 初めてPCを触ったのは小2にも関わらず、言語知識に乏しいので、 .NETの勉強会を通して、.NETの知識向上と、人脈を広げたい。 座右の銘は「死ぬ気でやってみろ。死なないから」

MSBuildでビルド可能なプロジェクトファイルを比較してみた

本ページは、「C# Advent Calendar 2017」の5日目の記事です。
qiita.com

なぜC#?

キッカケは、本Advent Calendarをつくった、ろっさむさん
(@4_mio_11)を尊敬しているので、何かお力になりたい、そんな不純?純粋?な動機からです。
qiita.com

普段は...

実は普段は全くと言ってよいほどC#を使いません。
なのに記事を書こうと手を挙げてしまった僕。さて、どうしましょうか。

※使っていないわけではなく、興味もあります。
※その証拠に、このような勉強会を行っています。是非!
 登壇者も個人的には、随時募集したいので、ぜひ繋がりましょう!!
 Niigata.NETngtnet.connpass.com
 Me -> twitter.com

なぜろっさむ氏と知り合ったか

東ゲ部ってしっていますか?
関東ゲーム部。
http://www.to-gebu.site/
https://twitter.com/proposertogebu

名前からしてわかる通り、ゲームを作る方々の自主的な集まりなのですが、
そこで「もくもく会」をなさっていると聞き、
ゲームより「もくもく会」に惹かれ行っちゃいました(笑)

なぜMSBuild?

ここを話さなければいけませんね。
実は普段はC++Builder使いなんです。
そうなると縁遠い、と思われがちですが、実は違います。

昔は、C++Builderは完全にMSと異なるプラットフォームをいきつつも、
(今はなき)「C# Builder」を作っていた時代があります
そして、わかる方には分かるのですが、
C++Builderときておそらく大方の方は「Dephi」が頭をよぎるでしょう。
Delphi構文を見ていただくと分かるのですが、VBC#と非常に似ています。
ましてやC++Builderの実装思想も、実はC#と非常によく似ています。

そして、今。

昔のC++Builderからビルドエンジンが変わり、bccから、MSBuildeでもビルド
できるように内部ロジックやプロジェクト構成が変わってきています。

ということで、MSBuildと出逢うこととなったわけです。
この辺の話は、次のAdvent Calendarで書きますね。
qiita.com

MSBuildとは

.NET Framework 2.0以降で搭載されたオープンなビルドエンジンです。
独自のXMLファイルを解釈することで、.NETのプログラムを生成することが出来ます。

MSBuildは何をやっているの?

そもそものMSBuild自体はオープンソース化されています。
こちら。
github.com
見ると分かりますが、プロジェクトは「csproj」ファイルです。
そう、C#!ソースコードC#!
単純にMiocrosoft.MSBuildクラス内の関数をコールしているだけですが、よく作ったなぁ、というのが個人的な印象です。

https://github.com/Microsoft/msbuild/blob/master/src/MSBuild/XMake.cs
BuildProject()関数があります。この中で、さらに「ExecuteBuild()」を読んでいますが、
実体はこれのようです。

  • buildManager.PendBuildRequest

→ビルドの予約。
https://docs.microsoft.com/ja-jp/dotnet/api/microsoft.build.execution.buildmanager.pendbuildrequest?view=netframework-4.7.1#Microsoft_Build_Execution_BuildManager_PendBuildRequest_Microsoft_Build_Execution_BuildRequestData_

  • s_activeBuild.Execute

→ビルドの実行
https://docs.microsoft.com/ja-jp/dotnet/api/microsoft.build.execution.buildsubmission.execute?view=netframework-4.7.1#Microsoft_Build_Execution_BuildSubmission_Execute

実体は単純に.NET Frameworkのクラスを読んでいるだけですので、
結構単純な様ですね。

コレさえ分かれば、究極な所、独自言語を作れる訳です。
独自言語を作ることはしないので、一旦はここで、MSBuildのソースを見ることはやめます。
興味がある方は、引き続きご覧ください。

ちなみに...

MSBuildでビルドできるプロジェクト構成を比較してみよう
と、ここまできたところで、ふとした疑問。
各言語で新規作成をしたプロジェクトファイルを比べてみたい。
C#VBって違うの?C++Builderってどう違うの?と。

ちなみに、家でVisual Studio 2015でF#をやろうとしたところ、
Downloadして!と新規作成時に促されたのでその通り進んたところ、
VSが閉じてないよ!とログで怒られたのは納得がいかない...
[0BB0:0D30][2017-12-03T23:15:27]i000: MUX: Warning Block: ProcessBlock : We recommend you close Visual Studio now before setup continues. If you proceed without closing Visual Studio, the application may become unstable.


全て新規作成をしただけの結果は、以下の通りです。(VS2013形式/C++Builder XE7形式)
gist.github.com

見ていただくと分かるのですが、明らかに、言語によってプロジェクト構成が異なります。
全てMSBuildが通ることは確認しましたが、こんなに言語によって書き方、量がことなるという点を考慮すると、C#は凄いのだな、と思います。
VS2017では、さらに形式が変わっている、とのお話もあります。
プロジェクト構成は、少しずつ進化をしているのですね。
ufcpp.net


さて、VS2013レベルですが、気がついた点。

  • 最もコード量が少ないのは、F#
    • プレーンプロジェクト、かつ、コマンドラインで生成してしまったので、仕方なし。
  • VBは案外頑張っている。
    • ファイルを見ると分かるのですが「41999,42016,42017,42018,42019,42020,42021,42022,42032,42036,42314」といった行が散見されます。
    • 若干無理矢理感が・・・
  • WinForm/Wpf共にプロジェクト構成はほとんど違わない
    • 当たり前と言えばそれまでなのですが、あまり気にすることがありませんでした。言語は共に同じであった時に、間隔的にすごく違うように思えていました。普段から使わないからこそ、そう感じていただけかもしれません。
  • C#とは違いますが、C++のプロジェクトは...汚いですね(^^;


ソースを記述することばかりに気が向きがちですが、
やはりビルドの事も少し気に掛けると、面白い、と思っていただければ、
これ幸いです。