トップ > .NET

Jenkins で Visual Studio のコード分析結果を表示する方法

ツール .NET

はじめに

先日、Jenkins でテスト結果やコードカバレッジを表示できるようにしました。

これで終了と思いきや、「コード分析の結果も表示して」との要望が。


まぁ、Visual Studio 2010 Premium Edition のライセンスは開発者全員分無いし(というか数個だけ)、FxCop 使うために利用許可を申請するのも面倒なので、ビルドサーバーでコード分析して表示するようにしましょうかね。

Visual Studio での設定

プロジェクトをビルド時に、自動でコード解析が実行されるように設定します。

プロジェクトのプロパティを開いて、一番下のコード分析を選択。自動でコード解析するにチェックをつけます。

これで、ビルドしたときにコード分析が実行されるようになります。分析結果は、アセンブリ出力先と同じディレクトリに、<アセンブリ名>.CodeAnalysisLog.xml というファイル名で出力されます。

Jenkins 側の設定

コード分析結果の表示には、Violations プラグインを使います。Violations プラグインは Trac Lightning で Jenkins をインストールしたら、すでに入っていました。

コード解析結果を表示したいプロジェクトの設定を開いて、Violations の設定をします。

Visual Studio のコード分析結果は FxCop 形式なので、FxCop のところに分析結果ファイルのパスを指定します。ちなみにワークスペースからの相対パスです。

分析結果ファイルは複数あるので、その全てを表示するためにファイルのパターンを指定しています。

これで設定完了

ビルドを実行し成功すると、Jenkins のプロジェクトのページにコード分析のレポートが表示されるようになります。

テスト結果にコードカバレッジに、コード分析結果。これだけ表示すれば十分でしょ。

Jenkins で MSTest の結果とコードカバレッジを表示する方法

ツール .NET

はじめに

Jenkins で .NET ソリューションのビルドとテストが出来るようになりました。これだけでも便利ですけど、欲を言えばテスト結果を Jenkins 上に表示したい。あと、コードカバレッジのレポートも表示できると、いろいろ捗りそうです。

ということで、テスト結果とコードカバレッジを Jenkins で表示することに挑戦しました。ちなみに Visual Studio 2010 のコードカバレッジ機能は Premium 以上のエディションで利用できます。

今回の作業は、次の記事を参考にしました。

そのままでは上手く動かないので、やったことをまとめておきます。

Visual Studio ソリューションの設定

テストプロジェクトが既に作成されていることを前提に進めていきます。

コードカバレッジの有効化

まず、テストプロジェクトを含むソリューションを開き、拡張子が .testsettings ファイルを開きます。ここでは Local.testsettings を選択。ソリューションに無い場合は、[追加] - [新しい項目(W)...] から [テストの設定] を選んで、ファイルを追加して下さい。

[テストの設定] ダイアログが表示されるので、[データと診断] を選択し、右下のリストに表示されている [コードカバレッジ] にチェックをつけます。

コードカバレッジを診断するアセンブリの指定

次に、リストの上にある [構成] ボタンをクリックすると、[コードカバレッジの詳細」ダイアログが表示されます。

カバレッジを測定するアセンブリにチェックをつけて、OK をクリック。[テストの設定]ダイアログに戻ったら、いったん、[適用] ボタンをクリックして設定を保存しておくといいです。

テスト結果出力先の固定

MSTest を実行して生成されるファイルやフォルダは、初期設定のままだと、名前にタイムスタンプがついてしまいます。タイムスタンプがついていると Jenkins で設定するのが面倒になるので、名前を固定しておきます。

[全般] を表示し、[ユーザー定義されたスキーム] を選択します。テスト結果が出力されるフォルダの名前を固定するために、下図のように入力。

これで Visual Studio での設定は終了

テストを実行すればコードカバレッジも測定されます。設定した後、ちゃんとコードカバレッジが出力されるかを試しておくといいです。

コードカバレッジのデータは 

<ソリューションディレクトリ>/TestResults/TestResult/In/<コンピュータ名>/data.coverage

に出力されます。


Jenkins にプラグインを導入

MSTest の結果を Jenkins に表示するために、MSTest プラグインを導入します。

コードカバレッジは Emma 形式に変換して表示するので、Emma プラグインが必要です。Trac Lightning で Jenkins をインストールしたので、最初から入っていました。

Jenkins の設定

ここから Jenkins の設定です。ビルドを行うための新規ジョブを作成します。

Subversion リポジトリを指定

Subversion リポジトリからソースコードをチェックアウトし、テストや診断を実行します。

MSBuild でテストプロジェクトを含むソリューションをビルド

MSBuild でソリューションをビルドします。

MSBuild の設定方法は、次の記事を参考にしてください。

MSTest を実行

ビルドに [Windowsバッチコマンドの実行] を追加し、次のコマンドを記述します。

::過去の結果があれば削除
rmdir /S /Q TestResults
mkdir TestResults

::テスト実行
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /testsettings:Local.testsettings /resultsfile:TestResults\TestResult.trx /testcontainer:"Sample.Test\bin\Debug\Sample.Test.dll"

テスト対象の DLL が増えてきたら、MSBuild 用ビルドファイルを作成した方がいいかも。

出力されたカバレッジデータを XML に変換

まず、ソリューションフォルダ直下に GenerateCoverage.build というビルドファイルを作成します。中身は下記の通り。

<Project ToolsVersion="3.5" DefaultTargets="Coverage" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <!--Jenkins ジョブのワークスペースディレクトリ-->
    <WorkspacePath>F:\Sample</WorkspacePath>

    <!--カスタムタスクのアセンブリのパス-->
    <TaskAssemblyPath>$(WorkspacePath)\CI.MSBuild.Tasks\CI.MSBuild.Tasks.dll</TaskAssemblyPath>

    <!--変換対象のファイル-->
    <CoverageFilePath>$(WorkspacePath)\TestResults\TestResult\In\$(ComputerName)\data.coverage</CoverageFilePath>

    <!--出力先-->
    <OutputDirPath>$(WorkspacePath)\TestResults\TestResult\Out</OutputDirPath>
  </PropertyGroup>

  <UsingTask TaskName="ConvertVSCoverageToXml"
             AssemblyFile="$(TaskAssemblyPath)" />

  <Target Name="Coverage">
    <Message Text="Processing code coverage results..." />
    <ConvertVSCoverageToXml CoverageFiles="$(CoverageFilePath)"
                            SymbolsDirectory="$(OutputDirPath)" />
  </Target>
</Project>

このビルドファイルで使っているカスタムタスクは、下記 URL から入手できます。

このビルドファイルを MSBuild で実行するように、Jenkins にビルド項目を追加します。

さらに Emma 形式に変換

Emma プラグインで読み込めるように、XSL 変換するビルドファイルを作成します。

<Project ToolsVersion="3.5" DefaultTargets="Convert" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <!--MSXSL のパス-->
    <MsXslPath>"C:\Program Files\MSXsl\msxsl.exe"</MsXslPath>

    <!--Jenkins ジョブのワークスペースディレクトリ-->
    <WorkspacePath>F:\Sample</WorkspacePath>

    <!--変換意使う XSL ファイルのパス-->
    <XslFilePath>$(WorkspacePath)\MSTestCoverageToEmma.xsl</XslFilePath>

    <!--カバレッジデータ(XML)のパス-->
    <CoverageFilePath>$(WorkspacePath)\TestResults\TestResult\In\$(ComputerName)\data.xml</CoverageFilePath>

    <!--Emma に変換したカバレッジデータの出力先-->
    <OutputFilePath>$(WorkspacePath)\coverage.xml</OutputFilePath>
  </PropertyGroup>

  <Target Name="Convert">
    <Exec Command="$(MsXslPath) $(CoverageFilePath) $(XslFilePath) -o $(OutputFilePath)" />
  </Target>
</Project>

上記の内容を ConvertToEmma.build という名前で、ソリューションフォルダ直下に保存。

使用している XSL ファイルは下記 URL から入手できます。

実行には MSXML と MSXSL が必要です。MSXML はすでにインストールされていたので、MSXSL をダウンロードして適当な場所にインストールします。

このビルドファイルも、MSBuild で実行するよう、Jenkins に追加します。

Jenkis でコードカバレッジを表示

まず、[Emmaカバレッジレポートの記録] にチェックを付け、先ほどのビルドファイルで出力される XML ファイルのパスを指定します。

次に、[Publish MSTest test result reposrt] にチェックを付け、MSTest で出力される拡張子 TRX のファイルを指定します。

これで完了

Jenkins のジョブを実行し、成功すれば、テスト結果とコードカバレッジが表示されるはずです。

まとめ

テストやコードカバレッジ診断の結果を Jenkins 上に表示することで、いつでもブラウザで最新のレポートが見れるようになりました。このレポートを見ればテスト漏れは一目瞭然。品質向上に役立こと間違いなしです。

あ、テストの目的が「コードカバレッジを100%にすること」にすり替わってしまわないよう、くれぐれも注意を。

.NET 開発者のための Jenkins 入門

ツール .NET

はじめに

仕事で Subversion と Trac を使っていますが、残念ながら、活用できているとは言えません。継続的インテグレーション(以下CI)？何それおいしいの？って状態。そもそも CI やるために Trac とか諸々導入したはずなんですけどね…。

CI 導入しなきゃと思い続けて結構な期間が経過しました。その間、定期的にリリースビルドを行っていたんですが、コミット忘れや修正し忘れにより、何度もビルド環境がぶっ壊される…。その度に手作業で修正してたんですが、さすがに堪忍袋の緒が切れて CI 導入を開始しました。

やりたいこと

ひとまず次ができれば OK。

  • Subversion を定期的に監視して、変更があったらビルドとテストを実行。
  • 失敗したら管理者にメールを送信する。
  • ビルドぶっ壊した人にメール送る。

CI ツールは Jenkins、ソースコード管理システムは Subversion、ビルドシステムは MSBuild を選択します。

Jenkins の導入

Jenkins と Subversion は Trac Lightning でインストール。Trac 月から Trac Lightning へのアップグレードになったので、かなり苦労しました。興味がある方は下記の記事を読んでください。

MSBuild プラグイン導入

Jenkins から MSBuild 呼び出せるようにします。MSBuild を呼び出すバッチファイルを作成して Jenkins から呼び出してもいいけど、せっかくプラグインがあるのだし、利用させてもらいましょう。MSBuild は結構使うので、毎回バッチファイル書きたくないですし。

MSBuild プラグインの入手

ビルドサーバーはネットに繋がっていないので、あらかじめ hpi ファイルを用意しておく必要があります。自分でビルドしてもいいですが、今回はネットで検索して hpi ファイル拾ってきました。

MSBuild プラグインのインストール

[Jenkins の管理] - [プラグインの管理] - [高度な設定] を開いて、[プラグインのアップロード] のフォームで hpi ファイルをアップロードします。

Jenkins を再起動したらプラグインが有効になります。

MSBuild プラグインの設定

[Jenkins の管理] - [システムの設定] から、利用する MSBuild を登録します。

これで MSBuild プラグインの導入完了。

メール設定

ビルド失敗時にメールを送信したいので、[Jenkins の管理] - [システム設定] でSMTP サーバーの指定をします。

Jenkins をインストールしたサーバーが SMTP サーバーを兼ねている場合は空欄でいいです。違う場合のみ指定します。

ジョブを作成

ようやくジョブを作成します。

新規ジョブの作成

Jenkins のメニューから [新規ジョブ作成] をクリックすると、作成ページが表示されます。
名前は一覧で見たときに何をするジョブかが分かる名前を付けます。今回は Sample プロジェクトの単体テストを行うので、UnitTestSample にしておきます。
MSBuild やバッチファイルを使うので、フリースタイル・プロジェクトを選択。

プロジェクトのオプションを設定

Workspace は結構容量を使うんですが、Jenkins をインストールしたドライブは空きが少ないので、別のドライブを使いたい。そこで、カスタム Workspace の指定します。

[カスタム Workspace の使用] にチェックを入れ、Workspace の作成先を入力。

空きが十分にあるなら、この作業は不要です。

ソースコード管理システムの設定

Subversion リポジトリを指定します。

初めてジョブを作成される場合、リポジトリにアクセスするためのユーザー名とパスワードを聞かれるので、管理者のものを入力しておきます。

ビルド・トリガの設定

1時間おきにリポジトリの変更をチェックします。

スケジュールの指定方法が独特cron と同じなので、右のはてなマークをクリックして、表示されるヘルプを読むべし。

ビルドの設定

あらかじめ登録しておいた MSBuild を選択し、ビルドしたいソリューションファイルのパスを指定します。

ビルド後に MSTest を実行したいので、[Windows バッチファイル]を追加します。

テキストエリアに MSTest を呼び出す下記のコマンドを入力。

rmdir /S /Q TestResults
mkdir TestResults
"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /testcontainer:"SampleTest.dll" /resultsfile:TestResults\TestResults.trx

上記でやっていることは、MSTest にテストプロジェクトの dll を引数として渡しているだけです。

MSTest の使い方は MSDN を参照。

ビルド後の設定

ビルドに失敗したとき、ビルドを壊した人と管理者にメールを送るよう設定します。

あ、画像のメールアドレスはダミーです。実際は社内で使うメールアドレスを入力しています。

ジョブ保存後にビルドを実行し、成功すれば CI 導入完了です。

まとめ

リポジトリからソースコードをダウンロード→ビルド→テストが完成しました。ビルドに失敗したとき、ちゃんとメールが送られてきます。これでビルドが壊されて、リリールビルド時に発狂することも少なくなりそうです。

今回はビルドとテストを行うだけでしたが、MSTest のコードカバレッジや、FxCop のコード解析の結果をレポートとして表示すると面白そうです。MSTest のコードカバレッジは Visual Studio 2010 Premium 以上が必要ですけど。

Jenkins を使えばいろいろと捗りそうです。CruiseControl.NET とかでもいいですけどね。要は、さっさと CI やればよかったってことです。

WebRole で大きなサイズのファイルをアップロードするための設定メモ

Microsoft Azure .NET

調査用に Blob ストレージを使った簡単なアプロダを作って Windows Azure にデプロイしたけど、いざ 100MB 超のファイルをアップロードしようとするとエラー。


ASP.NET ではアップロードできるファイルのサイズが制限されている(デフォルトでは 4MB)ので、下記のように、Web.config に 120MB までアップロードできるように構成していました。それなのに…。

<configuration>
    ...
    <location path="Default.aspx">
        <system.web>
            <!--POSTの最大値を120BB、実行タイムアウトを60分に設定-->
            <httpRuntime maxRequestLength="120000" executionTimeout="3600"/>
        </system.web>
    </location>
    ...
</configuration>

これだけでは不十分みたい。(´・ω・`)ｼｮﾎﾞｰﾝ


Twitter で愚痴ってたら、アドバイスもらいました。

下記のように、requestLimitsMaxAllowedContentLength も設定する必要があるのか。常識なんですかね。ASP.NET 開発経験ゼロなので知らなかったです。

<configuration>
  ...
  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true" />
      <security>
          <requestFiltering>
              <requestLimits maxAllowedContentLength="120000000"/>
          </requestFiltering>
      </security>
  </system.webServer>
  ...
</configuration>

これでアップロードできるようになりました。orz_yuki さんに感謝！

『MCTS: .NET Framework 3.5, Windows Presentation Foundation アプリケーション』に合格

.NET

土曜日に『MCTS: .NET Framework 3.5, Windows Presentation Foundation アプリケーション』を受験しました。今回が MCP 初受験。


結果は

一発で合格することができました。これで私も MCTS の仲間入りです。


この1か月ほど、高い的中率で評判のC社の問題集を使って勉強しました。でも、いざ試験を受けてみると類似問題がぜんぜん出ない。。。10問あったかなぁ？大半が初めて見る問題でした。「これは絶対正解してる」って自信を持って答えられたのは半分くらいです。


それでもなんとか合格できたのは、これまで WPF をいろいろいじっていたおかげ。WPF 未経験で問題集だけやっていたら、まず合格できなかったでしょうね。ちなみに、点数は 809 点でした。

Silverlight と HTML5 の使い分け

.NET

ネタ元→「マイクロソフトが戦略変更。HTML5が唯一のクロスプラットフォーム、SilverlightはWindows Phone 7のプラットフォームに － Publickey」
こんなニュースがあったので、今後 HTML5 と Silverlight をどう使い分けていくか、自分なりの方針を考えてみました。


まず、コンシューマ向けの Web サービスは HTML5 で開発した方がいいと思っています。多くのユーザーに使ってもらってナンボなので、それを考えると iPhone や iPad は無視できません。ぶっちゃけ、Web サービスの運営にはお金がかかるので、将来のマネタイズの可能性も考慮すると、多くの環境で動く HTML5 を選択するのが賢明です。


ただ、ニコニコ動画のプレーヤーみたいなものを HTML5 で実装するのはなかなか難しいと思うので、そういった部分で Silverlight を利用します。HTML5 を Silverlight が補うイメージです。


企業向けの Web サービスで、サーバー側が .NET なら Silverlight を選ぶかもしれません。例えば、基幹業務で使う Web サービスで、デスクトップアプリ並の操作性を求められた場合とか。今後増えそうなケースです。サーバー側も .NET なら、開発時に Visual Studio の支援をフルに受けられます。サーバー側が非 .NET の場合は、Silverlight のデバッグが非常に面倒なので非推奨。


簡単にまとめると

  • 基本的に Web サービスは HTML5 で開発
  • HTML5 では難しい部分を Silverlight で補う
  • 企業向けで、かつサーバー側が.NETなら、Silverlight メインもあり

といったところでしょうか。