この記事は Vue.js #3 Advent Calendar 2018 の17日目の記事です。 昨今のフロントエンド界隈では、なんでもSPAのアーキテクチャを前提として語られる雰囲気を感じますが、Non-SPAなサーバーサイドのMVCフレームワーク（LaravelやRails、ASP.NET Coreなど）をメインに使いつつ、Vue.js などのJavaScriptライブラリを使って画面に味付けをしたいというニーズも相変わらず存在します。また、あえてそう設計すべきアプリケーションも多くあるでしょう。 ここで、 Vue.jsの公式サイト(日本語版) の冒頭に書かれている文章を紹介します。 …Vue は少しずつ適用していけるように設計されています。中核となるライブラリは view 層だけに焦点を当てています。そのため、使い始めるのも、他のライブラリや既存のプロジェクトに統合するのも、とても簡

最近の仕事で （個人的にやや敬遠がちだった）EFを使ってAzureのSQL Databeseに接続するのに 「接続のリトライは実装してね」とお願いしてたら、大掛かりな実装をされた事件があり「おいおーい」と感じたので、メモっておきます。 前提として、現在の開発は Visual Studio 2013 update4 .Net Framework4.5 Entity Framework6.1.2 そしてC#って感じでやってます。 Overview MSDNとかみてると、MS用語的には、Connection の Resiliency とか RetryのLogicと言うようですね。 実装方法は、以下です。非常にシンプル。 DbConfigurationクラスの派生クラスを作って、リトライの設定を持たせる（≒属性を作成する）。 対象のDbContextの派生クラスに、属性をつける。 Implimen

Entity Framework 6 の頃はデフォルトで有効化されていたので、特に意識することなく使われていたであろう Lazy Loading ですが、Entity Framework Core では 2.1 から拡張という形で実装がされました。 デフォルトでは有効化されないので、Entity Framework 6 からの移行時にはまることが多そうと思ったので、簡単に試しておきました。 とりあえず単純な .NET Core コンソールアプリを作成しました。EF Core 2.1 を使っています。Generic Host を使った方が DI とか Logging が楽だと思いますが、コードが複雑になるので止めました。 class Program { static async Task Main(string[] args) { var context = new AppDbContext

ASP.NET MVC 5 から Core MVC 2.1 への移行作業を行っていますが、地味に Identity 周りの移行ではまった部分が多かったのでメモとして残します。作業としては DB のマイグレーションがメインです。 移行に関してはドキュメントがありますが、正直これは役に立たないですね。 喜ばしいことに ASP.NET Core Identity になってもパスワードのハッシュ化形式は変更されていないので、ASP.NET Identity のデータをそのままでログインすることは出来ます。 しかし、テーブルのスキーマが変更されているので、マイグレーションを行う必要があります。パッと調べた感じではマイグレーションの方法は公式に用意されていないみたいなので、手動で対応しないといけません。 Identity 設定を移行する とりあえず ASP.NET Identity と ASP.NET

ASP.NET Core 2.0 から導入された必要なパッケージを一通り参照するメタパッケージですが、あまりにも参照が多いので何となく嫌な感じがする人はいると思いますが、絶対に使うべきなので理由を書いておきます。 メタパッケージに関しては公式ドキュメントにあるので、基本的な方針に関しては参照してください。 共有フレームワークとしてメタパッケージはインストールされる点が非常に大きい特徴です。 このドキュメントにはちゃんとメタパッケージを使うべき理由が書いてあります。 Applications that use the Microsoft.AspNetCore.App metapackage automatically take advantage of the ASP.NET Core shared framework. When you use the Microsoft.AspNetCo

ASP.NET Core 1.0 時代に書いた気もしますが、最近は ASP.NET MVC 5 から ASP.NET Core MVC 2.1 への移行を行っていて、いい感じに MVC 5 と Core MVC 2.1 で共存させないといけない部分があり、DI 周りではまったので調べました。 まあ、タイトルの通り ASP.NET Core のデフォルト DI はコンストラクタがオーバーロードを持つ場合にはエラーになります。これはドキュメントにも記載されている挙動です。 Constructor injection requires that only one applicable constructor exist. Constructor overloads are supported, but only one overload can exist whose arguments can

-- この記事は2016/10/28(Fri)現在の情報に基づいています -- この記事をざっくり言うと 前回の記事の補足的内容で、 tkiryu.hatenablog.com ASP.NET MVC プロジェクトに npm 入れたのはいいけど、もともと Nuget もあるしどう使い分けよう、と悩んだときに npm ではフロントエンドのパッケージだけ管理 Nuget ではバックエンドのパッケージだけ管理 すればいいんじゃないか、という話です。 npm と Nuget を共存させた場合の問題 デフォルトのMVC プロジェクトテンプレートでは、Nuget で jQuery や Bootstrap などのフロントエンドパッケージが管理されています。 Nuget だけでやりくりする場合は何の問題もありませんが、Nuget に加えて npm も使う場合、両方のパッケージマネージャーでフロントエンドパ

主に「ASP.NET Core」の名前や歴史に関する話です。 誰も彼もが解説をさぼった結果、世間的な認識がとても曖昧になっているように見えるところを少し整理しようと思います。 少しめんどくさい話になりますがお付き合いください。 ASP.NET の派生。Core という名前について。 ASP.NET 上に構成されるフレームワークにはいくつか派生があり、名称としては「ASP.NET Web Forms」「ASP.NET MVC」「ASP.NET Core」「ASP.NET Core MVC」等の表記を見ることがしばしばあるかと思います。 これは少し名前を分解して考える必要があります。 まず、ASP.NET というウェブアプリケーション用のエンジンがあり、このエンジンは名前通り .NET Framework 上で動きます。この ASP.NET エンジンの上に「Web Forms」「MVC」のテン

仕事でも Application Insights を弄っていたのに全く知らなかった機能である Snapshot Debugger ですが、チャックさんの記事で存在を知ったのと何となく試して見たかったので検証してみることにしました。 Tech Summit 2017 のチャックさんのセッションで話があったっぽいですね。Tech Summit 2017 は登壇側だったのと、登壇者は他のセッションに参加できないパスだったので見れてませんでした。 最近実装されたのかと思ってたらそんなことはなく、地味に前からある機能でした。ドキュメントもちゃんと整備されていて ASP.NET 4.6 以降と ASP.NET Core 2.0 アプリケーションならすぐに使えるようです。 上のスライドでは Visual Studio からの利用になってますが、アプリケーションにインストールしておくと、例外が投げられた

サンプルとか超小規模以外の ASP.NET Core MVC アプリケーションを書いてますが、いろいろと悩んだりはまったりしたポイントがあったのでまとめました。 まだまだありそうなので、ちょっとずつまとめようかと思います。 addTagHelper にはアセンブリ名を指定する これに気が付かずに 1 時間以上無駄にしました。最初から書かれている Tag Helpers の追加コードが名前空間に見えたので、ずっと名前空間を指定していました。 ドキュメントをちゃんと読めばアセンブリと書いてあったのですが、完全に見落としていました。 このプロジェクトの場合は Tag Helper は WebApplication14.TagHelpers 名前空間にいますが、アセンブリ名を指定しないといけないので WebApplication14 とだけ書きます。 @addTagHelper *, Micros

JavaScript界隈のフレームワークの組み合わせがファッキンホットですよね。個人的にはreactに頑張ってほしいと思いつつAngularJSも2が正式リリースされたら追いかけてみようかなというスタンスです。 といいつつ、最近reactを放置してたら自分のフィールドのVisual Studio 2015でどうやってやるのかすっかり忘れてしまったので、思い出したりするのを兼ねてやってみました。 nodejsとかは入れようね nodejs入れよう。 Node.js webpack入れよう 最近はwebpackで色々やるのがはやりなんですかね。ということでwebpackを入れておきます。 npm install -g webpack typescript 2.0 rcを入れよう npm install -g typescript@rc 正式版がリリースされると@rcがいらなくなる。 Visua

この記事は、Fujitsu Advent Calender 2016の6日目の記事です。 はじめに 仕事柄、沢山の人が関わるお仕事の効率化に関心があり、プライベートで研究や開発をしています。システム・インテグレーションをはじめ沢山の人が関わるお仕事は、人海戦術で行なわれる事がよくあります。しかし、経験上ITが関わるお仕事の人海戦術はおすすめできません。効率面、品質面、労務管理の面で問題が発生する事が多いからです。 人海戦術にならないようにするには、「人間的な仕事」と「機械的な作業」を切り分けて、機械的な作業をIT化するのが近道ではないかと考えています。 ITの現場における機械的な作業の例 情報を記録する（課題とか、バグとか、更新履歴とか） 情報を探索する（あの資料どこだっけ？とか） 情報を収集する（進捗どうですか？だめですか？とか） 情報を転記する（メールからエクセルとか） 情報を伝達する

Azure App Service の Linux 版が Docker に対応したり、Azure Container Registry がプレビューになったりと、Docker と Container に対応しておくと色々幸せになれそうなので、既存の ASP.NET アプリケーションに絞って調べることにしました。 Azure Container Service は Windows Containers 対応がプライベートプレビューになっていますし、ASP.NET 4.6 アプリケーションを Windows Containers 対応にしておくと有利になりそうです。 今後は App Service でも Windows Containers 対応が来る可能性もありますし、対応しておいて損はないと思います。対応させるための手間もほとんどかかりません。 既に Docker Hub で公開されている

Windows Server 2016 が MSDN からダウンロード出来るようになっていたので、Service Fabric Cluster 用に買った Intel NUC にインストールしてみました。 Hyper-V 上に入れた 2016 で Windows Containers を試したとき、1 日経ってもコンテナが起動しなかったのでホスト OS に Windows Container をインストールして再度試しました。 MSDN のドキュメントも更新されているようなので、Docker を含んだセットアップは手順通り行いました。 ドキュメントにある .NET Core のサンプルはあっさり動作したので、前に Hyper-V 上だと実行に失敗した microsoft/iis イメージを実行してみます。 既に Windows Container と IIS を使って ASP.NET を動

Web サイトとかにデプロイを行う時に利用する Web 発行には、ビューのプリコンパイルを実行する機能があるのですが、これを使えば ASP.NET MVC の Razor ビューもプリコンパイル出来ます。 プリコンパイルすると何が嬉しいかという話ですが、初回アクセス時にビューのコンパイルが行われない為、デプロイ直後でも高速に動作してくれます。 代わりに、サーバ上のファイルを直接弄っての修正は行えなくなったり、デプロイに数十秒時間がかかったりはするようになりますが、初回アクセスに時間がかかることを考えると、全く問題ないレベルです。 設定は非常に簡単で、発行ウィザードの途中にある「発行中にプリコンパイルする」にチェックを入れます。すると横にある「構成」のリンクが押せるようになるので、もう少し追加の設定を行います。 「構成」リンクを選択すると、以下のようなダイアログが表示されます。 初期表示状態

ASP.NET Coreでは「DI(Dependency Injection)」を基本として使用するアーキテクチャが採用されています。 DI自体は古くからある考え方であり、Javaなどでは昔から、そして今でもメジャーに使われている技術です。 勿論 .NET 開発者の間でも利用されています。古くはSeaserコンテナから始まり、MEF(Managed Extensibility Framework)、Unity、Ninject、AutoFac・・・等いくつものDIコンテナが存在しています。 DIは基本的に「特定の具象クラスに依存した実装を行わない」ことを実現します。つまり、あるオブジェクトAがあるオブジェクトBを使用する（依存する）場合、Aの中で直接 new B() のようなことはしないのです。 以下が非DIな実装です。ShoppingCartControllerクラスは、ShoppingC