今日も今日とて休日出勤\(^o^)/
現在、C#をメイン言語として使用しています。
で、当然というか、開発の区切りだったり、テストするためにビルドというものをやります。
このビルド、プロジェクトが巨大化すると、非常に重く、更に時間がかかるようになります。
それだけなら、コマンドプロンプトで~なんてことは考えなかったのですが、「Release」ビルドの作成が必要となり、コマンドラインでの実行を模索することになりました。
なぜ、切り替えが必要なのか
普段は、Debugモードで、処理の途中の値とか確認したりするけど、デバッグ用に無駄(?)なファイルも生成するし、最終的にお客さんに提供する時は、Releaseモードでビルドしたものが必要になる。
って感じ。
詳細に解説は出来ないので、ざっくり言うと、お客さん用のバージョンを作るわけ。
DebugとReleaseの切り替えに時間がかかる
自分がバージョンは、2015なので、その画面を前提に話をしますが、DebugとReleaseの切り替えにとにかく時間がかかる。
今のプロジェクトだと、2~3分ちょっと・・・かな。
手元の時計での計測だから、厳密じゃないけど、この切り替えだけで1分超えってのは、とにかく無駄。
作業の途中で、Release版のビルドをお願いされたりすると、作業を止めて開発途中のソースが影響出さないようにしてからのビルドになる。
開発の手も止まるし、時間もかかるしで、いいことが全く無い。
開発部署によっては、最終的なReleaseビルドは管理されたサーバーでしか作らないとかルールはあるんだろうけど、今プロジェクトでは、自分が半分くらい担当してたりw
時間がかかることだけが問題じゃない
切り替えや、準備に時間がかかると書いてきましたが、問題はそれだけじゃありません。
切り替えにかかる時間を無くそうと、Releaseビルド用のフォルダを作成し、そこへプロジェクト用のファイルを全てコピーしました。
ビルドの構成はもちろん、Releaseに選択済みです。
なので、必要なファイルを受け取ったら、即Releaseビルドが出来るぜ!ヒャッハー!!
って感じだったのですが、そもそもプロジェクト(.slnファイル)を起動し、もろもろのファイルを読み込み、ビルドが出来る状態になるまでに、おおよそ2分!
構成をDebugからReleaseへ切り替えるより、余計に時間がかかるようになりました\(^o^)/
更に、その間は時間がかかるからといって、PCの前から離れられないオマケ付きw
MS製品だし、コマンド実行出来てしかるべきじゃね?
ということで、Microsoftの製品だし、コマンド実行オプションがあるはず!!
で、調べました。
方法は2つ。
msbuild.exeを使った方法
https://msdn.microsoft.com/ja-jp/library/ms164311.aspx
devenvを使った方法
https://msdn.microsoft.com/ja-jp/library/xee0c8y7.aspx
msbuild.exeを使った方法
Linuxとかでよく使うMakeコマンド的なことが出来るみたい。
なんですが・・・
すいません、知識不足で、ビルドまで辿り付けませんでした・・・
ネットで探すも、バージョン違いだったりして、自分の環境には合わず。
XMLでパラメータファイルを作成して、かなり細かいことが出来るみたいなんですが、今回は、Releaseビルドが作成できればよかったので、諦めました。
開発と並行でなく、時間が出来たら、また調べたい。
devenvを使った方法
こちらを採用しました。
devenv
スイッチの構文規則は、他の DOS コマンド ライン ユーティリティのものとよく似ています。 すべてのdevenv
スイッチと引数に適用される構文規則は以下のとおりです。
devenv
で始まるコマンド。- スイッチは大文字と小文字を区別しません。
- ソリューションまたはプロジェクトを指定するとき、最初の引数はソリューション ファイルまたはプロジェクト ファイルの名前 (ファイル パスを含む) です。
- 最初の引数がソリューションでもプロジェクトでもないファイルの場合、そのファイルが IDE の新しいインスタンスで適切なエディターを使用して開かれます。
- ソリューション ファイル名の代わりにプロジェクト ファイル名を入力すると、
devenv
コマンドは、プロジェクト フォルダーの親フォルダーで同じ名前が付いているソリューション ファイルを検索します。 たとえば、devenv /build myproject1.vbproj
というコマンドは、親フォルダーで “myproject1.sln” という名前のついたソリューション ファイルを検索します。
メモ このプロジェクトを参照するソリューション ファイルは、親フォルダーの中に 1 つだけ置かれている必要があります。 親フォルダーにこのプロジェクトを参照するソリューション ファイルがない場合、また親フォルダーにこのソリューション ファイルが 2 つ以上ある場合は、一時ソリューション ファイルが作成されます。一時ソリューション ファイルは、プロジェクトにちなんだ名前となり、プロジェクトを参照します。 - ファイル パスやファイル名にスペースが含まれる場合は、二重引用符 (“”) で囲む必要があります。 たとえば、”c:\project a\” と指定します。
- 1 行に複数のスイッチや引数を入力する場合は、空白文字 1 つで区切ります。 たとえば、devenv /log output.txt というコマンドは、IDE を開き、そのセッションのすべてのログ情報を output.txt に出力します。
devenv
コマンドではパターン一致構文を使用できません。
https://msdn.microsoft.com/ja-jp/library/xee0c8y7.aspx
から引用。
正直、意味不明です。
まぁ、大体こんな時は、使ってみて、必要なことが出来ればOKなのでw
ということで、何はともあれ、使える状態になりました。
実際のバッチファイル
"c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv" プロジェクト.sln /Build "Release" /out build.log
この1行です。
実行パス
公式ページでは、
<strong>Devenv myproj.csproj /build</strong>
で実行できるらしいけど、自分の環境だと環境変数とかの関係で、フルパスで実行してやる必要がありました。
面倒くさかったしw
で、そのdevenvの場所は、VisualStudioのインストール先になります。
自分の場合は、VisualStudio 2015なので「c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv」がその場所になります。
バージョンによって、Microsoft Visual Studio 14.0 が13だったり、12だったりするので、自分の環境を確認してください。
一番簡単なのは、スタートメニューから、VisualStudioのメニューのショートカット先を確認するのが早いかな。
ソリューション
これは、ビルドしたいソリューションファイルを指定。
プロジェクトによるけど、「.sln」の拡張子のやつです。
ビルドオプション
/Build って部分。
その後ろの「”Release”」部分で、DebugかReleaseの切り替えが出来る。
なので、ソリューションファイルを起動すると重くて時間がかかる・・・って時には、Debugに指定したバッチファイルを作っておくと、ビルドも出来る。
ログの出力
/Out って部分。
必要なければ、つけなくても良い。
GUIだと、出力ログに表示されるところが出力される。
一応、エラーとかの原因でビルドが失敗することもあるから、ログには出力するように。
他のビルドオプション
個人的には、/Clean ぐらいかな。
念のため、クリーンをかけてから、ビルドって流れにしたい。
他のオプション
"c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv" プロジェクト.sln /Clean Release
で、/Cleanオプションをつけておけば、クリーン実行も可能。
後ろに「Release(もしくはDebug)」ってつけないと、「プロジェクト.sln」で保存されているソリューション構成になってしまうので、明示的に指定する必要があるくらい。
クリーンの後にビルドするぐらいなら、/Rebuild オプションでもいいぐらいだけどw
バッチファイルのメリット
ソリューションを起動する必要がないのでその分だけ早い
DebugとReleaseを1行ずつ記載すれば、1つのバッチファイルで両方のビルドが可能
devenvの起動自体に時間はかかるけど、VisualStudio起動時のような大量のファイルの読み込みは発生しない
バッチファイルのデメリット
ビルドエラーは、ログファイルを見るまで分からない
正味の時間はあまり変わらない
まとめ
自分の環境では、VisualStudioの起動自体がそこそこ時間かかるので、バッチファイルを実行しても、実際にビルドが開始されるまではそれぐらいの時間はかかります。
ビルドにかかる正味の時間だけなら、あまり変わりません。
でも、新しくソリューションファイルを起動して、プロジェクトの読み込みを待って・・・って事を考えれば、一連の処理がダブルクリックで完結するので、問題は解決できたと言って良いw
朝、PCを起動してから、バッチファイルを実行しておけば、トイレ行ったりコーヒー淹れたりしている間に、最新ビルドが作成出来ているのでオススメ。
今後の課題は、もう少しオプションを使い分けられるようになること・・・かなw