この記事は、(この記事が初公開された日を基準にして) 4年前に投稿された
の記事のフォロー記事だ。Visual Studio 2012 に標準で含まれて以降、 NuGet を使ってライブラリパッケージをインストールすることが標準的になった。
しかし、 System.Data.SQLite に於いては、 NuGet パッケージの方も相変わらず多くのパッケージが公開されているので、 これらについてもどれをインストールすべきか解説してみようと思う。 
Entity Framework Core について書いたひとつ前の記事の
とは異なり、 こちらの記事は Full .NET で SQLite を使う場合で、 特に Entity Framework 6.x と組み合わせる際に有用な内容となっている。しばやん御大の Entity Framework Core についての以下の記事を読んで、
データベースは、扱いが簡単な SQLite にする。
記事の最後に、 Visual Studio 2015 ですぐに使えるサンプルプロジェクトを用意しているので、 手っ取り早く結果を見たければ、 そのサンプルプロジェクトを見てみてほしい。
まずは、何を実現させるのかをハッキリさせておこう。
ここで言う EF Tools とは、Entity Framework Core の コマンドラインツール のことだ。
このツールを使うと、 パッケージマネージャーコンソールから Add-Migration とか Update-Database と実行したり、 dotnet.exe から dotnet ef コマンドを 実行することで、 コード生成やマイグレーションなど を利用することができる。
EF Tools でデータベースを取り扱う際、その接続文字列は DbContext に設定されたものが使用される。
コード内に接続文字列を書いてしまうと、マイグレーションするためのデータベースファイルが決め打ちになってしまい、変更ができなくなる。
このため、 EF Tools を実行した際も、依存性の注入が行えるようにしたい。
document.location = document.getElementById('page1').toDataURL();Firefox で PDF 開いて任意のサイズで表示し、 開発者コンソール (F12キー) で上記のコード実行すれば、png 画像になって表示される。
あとはその画像を「名前をつけて保存」すればいい。
プロキシ環境下で、 electron-quick-start レポジトリを npm install しようとしたり、 npm で electron-prebuilt モジュールをインストールしようとすると、 npm config set https-proxy "http://proxy.example.com:8080/" とプロキシを設定しているのにもかかわらず、
Error: connect ECONNREFUSED 192.30.252.128:443
at Object.exports._errnoException (util.js:949:11)
at exports._exceptionWithHostPort (util.js:972:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1080:14)
などとエラーが出てしまうことがある。
特定の通信に、 npm のプロキシの設定が使われていないのだ。
netsh winhttp import proxy source=ie のコマンドを実行するといった解決方法が紹介されているが、 これは WinHTTP を使った通信全体に、 IE の proxy の設定をコピーするものであって、今回の問題の本質ではない。
あくまで、 npm config の https-proxy や proxy で設定したプロキシで、エラーとなっている通信を実行させたい場合の解決方法について述べよう。
結論を先に言うと、 npm config --global https-proxy ではなく、 npm config https-proxy を使って プロキシを設定する のだ。
.NET で 単体テストと言えば、いまや xUnit.net が事実上の標準となっている。
ASP.NET Core や .NET Core のドキュメントでも、単体テストは xUnit.net を使うように案内されている。
ところが Visual Studio の Express Edition 系列 の テストエクスプローラは、 xUnit.net に対応していない。
それでも Full .NET Framework や dnx では、そのままテストプロジェクトを「実行」してしまえば、とりあえずデバッグ実行はできていた。
しかし、 .NET Core + dotnet-test-xunit では、それすらもできなくなってしまい、 dotnet test コマンドの出力を確認するしかなくなってしまった。
デバッグ実行ができないのは流石に不便… ということで、デバッグ実行を行うハックを紹介しよう。
# ライセンス的に Visual Studio Community 使えるのなら、そちらを使うべき。
# ただ、たとえ Express ではなくても、 この方法を使うと xUnit.net の出力が文字化けする問題も防げるぞ。
だいぶ予定が遅れたようだが、 .NET Core 1.0 の RC2 が5月中旬にリリースされた。
2000年に初めて .NET がリリースされてから、 mono が登場したりといったことはあったものの、 16年越しでついに クロスプラットフォームのアプリケーションを作成できる環境が、マイクロソフト公式から提供された。
ということで、さっそく .NET から VS2015 DotNetCore Tools Preview 1 をインストールして、 Hello World を書いてみよう。
using System;
using System.Text;
namespace netcore_console_test_01 {
public class Program {
public static void Main(string[] args) {
Console.WriteLine("はろー わ～るど！");
}
}
}
…文字化けするぞ!!?
Visual Studio Code 1.1.1 がリリースされた。
先日の 「Visual Studio Code が ついに 1.0 に!! しかし、とんでもローカライズでおかしなことに」 の記事で紹介した不具合が修正されたり、 日本語フォントがだいぶマシになったり、 Markdown のプレビューを横に表示させるコマンドが増えたり、いろいろな変更点が入っている。
その中でも特に私が気に入った変更点は、ユーザ設定で以下のようにウィンドウ幅での折り返し設定にしたときなどが特にわかりやすいのだが、
{
+ "editor.wrappingColumn": 0,
}中日韓の文字が スペースで区切られた部分以外でも、ちゃんと折り返すようになったこと。
文字の幅によっては、少し隙間が空いてしまうことがあるが、それでもかなり見やすくなった。
おかげで、テキストエディタとしてだいぶ優秀になった。
Visual Studio Code 1.0.0
Visual Studio Code 1.1.1
atom エディタなどはこれができなくて、 ところどころ半角スペースの混じった日本語を書いた時の表示が微妙なのよね。
さて、このように複数のバージョンが公開されていくと、古いバージョンを取得したり、その古いバージョンをインストールせずに使用したりしたくなる。
Visual Studio Code は GitHub にて オープンソース で公開されているので、そこから自分でビルドすることもできるが、それはめんどくさい。
過去バージョンについては公式では案内されていないものの、 Win32用 zip アーカイブ版 (いわゆる Portable版 のようなもの) を取得する方法があるようなので、それを紹介しよう。
Visual Studio Code が、ついに 1.0 になった。
Visual Studio Code は、 Microsoft が提供する クロスプラットフォームでオープンソース な IDE 環境だ。
昨年の Build 2015 で電撃発表されたあと、プレビュー版とベータ版が毎月リリースされてきた。
今回の 1.0 では、 一旦カーソル設置後 に Shift+Alt+終了箇所クリック することで 矩形選択 (Column Selection) ができるようになったり、インテリセンスの操作が改善されたりと、エディターとしてもなかなか洗練されてきた。
そして正式版となったのにあわせて、 Microsoft らしく 主要な言語へのローカライズが実施された。
しかし、そのローカライズのせいで、ものすごく操作がしにくくなっている…
| メモ: | この ローカライズの不具合は、 1.1 で無事修正されている。 記事の内容は言語設定を変更する方法として有用なので、記事自体は残しておく。 |
私が使用しているいくつかの node.js 環境 (すべて Windows) の中で、 ほぼ同じ構成の npm パッケージにしているはずであるにもかかわらず、 yo コマンドを実行してからインターフェースが表示されるまでの時間に、大きく開きがあった。 その差、 ほぼ瞬時～数十秒。
正直、 yo コマンド実行する度に数十秒待たされるのは非常にストレスがたまる。
何が問題なのか調べてみた。
デバッガを使って、どの部分の実行に時間がかかっているのか調べてみたところ、 fullname モジュール でユーザ名を取得している部分に時間がかかっていることがわかった。
しかもこのユーザ取得部分、 yo コマンド の引数に ジェネレータ 指定して ユーザ名を表示しないようにしても、 ユーザ名取得は必ず実行されるらしい。
では、この fullname モジュール、いったいどうやってユーザ名を取得しているのだろうか…？
この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。
バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと（主に私）が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。