What could cause a "TypeError: (0 , d.__decorate) is not a function" of an angular function inside a docker container? - asp.net

I'm building a web application. The frontend is in angular and the backend in .Net Core.
Currently, I'm doing the following, to build my final docker image:
Build angular app
Copy the built angular files in the wwwroot of asp.net core
Building the asp.net core app
Publishing the asp.net core app
Copying the publish result inside a docker image.
Here is my current dockerfile:
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM node:latest as node
WORKDIR /app
COPY Frontend .
RUN npm install
RUN npm run build
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["Backend/my-project.csproj", "Backend/"]
RUN dotnet restore "Backend/my-project.csproj"
COPY Backend Backend
WORKDIR "/src/Backend"
COPY --from=node /app/dist/app/ /wwwroot/
RUN dotnet build "my-project.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "my-project.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "my-project.dll"]
The whole process finish without errors, but when I'm trying to access to http://localhost/, I get the html, but there is a javascript error:
Uncaught TypeError: (0 , d.__decorate) is not a function
at Object.619 (main.3ba20fe70ead0a4b.js:1:45137)
at r (runtime.834ae414fca175dc.js:1:127)
at Object.1983 (main.3ba20fe70ead0a4b.js:1:45670)
at r (runtime.834ae414fca175dc.js:1:127)
at main.3ba20fe70ead0a4b.js:1:512504
at n (runtime.834ae414fca175dc.js:1:2649)
at main.3ba20fe70ead0a4b.js:1:57
But:
the result of ng serve work
serving with a test server the result of npm build works
Copying the result of npm build to wwwroot of my asp.net core works in debug
Publishing the asp.net core app(with the wwwroot populated) also works
When I try to access to each individual file present in my npm build folder, it seems to be accessible(not sure, because names have this number that is not exactly the same)
If I deleted nodes_modules, packages-lock.json and run npm install and npm run build, it also works
I deleted the angular app, created another one, run the whole docker build, it works.
I tried to change node to the version I'm using on my computer(node 16.14)
Edit
I started to remove everything from my app to see when it starts working again. It appears that once I remove my State(s) of NgxsModule.forFeature([]), it works.
So basically, if I've a module with:
NgxsModule.forFeature([])
It works, but NgxsModule.forFeature([UiState]) doesn't, even if UiState is almost empty:
#State<UiStateModel>({
name: 'ui',
defaults: {
isMenuOpen: true,
},
})
#Injectable()
export class UiState {}
I'm kind of desperate, any idea what could cause this error?

I'm not exactly sure what did the trick, but I finally solved it.
What I did:
I had some ngxs packages that were refered as dev dependencies AND dependencies(with different version), I kept only the one in the dependencies
In my tsconfig.json, I was having a paths specified for "tslib"(to the nodes_modules one). I remember I added it, but I don't remember why, I think at some point I was having a compilation error and I found on SO this solution. I did remove this path for tslib, which is what probably solve the issue.

Related

.Net Dockerizing excluding build stage in the dockerfile

I am new to docker and AKS, I am working on a .Net project that is migrated from .Net core 3.1 to .Net 6 , I am trying to containerize and deploy to AKS. First i wanted to test in the local machine so i had setup docker in the macbook m1 and followed this link https://learn.microsoft.com/en-us/visualstudio/mac/docker-quickstart?view=vsmac-2022 to create a dockerfile, I am able to run the dockerfile from Visual Studio if i follow the steps given in the link but if i run docker compose command from terminal i am getting issues with SDK version, however what i am trying to achieve is remove the build stage and directly run the .net application as the build stage is taken care by Jenkins and the DLL is placed in a folder
Here is the complete dockerfile with all the stages
FROM mcr.microsoft.com/dotnet/core/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:6.0 AS build
WORKDIR /src
COPY DockerDemo/DockerDemo.csproj DockerDemo/
RUN dotnet restore "DockerDemo/DockerDemo.csproj"
COPY . .
WORKDIR "/src/DockerDemo"
RUN dotnet build "DockerDemo.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "DockerDemo.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DockerDemo.dll"]
I modified dockerfile excluding build stage, I am taking DLL file from a "lib/net6.0" that is built by jenkins and placed in this folder
FROM mcr.microsoft.com/dotnet/core/aspnet:6.0 AS base
COPY ["lib/net6.0","/src/"]
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM base as final
WORKDIR /app
COPY --from=base /src/ .
ENTRYPOINT["dotnet","DockerDemo.dll"]
If i build the dockerfile the image is getting created but when i run I am getting following error
unhandled exception system.io.filenotfoundexception could not load
file or assembly 'NLog, Version=.5.0.0.0
The project is using NLog.Web.ASPNetCore 5.1.4 version, i tried downgrading it to 5.0.0 but i am still getting the same error, i also tried adding just NLog 5.0.0 package but no luck
As i said i am new to Docker and also to the .net development on macbook
My Questions
Q1) Is it possible to exclude the build stage in dockerfile and directly run
Q2) Does the macbook m1 completely supports .Net Core and .Net 6 development so that it can be deployed to AKS via Jenkins pipeline

Next failed to load SWC binary

When trying to run the command using nextjs npm run dev shows error - failed to load SWC binary see more info here: https://nextjs.org/docs/messages/failed-loading-swc.
I've tried uninstalling node and reinstalling it again with version 16.13 but without success, on the vercel page, but unsuccessful so far. Any tips?
Also, I noticed it's a current issue on NextJS discussion page and it has to do with the new Rust-base compiler which is faster than Babel.
Delete the package-lock.json file and the node_modules directory in your project and then run npm install on your terminal.
This worked as suggeted by nextJS docs but it takes away Rust compiler and all its benefits... Here is what I did for those who eventually get stuck...
Step 1. add this line or edit next.json.js
{
swcMinify: false // it should be false by default
}
Step 2. add a ".babelrc" file to project root dir
Step 3. add this snippet to the new file ".babelrc"
{
"presets": ["next/babel"]
}
Step 4, you need to run this command as steps 1-3 will remove SWC failed to load error but you will notice another error when you run the build command. So run this too
npm install next#canary
hope this helps
If you use Docker, just add RUN npm install -D #swc/cli #swc/core to Dockerfile.
I have the same issue, don't know why, I am using
node v18.4.0
next#12.1.6
to fix this issue
just visit this website
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
install this
I had the same issue on Windows 11. I upgraded NodeJS to 17.0.1. After that, everything works now.
make .babelrc in root directory. And add the following code.
{ "presets": ["next/babel"], "plugins": [["styled-components", { "ssr": true }]] }
This error occurs because next js uses a Rust-based compiler to compile JavaScript which is much faster than babel but this is not compatible with all system architecture, in other to fix this you have to disable this compiler and use the native babel compiler. This is done by creating a .babelrc file in your root directory and adding this code below to the file;
{"presets": ["next/babel"]}
you can check out this link for more details: SWC Failed to Load - NEXTJS DOCS
If you are running using Docker, I had to use node:14-buster-slim as my base image to make it work. I got the idea for my working solution from https://github.com/vercel/next.js/discussions/30468#discussioncomment-1598941.
My multi-staged Dockerfile looks like this:
############### Base Image ###############
FROM node:14-buster-slim AS base
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
############### Build Image ###############
FROM base AS build
ARG app_env=production
ARG app_port=3000
WORKDIR /build
COPY --from=base /app ./
ENV NODE_ENV=${app_env}
ENV PORT=${app_port}
EXPOSE ${app_port}
RUN npm run build
############### Deploy Image ###############
FROM node:14.18.1-alpine AS production
ARG app_env=production
ENV NODE_ENV=${app_env}
WORKDIR /app
COPY --from=build /build/package*.json ./
COPY --from=build /build/.next ./.next
COPY --from=build /build/public ./public
RUN npm install next
EXPOSE 3000
CMD npm run start
If you want to use docker-compose to run your services, the docker-compose.yaml file for running the next dev will look something like this:
version: "3"
services:
web-server:
env_file:
- ./.env
build:
context: .
dockerfile: Dockerfile
target: base
command: npm run dev
container_name: web-server
restart: always
volumes:
- ./:/app
- /app/node_modules
ports:
- "${NODEJS_PORT}:3000"
In your NextJS Project you have this file , named .eslintrc.json, In this file
You have following code
{
"extends": "next/core-web-vitals"
}
Replace it with
{
"extends": ["next/babel","next/core-web-vitals"]
}
The best way to fixed this problem on Windows is install "Microsoft Visual C++ Redistributable"
The error is occurring because Next.js is using Rust-based compiler SWC to compile JavaScript/TypeScript now and for this SWC requires a binary be downloaded that is compatible specific to your system.
To Solve this problem :
Just go to Microsoft Visual C++ Redistributable to download
latest supported Microsoft Visual C++ Redistributable.
Or, you can simply download from here (please check your version first)
Permalink for latest supported x64 version
The X64 Redistributable package contains both ARM64 and X64 binaries. This package makes it easy to install required Visual C++ ARM64 binaries when the X64 Redistributable is installed on an ARM64 device.
Permalink for latest supported x86 version
Permalink for latest supported ARM64 version
Just run 'npm i' or 'yarn' and then restart the server.
Remove node_modules directory and package-lock.json
Run npm i to install the dependencies
If you are on MAC OS, you can directly run below command in terminal
rm -rf node_modules && rm package-lock.json && npm i
In my case issue was with NextJs version 12.2. I have downgraded it to 12.1.6 and my issue is fixed.
I'm a beginner with next.js and I had the same error. After searching I got a solution to add .babelrc. but using that couldn't get the features of SWC.
Today I got a real solution, using this example project command. When we create our new project, then swc will work as well as no error will be there.
command- npx create-next-app 'your_project_name' --use-npm --example "https://github.com/vercel/next-learn/tree/master/basics/learn-starter"
Let me know if you face any further issues.
Just Download Redistributable C++ 2015
If you read the docs it says you need a distributable file which can be downloaded at https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-
Best solution for this problem is
Delete your package-lock.json.
Downgrade your next.js version "12.1.6" from current version.
run npm i --force command.
now run npm run dev command and it will work.
This is Happen because of you have uninstalled npm modules or yarn in your project
Just Run this command / install node packages you will get your back

Slow Next.js builds on Gitlab CI

We have a JS-based stack in our application - React with vast majority being a React Admin frontend, built on Next.js server, with Postgres, Prisma and Nexus on backend. I realize it's not a great use case for Next.js (React Admin basically puts entire application in a single "component" (root), so basically I have a giant index.tsx page instead of lots of smaller pages), but we've had quite terrible build times in Gitlab CI and I'd like to know if there's anything I can do about it.
We utilize custom gitlab-runners deployed on the company Kubernetes cluster. Our build job essentially looks like:
- docker login
- CACHE_IMAGE_NAME="$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:latest"
- SHA_IMAGE_NAME="$CI_REGISTRY_IMAGE/$CI_COMMIT_SHORT_SHA"
- docker pull $CACHE_IMAGE_NAME || true
- docker build
-t $CACHE_IMAGE_NAME
-t $SHA_IMAGE_NAME
--cache-from=$CACHE_IMAGE_NAME
--build-arg BUILDKIT_INLINE_CACHE=1
- docker push # both tags
And the Dockerfile for that is
FROM node:14-alpine
WORKDIR /app
RUN chown -R node:node /app
USER node
COPY package.json yarn.lock ./
ENV NODE_ENV=production
RUN yarn install --frozen-lockfile --production
COPY . .
# Prisma client generate
RUN npm run generate
ENV NEXT_TELEMETRY_DISABLED 1
RUN npm run build
ARG NODE_OPTIONS=--max-old-space-size=4096
ENV NODE_OPTIONS $NODE_OPTIONS
EXPOSE 3000
CMD ["yarn", "start"]
This built image is then deployed with Helm into our K8s with the premise that initial build is slower, but subsequent builds in the pipeline will be faster as they can utilize docker cache. This works fine for npm install (first run takes around 10 minutes to install, subsequent are cached), but next build is where hell breaks loose. The build times are around 10-20 minutes. I recently updated to Next.js 12.0.2 which ships with new Rust-based SWC compiler which is supposed to be up to 5 times faster, and it's actually even slower (16 minutes).
I must be doing something wrong, but can anyone point me in some direction? Unfortunately, React Admin cannot be split across several Next.js pages AFAIK, and rewriting it to not use the framework is not an option either. I've tried doing npm install and next build in the CI and copy that into the image, and store in the Gitlab cache, but that seems to just shift the time spent from installing/building into copying the massive directories in/out cache and into the image. I'd like to try caching the .next directory in between builds, maybe there is some kind of incremental build possible but I'm skeptical to say the least.
Well, there are different things that we can approach for making it faster.
You're using Prisma, but you're generating the client every time that you have a modification in any of the files, preventing the Docker cache to actually take care of that layer. If we take a look into the Prisma documentation, we need to generate the Prisma Client each time that there's a change on the Prisma schema, not in the TS/JS Code.
I will suppose you have your Prisma schematics under the prisma directory, but feel free to adapt my suppositions to the reality of your project:
ENV NODE_ENV=production
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile --production
COPY prisma prisma
RUN npm run generate
You're using a huge image for your final container, which maybe doesn't have a significant impact on the build time, but it definitely has on the final size and the time required to load/download the image. I would recommend to migrate into a multi-stage solution like the following one:
ARG NODE_OPTIONS=--max-old-space-size=4096
FROM node:alpine AS dependencies
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile --production
COPY prisma prisma
RUN npm run generate
FROM node:alpine AS build
WORKDIR /app
COPY . .
COPY --from=dependencies /app/node_modules ./node_modules
ENV NEXT_TELEMETRY_DISABLED 1
RUN npm run build
FROM node:alpine
ARG NODE_OPTIONS
ENV NODE_ENV production
ENV NODE_OPTIONS $NODE_OPTIONS
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nextjs -u 1001
WORKDIR /app
COPY --from=build /app/public ./public
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package.json ./package.json
COPY --chown=nextjs:nodejs --from=build /app/.next ./.next
USER 1001
EXPOSE 3000
CMD ["yarn", "start"]
From another point of view, probably you could improve also the NextJS build by changing some tools and modifying the NextJS configuration. You should use locally the tool https://github.com/stephencookdev/speed-measure-webpack-plugin to analyze which is the culprit of that humongous build-time (which probably is something related to sass) and also take a look into the TerserPlugin and the IgnorePlugin.

Cannot connect to azure nuget feed when creating a container

I have been trying to get docker to pull from a private nuget feed which is hosted within Azure Devops, but I consistently get a 401 unauthorized error. I have looked a numerous other answers and resources, but all of which have not helped. My dockerfile script is the following
# escape=`
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
WORKDIR /src
EXPOSE 80
EXPOSE 443
ARG FEED_URL
ARG FEED_ACCESSTOKEN
# Install powershell via dotnet
RUN dotnet tool install --global PowerShell --version 7.0.0
SHELL ["pwsh", "-command"]
## CURRENT ERROR - "-AddNetfx" - NOT CONSIDERED AN ARGUMENT, ALTHOUGH IT IS (CAN BE SEEN IN THE SCRIPT ENTRY) ##
# Install credprovider which is required for accessing private artifact repository
RUN Invoke-WebRequest https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -OutFile installcredprovider.ps1; `
.\installcredprovider.ps1 -AddNetfx; `
del installcredprovider.ps1
#################################################################################################################
# Copy csproj and sln files
COPY ["Abstractions/*.csproj", "./Abstractions/"]
COPY ["AdminServicesPortal/*.csproj", "./AdminServicesPortal/"]
COPY ["DataInterface/*.csproj", "./DataInterface/"]
COPY ["Resources/*.csproj", "./Resources/"]
# Need to copy over docker NuGet packages
COPY "AdminServicesPortal/nuget.config" "AdminServicesPortal/"
# Enable session token cache
ENV NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED true
ENV VSS_NUGET_EXTERNAL_FEED_ENDPOINTS `
"{`"endpointCredentials`": [{`"endpoint`":`"https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/nuget/v3/index.json`", `"username`":`"USER`", `"password`":`"PAT`"}]}"
RUN echo $Env:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS
# Restore dependencies before copying everything else over
RUN dotnet restore "AdminServicesPortal/Portal.csproj"
# Copy the rest of the files required for a build
# Note that this is separate, because we should stop building
# the container if we do not have all required dependencies
COPY Abstractions/. ./Abstractions/
COPY AdminServicesPortal/. ./AdminServicesPortal/
COPY DataInterface/. ./DataInterface/
COPY Resources/. ./Resources/
WORKDIR "/src/AdminServicesPortal"
RUN dotnet build "Portal.csproj" -c Release -o /app/build
# Publish application
FROM build-env AS publish
RUN dotnet publish "Portal.csproj" -c Release -o /app/publish
# Runtime environment for container
FROM build-env AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MPX.AdminServices.Portal.dll"]
The error I get from Visual Studio is the following
2> Failed to restore C:\src\Resources\Resources.csproj (in 2.99 sec).
2>C:\Program Files\dotnet\sdk\3.1.404\NuGet.targets(128,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/{ORG}/{PROJECT}/_packaging/{FEED}/nuget/v3/index.json. [C:\src\AdminServicesPortal\Portal.csproj]
2>C:\Program Files\dotnet\sdk\3.1.404\NuGet.targets(128,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\src\AdminServicesPortal\Portal.csproj]
From what I can tell in the link below; my dockerfile script should work
https://github.com/dotnet/dotnet-docker/blob/master/documentation/scenarios/nuget-credentials.md#using-the-azure-artifact-credential-provider
To ensure it wasn't an issue with the PAT of the user not having access, I gave them access to everything across the whole entire organisation. Any help would be greatly appreciated!
Note #1: My current suspicion is that there are some additional parameters I might need to pass, since the private nuget feed is for a project rather than the entire organisation?
Note #2: I ran the following PowerShell command (https://learn.microsoft.com/en-us/azure/devops/artifacts/tutorials/private-powershell-library?view=azure-devops#package-and-publish-the-module) which worked fine, so I am even more confused to why my dockerfile script does not work.
nuget sources Add -Name "PowershellModules" -Source "https://pkgs.dev.azure.com/<org_name>/_packaging/<feed_name>/nuget/v3/index.json" -username "<user_name>" -password "<personal_access_token(PAT)>"
You can check out below workarounds without using NuGet credential plugin.
1, Use dotnet cli to add credentials to the nuget source in your docker file. And then pass the $PAT in the build arguments (ie. --build-arg PAT=$PAT ):
ARG PAT
COPY . .
RUN dotnet nuget add source "your-source-url" --name "source-name" --username "useless" --password "$PAT" --store-password-in-clear-text
RUN dotnet restore
2, You can also try adding the credentials to the config file using the nuget command. And include the nuget.config which has the credentials in the build context. And copy the nuget.config in your docker file . See below:
sources Add -Name "MyPackages" -Source "https://my.pkgs.visualstudio.com/_packaging/MyPackages/nuget/v3/index.json" -username any -password $PAT -ConfigFile Source/Nuget.config -StorePasswordInClearText
Copy the nuget.config in the docker file, You can delete the nuget.config file when the restore is complete:
COPY *.csproj .
COPY ./nuget.config .
RUN dotnet restore
RUN rm nuget.config
You can refer to my answer to this similar thread that using azure nuget feed in the docker container in Azure pipelines.

Containerrizing Hosted Blazor WebAssembly for Raspberry Pi Docker Swarm

I’m developing a DotNet Core hosted Blazor WebAssembly, as a frontend to my backend ASPNet Core API, running on Raspberry Pi’s, containerised in a Docker Swarm.
I’m developing on a MacBook Pro, using VSCode for Mac, and it’s really a great tool. I created the solution as “dotnet new blazorwasm —hosted” and got the solution created and build.
I have installed Docker Desktop, and created a Buildx builder for arm, which works great with all my other solutions (DotNet Core API, DotNet Background solutions), but with the hosted blazorwasm solution, I run into several problems, probably caused by my lacking knowledge on setting up build options.
So I installed Visual Studio 2019 (I have used VS on Windows for 20 years) and was actually surprised over the look and feel, a really great tool.
I created the hosted Blazor WebAssembly solution, which works great om Mac, and even the Docker desktop integration work without problems.
Building the Docker Image was easy, I just used my Buildx builder, and executed below command from the command line:
“docker buildx build --file ./SnakeConsole/Server/Dockerfile --platform linux/arm/v7 -t jagdriver/wavesnake:SnakeConsole3 --push .”
On the Raspberry Swarm, I then created the Stack/Container. The Stack installed but the container refused to start, and the log was:
standard_init_linux.go:211: exec user process caused “exec format error”.
I have seen this error before, and as far as I remember I added “-r ubuntu.19.10-arm” to the dotnet publish command to ensure that the code is generated for linux-arm.
So I tried to add “-r ubuntu.19.10-arm” to the dotnet publish command in below dockerfile, and execute the Docker buildx build command again, but then the Build Engine run into below error.
project.assets.json' doesn't have a target for '.NETCoreApp,Version=v5.0/browser-wasm'. Ensure that restore has run and that you have included 'net5.0' in the TargetFrameworks for your project. You may also need to include 'browser-wasm' in your project's RuntimeIdentifiers
Can anyone out the give me a helping hand on this, thanks in advance.
FACTS:
The solution I’m mentioning is the standard Hosted Blazor
WebAssembly template without any changes.
The target framework is .Net 5.0
Visual Studio for Mac community is version 8.7.2 (build 4)
Docker file from the default hosted Blazor WebAssembly template.
FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build
WORKDIR /src
COPY SnakeConsole/Server/SnakeConsole.Server.csproj SnakeConsole/Server/
COPY SnakeConsole/Client/SnakeConsole.Client.csproj SnakeConsole/Client/
COPY SnakeConsole/Shared/SnakeConsole.Shared.csproj SnakeConsole/Shared/
RUN dotnet restore "SnakeConsole/Server/SnakeConsole.Server.csproj"
COPY . .
WORKDIR "/src/SnakeConsole/Server"
RUN dotnet build "SnakeConsole.Server.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "SnakeConsole.Server.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SnakeConsole.Server.dll"]
Have faced similar issue, documentation says:
Deploying a standalone Blazor WebAssembly app to Azure App Service for Linux isn't currently supported. A Linux server image to host the app isn't available at this time. Work is in progress to enable this scenario.
https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0#standalone-deployment
Looks like this is a Docker OS compatibility and framework functionality issue. I would suggest to target your app to Server (Blazor Server Hosting model scenario).

Resources