App Development – Nguyen Quy Hy's blog

Dev Drive and Dotnet Tools

December 31, 2023December 31, 2023 nguyenquyhy Leave a comment

I recently tried out Dev Drive of Windows 11, where a ReFS partition can be created for your code and packages. It went smoothly and most of my projects were built successfully until it came to my Monogame project.

For your context, Monogame is a game engine written in .NET and allows you to write your game entirely in C#. It has a content pipeline to convert your audio and images assets to certain format, and the pipeline is written as local dotnet tools.

Turns out dotnet tools stop working after I moved Nuget package cache folder to the Dev Drive (with NUGET_PACKAGES environment variable). I tried to trigger the tool manually, but the error message is confusing an unhelpful:

❯ dotnet mgcb
Run "dotnet tool restore" to make the "mgcb" command available.
❯ dotnet tool restore
Skipping NuGet package signature verification.
Tool 'dotnet-mgcb' (version '3.8.1.303') was restored. Available commands: mgcb
❯ dotnet mgcb
Run "dotnet tool restore" to make the "mgcb" command available.

❯ dotnet mgcb

Run "dotnet tool restore" to make the "mgcb" command available.

❯ dotnet tool restore

Skipping NuGet package signature verification.

Tool 'dotnet-mgcb' (version '3.8.1.303') was restored. Available commands: mgcb

❯ dotnet mgcb

Run "dotnet tool restore" to make the "mgcb" command available.

I tried to check my Dev Drive and I can see dotnet-mgcb had been restored correctly. Looking a bit further, I realized that .NET is still trying to look for the tool in the old path in %userprofile%\.nuget (even after computer restart).

I might have guessed the issue by now: there must be a cache somewhere pointing to the old paths. Turned out local dotnet tools cache the package information (including the path) in %userprofile%\.dotnet\toolResolverCache.

The fix is obvious now:

Empty %userprofile%\.dotnet\toolResolverCache
Run dotnet tool restore again and double check toolResolverCache to ensure the files are recreated.

I think ideally, since dotnet tool restore can already get the package to the new cache folder in Dev Drive, it should also try to update this toolResolverCache folder automatically instead of requiring a manual wipe like this.

Delegating authentication in ASP.NET 5 (or Core 3)

August 7, 2020September 15, 2020 nguyenquyhy Leave a comment

Most web applications nowadays need some authentication mechanism to differentiate their users for various levels of personalization. However, user authentication tends to get more sophisticated due to the variety of client platforms as well as the susceptibility to attacks.

As a user, I no longer want to create a new credential for each site I am visiting. Giving my password to a site requires a certain amount of trust in the site’s security since not all sites implements proper amount of protection to password (or credential in general) with standard mechanisms of password hashing or 2FA.

As a system developer, protecting users’ passwords and users’ credentials in general becomes a big burden due to the growing list of attack techniques. This is also a source of distraction when signing in is certainly not the focus of most web application.

A better way to tackle authentication would be to leave this part to the “professional,” or in other words, to delegate user authentication to popular identity services such as Google Account or Microsoft Account. Our web application now only needs to take care of authorization and managing users’ data. This has become a major trend thanks to the introduction of JWT and OIDC protocol.

In this post, I’ll go through what I have done to incorporate Signing in with Microsoft Account into my ASP.NET 5 web applications. This should be directly applicable for ASP.NET Core 3 thanks to similar authentication setup. Authentication mechanism in this post is using open standards such as JWT and OIDC, so it should be able to extend to many other identity providers such as Google Account.

Javascript Module Loaders

January 20, 2020January 20, 2020 nguyenquyhy Leave a comment

Javascript has a long history with so many changes over the years. One area that has so much improvements yet might still be so confusing is its support for modularization.

This blog post discusses a part of this area, specifically on how to your Javascript source files can be loaded into your application. This blog post also focuses on Javascript on browser instead of other native environment such as NodeJS.

React & ASP.NET Core

June 2, 2019September 8, 2019 nguyenquyhy 1 Comment

Update 08 Sep 2019: since Microsoft has officially announce the deprecation of aspnet-webpack package in .NET Core 3.0, you might not want to use the code in this blog post directly in production. However, you might still be able to learn a thing or two from it. I will write a new blog post on restoring all the following feature on the new React template in Visual Studio.

React is getting very popular for building rich web interface, and is one of the supported project template in ASP.NET Core. In .NET Core, you can quickly create a new React project by running the command (or using the new project dialog):

dotnet new react

1	dotnet new react

The template immediately gives you a working project with both React and ASP.NET Core. However, I don’t feel very happy with the latest template in .NET Core 2.2 and 3.0, so I created a new one based on the template from older version of .NET Core for my own projects.

What I’ve learned moving from Azure WebJobs to Azure Function Apps

December 24, 2018March 12, 2019 nguyenquyhy 5 Comments

Updated: some previous of the content in this post is no longer applicable when you upgrade Microsoft.NET.Sdk.Functions to version 1.0.26, so I have added some notes and sections on that.

If you have been using Azure for some times, you might know about Azure WebJob, a great way to run your code in background on triggers and integrate with other services via bindings. Recently, Azure introduced a similar offering: Azure Function App. Function App is based on a very similar idea, where you can run your code in any supporting languages on certain triggers such as a Queue message or a HTTP request or a timer.

We have been using Azure WebJob for a couple of years to process our email/push notifications and to clean up of our database. WebJob served that purpose perfectly until our app growth reveals a big limitation: WebJob consumes all the resource of the web app itself. In theory, WebJob should be a separate background process and should not interfere with the web app. However, since it is inside the App Service, it utilizes the same CPU/Memory consumption constraint of the App Service Plan. We started getting downtime alert from our APIs because the WebJob is running too heavily, defeating the purpose of splitting up some processing to a separate process in the first place.

We look around for solutions. First of all, we tried scaling out the app service plan based on CPU and memory consumption. However, it was hard to set a proper rule to scale up and down, and the cost multiplied quite quickly. We started looking at moving to Azure Function App with consumption plan. On paper it looks great because we can completely separate our background processing and our API. We also does not have to waste computing resources for the WebJob dashboard as telemetry is now sent to Application Insights instead of Azure Storage (I heard the WebJob dashboard consumed App Service Plan’s CPU to perform certain indexing).

Unfortunately, the migration was not as smooth as we thought. We soon met many problems with our C# implementation:

If you are using Timer trigger in Function with consumption plan, remember that you have to use the CRON schedule format (0 0 */8 * * *), not the Timer format (08:00:00).
(This is no longer applied for Microsoft.NET.Sdk.Functions 1.0.26) Using QueueTrigger, you’ll get an amazingly cryptic error message on Azure Dashboard: The binding type(s) ‘queueTrigger’ are not registered. Please ensure the type is correct and the binding extension is installed. Visual Studio generated a functions.json with binding queueTrigger and can be seen on the Azure portal. We also added queues section to host.json file. We have also installed Microsoft.Azure.WebJobs.Extensions.Storage to enable QueueTrigger in code. So what did we miss here? Turn out you have to add
Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator nuget package as well, so that Visual Studio will generate extensions.json. This is not mentioned anywhere in the docs but only a small page on GitHub, which is very irritating.
If you are using Microsoft.NET.Sdk.Functions 1.0.26 and are using the above workaround, extensions.json might not be generated in the correct place, and you would suddenly get the same issue with unregistered binding types again when testing locally. You can try to remove Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator and let the SDK handle the json generation.
ILogger is supported by the new WebJob SDK since the migration to .NET Core and also by Function SDK v2, which is great since our Functions can finally share code with ASP.NET Core. Unfortunately, you might get error “Cannot bind parameter ‘log’ to type ILogger. Make sure the parameter Type is supported by the binding.” Turn out you need to use the exact version of ILogger in the SDK (e.g. SDK 1.0.19 uses 2.1.0) (stackoverflow), which would be a big problem if one of the dependencies updates to higher versions.

There are also several limitations that is probably due to Function App being a quite young platform in Azure:

It seems that Function is actually based on WebJob behind the scene, so the features set of Function SDK in C# is only a subset of that of WebJob:
- (This is no longer applied for Microsoft.NET.Sdk.Functions 1.0.26) WebJob recently moved to .NET Standard and get the extremely convenient dependency injection. Meanwhile, there is no DI story in Function. This might be ok with small function, but ours get a lot of logic and we would like to have DI to get proper tests.
- If you are using Microsoft.NET.Sdk.Functions 1.0.26, you can check out this blog post on the new DI support https://platform.deloitte.com.au/articles/performing-constructor-injections-on-azure-functions-v2.
- A small extra note: if previously you have been using SetBasePath(context.FunctionAppDirectory) to read configuration in local.settings.json. You can now use SetBasePath(Directory.GetCurrentDirectory()) in your startup class.
The current dashboard experience in Azure portal lacks the ability to replay the execution. This is not really critical for applications that have already been in production for a while as you should already have some retry mechanisms. However, it is quite convenient for development and small testing. Hopefully this will come soon in the future.

If you have any better solutions for those problems, please feel free to let me know in the comments.

Meta