年の瀬も迫ってまいりました。 本記事は C# Advent Calendar 2024 の16日目の記事です。 本記事は未完成で鋭意執筆中ではありますが、Advent Calendar に穴を空けたままにしておくのも申し訳ないので、一旦プレビュー版として公開します。 年内には完成させたいと思っています。しばらくお待ちください。 GitHub に dotnet/extensions というリポジトリがあります。 ここはかつて、Microsoft.Extensions.DependencyInjection 等に代表される Microsoft.Extensions 系ライブラリのソースコード リポジトリだったのですが、.NET 5.0 の頃に、それらは dotnet/runtime や dotnet/aspnetcore といったリポジトリに統合されていきました。 その後しばらく廃墟になってい
ASP.NET Core ASP.NET Core Identity Auth Security Implementing custom token providers for passwordless authentication in ASP.NET Core Identity This post was inspired by Scott Brady's recent post on implementing "passwordless authentication" using ASP.NET Core Identity.. In this post I show how to implement his "optimisation" suggestions to reduce the lifetime of "magic link" tokens. I start by prov
Photo by Domenico Loia on UnsplashHotwired ASP.NET Core Web Application (6 Part Series) Hotwired ASP.NET Core Web Application — Part 1 (Intro) Hotwired ASP.NET Core Web Application — Part 2 (NPM, Webpack Setup) Hotwired ASP.NET Core Web Application — Part 3 (Turbo Drive & Frame) Hotwired ASP.NET Core Web Application — Part 4 (Turbo Stream) Hotwired ASP.NET Core Web Application — Part 5 (Stimulus)
少し前から Application Insights の Performance を開くと、上部に Code Optimizations というボタンが表示されるようになっています。隣にある Profiler は以前からある機能ですが、Code Optimizations はひっそりと追加された新しい機能となります。 あまり注目されている気配を感じないのですが、上手く有効化出来ると継続的にアプリケーションのパフォーマンスを解析し、改善するというループを回しやすくなるはずです。ドキュメントがあるので、こちらも目を通しておくのが良いです。ちなみに現在サポートされているのは .NET のみです。 後で触れますが、Code Optimizations を利用するには Profiler を有効化する必要があります。この有効化方法が少し悩ましいので後半でまとめておきました。 Code Optimiza
Created at: 2020-12-25 これは Blazor Advent Calendar 2020 の25日目のエントリーです。 Blazor はお手軽に Single Page Application を作れるのですがコンポーネントのライフサイクル、ステート関連について知らないと若干不思議な仕組みで動いているように見えます。 例えばプロジェクトテンプレートの Counter は @onclick="IncrementCount" でプライベート変数 currentCount をインクリメントするとページのカウントがアップしますが、これは初見ではなかなか不思議な挙動です。Blazor は currentCount の変更をどうやって知ったのか?としばらく不思議に思っていました。そういったこともライフサイクルを知ることで理解できます。 基本的には ASP.NET Core Blaz
昔は ASP.NET で Swagger / OpenAPI 定義を出力するには Swashbuckle が定番でしたが、あまりアクティブではない時期が長かったせいか最近は NSwag を使うようにしています。 今では GitHub の Star 数も Swashbuckle より NSwag の方が多くなっています。 Docs でも Swashbuckle と共に NSwag を使ったドキュメントが公開されています。 機能的には Swashbuckle と NSwag で大きな差はないですが、NSwag は MSBuild 向けパッケージや CLI を使った静的な Swagger / OpenAPI 定義の生成が行えます。 Swagger / OpenAPI 正義は実行時にわざわざリフレクションを使用して生成する必要はゼロで、ビルド時や CI といったタイミングで生成できれば全く問題ない
ちゃんとやったことなかった（存在は知ってた）ので覚書です。 ASP.NET Core で Controller を作ったけど、結合テストしないとなぁ…と思ってたけど、単体テストしてるしなぁめんどくさいなぁ…とも思ってたりしてたけど、便利な機能なのでやります！やりますよ。 テスト対象のプロジェクトの作成 ASP.NET Core の API のプロジェクトテンプレートを作成します。 認証は個別のユーザー アカウント（Azure AD B2C を使うやつ）を設定しました。 前はここにアプリ内でユーザー管理するやつがあった気がするけど…、変わったのかな？ 今回はテスト用なので、ドメイン名やアプリケーション ID などは適当なものを入れました。 Entity Framework Core 系の以下のパッケージを追加して DB 操作のコードを追加します。 Microsoft.EntityFramew
Auth0 Marketplace Discover and enable the integrations you need to solve identity Explore Auth0 Marketplace 注意！本書は ASP.NET Core プラットフォームのバージョン 2.0 を参照しています。ASP.NET Core 1.0 をセキュアにする方法をお探しの方は、 ASP.NET Core 認証チュートリアル セクションをご参照ください。お楽しみください！ TL;DR: 以前のバージョンとは異なり、ASP.NET Core 2 は JSON Web Token に対するネイティブサポートを提供します。このサポートにより、ASP.NET アプリケーションにおけるこのテクノロジをより簡単な方法で統合することができます。本書では、ASP.NET Core 2 をベースにして We
Azure App Service に ASP.NET Core アプリケーションをデプロイする時には、必ず Application Insights を同時に有効化するようにしていますが、有効化の方法として 2 種類が存在しているので軽くまとめておきます。 自分でもこのあたりは割と混乱していたのと、App Service 側の挙動が微妙に変わっていたりしたので一度しっかりと確認しておきたかった部分です。 現時点では以下の 2 つの方法で Application Insights を有効化できるようになっています。ASP.NET Core アプリケーションと言ってますが、ASP.NET でもほぼ同じ扱いです。 ASP.NET Core に Application Insights をインストールする App Service の Application Insights 設定から有効化する
.NET Core になると WCF のサーバーサイドが消えて移行先として gRPC があげられてるのを何処かで見た気がします。OSS の WCF もあった気がするけど、そっちはよく見てない。 ということで、ASP.NET Core 3.0 Preview で gRPC 試してみようと思います。 プロジェクトの作成 今日は出先のカフェでコーヒー飲みながら Surface Go で書いてます。なので Visual Studio 2019 は入ってない（Surface Go には重すぎた）ので、Visual Studio Code でいきます。 適当なフォルダーで空の Web アプリを作ります。 $ dotnet new web -o GrpcServer ソリューションも作って追加しておきましょう。 $ dotnet new sln $ dotnet sln add GrpcServer/G
UPDATE [2018–02–21]: initial code contained a major drawback that leads to threads hangs. My apologies! Please see the new section “SSE on AspNet Core (done right)”. Let’s consider we need to build an admin web console in an app for displaying log/diagnostics events in real-time. I used to use Server Sent Event (SSE) technology for such a task. And recently migrated that code from WebApi 2 onto As
ASP.NET Core 2.2 から Health Checks API が実装されました。最近の Container や Microservices の流れでは必須機能と言えるので、シンプルな API として実装されたのは良い感じです。 ドキュメントがありますが重要な機能だからかとても長いです。過去最長ぐらいのレベルで。 API はシンプルな割に行えることがとても多いので、実際に自分で触ってみておくことにします。 ちなみに Health Check に関係するデザインパターンやアーキテクチャのドキュメントも、Microsoft Docs にて公開されています。使ってる技術は古いですが、こういうのは考え方が重要なので問題ありません。 目を通しておくと、何故 Health Check が今必要なのかが理解できると思います。 以下に実際に自分が触って動作を確認したり、試してみて気になったこと
はじめに Blazor は、WebAssembly を使用してブラウザで実行される、.NET上に構築されたシングルページ Web アプリケーションフレームワークです。 @jsakamoto さんのC# で Single Page Web Application が書ける Blazor が凄かった件 にとても詳しく載っています。 大まかな仕組みとしては C# をコンパイルした IL（.NET の中間言語）を WebAssembly にコンパイルすることでブラウザで .NET が実行できます。 TypeScript やその他 AltJS のように JavaScript にトランスパイルされるわけではなく、本当に C# のコードがブラウザで動きます。 このような技術は、今は無き Microsoft Silverlight を連想させますが、そうではなく、オープンな Web 標準を使用してブラウザ
.NET Core 2.1 と ASP.NET Core 2.1 がリリースされたので、これまで 2.0 や 2.1 rc1 で開発していたアプリケーションを 2.1 にアップデートしてました。2.1 rc1 は特にやることないのですが、2.0 からはちょっと作業が必要だったのでメモ。 といっても、基本は以下のドキュメントに従えば良いです。実際この通りに作業しました。 元々は ASP.NET Core 1.0 から開発していたアプリを題材にしたので、思ったより変更点が多かったため以下のようになりました。 基本的にはコードや設定の量が減っていくので非常に好感が持てます。 .NET Core 2.1 に変更 当然ながらターゲットフレームワークを .NET Core 2.1 に変更する必要があります。 Visual Studio から変更しても良いですし、csproj を直接開いて netcor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
