DEV Community: jsakamoto

The Missing Third Config Layer: Adding User Secrets to Blazor WebAssembly

jsakamoto — Wed, 04 Mar 2026 13:04:20 +0000

🤔 The Problem with Blazor WebAssembly

A while back, I wrote a Japanese article about how to manage API keys for error monitoring services like Raygun and Sentry in a Blazor WebAssembly app.

https://qiita.com/jsakamoto/items/e72bbf0681994307d07c

In that article, I touched on how to handle configuration values during development. Here is one passage I wrote:

I think it would be a good idea to exclude appsettings.Development.json from version control using a .gitignore file, but I will skip the details in this article. If you were using a project other than Blazor WebAssembly, User Secrets would be a convenient and reasonable option. Unfortunately, Blazor WebAssembly does not support User Secrets, so using appsettings.Development.json seemed like the safest approach.

Yes, Blazor WebAssembly does not support User Secrets. And this turns out to be more of a problem than it first appears.

🔍 The Three-Layer Configuration Problem

In .NET apps, I think most developers want to manage configuration values in three layers, where each layer overrides the one before it:

Release configuration: values for the production environment. Committed to source control and shared with everyone.
Shared development configuration: values for the development environment, shared with all team members. Also committed to source control.
Personal developer configuration: values specific to each developer's local environment. Not committed to source control.

In Blazor WebAssembly, appsettings.json (the first layer) and appsettings.Development.json (the second layer) cover the first two cases nicely.

The problem is the third layer.

In that earlier article, I mentioned excluding appsettings.Development.json from source control using .gitignore. But if you think about it, doing that removes the place where you would normally store shared development configuration (the second layer). Trying to keep both "shared team settings" and "personal settings" in a single file, and then excluding that file from source control, is a dead end.

In a regular ASP.NET Core project, User Secrets (via the dotnet user-secrets set command) can serve as this third layer. It lets each developer save personal settings locally without committing them to the repository. But since Blazor WebAssembly does not run on the server side, this mechanism simply was not available.

💡 I Thought, "Why Not Build It Myself?"

While writing that article, I had a sudden idea.

"What if I intercepted requests to the dev server and merged the User Secrets values into the response for appsettings.*.json files?"

But when I thought about how to implement that, it felt a bit wasteful to build just a dedicated tool for merging User Secrets. If I could build a general-purpose mechanism for extending the dev server, it could be useful for all kinds of purposes in the future too.

So I decided to take a two-part approach:

Extensible Dev Server: a Blazor WebAssembly dev server that can be extended with custom middleware
User Secrets extension: an extension that runs on the Extensible Dev Server and merges User Secrets values

The Extensible Dev Server is designed as a drop-in replacement for the standard Blazor WebAssembly dev server NuGet package (Microsoft.AspNetCore.Components.WebAssembly.DevServer). The mechanism for plugging in custom middleware is built on top of the ASP.NET Core Hosting Startup feature. Hosting Startup lets you inject middleware from a separately built assembly into an existing ASP.NET Core app, without touching the app itself. I wrote a separate article on dev.to explaining this feature in more detail:

jsakamoto

Feb 14

Extending an ASP.NET Core App with External Middleware Using "Hosting Startup"

#dotnet #aspnetcore

Comments

6 min read

I then implemented User Secrets merging as the first extension for the Extensible Dev Server and released both as NuGet packages.

🔧 What I Built

Blazor WebAssembly Extensible Dev Server

https://github.com/jsakamoto/Toolbelt.Blazor.WebAssembly.ExtensibleDevServer

User Secrets Extension for Blazor WebAssembly Extensible Dev Server

https://github.com/jsakamoto/Toolbelt.Blazor.WebAssembly.ExtensibleDevServer.UserSecretsExtension

⚡ How to Use It

🛠️ 1. Add the Packages

Add the following two packages to your Blazor WebAssembly project.

dotnet add package Toolbelt.Blazor.WebAssembly.ExtensibleDevServer
dotnet add package Toolbelt.Blazor.WebAssembly.ExtensibleDevServer.UserSecretsExtension

You no longer need the existing Microsoft.AspNetCore.Components.WebAssembly.DevServer package, so remove it.

dotnet remove package Microsoft.AspNetCore.Components.WebAssembly.DevServer

🛠️ 2. Set Up User Secrets

After that, set up User Secrets the same way you would in any other .NET project.

In Visual Studio, right-click the project and select "Manage User Secrets".

From the CLI, run these commands:

dotnet user-secrets init
dotnet user-secrets set "SomeSection:SomeKey" "my-custom-value"

🚀 3. Run the App

Then just run the app as usual with dotnet run or through Visual Studio. No extra code is needed, and there is nothing else to configure.

Your app's configuration will automatically include the values from User Secrets, merged in. It almost feels too easy 😅

🔰 How It Works

The Extensible Dev Server intercepts HTTP GET requests for appsettings.*.json files. The User Secrets extension handles those requests and does the following:

Read the original appsettings.*.json from the wwwroot folder
Read the User Secrets configured for the project
Merge them together and return the result as the HTTP response

The files on disk are never modified. Only the HTTP response content is changed.

The configuration priority order looks like this:

appsettings.json (lowest priority)
  overridden by
appsettings.Development.json
  overridden by
User Secrets (highest priority)

⚠️ User Secrets Values Are Not Actually Secret

Before using this package, please understand one important point.

When developing a Blazor WebAssembly app with this package applied, values stored in User Secrets are returned as plain text in the HTTP response to the browser. In other words, they are not actually secret.

This is probably why Microsoft has not added official support for User Secrets in Blazor WebAssembly. In a regular server-side .NET app, User Secrets stores values in a safe location separate from the compiled code. Applying that same idea to Blazor WebAssembly would cause confusion: the values would be fully visible in the browser despite the word "Secrets" in the name. I imagine Microsoft decided that supporting such misleading behavior was not the right call.

This package intentionally works around that limitation. It does not treat User Secrets as a vault for sensitive information. Instead, it borrows the User Secrets storage mechanism purely as a third configuration layer.

So please do not store passwords, authentication tokens, or any other information that must not be exposed. This package is intended for configuration values that are safe to be public, such as:

Local dev server URLs
Flags to enable personal or debug features
API keys for error monitoring services like Raygun and Sentry (as discussed in the original article)

🎉 Summary

With this package, you can now manage personal developer configuration in Blazor WebAssembly using dotnet user-secrets, just like in any other .NET project.

For example, API keys for error monitoring services like Raygun and Sentry (the very problem from the original article) can now be stored in each developer's own User Secrets. You can keep shared team settings in appsettings.Development.json and separate each person's personal settings into User Secrets. This cleanly solves the problem of having "settings you want to share" and "settings you do not want to commit" living in the same file.

Just add the packages and you are ready to go. No extra code needed.

If you try it out, or if you have any questions or feedback, feel free to share them in the comments! 👇

❤️ Happy coding!

Your Component Catalog Already Knows Everything. So Why Not Make It an MCP Server?

jsakamoto — Wed, 25 Feb 2026 12:03:26 +0000

🔰 Introduction

Note: A quick note before we dive in: the implementation described in this article was carried out in the spring of 2025, nearly a year before I sat down to write about it. The AI ecosystem moves at a breathtaking pace, so some specifics may feel a bit dated by now. That said, I believe the core ideas and approach still hold value, and I hope this article proves useful to at least some of you.

I recently published the following article, which introduces a project I've been working on since March 2023 called "Blazing Story", a Storybook clone fully reimplemented in Blazor (licensed under Mozilla Public License 2.0).

jsakamoto

Feb 23

Storybook Doesn't Support Blazor, So I Reimplemented It in C#

#storybook #blazor #webdev

Comments

7 min read

This article is a follow-up to that one. Here, I'll walk you through how I added an MCP server feature to Blazing Story.

For an introduction to Storybook, Blazor, and Blazing Story itself, please refer to the article linked above.

🤔 What is MCP?

If you're reading this, you're probably already familiar with MCP. But just in case, here's a quick overview.

MCP stands for Model Context Protocol. It is a standard interface that allows generative AI to interact with the outside world. In a typical setup, the generative AI acts as the MCP "client," while the systems that provide information to the AI (or receive instructions from it) are called MCP "servers." When both sides follow the MCP specification, they can communicate with each other seamlessly.

Before MCP came along, connecting generative AI to external systems was still possible, but every AI platform had its own proprietary way of doing it. When MCP emerged as a shared standard, a flood of MCP servers were released in a short time, and AI platforms quickly adopted support for it. Working with generative AI in real-world applications became dramatically easier as a result.

💡 The Idea: Exposing an In-House Design System via MCP

In the spring of 2025, the following article made quite a splash in the Japanese developer community:

社内デザインシステムをMCPサーバー化したらUI実装が爆速になった

zenn.dev

(This article is written in Japanese.)

It describes how a team built an MCP server that scans the source code of their in-house UI components (written in JavaScript/TypeScript) and returns information about them. By connecting this MCP server to a generative AI, when they asked the AI to generate UI through a text prompt, the AI correctly used those in-house components instead of making things up.

This addresses a real pain point. Without such a setup, when you ask generative AI to write UI code, it tends to build everything from scratch using something like Tailwind CSS directly, creating its own ad-hoc components. Having an MCP server that informs the AI about your existing UI component library is a genuine game-changer for AI-assisted UI development.

But do you always have to build this kind of MCP server from scratch? Is there a way to reuse something you already have?

🤩 Wait, Doesn't Storybook Already Know Everything?

That's when an idea hit me.

In many frontend development teams, Storybook is already in use, and Storybook actually "knows a lot" about the components in a project:

What components exist, with usage examples (from story definitions)
The purpose and overview of each component (from JSDoc)
Real markup examples (from story definitions)
What parameters a component accepts, including their types and descriptions (from type definitions and JSDoc)

So the idea was simple: What if Storybook could talk to the AI through MCP?

⚡ Adding an MCP Server Feature to Blazing Story

Personally, I work more with Blazor (C#/.NET) than with JavaScript/TypeScript-based frontend frameworks. Blazing Story is a Blazor-based alternative to Storybook, and I develop and maintain it myself.

Since I know the internal structure of Blazing Story well (and can actually make changes to it), I decided to implement this idea for real.

Fortunately, a C#/.NET SDK for building MCP servers was already available. Using this SDK, adding MCP server functionality to Blazing Story turned out to be surprisingly straightforward.

🧪 Trying It Out

With the MCP server feature in place, I tried asking a generative AI to generate UI code, just to see what it would come up with.

🛠️ Setting Up the Environment

This experiment was done around July 2025, so the tooling is a bit dated, but here's what I used:

Visual Studio Code with GitHub Copilot
Claude Sonnet 4 as the AI model
.NET SDK for the Blazor project

For the MCP integration, I configured two things in advance:

In .vscode/mcp.json, I specified the HTTP Streaming API endpoint of Blazing Story's MCP server
In .github/copilot-instructions.md, I added a custom instruction: "When generating UI code, query the Blazing Story MCP server and prioritize using the available components"

✍️ First Try: Generating UI from a Text Prompt

As a first step, I typed the following prompt into the GitHub Copilot chat in VSCode:

Please implement a checkout form for an e-commerce site inside the currently open Checkout.razor file.

- Add a "Checkout" title at the very top of the page.
- Below that, place a stepper component showing the following 3 steps.
  - Information
  - Confirmation
  - Complete
- For now, focus on building the "Information" form.
- The form should include the following sections and fields.
  - Shipping Information
  - Full Name
  - Postal Code
  - Address
  - Phone Number
  - Email Address
  - Shipping Options
  - Preferred Delivery Date
  - Preferred Delivery Time (choose from Morning, Afternoon, or Evening)
  - Payment Method (choose from Cash on Delivery, Credit Card, or PayPay)
  - A "Next" button
- Use a select component for the Preferred Delivery Time field.
- Use a vertically stacked radio group component for the Payment Method field.

The result was honestly surprising. The AI generated exactly the Razor component UI code I was looking for. It used the components already registered in Blazing Story rather than making up its own. And because it understood what parameters those components accept, it produced perfectly working code with no build errors on the very first prompt. 🎉

🖼️ Second Try: Generating UI from a Sketch Image

Next, I tried generating UI from an image. Instead of using Figma, I drew a rough "hand-drawn style" sketch of the desired layout in PowerPoint, exported it as an image, and submitted it to the same Copilot chat setup.

This also worked without any trouble. Just like with the text prompt, the AI generated Razor component source code based on the layout shown in the sketch, using the component info provided by Blazing Story's MCP server. It worked so well that it felt almost too easy. 😅

You can also watch a video of this experiment here:

https://blazingstory.github.io/docs/mcp-server-feature?_highlight=mcp#summary

📝 What We Learned

Those results revealed something important.

By feeding UI component information to the AI through an MCP server, the AI generated highly accurate UI source code from a single prompt. It used the existing components rather than inventing its own. And it avoided the hallucinations that generative AI is often prone to, like confidently setting parameters that sound plausible but simply don't exist.

I also noticed something interesting on the software engineering side. The principles that have always mattered in human team development still matter just as much when working with generative AI:

Write documentation carefully (JSDoc or XML doc comments in C#/Blazor), because the AI reads them too
Use clear, meaningful names for your components and parameters

If these are neglected, the AI produces incorrect or confusing code for the exact same reasons human developers would struggle. Good practices remain good practices.

🤷 But Isn't Writing Stories a Lot of Work?

Fair question. Building the MCP server described above still requires humans to write stories one by one. If your only goal is to expose UI component info to the AI, it might actually be more efficient to implement a lightweight MCP server that scans component source code directly.

But here's the thing: in practice, frontend teams often need Blazing Story (or Storybook) anyway, for component-level E2E testing, visual regression testing, and as a reference resource for developers learning the codebase. Since you're already building stories for those reasons, it makes total sense to let that existing setup serve as the MCP server too. You get the best of both worlds without extra overhead.

🔍 What About the Official Storybook?

When I first looked into this in July 2025, the official Storybook did not yet have this kind of MCP integration. Some community-made add-ons existed, but they were focused on helping AI write stories, not on feeding component information to AI for UI generation. The Storybook GitHub repo had active discussions about the need for something like this, but nothing official had landed yet.

Since then, the Storybook team has moved in exactly this direction. Starting in late 2025, they released official MCP server packages (a standalone library and a Storybook addon) that expose component metadata to AI agents so they can generate UI code using the right components and props. By late February 2026, the project had seen 40+ releases and continues to be actively developed.

It's encouraging to see the same core idea validated by the broader ecosystem. The Blazor/.NET world that Blazing Story serves is a different territory from the JavaScript-centric official Storybook, but the underlying principle of giving AI structured knowledge about your components is clearly the right direction regardless of the tech stack.

🎉 Conclusion: It Works at a Practical Level

To sum up: I added an MCP server feature to Blazing Story, used it to let generative AI generate Blazor UI code, and the results were genuinely practical and useful.

Even in the age of AI, UI component catalogs like Blazing Story continue to play an important role in development workflows, and now they can directly power your AI-assisted development as well.

If you're developing Blazor applications, I strongly encourage you to consider adopting Blazing Story along with its MCP server feature. It can make a real difference in your day-to-day workflow.

For step-by-step instructions on setting up the MCP server feature in your own Blazing Story project, check out the official documentation:

MCP Server Feature | Blazing Story

Summary

blazingstory.github.io

I hope this article was helpful, and I hope you enjoy building Blazor apps even more. ❤️ Happy coding!

Storybook Doesn't Support Blazor, So I Reimplemented It in C#

jsakamoto — Mon, 23 Feb 2026 13:48:47 +0000

If you're building web apps with Blazor, you've probably wished for something like Storybook, a UI component catalog for browsing and developing components in isolation. The problem is, Storybook doesn't support Blazor. So I built one from scratch.

I'm the developer of "Blazing Story" (Mozilla Public License 2.0), a Storybook clone reimplemented entirely in Blazor. I first released it in March 2023, presented it at local conference events, but never wrote about it as a technical article until now. This is the story of how and why I built it.

🔍 What Is Storybook?

For component-based front-end frameworks like Angular, React, Vue, and Svelte, there's an open source library called "Storybook" (MIT License).

Storybook: Frontend workshop for UI development

Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It's open source and free.

storybook.js.org

Storybook provides what's commonly called a "UI component catalog," which is a web UI that works alongside your existing front-end project.

For each component, you write a small JavaScript (TypeScript) file called a "story" that describes how the component should be rendered. Storybook then displays all those stories together in its web UI.

In the Storybook UI, you can see how to use each component, inspect its markup, and explore what parameters it accepts, all without touching the main application. You can change parameters on the fly and immediately see how the component looks. This makes it easy for everyone on the team to share knowledge about which components are available and how to use them, helping the whole team move faster.

Storybook also works as a development workbench for individual components. Instead of developing inside a full application, you can focus on a single component in isolation. This makes it an excellent platform for end-to-end testing per component, and a natural target for screenshot-based visual regression testing (VRT). In fact, Chromatic (the company behind Storybook) offers a SaaS product that lets you deploy your Storybook project for team collaboration and automated visual regression tests on every deployment.

As you can see, Storybook has become an essential part of modern component-based front-end development.

⚡ What Is Blazor?

"Blazor" is an open source framework by Microsoft for building various web applications, including SPAs, using C#.

Blazor | Build client web apps with C# | .NET

Blazor is a feature of ASP.NET for building interactive web UIs using C# instead of JavaScript. It's real .NET running in the browser on WebAssembly.

dotnet.microsoft.com

Blazor supports several hosting models. Blazor WebAssembly, for example, compiles your C# code to MSIL binary and runs it directly in the browser using a CLR reimplemented on top of WebAssembly. In other words, .NET assemblies (.dll files) run right inside your browser. That's how Blazor WebAssembly delivers single-page applications.

Like other modern frameworks, Blazor is component-based. You write components in .razor files, mixing HTML with C# code. Think of it as the C# equivalent of JSX (or TSX).

In a real-world Blazor application, you may occasionally need to call JavaScript code, but for the most part everything is implemented in C#. And since Blazor doesn't transpile C# to JavaScript but instead uses .NET assemblies at the binary level, the development ecosystem is exactly the same as any other .NET project. You don't need to know anything about JavaScript bundlers. Blazor lets you build rich, interactive web applications entirely in C#.

😔 The Problem: No Storybook for Blazor

Since Blazor is a component-based framework, it's natural to want the same kind of UI component catalog that Storybook provides.

Storybook Doesn't Support Blazor

Unfortunately, Storybook doesn't support Blazor, and it's easy to understand why.

Blazor brings a full .NET runtime into the browser, which is a completely different world from what Storybook expects. A Blazor build outputs .NET assembly files containing MSIL binary code. Storybook, on the other hand, expects importable JavaScript modules. The two simply can't work together.

There's a Workaround, But...

Blazor does allow you to instantiate a component from the JavaScript side and mount it to a DOM element. You can even wrap it as a Web Components custom element for use in other JS frameworks. So technically, it might be possible to use Blazor components inside Storybook.

But would Blazor developers actually want that?

You chose Blazor specifically to build web apps in C#. Having to learn the JavaScript ecosystem just to use Storybook, and worse, having to write stories in JavaScript or TypeScript, defeats a big part of the purpose. It's a significant burden.

So what else can we do?

💡 What If We Reimplemented Storybook in Blazor?

That's the conclusion I eventually reached.

Introducing Blazing Story

So I went ahead and did it. I started in December 2022, and about three months later, in March 2023, I released the first version: "Blazing Story".

Overview | Blazing Story

The clone of "Storybook" for Blazor, a frontend workshop for building UI components and pages in isolation.

blazingstory.github.io

With Blazing Story, you get a full UI component catalog experience for Blazor development, just like Storybook.

A live demo is available on GitHub Pages. Feel free to open it and see it in action:

https://jsakamoto.github.io/BlazingStory/?path=/custom/configure-your-project

The Goal: Match Storybook Pixel by Pixel

Blazing Story is designed to look exactly like Storybook visually. The key thing is: I basically didn't look at Storybook's source code. I did reuse Storybook's icon images (SVG), which are available under the MIT License, but everything else I built by comparing pixels in the browser by eye, writing my own DOM structure and CSS to match.

As a result, Blazing Story's screen looks nearly identical to Storybook's at the pixel level, but the underlying DOM structure is completely different. I used color picker tools and browser dev tools to match colors and fonts, and URL routing follows Storybook's specification.

The way you write stories is inspired by Storybook, but it's its own format, with stories written in .razor files.

⚠️ Limitations of a Personal Project

Blazing Story is a personal project, so it naturally has far more limitations than the original Storybook.

Development capacity is the biggest difference. I develop it alone, in the gaps between work and daily life. Even three years after the initial release, many features remain unimplemented, and there are likely bugs that haven't been reported yet. There's also the natural question of what happens if I lose motivation.

Blazing Story also can't use Storybook's plugin ecosystem, which makes sense since it runs on the .NET runtime rather than JavaScript. And the SaaS services Chromatic offers for Storybook are not available either.

Does Blazing Story Still Have a Reason to Exist?

Given all those limitations, you might wonder whether Blazing Story is worth using.

I believe it is.

For one thing, it's a UI component catalog you can use right now in your Blazor development, without waiting for Storybook to add Blazor support (which, realistically, may never happen).

I also think Blazing Story is a compelling showcase for what Blazor can do. It proves that you can build a Storybook equivalent, a sophisticated developer tooling application, entirely in Blazor. On performance: yes, Blazor WebAssembly has the well-known drawback of a slow initial load. But as you can see in the live demo, it's not slow enough to hurt practical usability. And the fact that a single developer was able to reach a first release of something like Storybook in just three months speaks to Blazor's development productivity.

📝 Summary

In modern front-end development, Storybook has become a go-to tool for component-driven development, knowledge sharing, and testing. But Blazor, the framework that lets you build web apps in C#, can't use it.

So I developed and released "Blazing Story" as an open source project: a UI component catalog for Blazor that reimplements Storybook 100% in Blazor. You can start using it in your Blazor project today.

Being a personal project, there are real concerns about missing features and long-term sustainability. Even so, I believe it has a clear reason to exist, both as a practical solution available today and as proof that Blazor is capable of building applications at this level.

If Blazing Story can be even a little helpful in your Blazor development, nothing would make me happier as its author. ❤️

Extending an ASP.NET Core App with External Middleware Using "Hosting Startup"

jsakamoto — Sat, 14 Feb 2026 07:37:03 +0000

Introduction

ASP.NET Core has a feature called "Hosting Startup". It allows us to run additional code when an ASP.NET Core Web application starts up. We can also add middleware through this feature.

Using Hosting Startup, we can add middleware to an already-built ASP.NET Core Web application without rebuilding it. The middleware is implemented in a separate assembly that is built independently.

The official documentation about Hosting Startup is available here.

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/platform-specific-configuration

How Hosting Startup Works

Let me explain how Hosting Startup works in more detail.

Prepare a pre-built assembly (a Hosting Startup assembly) that implements the IHostingStartup interface and is marked with the HostingStartup assembly attribute.
Set the environment variable ASPNETCORE_HOSTINGSTARTUPASSEMBLIES to the name of the Hosting Startup assembly created in step 1.
Run the separately-built ASP.NET Core application.
When the ASP.NET Core application starts up, the IHostingStartup.Configure(IWebHostBuilder builder) method in the Hosting Startup assembly (specified by the environment variable) is called. Inside this method, we can use the IWebHostBuilder object passed as an argument to register additional services to the DI container and perform other initialization tasks.

To add middleware to the ASP.NET Core HTTP request pipeline, we need a few more steps.

Inside the IHostingStartup.Configure(IWebHostBuilder) method of the Hosting Startup assembly, register a class that implements IStartupFilter with the DI container.
After the host is built in the main ASP.NET Core application, when the HTTP request pipeline is being constructed, the IStartupFilter class registered above is instantiated and its IStartupFilter.Configure(Action<IApplicationBuilder> next) method is called. This method returns a function that registers middleware.
The "function that registers middleware" returned from the above method is then executed. This is how the middleware specified in the Hosting Startup assembly gets added to the target ASP.NET Core application.

Implementing a Hosting Startup Assembly and Seeing It in Action

Let's actually implement a Hosting Startup assembly that adds middleware and see it load when an ASP.NET Core Web application starts up.

1. Prepare a Simple ASP.NET Core Web Application

First, let's prepare a simple ASP.NET Core Web application. Open a terminal and run the following dotnet commands to create a new ASP.NET Core Web application and run it.

$ dotnet new web -n MyAspNetCoreApp -f net10.0
$ dotnet build ./MyAspNetCoreApp
$ dotnet ./MyAspNetCoreApp/bin/Debug/net10.0/MyAspNetCoreApp.dll

Open another terminal and check if it works using the curl command.

$ curl -i http://localhost:5000/
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Sat, 14 Feb 2026 02:17:10 GMT
Server: Kestrel
Transfer-Encoding: chunked

Hello World!

Looks good! Now, press Ctrl + C to stop the running ASP.NET Core Web application for now.

2. Implement the Hosting Startup Assembly

Next, let's implement the Hosting Startup assembly. A Hosting Startup assembly is just a regular class library. So run the following dotnet commands to create a new class library project. Additionally, add the Microsoft.AspNetCore.Hosting package to the project, since we need the types for implementing a Hosting Startup assembly. Then open it in VSCode and start implementing.

$ dotnet new classlib -n MyHostingStartup -f net10.0
$ dotnet add package Microsoft.AspNetCore.Hosting --project ./MyHostingStartup
$ code ./MyHostingStartup

We will work in reverse order from how things are called at runtime. Let's first implement the IStartupFilter class, which "returns a function that registers middleware".
Add a file named "MyStartupFilter.cs" to the Hosting Startup project and write the following code.

// MyHostingStartup/MyStartupFilter.cs
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;

public class MyStartupFilter : IStartupFilter
{
    public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
    {
        // Return a function that adds middleware
        return app =>
        {
            app.Use(async (context, nextMiddleware) =>
            {
                // In this sample, add a custom header to the HTTP response
                context.Response.Headers.Add("X-Custom-Header", "MyCustomValue");

                // Call the next middleware in the HTTP request pipeline
                await nextMiddleware.Invoke();
            });

            // Call the next middleware registration process
            next(app);
        };
    }
}

In this implementation, as an example, the middleware adds a response header called "X-Custom-Header" to every HTTP response.

Next, add a class that implements the IHostingStartup interface. This class is called when the ASP.NET Core Web application starts up, and it registers the IStartupFilter class above with the DI container. Add a file named "MyStartup.cs" to the project and write the following code.

// MyHostingStartup/MyStartup.cs
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;

[assembly: HostingStartup(typeof(MyStartup))]

public class MyStartup : IHostingStartup
{
    public void Configure(IWebHostBuilder builder)
    {
        // Register IStartupFilter to the service collection
        builder.ConfigureServices(services =>
        {
            services.AddSingleton<IStartupFilter, MyStartupFilter>();
        });
    }
}

That is all the source code we need. Let's build it with the dotnet command.

$ dotnet build ./MyHostingStartup

3. Run the ASP.NET Core Web Application with the Hosting Startup Assembly

Now, let's set the environment variable ASPNETCORE_HOSTINGSTARTUPASSEMBLIES to the assembly name "MyHostingStartup" that we just built.

$ export ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=MyHostingStartup

If you are using PowerShell, run the following instead.

PS> $env:ASPNETCORE_HOSTINGSTARTUPASSEMBLIES="MyHostingStartup"

With this setting in place, let's run the ASP.NET Core Web application that we created earlier again.

$ dotnet ./MyAspNetCoreApp/bin/Debug/net10.0/MyAspNetCoreApp.dll

But unfortunately, it does not start successfully. We get an error saying "the assembly 'MyHostingStartup' was not found", as shown below.

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
crit: Microsoft.AspNetCore.Hosting.Diagnostics[11]
      Hosting startup assembly exception
      System.InvalidOperationException: Startup assembly MyHostingStartup failed to execute. See the inner exception for more details.
       ---> System.IO.FileNotFoundException: Could not load file or assembly 'MyHostingStartup, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
      File name: 'MyHostingStartup, Culture=neutral, PublicKeyToken=null'
         at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext, RuntimeAssembly requestingAssembly, Boolean throwOnFileNotFound)
         at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
         at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.ExecuteHostingStartups()
         --- End of inner exception stack trace ---

Actually, this is expected. The .NET runtime does not have enough information to determine where to load the assembly MyHostingStartup.dll, so it fails with a "file not found" error.

4. Make the Hosting Startup Assembly Loadable by Specifying the Dependency

So, we need to add MyHostingStartup.dll as a dependency of the ASP.NET Core Web application and tell the runtime where to find it (so it can be resolved to an absolute path). To do this, we need to take care of a couple of things.

First, to make things simple, let's place the Hosting Startup assembly in the same folder as the ASP.NET Core Web application assembly. We can either copy the built Hosting Startup assembly file manually or rebuild the Hosting Startup project with the output folder set to the same folder as the ASP.NET Core Web application output, like this.

$ dotnet build ./MyHostingStartup -o ./MyAspNetCoreApp/bin/Debug/net10.0

Next, create a JSON file that describes the .NET dependency. The file name can be anything, but here we will call it "additional.deps.json". Let's create the file in the current folder and open it in an editor like VSCode.

$ echo "" > additional.deps.json
$ code ./additional.deps.json

In this JSON file, write the following to declare that MyHostingStartup.dll is a dependency.

{
    "runtimeTarget": {
        "name": ".NETCoreApp,Version=v10.0"
    },
    "targets": {
        ".NETCoreApp,Version=v10.0": {
            "MyHostingStartup": {
                "runtime": {
                    "MyHostingStartup.dll": {}
                }
            }
        }
    },
    "libraries": {
        "MyHostingStartup": {
            "type": "project",
            "serviceable": false,
            "sha512": ""
        }
    }
}

After saving this JSON file and closing the editor, we set the environment variable DOTNET_ADDITIONAL_DEPS to the path of this dependency JSON file so that it is loaded at runtime.

$ export DOTNET_ADDITIONAL_DEPS=./additional.deps.json

Or if you are using PowerShell,

PS> $env:DOTNET_ADDITIONAL_DEPS = './additional.deps.json'

After doing this, let's run the ASP.NET Core Web application project again. This time, it should start without any errors.

$ dotnet ./MyAspNetCoreApp/bin/Debug/net10.0/MyAspNetCoreApp.dll

Let's check with the curl command to see if the Hosting Startup assembly was really loaded and the middleware was added.

$ curl -i http://localhost:5000/
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Sat, 14 Feb 2026 04:10:47 GMT
Server: Kestrel
Transfer-Encoding: chunked
X-Custom-Header: MyCustomValue

Hello World!

Looking at the curl output above, we can see that the "X-Custom-Header" response header has been added. This confirms that the Hosting Startup assembly MyHostingStartup.dll was loaded and its IHostingStartup.Configure(IWebHostBuilder builder) method was called.

Conclusion

Using the Hosting Startup feature, we can add middleware to an existing ASP.NET Core Web application without rebuilding it. The middleware is implemented in a separately-built assembly and added at runtime.

The basic steps to implement a Hosting Startup assembly are to build a class library that contains a class implementing the required interfaces and the assembly attribute following the conventions, and then start the ASP.NET Core Web application with the assembly name specified in the ASPNETCORE_HOSTINGSTARTUPASSEMBLIES environment variable.

However, because of how .NET application execution works, we need to explicitly specify assembly dependencies along with the location of the assembly files in a JSON file. The Hosting Startup assembly is no exception. We need to declare the dependency in a JSON file from the perspective of the target ASP.NET Core Web application and specify that JSON file in the DOTNET_ADDITIONAL_DEPS environment variable.

So in short, the Hosting Startup feature lets us add middleware to an existing ASP.NET Core Web application to extend its functionality. I think this is a feature that opens up many possibilities depending on your ideas. Please give it a try!

Tired of Accidentally Zipping Build Artifacts? Try "dnx zipsrc"!

jsakamoto — Fri, 09 Jan 2026 12:45:56 +0000

The Problem Every Developer Knows

We've all been there. You need to quickly share your project with a colleague, attach it to a support ticket, or upload it somewhere. You right-click, select "Compress to ZIP," and then... wait. Why is it taking so long? Why is the file 500MB?

Oh right. You just zipped node_modules. Or bin/obj. Or that massive .nuget cache.

Now you have to manually exclude folders, or worse, copy everything to a new location first. What should take 5 seconds becomes a 5-minute ordeal.

Introducing `dnx zipsrc` 🎉

dnx zipsrc is a smart CLI tool that creates zip archives containing only your source code. It automatically excludes build outputs, dependencies, and other artifacts you don't want to share.

The best part? With .NET 10's new dnx command, you don't even need to install it first!

dnx zipsrc

That's it. One command. Your source code is now neatly packaged in a zip file, ready to share.

How It Works

Smart Exclusion with .gitignore

Instead of reinventing the wheel, dnx zipsrc leverages your existing .gitignore patterns. If your project has a .gitignore file, those rules are automatically honored.

No .gitignore? No problem! The tool falls back to sensible defaults equivalent to dotnet new gitignore, covering common patterns for:

C#/.NET: bin/, obj/, *.user, *.suo, .vs/
Node.js: node_modules/, dist/, .cache/
And many more: Build outputs, IDE files, logs, etc.

It even respects .gitignore files in subdirectories and correctly handles negation patterns (!important-file.txt).

Under the hood, this is powered by GitignoreParserNet, a robust .gitignore parser library for .NET. It handles all the edge cases so I didn't have to reinvent that wheel!

Intelligent Naming

Don't want to think about file names? Neither do I.

When you run dnx zipsrc without specifying an output name:

If your folder contains a .sln or .slnx file, the zip is named after that solution
Otherwise, it uses the folder name

Already have a MyProject.zip? The tool automatically creates MyProject (2).zip instead of overwriting.

Usage Examples

Zip the Current Directory

dnx zipsrc

Zip a Specific Directory

dnx zipsrc -d ./src/MyAwesomeApp

Specify a Custom Output Name

dnx zipsrc -d ./src/MyApp -n ./archives/MyAppSource
# Creates: ./archives/MyAppSource.zip

The .zip extension is automatically added if you forget it!

Why `dnx` Instead of `dotnet tool install`?

.NET 10 introduced the dnx command, which lets you run .NET global tools without installing them first. It downloads, caches, and runs the tool in one step.

This means:

✅ No cluttering your global tools list
✅ Always runs the latest version
✅ Works immediately on any machine with .NET 10+
✅ Perfect for one-off tasks like zipping source code

Of course, if you use it frequently, you can still install it the traditional way:

dotnet tool install -g zipsrc
zipsrc -d ./MyProject

Real-World Use Cases

📧 Email attachments: Share clean source code without the bloat
🎫 Support tickets: Attach minimal reproductions to bug reports
📚 Teaching: Distribute starter projects to students
💾 Quick backups: Archive your work before major refactoring
🤝 Code reviews: Share snapshots with teammates who aren't on your repo

"But Wait, Doesn't This Already Exist?"

You're right! Tools for zipping source code aren't new. There are already some options out there:

Zipper Extension - A Visual Studio add-in that can zip your solution
dotnet-zip-source - A .NET global tool with similar goals

So why create yet another tool? Here's what motivated me:

1. Naming Conventions and Output Location

Existing tools often have opinionated defaults for where the zip file goes and what it's named. I wanted control over the naming logic—specifically, automatically using the solution file name when available, and placing the output exactly where I expect it.

2. No Auto-Incrementing for Repeated Runs

When I zip a project multiple times (maybe after making changes), I don't want to manually rename files or have the previous archive overwritten. dnx zipsrc automatically appends (2), (3), etc., so you never lose a previous archive.

3. Better Default Ignore Rules

When there's no .gitignore file, some tools have minimal or no exclusion rules. dnx zipsrc falls back to comprehensive defaults equivalent to dotnet new gitignore, which covers a much wider range of common artifacts out of the box.

These might seem like small things, but when you're zipping projects multiple times a day, these little conveniences add up!

Requirements

.NET SDK 10.0 or later

Get Started Now!

Ready to stop accidentally zipping node_modules? Just run:

dnx zipsrc

Check out the project on GitHub: jsakamoto/dnx-zipsrc

Install from NuGet: zipsrc on nuget.org

Have questions or feedback? Drop a comment below or open an issue on GitHub. Happy zipping! 🗜️

Acknowledgments

Special thanks to Guiorgy for creating GitignoreParserNet. This library handles all the complex .gitignore parsing logic, making it easy to build tools that respect ignore patterns correctly. Open source makes building tools like this so much easier! 🙏

This article was written with the help of VS Code and GitHub Copilot (Claude Opus 4.5 model). As a Japanese developer who is not a native English speaker, I appreciate your understanding if there are any awkward expressions!

How to Quickly Test Your Blazor App on a Real Smartphone

jsakamoto — Mon, 10 Nov 2025 08:50:23 +0000

Using Dev Tunnels to Access Your Development App from Your Phone via the Internet

Sometimes I want to test my Blazor application on my phone while developing it. Of course, if I just need to check the layout, I can use the device emulation feature in the developer tools in desktop browsers. However, there are times when testing on an actual device is faster. Additionally, I sometimes need to use browser APIs that are difficult to test without a physical device.

In such cases, if you are developing with Visual Studio on Windows, you can use a feature called "Dev Tunnels." With Dev Tunnels, you can temporarily relay and publish HTTP traffic from your Blazor application, running on localhost, to the Internet. Let me explain this more. When you run your app with Dev Tunnels through Visual Studio, a unique public URL is created on the Internet. When you open this URL in a browser on your smartphone (which has Internet access), HTTP requests to that Internet URL are relayed to your Blazor application running on localhost. It's like creating a tunnel from the Internet to localhost.

You'll need a GitHub or Microsoft account to use Dev Tunnels.

How to Use Dev Tunnels

Here are the steps to use Dev Tunnels.

Creating and Enabling a Dev Tunnel

First, start Visual Studio and open your Blazor application project.

Next, open the dropdown list next to the Debug Execution Tool button and select the [Dev Tunnels] item. If you have never used the Dev Tunnels feature before, you will see a screen like the one below, so please select [Create a Tunnel...] shown in the red circle below. If you have already created a Dev Tunnel before, the name of the existing Dev Tunnel should be listed here. In that case, you can click and select that existing Dev Tunnel name instead of creating a new one.

When you click [Create a Tunnel...], a dialog box will open to create a new tunnel. Here, you need to specify the following settings.

Select the GitHub account or Microsoft account to use for creating the tunnel
Specify the tunnel name so you can distinguish each tunnel in your Visual Studio work (In the example below, I specified "default" as the tunnel name)
Select the expiration period of the tunnel URL (In the example below, I selected "Temporary", which creates a new URL each time you restart Visual Studio)
Select whether to require authentication when accessing the published tunnel URL (In the example below, I selected "Private", which denies access without authentication)

After specifying all of these, click [OK].

Then, a message will appear showing that a new "Dev Tunnel" has been created and that this Dev Tunnel is now set to be used when running this Blazor application project.

Checking Dev Tunnel Active Status and Running the App

When you reopen the dropdown list next to the Debug Execution tool button in Visual Studio again, you can see that the Dev Tunnel "default" you just created is selected and active, as shown below.

In this state, press Ctrl + F5 or click the "Run without debugging" tool button to run this Blazor application. (Of course, you can also run it with debugging.)

After waiting a moment, the browser will launch and open the URL published to the Dev Tunnel. If you selected [Private] for [Access] when creating the Dev Tunnel, you will be prompted to authenticate with your GitHub account or Microsoft account, then complete the authentication as needed.

When accessing for the first time, a confirmation message will appear
asking whether you want to proceed. Of course, in this case, you know that this is access to the Dev Tunnel you created yourself. So click [Continue] to proceed.

Then, your Blazor application, which is under development and should be running on localhost, becomes accessible via a public URL on the Internet.

Accessing from Your Smartphone via the Internet

Now, all you need to do is open this Dev Tunnel public URL in your smartphone browser. That's it. Modern web browsers have a feature that allows you to share the URL of the page you are viewing as a QR code. You can use this feature to open it on your smartphone. (The screenshot below shows how to generate a QR code in the Microsoft Edge browser by right-clicking on the page and selecting it from the menu.)

Deactivating the Dev Tunnel

To stop running via the Dev Tunnel, reopen the dropdown list next to the Debug Execution tool button again and click [None] from the [Dev Tunnels] item.

Conclusion

Review and Precautions

As explained above, if you are using Visual Studio on Windows, you can make your Blazor application under development accessible via a URL on the Internet by using the Dev Tunnels feature. Since you can also access this Dev Tunnel URL from your smartphone, you can easily test your app. However, please be careful from a security perspective. This means you are allowing access and intrusion from the Internet to the program running in your local development environment. If you set the access to private when setting up the Dev Tunnel, you can protect it so that it can only be accessed with your GitHub account or Microsoft account. This provides a certain level of safety.

If You Are Not Using Visual Studio or Not on Windows

If you are not using Visual Studio, Visual Studio Code also has the same feature. It's called "Port forwarding." You can use that. Additionally, the Dev Tunnels feature itself is actually a service of Microsoft Azure, Microsoft's public cloud service. A CLI tool called "devtunnels" is provided for creating, activating, and managing Dev Tunnels. With the "devtunnels" CLI, you can use Dev Tunnels in any environment. Of course, it seems to be available not only on Windows but also on macOS and various Linux distributions.

Compared to Other Methods

Besides using Dev Tunnels or similar methods (like ngrok), you can also test your Blazor application on your smartphone by connecting your smartphone to the same LAN as your development PC, configuring the Blazor application to listen on a hostname or external IP address instead of localhost, adjusting the firewall settings of your development PC's OS, and so on. However, the steps I just wrote here are quite complicated, right?

In that regard, although you need to be careful when using it, if you know about the Dev Tunnels feature, testing your Blazor application on an actual device becomes much easier and more convenient. Let's use it well.

Creating chip-tuned square & triangle wave sounds on web browsers with Blazor WebAssembly

jsakamoto — Sat, 31 Dec 2022 12:37:51 +0000

"SoundMaker" Library

I found an interesting post in my Twitter timeline last month.

// Detect dark theme var iframe = document.getElementById('tweet-1588806133275594752-736'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1588806133275594752&theme=dark" }

The tweet introduced a library that allows us to create chip-tuned square & triangle wave sounds and save them to a .wav file by only C#, "SoundMaker". (The GitHub repository URL is below.)

AutumnSky1010 / SoundMaker

You can do The following content with this library. 1. make the sound of chiptune(old game sound) 2. export sound to a file of wave format.

🗺️言語(Language)

🎵概要

本ライブラリを用いると、以下の事が可能です。

チップチューンサウンド？を作成する
waveファイルにサウンドを書き込む

📑ドキュメント

Wiki

⛰️要件

.NET 8 以降

⏬インストール方法

NuGet

SoundMaker

🎶簡単な使い方

using SoundMaker
using SoundMaker.Sounds;
using SoundMaker.Sounds.Score;
using SoundMaker.Sounds.SoundChannels;
using SoundMaker.WaveFile;

namespace YourNamespace;
public static class YourClass
{
    private static void Main()
    {
        // サウンドの形式を作成する。
        var builder = FormatBuilder.Create()
            .WithFrequency(48000)
            .WithBitDepth(16)
            .WithChannelCount(2);

        var soundFormat = builder.ToSoundFormat();
        StereoWave wave = MakeStereoWave(soundFormat);

        // ファイルに書き込む。
        var sound = new SoundWaveChunk(wave.GetBytes(soundFormat.BitRate));
        var waveFileFormat = builder.ToFormatChunk();
        var writer = new WaveWriter(waveFileFormat, sound);
        string filePath = "sample.wav";
        writer.Write(filePath);
    }

    private static StereoWave MakeStereoWave(SoundFormat format)
    {
        // 一分間の四分音符の個数
        int tempo = 100;
        // まず、音のチャンネルを作成する必要がある。
        // 現段階では矩形波、三角波、疑似三角波、ロービットノイズに対応している。
        var rightChannel = new SquareSoundChannel(tempo, format, SquareWaveRatio.Point25, PanType.Right)
        {
            // ISoundComponentを実装したクラスのオブジェクトをチャンネルに追加していく。
            // 現段階では普通の音符、休符、タイ、連符を使うことができる。
            new Note(Scale.C, 5, LengthType.Eighth, isDotted: true),
            new Tie(new Note(Scale.D, 5, LengthType.Eighth), LengthType.Eighth),
            new Tuplet(GetComponents(), LengthType.Quarter)
        };
        var rightChannel2 = new SquareSoundChannel(tempo, format, SquareWaveRatio.Point125, PanType.Right)
        {
            new Note(Scale.C, 4, LengthType.Eighth, isDotted: true),
            new Note(Scale.D, 4, LengthType.Quarter),
            new Rest(LengthType.Quarter)
        };
        var leftChannel = new

…

View on GitHub

The "SoundMaker" is distributed under the MIT license.

When I saw that tweet, one idea came to my mind. He said the "SoundMaker" is built on 100% pure C#. If it is true, we should also be able to run the "SoundMaker" on web browsers powered by Blazor WebAssembly. So I tried it.

Implement it

There is a simple example code on how to use the "SoundMaker" to create and save square & triangle wave sounds on the README document in the GitHub repository of the "SoundMaker". I created a new Blazor WebAssembly project and copied that example code, almost as is, into a @code { ... } code block of a Razor component file (.razor) in that Blazor WebAssembly project.

The outline of the code is like this:

...
@code {
  private static string GenerateWavFile()
  {
    // Specify sound format, and generate sound waves.
    var soundFormat = new SoundFormat(SoundMaker.Sounds.SamplingFrequencyType.FourtyEightKHz, SoundMaker.Sounds.BitRateType.SixteenBit, SoundMaker.Sounds.ChannelType.Stereo);
    var wave = MakeStereoWave(soundFormat);

    // Save it into a file.
    var sound = new SoundWaveChunk(wave.GetBytes(soundFormat.BitRate));
    var waveFileFormat = new FormatChunk(SoundMaker.WaveFile.SamplingFrequencyType.FourtyEightKHz, SoundMaker.WaveFile.BitRateType.SixteenBit, SoundMaker.WaveFile.ChannelType.Stereo);
    var writer = new WaveWriter(waveFileFormat, sound);
    var filePath = "sample.wav";
    writer.Write(filePath);

    return filePath;
  }

  private static StereoWave MakeStereoWave(SoundFormat format)
  {
    // Number of quarter notes per minute.
    var tempo = 100;
    ...
    // can mix with StereoMixer class. 
    return new StereoMixer(channels).Mix();
  }
}

But, wait, wait.

If you look closely at the above code, you will find that the program is doing a write to a file. Here is an excerpt.

private static string GenerateWavFile()
{
    // Save it into a file.
    ...
    var filePath = "sample.wav";
    writer.Write(filePath);
    ...

This program is a Blazor WebAssembly program that is loaded into a web browser and executed in its sandbox. So what happens when you do this write to a local file? Of course, it would not be written to the local storage of the device on which the web browser is actually running. So, would this process fail with an exception? That said, the WaveWriter class in the SoundMaker library apparently does not have the ability to write to an arbitrary Stream, and there is no way to write a .wav file other than specifying the file path. Is this that the "SoundMaker" library is not available on Blazor WebAssembly, unfortunately?

Writing to local files in Blazor WebAssembly apps will be a success

In fact, writing to local files in Blazor WebAssembly apps will be a success!

Blazor WebAssembly uses Emscripten as its foundation to generate WebAssembly code generation, and because of this, the on-memory filesystem simulation (virtual file system) provided by Emscripten is also available in Blazor WebAssembly! (For more information, please refer to the following links.)

emscripten.org

Therefore, writing a .wav file into the local file system by the WaveWriter class in the "SoundMaker" library will be successful. The written file exists on the virtual file system in the web browser's WebAssembly process memory space. And, we can read the .wav file written to the virtual file system into an array of byte, and can do anything, such as playing back, downloading, etc., from the web browser.

Real example

I've publicly pushed the Blazor WebAssembly project source code I explained above on the following GitHub repository.

sample-by-jsakamoto / Blazor-SoundMaker-on-BlazorWasm

Demonstration of the "SoundMaker" on Blazor WebAssembly

And, this example has been deployed on GitHub Pages by a GitHub Actions script. You can try it immediately by following the next link.

sample-by-jsakamoto.github.io

The screenshot below shows how the above link looks when opened.

When you click the "Generate Sound and Play" button, the sound generated on the fly by the C# program I explained above will be played back. When you click the "Generate Sound and Download" button, the .wav file will be downloaded instead of playing back it. Please remember the generating sound process runs on your web browser! I confirmed that the example site can also be run on Apple mobile devices. I could generate the chip-tuned sound with that example site and play it on my iPhone SE2. That's amazing!

Moreover, as I already mentioned above, due to the source code of the example site being hosted on the GitHub repository, when you create a new "GitHub Codespace" for this repository, like the following screenshot,

As shown in the screenshot below, you can edit and run the code ("dotnet run" command execution) of this example site in a web browser immediately, without the need to set up a local development environment on your PC!

Conclusion

Now you can easily enjoy chip-tuned sound generation programming with "SoundMaker" anytime, anywhere, as long as you are connected to the Internet and use any device that supports GitHub Codespaces! That's really amazing!

Thanks to the author of the "SoundMaker", AutumnSky1010, for publishing such a great library as an Open Source!

Happy Coding :)

How to install a ".xpi" browser extension through remote session of Selenium WebDriver C# binding for testing it.

jsakamoto — Mon, 31 Oct 2022 12:57:20 +0000

Prologue

The "GeckoDriver" (a.k.a "FirefoxDriver"), one of the WebDriver to remote-operate Web browsers, provides us with the ability to install a ".xpi" Mozilla browser extension file in its remote-operation session.

This feature is convenient for conducting End-to-End tests for a ".xpi" Mozilla browser extension.

Unfortunately, I ran into some pitfalls when I tried to do that. So I'll explain the best way to install a ".xpi" file via Selenium GeckoDriver in this article.

By the way, I'm a .NET guy, so I'll explain based on the C# binding of Selenium.

Don't use the "FirefoxProfile.AddExtension"

First, you might notice that there is the "AddExtension()" method in the "FirefoxProfile" class. The name of that method seems good to use the installing an extension.

However, unexpectedly, the "FirefoxProfile.AddExtension()" method didn't work correctly. I don't know why this method doesn't work, but anyway, I've never succeeded in installing an extension with that method.

// ⚠️ Don't do this.
var profile = new FirefoxProfile();
profile.AddExtension(pathToXpiFile);

Use the "FirefoxDriver.InstallAddOnFromFile"

Instead, please use the "InstallAddOnFromFile()" method of the "FirefoxDriver". The argument of this method is a path to a ".xpi" file. The "FirefoxDriver.InstallAddOnFromFile" method will work fine as we expected, and there is nothing too difficult.

// 👍 Do this.
using var driver = new FirefoxDriver();
driver.InstallAddOnFromFile(pathToXpiFile);

The "FirefoxDriver" class also exposes the "InstallAddOn()" method, and this method accepts the binary contents of the browser extension as a base64 encoded string.

Don't use the "FirefoxProfile.SetPreference"

Usually, during the End-to-End testing of a browser extension, the ".xpi" browser extension file is not signed because it is in the development phase before submitting it for store review. But web browsers usually reject installing an unsigned browser extension file. So we have to disable this restriction of browsers during the testing.

To do that, you may find a way to set the preference "xpinstall.signatures.required" to false from the Internet search result.

However, the code below that uses the "SetPreference" method of the "FirefoxProfile" class will never work.

// ⚠️ Don't do this.
var profile = new FirefoxProfile();
profile.AddExtension(pathToXpiFile);

If you do that, you will run into an exception like this:

"System.ArgumentException: Preference xpinstall.signatures.required may not be overridden: frozen value=False, requested value=False"

Use the "FirefoxOptions.SetPreference"

Instead, please use the "SetPreference" method of the "FirefoxOptions" class, not of the "FirefoxProfile" class. This way will work fine.

// 👍 Do this.
var option = new FirefoxOptions();
option.SetPreference("xpinstall.signatures.required", false);
using var driver = new FirefoxDriver(option);

Don't use the normal edition of Firefox

After doing the above step, you will still see an unexpected error at runtime like the bellow, even though you set the "xpinstall.signatures.required" preference to false:

"Could not install add-on: ....xpi: ERROR_SIGNEDSTATE_REQUIRED: The addon must be signed and isn't."

Because Firefox Browser of the normal edition is designed as it never allows us to install an unsigned ".xpi" browser extension file.

Use the Developer or Enterprise edition of Firefox

Instead, you must install the Developer Edition or Enterprise Edition of Firefox web browser on your PC for this scenario.Please follow the link below for more details about the Firefox Developer Edition.

https://www.mozilla.org/firefox/developer/

Conclusion

I'm not sure why there are some pitfalls that are hard to notice to install a ".xpi" browser extension file via Selenium WebDriver. So I hope this article will save the time of other developers.

You can see the entire sample code of this article in the following GitHub repository.

https://github.com/sample-by-jsakamoto/InstallAddOnTestOnSeleniumAndFirefox

Have a nice coding :)

Why can't your Blazor WebAssembly PWA with offline support update even though you reload it?

jsakamoto — Wed, 07 Sep 2022 06:44:51 +0000

😥 Introduction

Please imagine the case that you have a Blazor WebAssembly PWA site that supports offline mode, and you've been opening that PWA by a web browser.
If you published a new version of that PWA, you might want to verify it, I guess. In this case, you will reload the page on that web browser.

However, you might never see the contents of the new version unexpectedly even though you hard-reload it. Disabling cache via the browser's developer tools window or clicking the "Empty cache and hard refresh" menu item from right-clicking the browser's reload icon button doesn't have any effect at all.😱

To enable the new version of that PWA, you must close the browser's "all" tabs that is opening that PWA site once. After closing them once and reopening that PWA site, you will see the contents of the new version of that PWA.

🤔 This behavior is "by design"

This is by design come from web browser's specifications and from the default implementation of the service worker JavaScript that is generated by the project template of Visual Studio or .NET SDK.

First of I should explain is a service worker will be updated to a new one "atomically". When a web browser detects a new version of service worker JavaScript code, a web browser will load it but makes it remain in the "waiting to activate" status. This is a standard web platform behavior. A service worker is a process shared by all browser tabs and control caching mechanism offline support. Therefore if its update mechanism is not "atomically", it will cause critical confusion, such as different tabs of the same PWA different behave or the page contents of the current version being partially contaminated by the new versions' contents.

⚙️ Update to the next version without closing all tab

However, in some cases, you might need to make the PWA site able to update to the next version immediately without closing all tabs.

In this case, the better practice is notifying the next version is ready to users via its user interface. And if users respond to that UI to update to the next version, your service worker can be implemented to do that via the skipWaiting() method.

Unfortunately, the implementation will be complicated a little.

To be able to invoke the skipWaiting() method in the service worker process from outside of the service worker process, such as user interaction code, implement service worker JavaScript to handle the specific "message" and call the skipWaiting() method in that message handler.
Implement the user interface that will show a message such as "The next version is ready" and a button such as "Update now". And make that UI send the specific message to the service worker process to invoke the skipWaiting() method of the service worker process when users click the button.
Handle the promise callback of the navigator.serviceWorker.register method.
if there is a "waiting" service worker process (that is the new version), then notify the next version is ready to users via UI.
handle the updatefound event of the service worker registration object. If the updatefound event is fired, handle the statechange event of the service worker process.
If the statechange event of the service worker process is fired, then check the current status of that service worker process. If the status is "installed", then notify the next version is ready to users via UI.
If the status is "activated", that means users respond to the UI, and the skipWaiting() method in the service worker process is invoked. Therefore reload the current page by calling the window.location.reload() method.

...Please don't misunderstand me, but are you keeping up with this explanation? 😅

🎉 The "Blazor PWA Updater" NuGet package and component

Fortunately, you don't need to implement all of the code above by yourself. Instead, you can use the "Blazor PWA Updater" NuGet package and its component.

Install the Toolbelt.Blazor.PWA.Updater NuGet package.
Register a "PWA updater" service to a service provider at startup.
Place a <PWAUpdater> component somewhere in your Blazor PWA
Add the "SKIP_WAITING" message handler to the service-worker.published.js file and invoke the skipWaiting() in that message handler.
Replace the script element <script>navigator.serviceWorker.register('service-worker.js');</script> inside of the index.html to
<script src="_content/Toolbelt.Blazor.PWA.Updater.Service/script.min.js"></script>.

That's all. After the implementation above, you will get the ability on your Blazor PWA to update to the new version immediately via user interaction.

You can also customize the appearance of the <PWAUpdater>, such as notification text, button caption, text color, background color, sizes, and position.

If you don't prefer the appearance and behavior of the <PWAUpdater> at all, you can also implement the user interface from scratch with minimal effort.

The IPWAUpdaterService service lived in the Toolbelt.Blazor.PWA.Updater.Service NuGet package is exposing NextVersionIsWaiting event and SkipWaitingAsync() method. So you can build your user interface with this service by yourself.

For more details, please visit the GitHub repository of the "Blazor PWA Updater" and read the README of it.

jsakamoto / Toolbelt.Blazor.PWA.Updater

Provide "Update Now" UI and feature to your Blazor PWA that appears when the next version of one is available.

Blazor PWA Updater

📝 Summary

Provide "Update Now" UI and feature to your Blazor PWA that appears when the next version of one is available.

Supported platforms

.NET 8, 9, or later. Both Blazor Server and Blazor Assembly are supported.

🤔 Backgrounds

Typically, a service worker of PWA is never updated even when updated contents have been deployed to a server, even if you reload the page of that PWA. After the user has navigated away from the PWA in all tabs, updates will complete. This is not specific to Blazor, but rather is a standard web platform behavior.

For more detail, please see also the following link on the Microsoft Docs site.

"ASP.NET Core Blazor Progressive Web App (PWA)" | Miceooft Docs

However, sometimes, a site owner or a developer may want updates completed as soon as possible. In that case, all we can do is notify the user…

View on GitHub

⚠️ Notice

Please keep in your mind that kind of these updating notifications sometimes makes users feel annoyed, especially if it happens so often.

If you don't have enough reason to implement such a notification user interface to update the new version immediately, it will be better to keep it by the default implementation.

❤️Happy coding :)

3 reasons why I've created yet another library for the downloading on Blazor apps

jsakamoto — Wed, 29 Jun 2022 13:42:52 +0000

Introduction

A few days ago, I created a library that provides the ability to implement a download feature on Blazor apps and published it on nuget.org.

However, maybe you already know we can easily find other libraries on nuget.org that provide the same feature, and those libraries were already published a few years ago.

Then, why did I create yet another new library even though there are already the same kinds of stuff?

There are three reasons why I did it.

1. They are using "eval()"

One of the reasons is that those other libraries are using the eval() JavaScript function to load a helper JavaScript code into a web browser.

However, the strict level of JavaScript code has recently risen, so I often see the websites that prohibit using the eval() JavaScript function by the Content-Security-Policy (CSP) HTTP header.

So I'd felt I wanted to get the library that doesn't use the eval() JavaScript function.

2. They are as a service

Another reason is that those other libraries provide its feature as a "service". In this context, the "service" is the object that will be created from a DI container. So those library users have to register the type of service in that library to a DI container at the startup code inside their "Program.cs" manually.

But I felt it is boring to add those startup ceremony codes.

3. They are optimized performce

The last reason is that those other libraries include tons of codes to optimize the performance of the downloading feature to the limit using the undocumented API. Those great work and code must be deserved to prise.

But it has increased the size of the library. And I feel ordinary users and use cases don't pursue the speed of the downloading operation. And I think the default implementation of transferring a byte array for the downloading operation on .NET 6 or later is fast enough.

So I'd felt I wanted to get a simple but small package size library.

So I created a new one by myself

So I created a new one by myself.

"Toolbelt.Blazor.InvokeDownloadAsync"

https://www.nuget.org/packages/Toolbelt.Blazor.InvokeDownloadAsync

1. 100% `eval()` free

It uses the standard InvokeAsync("import",...) method calling to import helper JavaScript code that is written as an ES module. 100% eval() free. (Instead, it can not use for apps on .NET Core 3.x.)

2. Minimal setup

It is an extension method for the IJSRuntime interface. You can use the downloading feature immediately if there is a JavaScript runtime object. You don't need to write any code in your startup.

3. Small package size

It doesn't have massive code optimized for performance. It is simple and small content size.

Usage

Once you added the package to your Blazor app project,

dotnet add package Toolbelt.Blazor.InvokeDownloadAsync

you can use the InvokeDownloadAsync() extension method for IJSRuntime interface to start to download the contents bytes, like this:

@using Toolbelt.Blazor.Extensions
@inject IJSRuntime JSRuntime
...
@code
{
  private async Task BeginDownloadAsync()
  {
    ...
    // 👇"InvokeDownloadAsync()" ex method
    //   starts to download the contents bytes.
    await this.JSRuntime.InvokeDownloadAsync(
      "Foo.png",
      "image/png",
      pictureBytes);
  }
}

That's all. 👍

Conclusion

These are the reasons why I have created a new library, even though we are halfway through 2022.

Happy coding! :)

Run JavaScript unit tests for a Razor Class Library on Visual Studio 2022 Test Explorer

jsakamoto — Fri, 06 May 2022 12:42:47 +0000

Introduction

Since Visual Studio 2022, JavaScript unit tests have been able to be discovered and run on Test Explorer of Visual Studio easily. That is much more convenient for developing Razor Class Library for Blazor. When I was developing a Razor Class Library that contains JavaScript helper code for use from C# code, I often wanted to execute unit tests for both C# code and JavaScript code. Visual Studio 2022 has made me able to do it.

How to do it?

Suppose you already have a unit test project for a Razor Class Library, particularly for the C# code. In that case, you can make that unit test project do tests for JavaScript code additionally just by adding a few steps like below.

1) Add the <JavaScriptTestFramework> property in your unit test project file (.csproj) to specify which JavaScript unit test framework you use. And also, add the <JavaScriptTestRoot> property to specify the relative path where unit test codes are placed.

The following example shows using "mocha", one of the well-known JavaScript test frameworks.

<!-- A .csproj file of your unit test project -->
<Project Sdk="Microsoft.NET.Sdk">
  ...
  <PropertyGroup>
    <JavaScriptTestFramework>Mocha</JavaScriptTestFramework>
    <JavaScriptTestRoot>tests\</JavaScriptTestRoot>
  </PropertyGroup>
  ...

2) Configure your JavaScript unit test environment. For example, to use "mocha", execute the following commands in a terminal console on the test project directory.

(As a premise, Node.js must be installed in your environment.)

> npm init -y
> npm install --save-dev mocha

And please remember to exclude the "node_modules" folder from the unit test project like this:

<!-- A .csproj file of your unit test project -->
<Project Sdk="Microsoft.NET.Sdk">
  ...
  <!-- 👇 exclude the "node_modules" folder for any purpose. -->
  <ItemGroup>
    <Compile Remove="node_modules\**" />
    <EmbeddedResource Remove="node_modules\**" />
    <None Remove="node_modules\**" />
  </ItemGroup>
  ...

3) Write your unit test code according to the JavaScript unit test framework you use.

// ./tests/fooTest.js

const assert = require("assert");

describe("fooTest", function () {
    it('foo is bar', function () {
        assert.ok("this test will alwasy pass.");
    })
});

After doing that, you will see those JavaScript unit tests on the Test Explorer, and you can run those unit tests in Visual Studio's usual way.

For more information, please see also the following link to official document site.

https://docs.microsoft.com/visualstudio/javascript/unit-testing-javascript-with-visual-studio?view=vs-2022&tabs=mocha

Write test codes by TypeScript

Of course, we can write those JavaScript unit test codes by TypeScript. For example, to do that, execute the following steps.

1) Install the "Microsoft.TypeScript.MSBuild" NuGet package into the unit test project. One of the ways to do that is by executing the dotnet add package command on the unit test project directory like this:

> dotnet add package Microsoft.TypeScript.MSBuild

2) Add type definition files (.d.ts) for TypeScript code that you need, like this:

> npm install --save-dev @types/mocha @types/node

3) Add the "tsconfig.json" file with the following contents into the unit test project directory to configure the behavior of the TypeScript compiler. (Please tweak the "target" configuration according to your needs.)

// ./tsconfig.json
{
  "compilerOptions": {
    "target": "ES2017",
    "module": "CommonJS",
    "strict": true
  },
  "compileOnSave": true
}

After doing that, you can write unit test codes by TypeScript like this:

// ./tests/fooTest.ts

import * as assert from "assert";
import { describe, it } from "mocha";

describe('fooTest', function () {
    it('foo is bar', function () {
        assert.ok("this test will always pass.");
    })
});

Problem - incompatible module system

By the way, I also write a helper JavaScript code inside a Razor Class Library ― that will be a target of unit tests in this scenario ― by TypeScript.

And the type of module system of them must be "ES Module", not "CommonJS", because those JavaScript codes will be invoked from Blazor applications by using IJSRuntime.InvokeAsync<IJSObjectReferense>("import", <the path of .js file>).

For example, the tsconfig.json in a Razor Class Library project will be like the following configuration.

// tsconfig.json in a Razor Class Library project
{
  "compilerOptions": {
    ...
    "module": "ES2015", // 👈 Use the ES Module system, not CommonJS.
    ...

And the compiled JavaScript code, for example, the "CatClass", will be the following code.

// catClass.js in the Razor Class Library project
export class CatClass {
    meows() {
        return "Meow!!";
    }
}

But unfortunately, "mocha" doesn't work with ES Module mode on Visual Studio expectedly.
I will omit the details, but anyway, you must configure unit test codes for "mocha" that are available for Visual Studio Test Explorer to CommonJS mode.

For example, if you have the test code like below that imports the "catClass.js" as a test target,

// ./tests/catClassTest.ts in the unit test project
...
import { CatClass } from "../../RazorClassLibrary1/catClass";

describe('CatClass', function () {

    it('meows', function () {
        const cat = new CatClass();
        assert.equal('Meow!', cat.meows());
    });
});

you will run into the error "SyntaxError: Unexpected token 'export'" when Visual Studio tries to detect unit tests like the above.
(In fact, "mocha" itself can work with ES Module mode since ver.9. But there is no way to enable ES Module mode of "mocha" when Visual Studio detects or runs tests so that it will fail.)

What should I do?

My solution - it's complicated but works

Fortunately, those my JavaScript codes are all written by TypeScript source codes.
So I decided to resolve that problem by compiling all TypeScript files by the "CommonJS" module mode into under the unit test project folder, not only files for the unit test but also for files for the test target.

Let's take a look at what I did.

First of all, I placed the unit test TypeScript files in the root folder of the unit test project.
This is important for compiling at once TypeScript files, including both unit test code and library code (test target).
Of course, I also tweaked the path of importing the test target module (TypeScript file) in the unit test TypeScript files, like this:

// move the ./tests/catClassTest.ts to ./catClassTest.ts
//   in the unit test project
...

// 👇 Fix the path of importing the test target module.

//import { CatClass } from "../../RazorClassLibrary1/catClass";
import { CatClass } from "../RazorClassLibrary1/catClass";
...

Next, I added two options to the configuration of the TypeScript compiler "tsconfig.json" in the root folder of the unit test project.
One of them is adding the folder of the Razor Class Library (it is the test target) to the compile target folder.
And another one is the configuration of the output folder explicitly to follow the <JavaScriptTestRoot> property value in the unit test project file (.csproj).

// ./tsconfig.json in the unit test project
{
  "compilerOptions": {
    ...
    // 👇 Add these two options.
    "rootDirs": [ "./", "../RazorClassLibrary1" ],
    "outDir": "./tests",
    ...

After I made the above changes and rebuilt the entire solution, I got the result like the following figure.

Finally, I've been able to run the JavaScript unit tests properly on Visual Studio's Test Explorer! 🎉

Conclusion

The ability to run unit tests both for C# and for JavaScript at once on Visual Studio Test Explorer UI is very convenient for me when developing a Razor Class Library for Blazor.

But the JavaScript test framework "mocha" can work only in CommonJS module mode on Visual Studio Test Explorer, even though the module type of the test target JavaScript code is ES Module.

Fortunately, I always write JavaScript code by TypeScript, so I resolved that problem by compiling test target TypeScript files to JavaScript files twice with different module modes ("ES Module" and "CommonJS").

The sample code has been published on the GitHub repository at the following link:

https://github.com/sample-by-jsakamoto/Runs-JavaScript-tests-on-Visual-Studio-2022-Test-Explorer

However, actually, I'm not sure whether my solution is the best.
Really Is there no way to run "mocha" in ES Module mode on Visual Studio Test Explorer?
Or else another JavaScript framework, such as Jest, Jasmine, etc., might allow me to run it in ES Module mode?

If you have a better solution or idea, I appreciate it if you share that.

Learn, Practice, Share. :)

Use Selenium to automate IE mode in Microsoft Edge on Windows 11

jsakamoto — Mon, 21 Mar 2022 12:55:22 +0000

Introduction

Today, the latest stable version of Windows OS (It is Windows 11 as of the writing of this article) no longer supports Internet Explorer as a standalone application.

However, Internet Explorer hasn't died yet.

Internet Explorer is still alive inside Microsoft Edge browser as "IE mode".

So there is still worth automating IE mode in Microsoft Edge for E2E testing by "Selenium" with Internet Explorer Driver.

There is even official Microsoft documentation for automating IE mode in Microsoft Edge.

https://docs.microsoft.com/en-us/microsoft-edge/webdriver-chromium/ie-mode

In some cases, the official document is not enough...

However, in some cases, you may run into runtime errors at automating IE mode in Microsoft Edge browser by Selenium even you certainly follow the steps in the official document.

In my case, I was using Selenium .NET binding with C# on Windows 11, I had to do additional two steps as the following list to make it works fine:

Set the IgnoreZoomLevel property of the InternetExplorerOptions object to true.
Set the Turn on Protected Mode local group policy to Enable for all zones.

I will explain more details of the above in the following sections of this article.

Ignore the zoom level

At first, the C# code I wrote was like below:

var driver = new InternetExplorerDriver(new InternetExplorerOptions {
  AttachToEdgeChrome = true,
  EdgeExecutablePath = "C:/Program Files (x86)/Microsoft/Edge/Application/msedge.exe"
});
...

The C# code above is equivalent to the official document's code.

But unfortunately, I ran into an error.

As I mentioned above, I was using Selenium .NET binding, so I saw the unhandled exception message on my application's console as below.

Started InternetExplorerDriver server (32-bit)
4.0.0.0
Listening on port 54479
Only local connections are allowed

Unhandled exception. 
System.InvalidOperationException: 
Unexpected error launching Internet Explorer. 
Browser zoom level was set to 175%. It should be set to 100% (SessionNotCreated)

The exception message said, "the zoom level of the browser must be 100%, but it was not".

However, I've never changed the zoom level, and the Edge browser zoom level indicated 100% in its menu at that time.

Therefore, finally, I decided to make Selenium ignore the zoom level forcibly.

We can do that by the IgnoreZoomLevel property of the InternetExplorerOptions object to true.

var driver = new InternetExplorerDriver(new InternetExplorerOptions {
  AttachToEdgeChrome = true,
  EdgeExecutablePath = "C:/Program Files (x86)/Microsoft/Edge/Application/msedge.exe",
  IgnoreZoomLevel = true // 👈 Added this line.
});
...

Turn on "Protected Mode" of IE... on Windows 11!

Unfortunately, even I avoided 1st error above, and I ran into 2nd error.

The console displayed the error message like below:

Started InternetExplorerDriver server (32-bit)
4.0.0.0
Listening on port 56568
Only local connections are allowed

Unhandled exception. 
OpenQA.Selenium.WebDriverException: 
The HTTP request to the remote WebDriver server for URL http://localhost:56568/session/c81cd23a-2f60-45ae-9636-ebd27fea9c22/url timed out after 60 seconds.
 ---> System.Threading.Tasks.TaskCanceledException: 
 The request was canceled due to the configured HttpClient.Timeout of 60 seconds elapsing.
 ---> System.TimeoutException: The operation was canceled.

The error message said the operation of the browser was timed out.
And when I saw that error message, I was immediately reminded that the error might be related to IE's "Protected Mode" configuration.

That means we have to set IE's "Protected Mode" configuration to "Enable" for all zones before automating IE.

That requirement is also mentioned in the official documents of Selenium.

https://www.selenium.dev/documentation/ie_driver_server/#required-configuration

you must set the Protected Mode settings for each zone to be the same value.

Therefore I opened the "Internet Properties" dialog from the Control Panel in a hurry for enabling IE's "Protected Mode".
But the "Enable Protected Mode" check box did not exist in the dialog... because it is Windows 11!

I stood there in confusion for a while, but I pulled myself together and started searching on the Internet to resolve this problem.

Before long, fortunately, I found the answer in the article written in 2016 below.

https://www.urtech.ca/2016/01/solved-how-to-disable-protected-mode-in-internet-explorer-using-gpo/

Actually, we could control the IE's "Protected Mode" by Local Group Policy.

So I opened Group Policy Editor (gpedit.msc), set the "Protected Mode" policy of all zones to "Enable", and applied it immediately by performing the gpupdate /force command.

After I did all of them, my C# code that is automating IE mode in Microsoft Edge had been started to work fine. 🎉

Conclusion

I hope this article will save time for developers who have to automate IE mode in Microsoft Edge by Selenium and IE Driver.

Learn, Practice, Share. :)

DEV Community: jsakamoto

The Missing Third Config Layer: Adding User Secrets to Blazor WebAssembly

🤔 The Problem with Blazor WebAssembly

🔍 The Three-Layer Configuration Problem

💡 I Thought, "Why Not Build It Myself?"

Extending an ASP.NET Core App with External Middleware Using "Hosting Startup"

🔧 What I Built

⚡ How to Use It

🛠️ 1. Add the Packages

🛠️ 2. Set Up User Secrets

🚀 3. Run the App

🔰 How It Works

⚠️ User Secrets Values Are Not Actually Secret

🎉 Summary

Your Component Catalog Already Knows Everything. So Why Not Make It an MCP Server?

🔰 Introduction

Storybook Doesn't Support Blazor, So I Reimplemented It in C#

🤔 What is MCP?

💡 The Idea: Exposing an In-House Design System via MCP

社内デザインシステムをMCPサーバー化したらUI実装が爆速になった

🤩 Wait, Doesn't Storybook Already Know Everything?

⚡ Adding an MCP Server Feature to Blazing Story

🧪 Trying It Out

🛠️ Setting Up the Environment

✍️ First Try: Generating UI from a Text Prompt

🖼️ Second Try: Generating UI from a Sketch Image

📝 What We Learned

🤷 But Isn't Writing Stories a Lot of Work?

🔍 What About the Official Storybook?

🎉 Conclusion: It Works at a Practical Level

MCP Server Feature | Blazing Story

Storybook Doesn't Support Blazor, So I Reimplemented It in C#

🔍 What Is Storybook?

Storybook: Frontend workshop for UI development

⚡ What Is Blazor?

Blazor | Build client web apps with C# | .NET

😔 The Problem: No Storybook for Blazor

Storybook Doesn't Support Blazor

There's a Workaround, But...

💡 What If We Reimplemented Storybook in Blazor?

Introducing Blazing Story

Overview | Blazing Story

The Goal: Match Storybook Pixel by Pixel

⚠️ Limitations of a Personal Project

Does Blazing Story Still Have a Reason to Exist?

📝 Summary

Extending an ASP.NET Core App with External Middleware Using "Hosting Startup"

Introduction

How Hosting Startup Works

Implementing a Hosting Startup Assembly and Seeing It in Action

1. Prepare a Simple ASP.NET Core Web Application

2. Implement the Hosting Startup Assembly

3. Run the ASP.NET Core Web Application with the Hosting Startup Assembly

4. Make the Hosting Startup Assembly Loadable by Specifying the Dependency

Conclusion

Tired of Accidentally Zipping Build Artifacts? Try "dnx zipsrc"!

The Problem Every Developer Knows

Introducing dnx zipsrc 🎉

How It Works

Smart Exclusion with .gitignore

Intelligent Naming

Usage Examples

Zip the Current Directory

Zip a Specific Directory

Specify a Custom Output Name

Why dnx Instead of dotnet tool install?

Real-World Use Cases

"But Wait, Doesn't This Already Exist?"

1. Naming Conventions and Output Location

2. No Auto-Incrementing for Repeated Runs

3. Better Default Ignore Rules

Requirements

Get Started Now!

Acknowledgments

How to Quickly Test Your Blazor App on a Real Smartphone

Using Dev Tunnels to Access Your Development App from Your Phone via the Internet

How to Use Dev Tunnels

Creating and Enabling a Dev Tunnel

Checking Dev Tunnel Active Status and Running the App

Accessing from Your Smartphone via the Internet

Introducing `dnx zipsrc` 🎉

Why `dnx` Instead of `dotnet tool install`?

1. 100% `eval()` free