「Programming」カテゴリーアーカイブ

DI っぽく EF Core 1.0 + SQLite を Full .NET と .NET Core のコンソールアプリケーションで使ってみる [Entity Framework Core]

投稿日時:
更新日時:
3

しばやん御大の Entity Framework Core についての以下の記事を読んで、

しばやん雑記
Entity Framework Core 1.0 を Full .NET のコンソールアプリケーションで使ってみ...
http://blog.shibayan.jp/entry/20160613/1465788134
Entity Framework 6 と比較するために Entity Framework Core 1.0 をコンソールアプリケーションで動かしたので、ざっくりと手順を残しておきます。コンソールアプリケーションに限らず、ASP.NET 4.6 でも同じ手順になると思います。NuGet で見た EF Core 1.0 の依存関係には .NET Framework 4.5.1 と記載されているので、このバージョン以上であれば動作するはずです。実際に .NET 4.6.1 で試しています。とりあえず使うためには NuGet から Entity Framework Core をインストールする必要があ…

コンソールアプリでも、 ソースコードに 接続文字列 や ログの設定を書かずに、設定ファイルから Dependency Injection (依存性の注入: 以下DI) するにはどうしたらよいのかな？ と思ったので、 ASP.NET Core の流儀を参考にしながら やってみようと思う。

データベースは、扱いが簡単な SQLite にする。

記事の最後に、 Visual Studio 2015 ですぐに使えるサンプルプロジェクトを用意しているので、 手っ取り早く結果を見たければ、 そのサンプルプロジェクトを見てみてほしい。

実現すること

まずは、何を実現させるのかをハッキリさせておこう。

  1. 接続文字列と ログ表示の設定を、外のファイルから指定すること
  2. マイグレーションなどを行うため、 EF Tools からも、上記設定が利用されるようにすること

ここで言う EF Tools とは、Entity Framework Core の コマンドラインツール のことだ。
このツールを使うと、 パッケージマネージャーコンソールから Add-Migration とか Update-Database と実行したり、 dotnet.exe から dotnet ef コマンドを 実行することで、 コード生成やマイグレーションなど を利用することができる。

EF Tools でデータベースを取り扱う際、その接続文字列は DbContext に設定されたものが使用される。
コード内に接続文字列を書いてしまうと、マイグレーションするためのデータベースファイルが決め打ちになってしまい、変更ができなくなる。
このため、 EF Tools を実行した際も、依存性の注入が行えるようにしたい。

前準備

続きを読む →

PDF のページを好きなサイズの png 画像に変換する たった1つのステップ

投稿日時:
更新日時:
返信 
document.location = document.getElementById('page1').toDataURL();

Firefox で PDF 開いて任意のサイズで表示し、 開発者コンソール (F12キー) で上記のコード実行すれば、png 画像になって表示される。
あとはその画像を「名前をつけて保存」すればいい。

続きを読む →

npm config -g でプロキシの設定をしているのに electron-quick-start や electron-prebuilt でコケる

投稿日時:
更新日時:
4

プロキシ環境下で、 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 のプロキシの設定が使われていないのだ。

Qiita
Windowsのnpm installで串を刺してもコケる場合 - Qiita
http://qiita.com/yupika/items/3662166f7872e4011957
Electron-prebuiltのnpmインストールの際にECONNREFUSEDというエラーが出ました。この解決はProxyであることはわかったのですが、npm set proxy "p…
などでは、 netsh winhttp import proxy source=ie のコマンドを実行するといった解決方法が紹介されているが、 これは WinHTTP を使った通信全体に、 IE の proxy の設定をコピーするものであって、今回の問題の本質ではない。

あくまで、 npm config の https-proxy や proxy で設定したプロキシで、エラーとなっている通信を実行させたい場合の解決方法について述べよう。

解決方法

結論を先に言うと、 npm config --global https-proxy ではなく、 npm config https-proxy を使って プロキシを設定する のだ。

続きを読む →

VS Express で .NET Core の xUnit.net を使ったテストのデバッグを行う

投稿日時:
返信

.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 での コンソールアプリの文字化けを直す

投稿日時:
更新日時:
返信

だいぶ予定が遅れたようだが、 .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("はろー わ～るど！");
        }
    }
}

160530_1

…文字化けするぞ!!?

続きを読む →

Visual Studio Code 1.1.1 と その zip 版 (Portable 版)

投稿日時:
更新日時:
1

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.0.0

Visual Studio Code 1.1.1

Visual Studio Code 1.1.1

atom エディタなどはこれができなくて、 ところどころ半角スペースの混じった日本語を書いた時の表示が微妙なのよね。

さて、このように複数のバージョンが公開されていくと、古いバージョンを取得したり、その古いバージョンをインストールせずに使用したりしたくなる。
Visual Studio Code は GitHub にて オープンソース で公開されているので、そこから自分でビルドすることもできるが、それはめんどくさい。

過去バージョンについては公式では案内されていないものの、 Win32用 zip アーカイブ版 (いわゆる Portable版 のようなもの) を取得する方法があるようなので、それを紹介しよう。

続きを読む →

Visual Studio Code が ついに 1.0 に!! しかし、とんでもローカライズでおかしなことに

投稿日時:
更新日時:
返信

Visual Studio Code が、ついに 1.0 になった。

Visual Studio Code は、 Microsoft が提供する クロスプラットフォームでオープンソース な IDE 環境だ。
昨年の Build 2015 で電撃発表されたあと、プレビュー版とベータ版が毎月リリースされてきた。

今回の 1.0 では、 一旦カーソル設置後 に Shift+Alt+終了箇所クリック することで 矩形選択 (Column Selection) ができるようになったり、インテリセンスの操作が改善されたりと、エディターとしてもなかなか洗練されてきた。

そして正式版となったのにあわせて、 Microsoft らしく 主要な言語へのローカライズが実施された。

しかし、そのローカライズのせいで、ものすごく操作がしにくくなっている…

メモ: この ローカライズの不具合は、 1.1 で無事修正されている。 記事の内容は言語設定を変更する方法として有用なので、記事自体は残しておく。

続きを読む →

Yeoman の yo コマンドの開始が遅いyo!

投稿日時:
返信

私が使用しているいくつかの node.js 環境 (すべて Windows) の中で、 ほぼ同じ構成の npm パッケージにしているはずであるにもかかわらず、 yo コマンドを実行してからインターフェースが表示されるまでの時間に、大きく開きがあった。 その差、 ほぼ瞬時～数十秒。
正直、 yo コマンド実行する度に数十秒待たされるのは非常にストレスがたまる。

何が問題なのか調べてみた。

遅い原因は ユーザ名取得部分

デバッガを使って、どの部分の実行に時間がかかっているのか調べてみたところ、 fullname モジュール でユーザ名を取得している部分に時間がかかっていることがわかった。

しかもこのユーザ取得部分、 yo コマンド の引数に ジェネレータ 指定して ユーザ名を表示しないようにしても、 ユーザ名取得は必ず実行されるらしい。

では、この fullname モジュール、いったいどうやってユーザ名を取得しているのだろうか…？

ユーザ名取得の方法

続きを読む →

PowerShell の組織の中で使えそうで使えないニッチな Tips

投稿日時:
返信

この記事は、 PowerShell Advent Calendar 2015 の 18日目 の記事だ。
私はこれまでずっとネットヒッキーだったので、ネット上でほかの人とのかかわりを持ったことがほとんどなかったが、今回意を決して参加させてもらうことになった。

バリバリの 情シス や プログラマ ではなくても、日常のちょっとした業務で PowerShell を使っている人もいるだろう。
そういったひとびと（主に私）が、組織の中で使えそうだと思ったニッチな話題を書こうと思う。

  • PowerShell Tools for Visual Studio を商用利用する環境は、無料でできる
  • コンソールウィンドウを極力表示せずにスクリプトを実行
  • ネットワーク共有上の DLL を読み込む

続きを読む →

TypeScript の async/await を Electron で使ってみる

投稿日時:
更新日時:
返信

TypeScript とは、 いわゆる altJS のひとつで、 ECMAScript (JavaScript) に静的型付けを加えたスーパーセットとなるプログラミング言語だ。
この TypeScript には、 ES6 (ECMAScript 6, Harmony) 相当のコードから ES5, ES3 にコンパイル (トランスパイル) する機能のほか、 ES7 で予定されている一部の機能を先取りし ES6 にコンパイルして使用することもできる。

そんな時代を先取りした機能の一つが "async/await" だ。

"async/await" とは 2012年に C# 5.0 とともに登場した記述方法で、 これを使うと、 非同期な処理を コールバック地獄にならず、 あたかも同期的な処理のように書くことができる。
同様の記述が、最近 Python 3.5 でもサポートされ、これからの非同期処理のスタンダードとなるだろう。

しかし、 TypeScript で async/await を使うには コンパイル後の ECMAScript の実行環境が ES6 をサポートしていなくてはならない。
現行のブラウザのシェアを考えると、 ES6 をサポートしないブラウザ (主に IE, Safari だが) を切り捨てる選択肢はちょっと厳しい。

一方でサーバサイド JavaScript として有名な node.js では、最近になって組織の変更のおかげで開発が活発化し、 ES6 のサポートが入ってきている。
しかし、 node.js はサーバサイドの技術。 クライアントアプリで使えた方がいろいろな用途で使えて夢が広がる気がする。

そこで Electron ですよ。

Electron (旧 Atom-Shell) とは、 Chromium の HTML5 と node.js の技術を使って、クロスプラットフォームのデスクトップアプリを作れるアプリケーションエンジンだ。

JavaScript エンジンごと中に内包しているため、 OS や インストールされたブラウザのバージョンを一切気にせずに HTML5 アプリケーションが作れるという、 IE に苦しめられている諸兄には夢のような技術 (?) だ。
Slack のデスクトップクライアントや、Visual Studio Code なんかも、 Electron を使って作られている。

そしてこの Electron は node.js の技術を使っていると述べたとおり、 ES6 がつかえるではないか！

…ということで、 Electron + TypeScript で async/await を使ってみようと思う。

続きを読む →