dotnet tool manifest on windows container throws a COM error

Steps to reproduce the issue

Try to build the following Dockerfile with windows containers:

FROM mcr.microsoft.com/dotnet/core/sdk

RUN dotnet new tool-manifest
RUN dotnet tool restore

Expected behavior

Successful build.

Actual behavior

The tool restore command throws the following error:

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)).
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)
   at System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type)
   at Microsoft.DotNet.Cli.Utils.DangerousFileDetector.InternetSecurity.IsDangerous(String filename)
   at Microsoft.DotNet.Cli.Utils.DangerousFileDetector.IsDangerous(String filePath)
   at Microsoft.DotNet.ToolManifest.ToolManifestEditor.Read(FilePath manifest, DirectoryPath correspondingDirectory)
   at Microsoft.DotNet.ToolManifest.ToolManifestFinder.TryFindToolManifestPackages(IEnumerable`1 allPossibleManifests, List`1& toolManifestPackageAndSource)
   at Microsoft.DotNet.ToolManifest.ToolManifestFinder.Find(Nullable`1 filePath)
   at Microsoft.DotNet.Tools.Tool.Restore.ToolRestoreCommand.Execute()
   at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
   at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

Additional information (e.g. issue happens only occasionally)

N/A

Output of docker version

Client: Docker Engine - Community
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        6a30dfc
 Built:             Thu Aug 29 05:26:49 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.8
  Git commit:       6a30dfc
  Built:            Thu Aug 29 05:39:49 2019
  OS/Arch:          windows/amd64
  Experimental:     false

Output of docker info

Client:
 Debug Mode: false

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 50
 Server Version: 19.03.2
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics l2bridge l2tunnel nat null overlay transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: inactive
 Default Isolation: hyperv
 Kernel Version: 10.0 17134 (17134.1.amd64fre.rs4_release.180410-1804)
 Operating System: Windows 10 Pro Version 1803 (OS Build 17134.1040)
 OSType: windows
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.85GiB
 Name: DEV-DENUZIERE-01
 ID: N7AR:BUTN:QKC7:ENBG:CIFU:FG2P:DKO3:IS4V:QW4L:OXOR:WJOY:U2RR
 Docker Root Dir: C:\ProgramData\docker
 Debug Mode: true
  File Descriptors: -1
  Goroutines: 28
  System Time: 2019-10-17T13:03:22.7454661+02:00
  EventsListeners: 1
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

[wli3]

Did nanoserver remove more things? I remember testing it explicitly on nano servier before using this COM API

[MichaelSimons]

It looks like the DLL associated with {7B8A2D94-0AC9-11D1-896C-00C04FB6BFC4} is C:\Windows\System32\urlmon.dll. urlmon.dll does not exist on nanoserver. Moving this issue to the CLI repo.