真・SQL Server Data Toolsのユニットテスト実行前に複数DBにデプロイする

前回の続きです。

前回のエントリに対して、@ahiru_sp さんからアドバイスいただきました。

これ、DatabaseTestService の派生クラスを作って、引数ありのDeployDatabaseProject呼ぶのが正攻法？かと思ったけど、引数になに指定すればいいのか分からんかった（

— あひるさん (@ahiru_sp) December 14, 2016

なんとなくapp.configに書かれてるのと同じ値で良い気はするのだけど

— あひるさん (@ahiru_sp) December 14, 2016

なるほど。リファレンスにあるprotected static な'DeployDatabaseProject(String, String, String, String)'のを使えばいいのではということですね。

SqlDatabaseTestService.DeployDatabaseProject Method (Microsoft.Data.Tools.Schema.Sql.UnitTesting)

SqlDatabaseTestServiceの派生クラスを作成する

ということで、そのままやってみます。

まず以下のような Microsoft.Data.Tools.Schema.Sql.UnitTesting.SqlDatabaseTestService のは派生クラスを作り、DeployDatabaseProject(String, String, String, String)を呼ぶメソッドを一つ作っておきます。

internal class CustomSqlDatabaseTestService : SqlDatabaseTestService
{
  /// <summary>
  /// DBのデプロイ
  /// </summary>
  /// <param name="projectFile">プロジェクトファイルのパス（相対パス）</param>
  /// <param name="projectConfiguration">プロジェクトファイルの構成設定</param>
  /// <param name="connectionString">接続文字列</param>
  public void DeployDatabaseProjectEx(string projectFile, string projectConfiguration, string connectionString)
  {
    SqlDatabaseTestService.DeployDatabaseProject(projectFile, projectConfiguration, "System.Data.SqlClient", connectionString);
  }
}

引数に何を渡すかは、app.configのSqlUnitTestingセクションをみれは推測はできますね。なお、第三引数はリファレンスに This must be System.Data.SqlClient. って明記されてるので埋め込んでおきます（まあどうせSQL Serverだし）。

あとは、昨日のやつと同様、InitializeAssemblyから呼んでやればOKです。例えばこんな感じ。

using System;
using System.Configuration;
using Microsoft.Data.Tools.Schema.Sql.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Xml;

namespace BletillaTestsNext
{
  [TestClass()]
  public class SqlDatabaseSetup
  {
    // ターゲットデータベース
    const string TARGET_DB_PROJECT = "..\\..\\..\\ MainDb\\MainDb.sqlproj";
    const string TARGET_DB_CONFIGURATION = "Release";
    const string TARGET_DB_CONNECTION_STRING = "＜デプロイ先のDBの接続文字列＞";
   
    // 依存データベース
    const string DEPEND_DB_PROJECT = "..\\..\\..\\SubDb\\SubDb.sqlproj";
    const string DEPEND_DB_CONFIGURATION = "Release";
    const string DEPEND_DB_CONNECTION_STRING = "＜デプロイ先のDBの接続文字列＞ ";

    [AssemblyInitialize()]
    public static void InitializeAssembly(TestContext ctx)
    {
      var testService = new CustomSqlDatabaseTestService();

      // テスト実行ターゲットをデプロイ
      testService.DeployDatabaseProjectEx(TARGET_DB_PROJECT, TARGET_DB_CONFIGURATION, TARGET_DB_CONNECTION_STRING  );
 
      // 依存DBをデプロイ
      testService.DeployDatabaseProjectEx(DEPEND_DB_PROJECT, DEPEND_DB_CONFIGURATION , DEPEND_DB_CONNECTION_STRING);

      // もともとあったこれは現在は使われてないので削除して問題ない
      //SqlDatabaseTestClass.TestService.GenerateData();
    }
  }
}

実際に試してみたら、あっさりそのまま動きました。なんだかすっきりしましたし無理やりapp.configを書き換えるとかするよりもこちらの方が断然スマートですね。

@ahiru_sp さん、ありがとうございました！

SQL Server Data Toolsのユニットテスト実行前に複数DBにデプロイする

SQL Server Data Tools (SSDT)のユニットテスト機能では、テスト実行前にソリューション内のデータベースプロジェクトをテスト実行対象のデータベースに自動でデプロイしてくれる機能があります。

これは非常に便利な機能です。しかし、複数のデータベースにまたがるような開発していると、依存関係があるなどの理由で複数のデータベースプロジェクトの内容をデプロイしたいことが出てきたりします。

SSDTの設定を調べて見ましたがそういった機能は用意されていなさそうで、一旦は諦めていました。が、別件で思案してたところでふと思いついたことを試してみた……ら、なんとか実現できなのでメモしておきます。

SSDTがユニットテスト実行前にデプロイしている仕組み

まず、SSDTがユニットテスト実行前にどうやってデプロイしているかを見てみます。

SSDTで作成されるテストプロジェクトでは、テストが実行されるとまずSqlDatabaseSetupクラスのInitializeAssemblyメソッドが呼ばれます。 このメソッドはMsTest（Microsoft.VisualStudio.QualityTools.UnitTestFrameworkアセンブリ）のAssemblyInitialize属性がついた属性です。

この中で実行されているの処理は二つ。 そのうちのSqlDatabaseTestClass.TestService.DeployDatabaseProject();がデプロイ処理であることは名前からして疑う余地はなさそうです。

この処理が実装されているMicrosoft.Data.Tools.Schema.Sql.UnitTestingアセンブリのソースは公開されていませんので具体的にどのような処理をしているのかはわかりませんが、MSDNには一応載っていました。

SqlDatabaseTestService.DeployDatabaseProject Method

この DeployDatabaseProjectメソッドは、上記のMSDNに

Deploys the database project by using the settings of the user in the app.config file.

と記載されている通り、app.confgのSqlUnitTestingセクションに記載された設定に従ってDBをデプロイします。この記載内容は、テストプロジェクト作成時や「SQL Server テスト構成」のダイアログで設定する内容です。

複数のDB・プロジェクトをデプロイする方法（強引）

追記：もっと適切だと思う方法がありましたので、ぜひそちらを参照してください kiyokura.hateblo.jp

SSDTが生成するユニットテストプロジェクトで自動デプロイが行われている仕組みをもう一度整理すると、こういうことです。

• AssemblyInitialize属性の追加メソッド内でDeployDatabaseProjectメソッドでデプロイが実施される
• DeployDatabaseProjectメソッド`はapp.configの設定に従って処理を行う

……ここまでくればピンと来たかもおられるでしょう。 そうです。

app.configを書き換えて DeployDatabaseProjectを呼ぶ

ようにすればいくらでもデプロイできそうじゃありませんか（

……ということで、例えば以下のようにapp.configを書き換えて実行してやることで、複数のデータベース／プロジェクトをすんなりデプロイすることができました。

using System;
using System.Configuration;
using Microsoft.Data.Tools.Schema.Sql.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Xml;

namespace BletillaTestsNext
{
  [TestClass()]
  public class SqlDatabaseSetup
  {
    // ターゲットデータベース
    const string TARGET_DB_PROJECT = "..\\..\\..\\ MainDb\\MainDb.sqlproj";
    const string TARGET_DB_CONNECTION_STRING = "＜デプロイ先のDBの接続文字列＞";
    
    // 依存データベース
    const string DEPEND_DB_PROJECT = "..\\..\\..\\SubDb\\SubDb.sqlproj";
    const string DEPEND_DB_CONNECTION_STRING = "＜デプロイ先のDBの接続文字列＞ ";

    [AssemblyInitialize()]
    public static void InitializeAssembly(TestContext ctx)
    {
      // テスト実行ターゲットをデプロイ
      RewriteConfig(TARGET_DB_PROJECT, TARGET_DB_CONNECTION_STRING);
      SqlDatabaseTestClass.TestService.DeployDatabaseProject();
 
      // 依存DBをデプロイ
      RewriteConfig(DEPEND_DB_PROJECT, DEPEND_DB_CONNECTION_STRING);
      SqlDatabaseTestClass.TestService.DeployDatabaseProject();
 
      // テスト実行用に元に戻しておく
      RewriteConfig(TARGET_DB_PROJECT, TARGET_DB_CONNECTION_STRING);


      SqlDatabaseTestClass.TestService.GenerateData();
    }
    
    private static void RewriteConfig(string projectFile, string connectionString)
    {
      // デプロイは特権コンテキスト（PrivilegedContext）で行われるのでそちらだけ書き換えればよい
      var xmlDoc = new XmlDocument();
      xmlDoc.Load(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
      xmlDoc.SelectSingleNode("//SqlUnitTesting/DatabaseDeployment").Attributes["DatabaseProjectFileName"].Value = projectFile;
      xmlDoc.SelectSingleNode("//SqlUnitTesting/PrivilegedContext").Attributes["ConnectionString"].Value = connectionString;
      xmlDoc.Save(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
      ConfigurationManager.RefreshSection("SqlUnitTesting");
    }
  }
}

見てのとおり、app.configを読み込んで、

• SqlUnitTesting/DatabaseDeploymentノードのDatabaseProjectFileName属性に対象のプロジェクトファイルを
• SqlUnitTesting/PrivilegedContextノードのConnectionString属性にでデプロイ先のプロジェクトファイルを

書き込んで反映、念のためリフレッシュしています。

なお、SqlUnitTestingセクションで接続文字列を宣言してる箇所としてPrivilegedContextとExecutionContextの二つがありますが、この最初のでデプロイで利用されるのはPrivilegedContextですのでそこは間違えないようにする必要があります。 またプロジェクトファイルのパスは、このテストプロジェクトのアセンブリ出力パス（bin\Debug）からの相対パスで指定しています。

そのほかこの例ではプロジェクトのパスや接続文字列を直書きしてますが、実際にはapp.configにAppSettingsセクションを追加したりして管理するといいかもしれません。

まとめ

多少強引感もありますが、割とすんなり動いてる感があります。というか標準で複数デプロイ先へのデプロイに標準で対応してくれればもっと嬉しいのですが:p

オープンソースカンファレンス2016広島でASP.NET Coreについてお話しさせていただきました

ぼやぼやしている間にずいぶんマが空いてしまったのですが、11/27（日）に開催されたオープンソースカンファレンス 2016 Hiroshimaにて、ASP.NET Core on Linuxのタイトルでお話しさせていただきました。

セッション資料はこちらです。

ASP.NET Core on Linux—きよくら ならみ

資料にも明記していますが、開発環境と実行環境という環境面（とデプロイについて）について、Linuxを実行環境としたデモを中心にしてお話しさせていただきました。 当日、実際に配置して実行した（手元のWebサーバからアクセスした）のは、クラウド上のLinux（Ubuntu）でした。

Windows上のVisual Studio Codeで開発し、そのままWindows上でUbuntu用のELF形式の実行ファイルの形でビルドしてサーバ上に転送、実行というデモもやらせていただきました。

ASP.NET Coreのプログラミンよりの部分についてはほぼ（というか全く）触れれませんでしたが、実際に触ってみようと思われた方は、ぜひ以下のオフィシャルのチュートリアルやセッション中でも紹介した書籍などを参考されるとよいのではないかと思います。

ASP.NET MVCプログラミング入門 (マイクロソフト関連書)

告知：ASP.NET Core on Macやります

今週末、 12/17（土）に開催される 合同勉強会 in 大都会岡山 -2016 Winter-にて、Macでの開発のデモをやってみる予定です。 Visual Studio Code, Visual Studio for Mac, Riderあたりでそれぞれデモをやってみようかなと思っています。

時間の都合上、デプロイ周りとか細かな説明はおそらく出来ないので、そのあたり興味あるかたは前述の資料をご覧いただくか、当日個別に捕まえて聞いていただければと思います。

DapperのQuery<dynamic>()の結果セットのフィールド名を取得する

ちょっと必要があったのでメモ。

Querydynamic()>が返すdynamicの実体はDapper.SqlMapper.DapperRowのコレクション

Query<dynamic()>()が返すdynamicの実体はDapper.SqlMapper.DapperRowのコレクションです。

このDapperRowはDapperのDapper.SqlMapperのprivateな型ですが、以下の通りIDictionary<string, object> の実装です。

github.com

ということで素直にIDictionary<string, object>にキャストしてみます。

  // SQLは実際にはSELECT * とか結果セット戻すストアドとか
  var result = cn.Query("SELECT 1 AS Id, 'Taro' AS Name , 20 AS Age"); 
  var fieldList = ((IDictionary<string, object>)result.First())
                    .Select(x => x.Key)
                    .ToList();

こんな感じで取れました。

どこでつかうん？

『どこでそんなもの使うの？』とか思う向きもかもしれないですが、クエリが返すフィールド名をハードコーディングしたくないケースって意外とあるというか、まあそんな感じで。 （例えばプログラム部分が『土管』に徹する場合（DB→JSONtとかDB→Excelとか）等だと、両端の柔軟性を生かす事ができると思います。というか、今回やりたいケースがまさにそれでした。）

Visual Studio Team Serviceで別のチームプロジェクトにリポジトリをforkして運用するメモ

Visual Studio Team Service（以下VSTS）で 別のチームプロジェクトにリポジトリをforkして運用してみよう と試行錯誤中です。とりあえず今やり始めたことをメモがてら。

実現したいこと

実現したいのはgithubでよくあるような『手元で修正してpull requestを送るためのfork』では無く。どちらかと逆で。『forkしてカスタマイズしたソースに、適宜分岐元の修正やバージョンアップを取り込む』という運用です。

有体に言うと、

• パッケージ販売するソリューションを開発していて
• 顧客後のカスタマイズが発生した場合はフォークしたプロジェクトで開発
• フォーク先は標準パッケージのバージョンアップや修正も適宜取り込む

ということをやりたい。

リポジトリの話だけではなく、VSTSその他の機能（WorkItem関連とかCI系の機能とかビルドサービスとか）もベースの開発プロジェクトとは分離さているほうが望ましいという事情もあって。で、今回はこういうのがうまくできないか試してみようとしているという次第です。

私が知る限り2016/12/06現在はVSTSにはこういった簡単にリポジトリをforkできるような機能がない（はず）です。しかし所詮リポジトリはgitですのでremoteでフォーク元を追跡すればどうにもでできるはず。少しググると、割と似たようなことをVSTS（当時はVSO）やってている記事を見つけたので、参考にさせていただきながらやってみました。

www.woodcp.com

注意：

これから紹介する内容は、実際に私が実務で「これから本格的に利用しよう」と思ってまずは実験的に作ってみた構成のメモです。 ほぼこのまま実務で利用しようとしてはいますが、まだ本格的に使っているわけではないので、気が付いていない不味いことや問題点などがあることは十分に考えられます。お気づきの点があればぜひ、教えていただけると本当にうれしいです。