昨日 IIS Manager Extension の紹介として JSON の MIME 設定を追加しましたが、折角なので最新の IIS 10.0 で定義されている MIME Map と比較してみました。 設定を丸っとコピーしてきて、差分を出してみると結構な差がありました。 有名なものを挙げると WebM や JSON LD、woff などの、最近の HTML5 アプリケーションの配信に必要となりそうな MIME が追加されていました。裏を返せば、今の Web Apps では手動で追加する必要があります。 MIME の設定などは XDT でやりなさい、と言うフィードバックへの回答もあります。 何故か mp4 すら追加されていなかったのが IIS 10.0 ではデフォルトで追加されているので、Web Apps の IIS がアップデートされると楽ですが、残念ながらまだまだ時間がかかりそうです。

Azure App Service (Web Apps) がリリースされて 6 年、情報のアップデートを行いつつ気になった情報は適当にブログに書くという日々ですが、Regional VNET Integration や Service Endpoins が使えるようになって設計に大きな変化が出るようになったのでまとめます。 最近は Microsoft で HackFest を行うことも多いのですが、App Service をこれから使い始めたいという場合に、失敗しない構成を共有したい、知ってほしいという意図もあります。多いですが中身は単純です。 基本設定 64bit Worker は必要な場合のみ利用する FTP / Web Deploy をオフにする Always on を有効化する ARR affinity をオフにする HTTP/2 の有効化を検討する Health Checks の

昔のように高い信頼性を持つオンプレのハードウェア上で動いていたアプリケーションとは異なり、昨今のクラウド上で動いているアプリケーションは障害が発生する前提でコードを書く必要があります。クラウドのハードウェアは毎日どこかで壊れるので、それを前提にソフトウェアで高可用性を担保しているわけです。 最近は Microservices の流行もあって 1 つのアプリケーションを構成するコンポーネントが増えているため、実装によっては 1 つのコンポーネントで発生した障害が全体に波及してしまい、アプリケーション全体が停止してしまうこともあり得ます。例としてよく挙げられるのがリコメンド周りでしょう、リコメンドサービスの障害でアプリケーション全体が落ちてはいけないのです。 今のアプリケーションは障害時には敢えてサービスレベルを下げてでも、全体としての可用性を維持することが必要です。そして復旧時には人の介入な

Azure App Service は非常に便利なのですが、アプリケーションに何らかの問題があった場合には VM などと比べると調査方法が若干特殊です。今は公式の診断機能がかなり強化されていますが、逆に多すぎて困ることもあるのでまとめました。 用意されているツール Diagnose and solve problems を使う Support Tools を使う Kudu を使う Application Insights を使う パフォーマンス問題の場合 プロファイリングを実行する メモリダンプを取得する Auto Heal を有効にする 恐らく歴史的経緯によって機能がダブっている部分もあるので、その辺りについても書きました。 用意されているツール Diagnose and solve problems を使う 何が起こっているのかわかっていない場合は、とりあえずこの自動診断機能を使えば大

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

仕事でも 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

割と時間がかかりましたが、Azure WebJobs SDK の正式版がついにリリースされました。 NuGet Gallery | Microsoft.Azure.WebJobs 1.0.0 そして、ついに Azure WebJobs 自体もプレビューが取れて正式リリースされたようです。数日前まではあったはずのプレビューという表示が無くなっています。 折角なので、Azure WebJobs を実際に使ってみて嵌った点など、使い方のコツ的なものを紹介しておこうかと思います。SDK に限らず紹介していきます。 プロジェクトテンプレート Visual Studio 2013 Update 3 をインストール済みの環境であれば、Cloud カテゴリに Azure WebJobs テンプレートが追加されているはずです。 しかし、このテンプレートは特にコンソールアプリケーションのプロジェクトテンプレー

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 で公開されている

エラー調査のために Kudu 周りを調べていたら、Wiki に Web Apps のタイムゾーン設定が追加されていたのに気が付いたので、実際に設定して試してみました。 Kudu の Wiki はちょいちょい更新されているので、ちゃんと確認しておかないといけないですね。 Configurable settings · projectkudu/kudu Wiki · GitHub 基本的に Azure のサービスは UTC がデフォルトの設定になっていて、Cloud Services では Startup Task などを使ったタイムゾーンの変更が非推奨となっていました。 But I would strongly advice against it. The Fabric Controller maintains operating system time synchronization fo

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 アプリケーションのエラー画面を見たことない人は、ASP.NET 開発者にはいないと思います。この画面を本番環境では出すわけに行かないので普通はカスタマイズしますよね。 しかし、ASP.NET では 404 をアプリケーション的に返しているのに、IIS のデフォルト 404 ページが表示されてしまい、悩まされた経験がある人も多いかと思います。これは ASP.NET と IIS で扱いが異なっているのが原因で、設定も別々に存在しているのでまとめておきたいと思います。 ASP.NET ASP.NET では Web.config の system.web 要素内に customError 要素を追加して、ステータスコード別にリダイレクト先の URL を設定できるようになります。 customErrors 要素 (ASP.NET 設定スキーマ) 例えば 404 ページを

全 24 回で完結しました。 はじめに 前提知識 構成図 完成したアプリのイメージ 環境の構築 プロジェクトを作成 ビューエンジンの選択 作成されたプロジェクトを確認 サーバ側のロジックを開発 モデルをコードファーストで作成 リポジトリパターンを適用する コントローラの追加 コントローラの実装 アクションの追加 強力なモデルバインダ アクションの実装 動画アップロードの実装 クライアント側のロジックを開発 ビューの作成 Razor の文法 ビューの実装 Details アクション Create, Edit アクション Delete, Index アクション HTML ヘルパーを活用 タグ・コメント登録を実装する クライアントサイド検証を利用する ローカル環境で動作を確認 IIS 7.5 Express で動作検証 ルーティング定義を確認、追加 自動的に作成されたテーブルを確認 ASP.NE

自分が毎回新規で ASP.NET MVC アプリケーションの開発を始めるときに忘れるので、今までブログに書いた分をまとめてみました。 ASP.NET MVC 5 と限定してあるのは、5 より前のバージョンではバグ持ちの設定を紹介しているからです。 Razor のみを使う ViewEngines.Engines.Clear(); ViewEngines.Engines.Add(new RazorViewEngine()); モバイルビューを無効にする DisplayModeProvider.Instance.Modes.Clear(); DisplayModeProvider.Instance.Modes.Add(new DefaultDisplayMode()); 生成される URL を小文字にする public static void RegisterRoutes(RouteCollec