msbuild
msbuild copied to clipboard
dotnet
Windows container build error on .Net 6.0.8
My WebAPI project that contains an embedded RESX. The windows container build failed with the following error. This error started when using .Net 6.0.8 as base.
Step 12/18 : RUN dotnet build "WebAPI.csproj" -c Release -o /app/build
---> Running in 426a4e2a3a0e
MSBuild version 17.3.0+92e077650 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: The "GenerateResource" task failed unexpectedly. [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7B8A2D94-0AC9-11D1-896C-00C04FB6BFC4} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)). [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at System.RuntimeTypeHandle.AllocateComObject(Void* pClassFactory) [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions) [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at System.Activator.CreateInstance(Type type, Boolean nonPublic, Boolean wrapExceptions) [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at System.Activator.CreateInstance(Type type) [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at Microsoft.Build.Tasks.GenerateResource.IsDangerous(String filename) [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at Microsoft.Build.Tasks.GenerateResource.Execute() [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [C:\src\WebAPI\WebAPI.csproj]
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [C:\src\WebAPI\WebAPI.csproj]
Build FAILED
Docker file is attached. Dockerfile.txt .
This seems like build problem with your project @alexxie. Does it build in VS without container?
It builds in VS. The error occurs in Windows container build. It can be reproduced with the attached simple WebApi project which has an embedded RESX. If you change the Build Action of the RESX to None then it builds in docker.
The COM CLSID points to C:\Windows\System32\urlmon.dll and the dll is missing in the SDK image
I have the same problem too. I run the same pipeline that working days before (3 august) and now show me the same error than @alexxie
I have the same issue in my Azure pipeline build. I can build the container locally fine. I tried removing the .resx file in the project and it builds fine.
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: The "GenerateResource" task failed unexpectedly.
C:\Program Files\dotnet\sdk\6.0.400\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7B8A2D94-0AC9-11D1-896C-00C04FB6BFC4} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)).
Had the same problem. I explicitly set the images to previous versions of the sdk and the runtime (6.0.2 from 6.0.4) to make the container build run:
FROM mcr.microsoft.com/dotnet/aspnet:6.0.2-nanoserver-ltsc2022 AS base ......
FROM mcr.microsoft.com/dotnet/sdk:6.0.200-nanoserver-ltsc2022 AS build ......
Any idea @jkoritzinsky @AaronRobinsonMSFT ? Anything close I could find was https://github.com/dotnet/runtime/pull/70537 but I'm not sure it is relevant.
If the native binary that has the COM server isn't there then this makes sense why it would fail, but I don't know enough about the images to say more. What version of Windows is this running on? Note that on Windows Nano Server many COM servers and features are removed. It does seem odd that resource management requires anything from an external COM server though.
This issue is stale because there has been no response to a request for more information for 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@wfurt, is there a alternative base image that has this required COM server registered? We can try @thodoris-papergo's approach but we are required to use the current version of .NET going forward. Can you please escalate this issue further?
Can you provide us with a small example project which reproduces this issue so we can investigate more?
@rzikm, please use the WebAPI.zip attached at the beginning of this thread: https://github.com/dotnet/core/files/9340610/WebAPI.zip
I have tried the attached project, and I did not manage to reproduce the issue.
First, the Dockerfile seems to be in wrong directory (the relative paths suggests that the file should be next to the sln file, not the csproj file)
After moving the dockerfile to the parent directory, I can build the container without issues:
❯ docker build .
[+] Building 24.0s (18/18) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 32B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 382B 0.0s
=> [internal] load metadata for mcr.microsoft.com/dotnet/sdk:6.0 0.1s
=> [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:6.0 0.1s
=> [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:d83d1dc9886a5e2916b03b3c846b24750619d62c0d4039480df8a1c5b7342426 15.4s
=> => resolve mcr.microsoft.com/dotnet/sdk:6.0@sha256:d83d1dc9886a5e2916b03b3c846b24750619d62c0d4039480df8a1c5b7342426 0.0s
=> => sha256:87851657143a9192b7653e7b145f32c30e34b921ca8d006d15b4514217d0f8ab 7.17kB / 7.17kB 0.0s
=> => sha256:d4619031a5152140e3b7fc84cd1639b1479b6e0ddd9ca9ceddcdfdfba37c711f 15.02MB / 15.02MB 1.0s
=> => sha256:6d618327faacce5a184fce1db044f8d91ea631e9a8f5fa60b8f41d682966d1ef 31.62MB / 31.62MB 1.7s
=> => sha256:d83d1dc9886a5e2916b03b3c846b24750619d62c0d4039480df8a1c5b7342426 1.82kB / 1.82kB 0.0s
=> => sha256:a449474589fc907592cc70410b2a133e5d0fc35e2527ec4ca2ea5a29e03c27d0 2.01kB / 2.01kB 0.0s
=> => sha256:7a6db449b51b92eac5c81cdbd82917785343f1664b2be57b22337b0a40c5b29d 31.38MB / 31.38MB 6.2s
=> => sha256:827cc4f3826adaafb6324759835167a5f06ffb94232f5d410c3427bd6090cf66 155B / 155B 1.1s
=> => sha256:fe3af87d6dfc333da3e42f33f18e6fd615fba4bba6a8f98229527f631329130c 9.46MB / 9.46MB 1.8s
=> => sha256:2ec9622b0c532b8ca87effcc4bb4fc7a72914ca49a05d30a3127eed3fc7410b3 25.37MB / 25.37MB 2.8s
=> => sha256:98d3fc8fd5a89407706bae7f544980fec81b3f178e7833abb349a0486b1fc958 147.77MB / 147.77MB 9.1s
=> => sha256:6936d33e45957f64d1681e46ea32ae313e9b5d128a27b671cad2be7d8ac9a8e9 12.89MB / 12.89MB 3.4s
=> => extracting sha256:7a6db449b51b92eac5c81cdbd82917785343f1664b2be57b22337b0a40c5b29d 1.3s
=> => extracting sha256:d4619031a5152140e3b7fc84cd1639b1479b6e0ddd9ca9ceddcdfdfba37c711f 0.4s
=> => extracting sha256:6d618327faacce5a184fce1db044f8d91ea631e9a8f5fa60b8f41d682966d1ef 0.9s
=> => extracting sha256:827cc4f3826adaafb6324759835167a5f06ffb94232f5d410c3427bd6090cf66 14.5s
=> => extracting sha256:fe3af87d6dfc333da3e42f33f18e6fd615fba4bba6a8f98229527f631329130c 14.5s
=> => extracting sha256:2ec9622b0c532b8ca87effcc4bb4fc7a72914ca49a05d30a3127eed3fc7410b3 0.9s
=> => extracting sha256:98d3fc8fd5a89407706bae7f544980fec81b3f178e7833abb349a0486b1fc958 4.0s
=> => extracting sha256:6936d33e45957f64d1681e46ea32ae313e9b5d128a27b671cad2be7d8ac9a8e9 0.4s
=> [internal] load build context 0.1s
=> => transferring context: 14.85kB 0.0s
=> [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:6.0@sha256:30f462a50ad021c35ab3ebbbb8f16049c8d41499f7063a95bc68e7c69b0a97c4 9.9s
=> => resolve mcr.microsoft.com/dotnet/aspnet:6.0@sha256:30f462a50ad021c35ab3ebbbb8f16049c8d41499f7063a95bc68e7c69b0a97c4 0.0s
=> => sha256:6d618327faacce5a184fce1db044f8d91ea631e9a8f5fa60b8f41d682966d1ef 31.62MB / 31.62MB 1.7s
=> => sha256:30f462a50ad021c35ab3ebbbb8f16049c8d41499f7063a95bc68e7c69b0a97c4 1.82kB / 1.82kB 0.0s
=> => sha256:00bb0003342d0c5ef2dba1643465ac884b5ea3c68737f848c573ed2130331b74 1.37kB / 1.37kB 0.0s
=> => sha256:ed63757da582c94791a9b59a6f00095e27d5e5fb5ba50c7fca1d4e89d73be394 3.26kB / 3.26kB 0.0s
=> => sha256:d4619031a5152140e3b7fc84cd1639b1479b6e0ddd9ca9ceddcdfdfba37c711f 15.02MB / 15.02MB 1.0s
=> => sha256:7a6db449b51b92eac5c81cdbd82917785343f1664b2be57b22337b0a40c5b29d 31.38MB / 31.38MB 6.2s
=> => sha256:827cc4f3826adaafb6324759835167a5f06ffb94232f5d410c3427bd6090cf66 155B / 155B 1.1s
=> => sha256:fe3af87d6dfc333da3e42f33f18e6fd615fba4bba6a8f98229527f631329130c 9.46MB / 9.46MB 1.8s
=> => extracting sha256:7a6db449b51b92eac5c81cdbd82917785343f1664b2be57b22337b0a40c5b29d 1.3s
=> => extracting sha256:d4619031a5152140e3b7fc84cd1639b1479b6e0ddd9ca9ceddcdfdfba37c711f 0.4s
=> => extracting sha256:6d618327faacce5a184fce1db044f8d91ea631e9a8f5fa60b8f41d682966d1ef 0.9s
=> => extracting sha256:827cc4f3826adaafb6324759835167a5f06ffb94232f5d410c3427bd6090cf66 0.0s
=> => extracting sha256:fe3af87d6dfc333da3e42f33f18e6fd615fba4bba6a8f98229527f631329130c 0.2s
=> [base 2/2] WORKDIR /app 0.2s
=> [final 1/2] WORKDIR /app 0.1s
=> [build 2/7] WORKDIR /src 0.3s
=> [build 3/7] COPY [WebAPI/WebAPI.csproj, WebAPI/] 0.1s
=> [build 4/7] RUN dotnet restore "WebAPI/WebAPI.csproj" 2.5s
=> [build 5/7] COPY . . 0.1s
=> [build 6/7] WORKDIR /src/WebAPI 0.1s
=> [build 7/7] RUN dotnet build "WebAPI.csproj" -c Release -o /app/build 3.0s
=> [publish 1/1] RUN dotnet publish "WebAPI.csproj" -c Release -o /app/publish /p:UseAppHost=false 1.9s
=> [final 2/2] COPY --from=publish /app/publish . 0.1s
=> exporting to image 0.2s
=> => exporting layers 0.1s
=> => writing image sha256:78008e5a472dc714f032432119b8e5bb761f5157be28c5a037355999111913fa
@rzikm can you please confirm you are building a Windows Container image, not Linux image?
my apologies, I didn't realise you need to switch docker to windows even to build the images. I can reproduce the issue now.
@mthalman Would you be able to help with this issue? If not, can you suggest somebody else who could take a look?
There appears to be a new code path in 6.0.400 that now requires urlmon.dll in this scenario. That file does not exist in Windows Nano Server (it never has):
> docker run --rm mcr.microsoft.com/windows/nanoserver:1809 cmd /c dir C:\Windows\System32\urlmon.dll
Volume in drive C has no label.
Volume Serial Number is 7CE8-7B27
Directory of C:\Windows\System32
File Not Found
But it does exist in Windows Server Core (and other Server SKUs):
> docker run --rm mcr.microsoft.com/windows/servercore:ltsc2019 cmd /c dir C:\Windows\System32\urlmon.dll
Volume in drive C has no label.
Volume Serial Number is F6B6-F8A6
Directory of C:\Windows\System32
08/06/2022 01:09 PM 1,860,096 urlmon.dll
1 File(s) 1,860,096 bytes
0 Dir(s) 21,237,432,320 bytes free
When targeting Windows containers and the 6.0 tag is used, or any tag that doesn't specify the Windows Server version, you will get a Nano Server image. Pair that with whatever change in 6.0.400 caused this dependency in this scenario is why it's failing.
The easiest workaround is to use a Windows Server Core for your sdk tag only: 6.0-windowsservercore-ltsc2019 or 6.0-windowsservercore-ltsc2022:
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
<rest of content removed for brevity>
FROM mcr.microsoft.com/dotnet/sdk:6.0-windowsservercore-ltsc2019 AS build
<rest of content removed for brevity>
All tags are documented at https://hub.docker.com/_/microsoft-dotnet-sdk/. The Server Core image is substantially larger than Nano Server. If you really don't want the larger image, you can fall back to the earlier unsupported SDK as your workaround. But in that case, be sure to use the most recent tag for your aspnet or runtime tag; you can use an older SDK with a newer runtime in your Dockerfile.
As for what caused the change in 6.0.400, I don't know. The call stack shows that this CLSID is being loaded by https://github.com/dotnet/msbuild/blob/main/src/Tasks/GenerateResource.cs and that code has existed for a long time. Throwing @rainersigwald into the discussion just in case he has any ideas.
I'm going to move this to the MSBuild repo. I don't know offhand why we'd start going down this long-existant codepath now.
thanks @mthalman, mcr.microsoft.com/dotnet/sdk:6.0-windowsservercore-ltsc2019 AS build works.