NuGet CLI でパッケージをダウンロード

NuGet CLI の install コマンドで、指定した場所にパッケージをインストールできた。依存パッケージもインストールしてくれた。

nuget install Microsoft.EntityFrameworkCore -o .\NuGetPackages

packages.config を指定してもいい。ただ、この場合 packages.config に書いてあるパッケージだけしかインストールされなかった。

nuget install packages.config -o .\NuGetPackages

ローカルに NuGet のパッケージソースを構築するとき役立つ。

.NET Core で開発する環境を MacBook Pro に構築

.NET Core と ASP.NET Core が RTM になった。 RTM になったら本気出す、って言ったので行動しないといけないな。 有限実行。 まずは家の MacBook Pro で、開発環境を作り直すところから始めよう。

まずは Homebrew で OpenSSL の最新版を先にインストールしておく。

$ brew update
$ brew install openssl
$ brew link --force openssl

.NET Core の公式サイトから、Mac 用のインストーラーをダウンロードして実行。

Get Started with .NET Core

これだけで、エディタと dotnet コマンドを使って開発できるようにはなった。

ただ、Hello World に毛が生えたような超単純なアプリならともかく、ちょっと規模の大きいアプリを作るとなると、 これだけではツライ。 特に ASP.NET Core で Identity を使うとき、 認証周りの定型コードを自分で書くとか面倒この上ない。

Visual Studio でプロジェクトを新規作成するときみたいに、テンプレートからプロジェクトを生成できるようにしたい。 そこで yo の出番。

yo を動かすためには Node が必要なので、Node から順にインストールする。 あと ASP.NET Core プロジェクトを作成するためのテンプレートも。

$ brew install node
$ npm install -g yo
$ npm install -g bower
$ npm install -g generator-aspnet

これでテンプレートから、.NET Core や ASP.NET Core のプロジェクトを作成できるようになった。

試しに、Identity を使った認証付きの ASP.NET Core プロジェクトを作成してみる。

$ yo aspnet

     _-----_     ╭──────────────────────────╮
    |       |    │      Welcome to the      │
    |--(o)--|    │  marvellous ASP.NET Core │
   `---------´   │        generator!        │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

? What type of application do you want to create? Web Application
? Which UI framework would you like to use? Bootstrap (3.3.6)
? What's the name of your ASP.NET application? HelloAspNetCore

Nuget のパッケージをインストールして、SQLite のデータベースを作ってから、アプリ実行。

$ cd HelloAspNetCore
$ dotnet restore
$ dotnet ef database udpate
$ dotnet run

Safarilocalhost:5000 にアクセスすると、ASP.NET Core MVC おなじみのページが表示された。 ユーザー登録とログインもちゃんとできる。

f:id:griefworker:20160721230204p:plain

作りたいアプリのアイデアはいくつかあるので、 それが .NET Core + ASP.NET Core で実現できるか、 これから調べていこうと思う。

NetTcpBind​ing の TCPポート共有を有​効にしているとトレー​スファイルに大量の警​告とエラーが出力され​る

WCF を使っているアプリをデバッグしていて、WCFトーレス機能を ON にしていると、 クライアント側のトレースファイルに大量の警告とエラーが出力されていた。

f:id:griefworker:20130607155150p:plain

アプリは一見普通に動いていたから、今の今まで気づかなかった。なんという悪夢。

2日ほど調べたんで、分かったことをメモしておく。

  • NetTcpBinding を使っていると警告とエラーが出力される
  • NetNamedPipeBinding を使っている場合は出力されない
  • NetTcpBinding のタイムアウトや通信データ量などの設定を MAX 値にしていても出力される
  • どうも、NetTcpBinding のポート共有を有効にしていると出力される
  • ポート共有を OFF にすると出力されない
  • NetTcpBinding のポート共有を有効にしていると SMSvcHost.exe がソケットを管理するようになる
  • SMSvcHost は NetTcpBinding の構成を反映してくれない
  • 2 つのエンドポイントにそれぞれ 5 スレッドからアクセスしたあたりから出力された

SMSvcHost の同時接続数エラーあたりが怪しい。SMSvcHost.exe.config を変更するしかないかも。

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

はじめに

先日、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 の結果とコードカバレッジを表示する方法

はじめに

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 入門

はじめに

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

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

やりたいこと

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

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

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

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 で大きなサイズのファイルをアップロードするための設定メモ

調査用に 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 さんに感謝!