MVC 3 から、標準で導入されたらしい。
Microsoft：ASP.NET Core の Razor 構文リファレンス

インライン式。
「コードナゲット」とも呼ばれるみたい。

複数行に渡る場合以外は、閉じる必要がない。

全て使える。

Razor の根幹となる @ を文字列として表記したい場合は
例によって @@ と、重ねて記述する。

複数行に渡る処理を書きたい場合は、@{} で記述する。

コードブロック内に出力内容を記述することも可能。

if などの構文を記述する際は、コードブロック拡張版を利用する。

if などの構文を記述する際は、コードブロック拡張版を利用する。

javascript へ値を渡すときは
‘（シングルクォーテーション）
“（ダブルクォーテーション）
いずれかで囲む必要があるらしい。

vaguely：【ASP.NET Core】Razorで遊んでみる（2018-11-08）

フォームの「OK」「キャンセル」ボタンのお話。

フォーム表に配置したボタンに「OK」「キャンセル」の挙動を持たせる。
＝Enter 押下で反応する「OK」ボタン、ECS 押下で反応する「キャンセル」ボタン。

フォームのプロパティ
AcceptButton：「OK」の挙動をするボタンの Name を設定
CancelButton：「キャンセル」の挙動をするボタンの Name を設定

下記のように手書きして、Form の Key_Down イベントへ登録する手もある。

private void Login_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyCode == Keys.Enter)
    {
    }
    else if (e.KeyCode == Keys.Cancel)
    {
    }
}

値の受け渡し

アプリケーション内の設定のこと。
preference の方が区別が付くかも？

この話、どこかの記事に書いた気がするんだけど
見つけられないので、改めて記述。

プロジェクトのコンテキストメニュー [プロパティ] 左ペイン [設定]

こちらの画面で、1つずつ下記を設定していく。
名前：設定値の名称。任意。プログラム内で使用するので、アルファベットで設定してね
種類：設定値のデータ型
スコープ：
アプリケーション：全ユーザー統一
ユーザー：ユーザー毎
値：値

// 取得
txtUsername.Text = Properties.Settings.Default.LoginUsername;
Properties.Settings.Default.Save();

// 設定
Properties.Settings.Default.LoginUsername = "username";

ユーザー設定は、ユーザーの非表示のローカル アプリケーション データ フォルダーのサブフォルダー内のファイルに保存されます。

MSDN：方法 : 実行時にユーザー設定を C# で書き込む

というわけで、SQLite -> 導入 にも書いた通り

にあるみたいだけど、上記記事は UWP の場合なわけで
フォームアプリケーションの場合は、パッケージ ID をどこで見ればいいのかしらね～。

データを一覧表示するコントロール。

MSDN：DataGridView コントロール (Windows フォーム)
MSDN：DataGridView クラス

データを一覧表示するコントロール。

MSDN：DataGridView クラス
一覧はこちらにあるので、逆引きで！

MSDN：AlternatingRowsDefaultCellStyle

RowHeadersVisible

@IT：DateTimePickerコントロールでDBNullを扱うには？［C#、VB］（2008-01-31）

MSDN：DateTimePicker コントロール (Windows フォーム)
MSDN：DateTimePicker クラス

DateTimePicker を使いたい。
だけど、null のときに日付が入ってしまうと
空欄にしておきたいユーザが、誤入力をしてしまう。
むぅ。

Google 先生に聞いてみると、色々とあるみたいだけど
ほとんどの情報が古い。。。

何で改善されないんだろう。
どこかにも書いてあったけど、DateTime 型を利用するのに
null は普通に使うと思うんだけどな～。

私の設計が悪いのかしらね。

それでも、DateTimePicker が null を許容できないことは
当時？みなさんが試行錯誤されたようで、下記のような記事を見つけた。
codeguru：Yet Another Nullable DateTimePicker Control（2005-04-25）
CodeZine：Nullを許容するDateTimePickerコントロール（2005-05-13、日本語訳記事）

現時点では、よい方針を思いつかないので
DbDateTimePicker を使ってみた。

@IT：DateTimePickerコントロールでDBNullを扱うには？［C#、VB］（2008-01-31）
おおお、奇しくも後1週間で10周年ｗ

カスタム コントロールを追加 して
自動生成ソースに、参考サイトのソースを、ちみっと調整してコピペ。

public partial class DbDateTimePicker : DateTimePicker
{
    public DbDateTimePicker()
    {
        InitializeComponent();
    }

    protected override void OnPaint(PaintEventArgs pe)
    {
        base.OnPaint(pe);
    }

    [Bindable(true), Browsable(false)]
    public new object Value
    {
        get
        {
            if (base.Checked)
                return base.Value;
            else
                return DBNull.Value;
        }
        set
        {
            try
            {
                if (Convert.IsDBNull(value))
                {
                    base.Checked = false;
                }
                else
                {
                    base.Value = Convert.ToDateTime(value);
                    base.Checked = true;
                }
            }
            catch (Exception ex)
            {
                base.Value = Convert.ToDateTime(value);
                base.Checked = true;
            }
        }
    }
}

アプリ側にコントロールを追加 して
フォーム上へ配置。
dbdtpDate

コントロールのプロパティから
ShowCheckBox を True

お試し で大分理解できたので
実際に挑戦！

お試し との変更点は
メインをフォームアプリにしたこと。

フォームアプリプロジェクトへ、NuGet パッケージ管理から、下記をインストール。

• SQLitePCLRaw.bundle_e_sqlite3
• SQLitePCLRaw.bundle_sqlcipher
• SQLitePCLRaw.bundle_green

上記3つのプロジェクトについて、何をするかによって
スタートアッププロジェクトを切り替えないければならない。

• フォームプロジェクト
• フォームアプリを動かすときは、これがスタートアッププロジェクト
• ビジネスロジックプロジェクト
• マイグレーションをするときは、これがスタートアッププロジェクト
• ビジネスロジックテストプロジェクト
• テストをするときは、これがスタートアッププロジェクト

Add-Migration Initial
More than one DbContext was found. Specify which one to use. Use the '-Context' parameter for PowerShell commands and the '--context' parameter for dotnet commands.

DbContext クラスが複数あったため。

対象 DbContext クラスを指定してコマンド実行。

Add-Migration Initial -Context MyAppSystem.EmployeeModel
To undo this action, use Remove-Migration.
Update-Database -Context MyAppSystem.EmployeeModel
Applying migration '20180121111141_Initial'.
Done.

Add-Migration Initial -Context MyAppSystem.EmployeeModel
Could not load assembly 'MyApp'. Ensure it is referenced by the startup project 'MyAppSystem'.

パッケージ マネージャー コンソール上部にある
「既定のプロジェクト」が、MyApp になっていた。

「既定のプロジェクト」を、MyAppSystem に変更。

今回は、フォームロード時に走らせる処理として Main_Load メソッドとした。
Main の部分は、フォームクラス名を入れるのが通例らしい。

フォームプロパティのイベント一覧（雷マーク）において
Load => Main_Load
と設定するだけ。

Entity の中から、特定のプロパティを取得する＝表示カラムを絞る。
このことを「射影」というらしい。

var arrayEmployees = db.Employees
    .Select(record => new {
        record.EmployeeCode,
        Name = record.FamilyName + " " + record.FirstName
    })
    .ToArray();

• record へ新しい配列をセットするよ～
• 配列のプロパティは、record.EmployeeCode と Name だよ～
• record.EmployeeCode はそのままでいいけど、Name は、record の FamilyName と FirstName を半角スペースで連結して戻してね～

という風に、計算や加工も含めて自由に取得できる。

この部分の表記方法を勉強中。

LINQ の考え方としては「配列の要素」を指していると思う。

foreach (var value in array) の value に当たる感じ？

今回は、DB から抽出したレコード群が要素なので
record としてみたけど、何でもよさそう。

データの個数。

db.Employees.Count()

上記例に合わせると、こうなる。

dgvEmployees.Columns[nameof(Employee.EmployeeCode)].HeaderText = "従業員コード";
dgvEmployees.Columns[nameof(Name)].HeaderText = "氏名";

ここで面白いのが
Employee.EmployeeCode を EmployeeCode とするとエラー。
record.EmployeeCode としてもエラー。
Name は、何も付けなくてもエラーにならないどころか、想定通りに動く。

まだまだ意味がわかっていない。

Qiita：Entity Framework6で単純なデータ表示フォームを作成（2015-09-08）
→DataGridView へのデータの登録の仕方。DataGridView のカラム名の変更の仕方

Keibalight プログラミングを淡々と：【LINQ】要素の個数を取得するには（Count集計演算子）（2011-07-19）
→LINQ による、データ個数の数え方

Visual Studio に GitFlow を導入するための機能拡張。

マーケットプレイス：GitFlow for Visual Studio 2017

上記ページから、.vsix ファイルを DL して開けば、
インストール作業が始まる。

その前に VS を閉じておくとスムーズ。

インストール後、チーム エクスプローラーのメニューに
「GitFlow」が追加される。

「GitFlow」へ移動して [Initialize] [OK]

「GitFlow」へ移動
[Start Feature] [Start Release] [Start Hotfix] [Other]

[Start Feature] Feature 名を入力
[Create Feature] [Finish Feature] [Finish Release] [Finish Hotfix]

今ひとつピンとこないので
勉強のため、テストプロジェクトを作成。

EntityFramework なるものを見つけて
ぜひ挑戦したいと思った。

ただ、慣れない VS 環境であることもあり
なかなかピンとこない。

そこで、参考サイトをそのまま実践してみることにした。

SlideShare：「Entity Framework Coreを使ってみる」 公開用（2017-03-07）

[ファイル]-[新規作成]-[プロジェクト] 「新しいプロジェクト」
左ペイン [インストール済み]-[Visual C#]-[Windows クラシック デスクトップ] 右ペイン [クラス ライブラリ（.NET Framework）] 名前：KptBoardSystem
場所：任意
ソリューション名：「名前」から自動入力
[ソリューションのディレクトリを作成] にチェック
[新しい Git リポジトリの作成] にチェックなし
[OK]

プロジェクトコンテキストメニューから [NuGet パッケージの管理] Microsoft.EntityframeworkCore で検索
Microsoft.EntityframeworkCore.Sqlite 2.0.1
Microsoft.EntityframeworkCore.Tools 2.0.1

ソリューションのコンテキストメニューから [追加]-[新しいプロジェクト] 後は前述同様に KptBoardSystemTest プロジェクトを作成。

前述同様に、下記を設定。
Microsoft.EntityframeworkCore 2.0.1
xunit 2.3.1
xunit.runner.visualstudio 2.3.1
Moq 4.8.1

P.12 User
P.13 KptBoardModel

Enable-Migrations
Enable-Migrations is obsolete. Use Add-Migration to start using Migrations.
Add-Migration setp00
To undo this action, use Remove-Migration.

1. マイグレーションを可能にする
2. マイグレーションを追加する

こんな感じで2ファイルが自動生成された。

KptBoardSystem
┗ Migrations
　　┣ 20180120074120_setp00.cs
　　┗ KptBoardModelModelSnapshot.cs

Update-Database
Applying migration '20180120074120_setp00'.
Done.

参考サイト P.15 のように処理がズラズラ並ぶのではなく
とても簡素なリアクションでしたｗ

参考サイトには「ソリューション直下に「kpt.db」が作成される」とあったけど
実際には、ソリューションの２つ上に作成された。

後述の試行錯誤に見られた、テストとの階層の差分があるということは
コマンドを打つ際に、階層を設定するべきなのではないかと思うけど
現在は手法不明。

そこで、

のパスを下記のように変更したところ、ソリューション直下に作成された。

- var connectionString = new SqliteConnectionStringBuilder { DataSource = "../../../kpt.db" }.ToString();
+ var connectionString = new SqliteConnectionStringBuilder { DataSource = "../kpt.db" }.ToString();

この件には、大きな落とし穴が。。。
詳細は、後述の「試行錯誤」コーナーにて。

コマンドを打つ際に、パッケージ マネージャー コンソールにおいて
「既定のプロジェクト」で何を選択しているかでファイル出力場所が変わる。

“kpt.db” というパスの場合は
プロジェクト直下へ生成されるので
KptBoardSystem を選択していれば、

KptBoardSystemTest を選択していれば、

となる。

この場合、テストではファイルが見つからないエラーになってしまうので
「既定のプロジェクト」は注意。

後述の如く、コマンドと実行でファイルパスの意味合いが変わるので
コマンドで生成された DB ファイルを手動で配置換えをした。

テストと本番で DB を分けることも考え
ソリューション直下ではなく、プロジェクト直下としてみる。

つまり、最終的な配置とファイルパスの指定は下記の通り。

var connectionString = new SqliteConnectionStringBuilder { DataSource = "../../kpt.db" }.ToString();

このようなやり方にすることで
コマンドを打つ度に
ファイルの移動が必要。

P.18
KptBoardSystemTest プロジェクト内「参照」のコンテキストメニュー [参照の追加] 「参照マネージャー」
左ペイン [プロジェクト]-[ソリューション] 中央ペイン [KptBoardSystem] にチェック
[OK]

P.19 KptBoardModelTest

using Xunit;

namespace KptBoardSystem.Test
{
    public class KptBoardModelTest
    {
        [Fact]
        public void TestInsertUser()
        {
            using (var db = new KptBoardModel())
            {
                var user = new User
                {
                    Name = "User01"
                };
                db.Add(user);

                db.SaveChanges();
            }
        }
    }
}

[テスト]-[ウィンドウ]-[テスト エクスプローラー] で、開くことができる。

[テスト]-[実行]-[全てのテスト] または、テスト エクスプローラーにて、対象テストを選択した上で
[テスト]-[実行]-[選択したテスト] で、テストを開始。

私の記述ミスのせいで、

var kptBoard = db.KptBoards.Where(b => b.Problem.Contains("続ける")).First();

こちらが空になってしまった。

その際、下記のエラーが出た。

[テスト]-[デバッグ] から、テストのデバッグをできる。

まだ使い方はよくわからない。

P.34 では、u が括弧書きだったのに
今回は括弧がつかない理由がわからない。

var user02 = db.Users.Where((u) => u.Name == "User02").Include("KptBoards").First();

var kptBoard = db.KptBoards.Where(b => b.Problem.Contains("続ける")).First();

LINQ を勉強すべし。

テスト初回実行時、下記のエラーが出た。

Google 先生に質問したところ、どうやら下記パッケージが不足していることらしい。

• SQLitePCLRaw.bundle_e_sqlite3
• SQLitePCLRaw.bundle_sqlcipher
• SQLitePCLRaw.bundle_green

テストプロジェクトへインストール。

Install-Package SQLitePCLRaw.bundle_e_sqlite3 -Version 1.1.9
Install-Package SQLitePCLRaw.bundle_sqlcipher -Version 1.1.9
Install-Package SQLitePCL.bundle_green -Version 0.9.3

NuGet パッケージ管理からインストールしても OK だと思う。

stackoverflow：Cannot run SQLite.net PCL in ASP.NET MVC（2017-02-09）

上記エラーが取れてホッとしつつテストを行うと
次は下記エラーが出た。

Users テーブルが見つからないってさ。。。

kpt.db の中には、確かに Users テーブルがある。

上で、DB ファイルへのパスを変えたからかもしれないと思い
パスを戻すと、エラーが出ないときもあるけど、確実ではないし
値は書き込まれない。

そもそも DB 接続に失敗しているのかと思って
ファイルパスを存在しないパスにしてみたら
エラー内容が下記の通り変わったので、接続には成功しているみたい。

途方に暮れて、ソリューションディレクトリをあちこち見ていたら
想定外の場所に kpt.db ファイルが！！！

コマンドで作成した kpt.db のファイルパスと
テストコードが参照する kpt.db のファイルパスが
異なることが原因だった。

と言っても、何かがおかしいので
いずれわかる日が来ると信じたい。

ともかく、下記のような検証結果だった。

GrandMother
┣ Mother
┃　┣ KptBoardSystem
┃　┃　┣ KptBoardSystem
┃　┃　┣ KptBoardSystemTest
┃　┃　┃　┣ bin
┃　┃　┃　┃　┣ Debug
┃　┃　┃　┃　┃　┗ kpt.db // テスト "kpt.db"
┃　┃　┃　┃　┣ Release
┃　┃　┃　┃　┗ kpt.db // テスト "../kpt.db"
┃　┃　┃　┗ kpt.db // コマンド "kpt.db"、テスト "../../kpt.db"
┃　┃　┗ kpt.db // コマンド "../kpt.db"、テスト "../../../kpt.db"
┃　┗ kpt.db // コマンド "../../kpt.db"
┗ kpt.db // コマンド "../../../kpt.db"

つまり
コマンドは、プロジェクトディレクトリがルート。
テスト（実行）は、アセンブリ（.dll）本体のある場所がルート？