microsoft/dotnet-framework-docker

The repo for the official docker images for .NET Framework on Windows Server Core.

Featured Repos

• dotnet/framework/sdk: .NET Framework SDK
• dotnet/framework/aspnet: ASP.NET Web Forms and MVC
• dotnet/framework/runtime: .NET Framework Runtime
• dotnet/framework/wcf: Windows Communication Foundation (WCF)
• dotnet/framework/samples: .NET Framework, ASP.NET and WCF Samples

About

The .NET Framework is a general purpose development platform maintained by Microsoft. It is the most popular way to build client and server applications for Windows and Windows Server. It is included with Windows, Windows Server and Windows Server Core. It includes server technologies such as ASP.NET Web Forms, ASP.NET MVC and Windows Communication Foundation (WCF) applications, which you can run in Docker containers.

.NET has several capabilities that make development easier, including automatic memory management, (runtime) generic types, reflection, asynchrony, concurrency, and native interop. Millions of developers take advantage of these capabilities to efficiently build high-quality web and client applications.

You can use C#, F# and VB to write .NET Framework apps. C# is simple, powerful, type-safe, and object-oriented while retaining the expressiveness and elegance of C-style languages. F# is a multi-paradigm programming language, enabling both functional and object-oriented patterns and practices. VB is a rapid development programming language with the deepest integration between the language and Visual Studio, providing the fastest path to a working app.

The .NET Framework was first released by Microsoft in 2001. The latest version is .NET Framework 4.8.

https://docs.microsoft.com/dotnet/framework/

Watch discussions for Docker-related .NET announcements.

Usage

The .NET Framework Docker samples show various ways to use .NET Framework and Docker together.

Container sample: Run a simple application

Type the following command to run a sample console application:

docker run --rm mcr.microsoft.com/dotnet/framework/samples:dotnetapp

Container sample: Run a web application

Type the following command to run a sample web application:

docker run -it --rm -p 8000:80 --name aspnet_sample mcr.microsoft.com/dotnet/framework/samples:aspnetapp

After the application starts, navigate to http://localhost:8000 in your web browser. You need to navigate to the application via IP address instead of localhost for earlier Windows versions, which is demonstrated in View the ASP.NET app in a running container on Windows.

Related repositories

• dotnet: .NET
• dotnet-nightly: .NET (Preview)
• dotnet/samples: .NET Samples

Support

Lifecycle

• .NET Framework Lifecycle FAQ
• Supported Tags Policy

Image Update Policy

• We update the supported .NET Framework images within 12 hours of any updates to their base images (e.g. windows/servercore:ltsc2019, windows/servercore:ltsc2022, etc.).
• We publish .NET Framework images as part of releasing new versions of .NET Framework including major/minor and servicing.

Feedback

• File an issue
• Contact Microsoft Support

License

• Microsoft Container Images Legal Notice: applies to all .NET Framework container images
• Microsoft Software Supplemental License for Windows Container Base Image: applies to all .NET Framework container images
• Visual Studio Tools License: applies to all .NET Framework SDK container images

dotnet-framework-docker's Issues

Missing Docker File for 4.7.1

The .NET 3.5 image doesn't clean up the the C:\build directory

Native images missing?

While investigating why a PowerShell healthcheck script consisting solely of iwr http://localhost/health -usebasic took three seconds and a full CPU core to execute, I discovered the .NET 4.7 container doesn't seem to have valid native images for framework assemblies. Running ngen update from inside the container built new images from mscorlib up, and reduced the script time to about 200ms.

Is it possible to have these either built into the base image, or background generated on container start?

Can't pull 4.7.1-windowsservercore-1709

I'm trying to pull the microsoft/dotnet-framework:4.7.1-windowsservercore-1709 image and every time the last layer finishes extracting I get this error.
I've checked the C:\ProgramData\Docker\windowsfilter folder while pulling and the first two layers are there.

I'm using docker-ce with Windows Containers for the first time in this machine so I think that I have a clean installation.
Version 17.09.0-ce-win33 (13620)
Channel: stable
8c56a3b
Shell:

λ» docker pull microsoft/dotnet-framework:4.7.1-windowsservercore-1709
4.7.1-windowsservercore-1709: Pulling from microsoft/dotnet-framework
5847a47b8593: Pull complete
768182d8a1bb: Pull complete
14c71c287f9a: Extracting [==================================================>]  78.29MB/78.29MB
failed to register layer: re-exec error: exit status 1: output: time="2017-11-08T11:03:06-02:00" level=error msg="hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471"
hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471

Docker log:

[10:51:43.529][ApiProxy       ][Info   ] proxy >> GET /_ping
[10:51:43.529][ApiProxy       ][Info   ] Dial name pipe  \\.\pipe\docker_engine_windows
[10:51:43.529][ApiProxy       ][Info   ] Successfully dialed name pipe \\.\pipe\docker_engine_windows
[10:51:43.529][ApiProxy       ][Info   ] proxy << GET /_ping
[10:51:43.530][WindowsDaemon  ][Info   ] debug: Calling GET /_ping
[10:51:43.531][ApiProxy       ][Info   ] proxy >> GET /v1.32/info
[10:51:43.531][ApiProxy       ][Info   ] Dial name pipe  \\.\pipe\docker_engine_windows
[10:51:43.531][ApiProxy       ][Info   ] Successfully dialed name pipe \\.\pipe\docker_engine_windows
[10:51:43.532][WindowsDaemon  ][Info   ] debug: Calling GET /v1.32/info
[10:51:43.539][ApiProxy       ][Info   ] proxy << GET /v1.32/info
[10:51:43.555][ApiProxy       ][Info   ] proxy >> POST /v1.32/images/create?fromImage=microsoft%2Fdotnet-framework&tag=4.7.1-windowsservercore-1709
[10:51:43.555][ApiProxy       ][Info   ] Dial name pipe  \\.\pipe\docker_engine_windows
[10:51:43.555][ApiProxy       ][Info   ] Successfully dialed name pipe \\.\pipe\docker_engine_windows
[10:51:43.557][WindowsDaemon  ][Info   ] debug: Calling POST /v1.32/images/create?fromImage=microsoft%2Fdotnet-framework&tag=4.7.1-windowsservercore-1709
[10:51:43.557][WindowsDaemon  ][Info   ] debug: Trying to pull microsoft/dotnet-framework from https://registry-1.docker.io v2
[10:51:45.847][WindowsDaemon  ][Info   ] debug: Pulling ref from V2 registry: microsoft/dotnet-framework:4.7.1-windowsservercore-1709
[10:51:46.685][WindowsDaemon  ][Info   ] debug: pulling blob "sha256:5847a47b8593f7c39aa5e3db09e50b76d42aa8898c0440c70cc9c69747d4c479"
[10:51:46.685][WindowsDaemon  ][Info   ] debug: pulling blob "sha256:14c71c287f9addee6fef2bd8b320c38a3120e86ad7176dc44497f5c4177568aa"
[10:51:46.686][WindowsDaemon  ][Info   ] debug: pulling blob "sha256:768182d8a1bb181439f7406a92cfa3d10f2751395fdd954c862ab100f8cde774"
[10:51:47.303][WindowsDaemon  ][Info   ] debug: Pulling sha256:5847a47b8593f7c39aa5e3db09e50b76d42aa8898c0440c70cc9c69747d4c479 from foreign URL https://go.microsoft.com/fwlink/?linkid=860907
[10:51:47.304][WindowsDaemon  ][Info   ] debug: Pulling sha256:768182d8a1bb181439f7406a92cfa3d10f2751395fdd954c862ab100f8cde774 from foreign URL https://go.microsoft.com/fwlink/?linkid=860916
[10:52:03.558][WindowsDaemon  ][Info   ] debug: Downloaded 14c71c287f9a to tempfile D:\Windows\TEMP\GetImageBlob495941575
[10:53:19.166][WindowsDaemon  ][Info   ] debug: Downloaded 768182d8a1bb to tempfile D:\Windows\TEMP\GetImageBlob958361489
[10:57:50.170][WindowsDaemon  ][Info   ] debug: Downloaded 5847a47b8593 to tempfile D:\Windows\TEMP\GetImageBlob773372538
[10:57:50.171][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer Flavour 1 ID a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582 parent 
[10:57:50.171][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer  - succeeded id=a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582 parent= flavour=1
[11:01:09.424][WindowsDaemon  ][Info   ] debug: Applied tar sha256:4bfe49d7bc33014df317149be23a71dfe176f2ddd6a78977068a37973dde89d8 to a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582, size: 4618854410
[11:01:09.465][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath Flavour 1 ID a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582
[11:01:09.466][WindowsDaemon  ][Info   ] debug: Calling proc (1)
[11:01:09.466][WindowsDaemon  ][Info   ] debug: Calling proc (2)
[11:01:09.466][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath succeeded flavour=1 id=a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582 path=C:\ProgramData\Docker\windowsfilter\a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582
[11:01:09.466][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer Flavour 1 ID 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5 parent a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582
[11:01:09.467][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer  - succeeded id=779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5 parent=a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582 flavour=1
[11:01:09.471][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath Flavour 1 ID a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582
[11:01:09.471][WindowsDaemon  ][Info   ] debug: Calling proc (1)
[11:01:09.471][WindowsDaemon  ][Info   ] debug: Calling proc (2)
[11:01:09.472][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath succeeded flavour=1 id=a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582 path=C:\ProgramData\Docker\windowsfilter\a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582
[11:02:55.125][WindowsDaemon  ][Info   ] debug: Applied tar sha256:c007b346b57336271844b8dec446233c6c96037a40f7375a98b2dc6d47b9f235 to 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5, size: 775586835
[11:02:55.171][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath Flavour 1 ID 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5
[11:02:55.171][WindowsDaemon  ][Info   ] debug: Calling proc (1)
[11:02:55.171][WindowsDaemon  ][Info   ] debug: Calling proc (2)
[11:02:55.172][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath succeeded flavour=1 id=779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5 path=C:\ProgramData\Docker\windowsfilter\779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5
[11:02:55.172][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer Flavour 1 ID 28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 parent 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5
[11:02:55.173][WindowsDaemon  ][Info   ] debug: hcsshim::CreateLayer  - succeeded id=28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 parent=779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5 flavour=1
[11:02:55.178][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath Flavour 1 ID 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5
[11:02:55.178][WindowsDaemon  ][Info   ] debug: Calling proc (1)
[11:02:55.179][WindowsDaemon  ][Info   ] debug: Calling proc (2)
[11:02:55.179][WindowsDaemon  ][Info   ] debug: hcsshim::GetLayerMountPath succeeded flavour=1 id=779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5 path=C:\ProgramData\Docker\windowsfilter\779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5
[11:03:07.509][WindowsDaemon  ][Info   ] debug: Cleaning up layer 28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0: re-exec error: exit status 1: output: time="2017-11-08T11:03:06-02:00" level=error msg="hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471" 
hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471
[11:03:07.509][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers query={}
[11:03:07.510][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers succeeded
[11:03:07.513][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer Flavour 1 ID 28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0-removing
[11:03:09.751][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer succeeded flavour=1 id=28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0-removing
[11:03:09.753][ApiProxy       ][Info   ] proxy << POST /v1.32/images/create?fromImage=microsoft%2Fdotnet-framework&tag=4.7.1-windowsservercore-1709
[11:03:09.754][WindowsDaemon  ][Info   ] Attempting next endpoint for pull after error: failed to register layer: re-exec error: exit status 1: output: time="2017-11-08T11:03:06-02:00" level=error msg="hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471" 
hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\28584d03cc630e6b39ed3b2bcbfe4fbcdb4ce0904be53472338805c613b174b0 flavour=1 folder=D:\Windows\TEMP\hcs915891471
[11:03:09.754][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers query={}
[11:03:09.754][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers succeeded
[11:03:09.781][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer Flavour 1 ID 779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5-removing
[11:03:25.051][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer succeeded flavour=1 id=779323313cdbc31482f5140a3649302914f3fc827c4775075caf96c63b96aaf5-removing
[11:03:25.053][WindowsDaemon  ][Info   ] Layer sha256:15dae6aa51f82ebf8a060364a446e9cdd586d564f3a25ed0a9e298849dcdefb4 cleaned up
[11:03:25.053][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers query={}
[11:03:25.053][WindowsDaemon  ][Info   ] debug: HCSShim::GetContainers succeeded
[11:03:25.098][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer Flavour 1 ID a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582-removing
[11:03:45.216][WindowsDaemon  ][Info   ] debug: hcsshim::DestroyLayer succeeded flavour=1 id=a3a1596b9d426c63f9354178cb775eeabda30e0caa1206029a2d21a861227582-removing
[11:03:45.221][WindowsDaemon  ][Info   ] Layer sha256:4bfe49d7bc33014df317149be23a71dfe176f2ddd6a78977068a37973dde89d8 cleaned up

Use manifest-based tags for Windows versions (RS1, RS3, ...)

Use manifest-based tags for Windows versions (RS1, RS3, ...)

We should use manifest-based tags for dotnet-framework images to enable the same tags to be used for RS1 and RS3. The Docker client will pull the correct image for the given OS (RS1 or RS1 and RS2 machines and RS3 for RS3+ machines).

The same change is being made to .NET Core images: dotnet/dotnet-docker#322

Experience

We want the following example behavior:

• Logical tag: 4.7.1
• RS1/2 physical tag: 10.0.14393.1770
• RS3+ physical tag: 4.7.1-windowsservercore-1709_KB4043961

This experience is only relevant for .NET Framework 4.7.1+ (only versions that are avaiable for both RS1 and RS3). This includes that latest tag.

Context

Docker offers a feature called manifest lists that enable you to create [multi-arch images](https://blog.docker.com/2017/09/docker-official-images-now-
multi-platform/). This feature enables a single logical tag to be exposed but that can result in different images for different operating systems. The feature was developed for different OSes -- Windows vs. Linux -- but it can also be used for different versions of the same OS. That's what we want here, to offer different images for the same logical tag, but differ by Windows version.

Windows container images are not as portable as Linux ones. Windows 10 RS3 images cannot be loaded on an RS1 system.

You need Docker 17.10 or later to use Windows-version-specific manifest list tags. The following change from the Docker 17.10 release notes is the one that enables this functionality.

• Add support for Windows version filtering on pull moby/moby#35090

Resources

• Windows Server Core Docker tags
• Windows 10 Version History

Add .NET Framework latest to 3.5 images

We've been creating images for .NET Framework latest. It stands to reason that the 3.5 images should include .NET Framework latest as well. It enables users to use the 3.5 image if they want all .NET versions to work in one image. This also applies to the .NET Framework builder image.

This is currently only a problem for the LTSC-2016 images.

No error message for supportedRuntime error case

Case: Add app.config for app with higher .NET Framework version than exists in dotnet-framework base image.

Expected: Text-based error.

Actual: No error reported.

msbuild.exe / full dotnet SDK

Hi,

I'd like to write about CI with Windows Containers and msbuild.

Can you help me put together an image which could run msbuild / nuget and output DLLs etc?

Here are a couple of posts I'm thinking about bringing under CI in a tutorial:

Docker voting app converted to Windows containers + ASP.NET:
http://blog.alexellis.io/p/2bca0a86-6c72-4b36-a5d0-73dc58cf847a/

Getting started guide for IIS / Windows Containers + .NET

http://blog.alexellis.io/run-iis-asp-net-on-windows-10-with-docker/

Build Tools 2015 fails to install on 4.7 image

I am attempting to install the Microsoft Build Tools 2015 on the current 4.7 image, but it crashes.

docker images
REPOSITORY                    TAG                 IMAGE ID            CREATED      SIZE
microsoft/dotnet-framework    4.7                 668d95076b9f        8 days ago      11.2 GB
<snip>

docker run -it --rm microsoft/dotnet-framework:4.7 cmd

C:\>powershell "(new-object System.Net.WebClient).DownloadFile('https://download.microsoft.com/download/E/E/D/EEDF18A8-4AED-4CE0-BEBE-70A83094FC5A/BuildTools_Full.exe', 'BuildTools_Full.exe')"

C:\>.\BuildTools_Full.exe  /NoRestart /Silent /Log BuildTools_Full.log

C:\>type BuildTools_Full.log
[0444:04D0][2017-06-22T15:04:40]i001: Burn v3.7.4029.0, Windows v10.0 (Build 14393:
Service Pack 0), path: C:\BuildTools_Full.exe, cmdline: '/NoRestart /Silent /Log BuildTools_Full.log -burn.unelevated BurnPipe.{DDFC2EE7-21B7-4C30-B9B0-241ABFD2848C} {2404657F-2B37-4560-B3EC-A54E3A761DE7} 2036'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'RebootRequested' to value '0'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'ExecuteSecondaryInstaller' to value '0'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'BundleProgressKey' to value 'Software\Microsoft\VisualStudio\14.0\Setup\BuildTools\Full'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'SetupFeedKey' to value 'Software\Microsoft\VisualStudio\14.0\Setup\BuildTools\Full'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'LicenseFwlinkId' to value '614950'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'MoreLanguageFwlinkId' to value '558795'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'VSEIPAndPrivacyFwlinkId' to value '558769'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'MinOsLevelFwlinkId' to value '558783'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'SolutionFwlinkId' to value '558770'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'HelpFwlinkId' to value '558771'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'IE10FwlinkId' to value '558773'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'Win81BlockFwlinkId' to value '558774'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'SHA256BlockFwlinkId' to value '558781'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'Win81PreRelBlockFwlinkId' to value '558775'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'UninstallMddInfoFwlinkId' to value '558777'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'ThirdPartyHelpFwlinkId' to value '558778'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing numeric variable 'UpdateXmlFwlinkId' to value '558780'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'NetfxProductVersion' to value '4.5.23026'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'ProfessionalVSVersion' to value '11.0.50727'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'ProductKey' to value '3NTMYRCPP3D7HMQMYJJKGJGWR'
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'ProductSKU' to value ''
[0444:04D0][2017-06-22T15:04:40]i000: Initializing string variable 'EditionDisplayName' to value 'Microsoft Build Tools 2015'
[0444:04D0][2017-06-22T15:04:40]i000: Setting string variable 'WixBundleLog' to value 'C:\BuildTools_Full.log'
[0444:04D0][2017-06-22T15:04:40]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\BuildTools_Full.exe'
[0444:04D0][2017-06-22T15:04:40]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\'
[0444:04D0][2017-06-22T15:04:41]i052: Condition '(VersionNT >= v6.1)' evaluates to true.
[0444:04D0][2017-06-22T15:04:41]i000: Setting string variable 'WixBundleName' to value 'Microsoft Build Tools 2015'
[0444:04D0][2017-06-22T15:04:41]i000: Loading managed bootstrapper application.
[0444:04D0][2017-06-22T15:04:42]i000: Creating BA thread to run asynchronously.
[0444:0788][2017-06-22T15:04:42]i000: Ux Started
[0444:0788][2017-06-22T15:04:42]i000: MUX:  Loading LocalizableStrings.xml string from LocalizableStrings.xml
[0444:0788][2017-06-22T15:04:42]i000: MUX:  Reset Result
[0444:0788][2017-06-22T15:04:42]i000: MUX:  Current action: Install
[0444:0788][2017-06-22T15:04:42]i000: Setting string variable 'CurrentOperation' to
value 'Install'
[0444:0788][2017-06-22T15:04:42]i000: Setting string variable 'IsLanguagePack' to value ''
[0444:0788][2017-06-22T15:04:42]i000: MUX:  Current action: Install
[0444:0788][2017-06-22T15:04:42]i000: Setting string variable 'CurrentOperation' to
value 'Install'
[0444:0788][2017-06-22T15:04:42]i000: MUX:  New last unconfirmed source: Web
[0444:0788][2017-06-22T15:04:42]i000: MUX:  Source confirmed
[0444:0788][2017-06-22T15:04:42]i000: Setting string variable 'CurrentRepairPackage' to value ''
[0444:0788][2017-06-22T15:04:42]i000: Setting numeric variable 'UpdateInModify' to value 0
[0444:0788][2017-06-22T15:04:42]i000: Setting numeric variable 'HypervisorSupported' to value 1
[0444:0788][2017-06-22T15:04:42]i000: Setting numeric variable 'HypervisorEnabled' to value 1
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Resume = None
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Restart = Never
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Relation = None
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Action = Install
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Display = None
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'CustomInstallPath' to value 'C:\Program Files (x86)'
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'ExecuteSecondaryInstaller' to value '0'
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'SecondaryInstallerParameters' to value ''
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'SecondaryInstallerDynamicItems' to value ''
[0444:0788][2017-06-22T15:04:43]i000: Setting numeric variable 'ConnectPipeToSecondaryInstaller' to value 0
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'SecondaryInstallerPipeName' to value ''
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'SecondaryInstallerPipeSecret' to value ''
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'RelationType' to value 'None'
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'DisplayMode' to value 'None'
[0444:0788][2017-06-22T15:04:43]i000: Setting numeric variable 'NetworkAvailable' to value 1
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'OriginalDisplayMode'
to value 'None'
[0444:0788][2017-06-22T15:04:43]i000: Setting string variable 'OriginalDisplayModeSwitch' to value '/quiet'
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Metrics: ShouldSendData=True
[0444:0788][2017-06-22T15:04:43]i000: MUX:  SetupAction: Install
[0444:0788][2017-06-22T15:04:43]i000: MUX:  ProductVersion: 14.0.23107.10
[0444:0788][2017-06-22T15:04:43]i000: MUX:  ProductLanguage: 1033
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Branch: d14rel
[0444:0788][2017-06-22T15:04:43]i000: MUX:  OS: Windows Server 2016 Datacenter
[0444:0788][2017-06-22T15:04:43]i000: MUX:  OSVersion: 10.0.14393.0
[0444:0788][2017-06-22T15:04:43]i000: MUX:  OSLanguage: 1033
[0444:0788][2017-06-22T15:04:43]i000: MUX:  OSArchitecture: AMD64
[0444:0788][2017-06-22T15:04:43]i000: MUX:  RecordVirtualMachineInformation version: vrtual - 1
[0444:0788][2017-06-22T15:04:43]i000: MUX:  RecordVirtualMachineInformation serialNumber: 8535-9947-8418-2435-4874-1591-48
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Ux Initialized
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Aquiring mutex 'Global\BuildTools_Full_amd64_Mutex' with a timeout of 0 ms
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Mutex 'Global\BuildTools_Full_amd64_Mutex' ownership: True
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Seen existing cache mutex 'Global\BuildTools_Full_amd64_Mutex CacheMutex': False
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Aquiring mutex 'Global\BuildTools_Full_amd64_Mutex CacheMutex' with a timeout of 60000 ms
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Mutex 'Global\BuildTools_Full_amd64_Mutex CacheMutex' ownership: True
[0444:0788][2017-06-22T15:04:43]e000: MUX:  ERROR: The type initializer for '<Module>' threw an exception.
[0444:0788][2017-06-22T15:04:43]e000: MUX:  Stack:    at Microsoft.Devdiv.Bootstrapper.ManagedUx.RunSilentUI(ViewModelSilent viewModel)
   at Microsoft.Devdiv.Bootstrapper.ManagedUx.InternalRun()
   at Microsoft.Devdiv.Bootstrapper.ManagedUx.Run()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()
[0444:0788][2017-06-22T15:04:43]e000: MUX:  Exception: Info: InnerException: Info:
[0444:0788][2017-06-22T15:04:43]e000: MUX:  ERROR: The C++ module failed to load during appdomain initialization.

[0444:0788][2017-06-22T15:04:43]e000: MUX:  Stack:    at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
   at .cctor()
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Metrics: ShouldSendData=True
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Permission to upload: Yes
[0444:0788][2017-06-22T15:04:43]i000: MUX:  Preparing to serialize data.
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Data serialized.
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Number of SQM File queued: 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  SQM sent: True
[0444:0788][2017-06-22T15:04:44]i000: Setting string variable 'CEIPConsent' to value ''
[0444:0788][2017-06-22T15:04:44]i000: Setting string variable 'SqmOption' to value ''
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: Configuration State
[0444:0788][2017-06-22T15:04:44]i000: MUX:  ----------------------------
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 426 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 8 = 31
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 596 = 5.0.0.0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 439 = BuildTools_Full_amd64
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 457 = 14.0.23107.10
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 440 = 14.0.23107
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 573 = d14rel
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 450 = 1033
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 15 = 2
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 16 = 198
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 1191 = 9
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 1193 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 1194 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 1189 = Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 3 = 1024
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 493 = 167784593
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 424 = 20119
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 453 = 10.0.14393.0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 13 = 1033
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 841 = 1
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 438 = 2
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 616 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 494 =
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 599 = 2
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 529 = False
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 833 = False
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 834 = False
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 563 = 000000000000
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 1063 = False
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 564 = False
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 439 = BuildTools_Full_amd64
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 457 = 14.0.23107.10
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 440 = 14.0.23107
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 437 = 1
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 461 =
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 517 = Crash: System.TypeInitialization
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 515 = 559b70de
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 501 = 449
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 642 = 37a
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 824 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 823 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Metrics: 434 = 0
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Watson Bucketting Parameters
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P1 - BuildTools_Full_amd64
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P2 - 14.0.23107.10
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P3 - 14.0.23107
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P4 - Install
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P5 -
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P6 - Crash: System.TypeInitialization
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P7 - 559b70de
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P8 - 449
[0444:0788][2017-06-22T15:04:44]i000: MUX:  P9 - 37a
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Adding Install Log to Watson=C:\BuildTools_Full.exe
[0444:0788][2017-06-22T15:04:44]i000: MUX:  Adding Install Log to Watson=C:\BuildTools_Full.log

Enable CI

CI should be enabled on this repo to ensure Dockerfiles are always in a buildable state are changes are made.

Publish of WebApplication results in no output due to lack of WebBuildTools workload

https://github.com/Microsoft/dotnet-framework-docker/blob/7636ebaba31bf2cc299fa1ebba0999a18f5cbbc6/4.7.1-windowsservercore-1709/build/Dockerfile#L20

Currently cannot successfully publish a ASP.NET MVC 4 Web Application probably due to missing Web Development Build Tools.

Got it working by creating my own (slightly modified) build-tools-container

# Use the latest Windows Server Core image.
FROM microsoft/windowsservercore

# Download useful tools to C:\Bin.
ADD https://dist.nuget.org/win-x86-commandline/v4.1.0/nuget.exe C:\\Bin\\nuget.exe

# Download the Build Tools bootstrapper outside of the PATH.
ADD https://aka.ms/vs/15/release/vs_buildtools.exe C:\\TEMP\\vs_buildtools.exe

# Add C:\Bin to PATH and install Build Tools excluding workloads and components with known issues.
RUN setx /m PATH "%PATH%;C:\Bin" 
RUN C:\TEMP\vs_buildtools.exe --quiet --wait --norestart --nocache --installPath C:\BuildTool \
    --add Microsoft.VisualStudio.Workload.WebBuildTools;includeRecommended \
    --add Microsoft.VisualStudio.Workload.MSBuildTools \
#    --remove Microsoft.VisualStudio.Component.Windows10SDK.10240 \
#    --remove Microsoft.VisualStudio.Component.Windows10SDK.10586 \
#    --remove Microsoft.VisualStudio.Component.Windows10SDK.14393 \
#    --remove Microsoft.VisualStudio.Component.Windows81SDK \
 || IF "%ERRORLEVEL%"=="3010" EXIT 0

ADD https://download.microsoft.com/download/9/0/1/901B684B-659E-4CBD-BEC8-B3F06967C2E7/NDP471-DevPack-ENU.exe C:\\TEMP\\NDP471-DevPack-ENU.exe
RUN C:\TEMP\NDP471-DevPack-ENU.exe /install /quiet /norestart

# SHELL ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-command"]

# Start developer command prompt with any other commands specified.
# ENTRYPOINT C:\BuildTools\Common7\Tools\VsDevCmd.bat &&

# Default to PowerShell if no other command specified.
CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]

Define tests for Dockerfiles

A basic set of tests should be defined for the Dockerfiles in this repo and run as part of CI (#66).

A set of test projects could be created (one project per supported .NET version). A multi-stage Dockerfile could then be defined. The Dockerfile can utilize the build images from this repo to build the project in one stage and then utilize the runtime images from this repo in a second stage to run the app. The tests can then simply build the Dockerfiles and run the resulting images.

Windows Docker Tag Scheme Changed

Windows Docker Tag Scheme Changed

.NET Core and .NET Framework Windows container images have been updated to use a new tag naming scheme for Windows container images, for both Windows Server Version 1709 and Windows Server 2016.

You will see the following changes in .NET Docker repos:

• Tag names will better describe Windows Release Channels.
• Only stable tags will be used.
• You will need to use image digests as the identifier for patch releases, as appropriate.

The following tags are examples of the new tag scheme:

• 2.0.0-runtime-nanoserver-1709
• 2.0.0-runtime-nanoserver-sac2016
• 4.7.1-windowsservercore-ltsc2016
• 4.7.1-windowsservercore-1709

This scheme is in use in the following repos:

• microsoft/aspnet
• microsoft/aspnetcore
• microsoft/aspnetcore-build
• microsoft/dotnet
• microsoft/dotnet-framework
• microsoft/wcf

Details

• dotnet/dotnet-docker #329
• Microsoft/dotnet-framework-docker #39
• dotnet/announcements #37
• dotnet/announcements #36

With the release of Windows Server 1709, Windows Server container images adopted stable tags, in addition to the release-specific tags already in use.

The following stable base tags are used in Windows repos, microsoft/nanoserver and microsoft/windowsservercore:

• Windows Server 2016 Server Core - ltsc2016
• Windows Server 2016 Nano Server - sac2016
• Windows Server 1709 Server Core - 1709
• Windows Server 1709 Nano Server - 1709

Notes: The 1709 release is a Semi Annual Channel release, but is missing the sac prefix. Windows Server 2016 Server Core is a Long Term Support Channel release.

Release-specific tags will still be used in Windows repos, which will look like the following examples:

• Windows Server 2016 - 10.0.14393.1770
• Windows Server 1709 - 1709_KB4043961

The following stable base tags will be used in .NET repos:

• Windows Server 2016 Server Core - windowsservercore-ltsc2016
• Windows Server 2016 Nano Server - nanoserver-sac2016
• Windows Server 1709 Server Core - windowsservercore-1709
• Windows Server 1709 Server Core - nanoserver-1709

The following tags are examples of the new tag scheme:

• 2.0.0-runtime-nanoserver-1709
• 2.0.0-runtime-nanoserver-sac2016
• 4.7.1-windowsservercore-ltsc2016
• 4.7.1-windowsservercore-1709

This scheme is in use in the following repos:

• microsoft/aspnet
• microsoft/aspnetcore
• microsoft/aspnetcore-build
• microsoft/dotnet
• microsoft/dotnet-framework
• microsoft/wcf

In cases that an immutable Docker reference is required, you are recommended to use an image digest instead of a tag name. Using an image digest will ensure that docker pull and build always use the same image, even after tags are updated.

The following string is an example of a digest reference:

microsoft/dotnet-framework@sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e

You can use this string as a parameter to docker pull or docker run. You can also use it with a FROM line to ensure that docker build is consistent, such as with the following.

FROM microsoft/dotnet-framework@sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e

You can determine an image digest with various Docker commands.

Image digests are displayed with every pull.

C:\>docker pull microsoft/dotnet-framework:4.7.1-windowsservercore-1709
4.7.1-windowsservercore-1709: Pulling from microsoft/dotnet-framework
Digest: sha256:bf8b882633fda16586b69c6f3937f9ccb176ff0c1c77542e175af38d9ee6714e
Status: Image is up to date for microsoft/dotnet-framework:4.7.1-windowsservercore-1709

Image digests are displayed for images with the --digests parameter.

$ docker images --digests
REPOSITORY            TAG                             DIGEST                                                                    IMAGE ID            CREATED             SIZE
microsoft/dotnet      2.0-runtime                     sha256:2e9ae1f83873ffb897f8fb7ada205b67b675a1b2c014d5875a49c050783cc469   c73382e1bbf7        38 hours ago        219MB                        

Image digests are displayed as part of docker inspect.

$ docker inspect microsoft/dotnet:2.0-runtime -f '{{.RepoDigests}}'
[microsoft/dotnet@sha256:2e9ae1f83873ffb897f8fb7ada205b67b675a1b2c014d5875a49c050783cc469]

We recommend that you use stable tags during development and image digests for production. This approach gives you an opportunity to test any image updates before they affect production apps. .NET images are updated each month with security updates. We recommend that you rebuild your images each month with these updates to ensure that applications are secure. You need to re-pull base images in order to update them. Otherwise, docker build is happy to use stale local copies of base images.

If you are not able to update source Dockerfiles regularly, then it may make more sense to reference stable tags. You still need to rebuild and redeploy your images in order to update your applications in production.

Support for Windows Authentication

I am in the understanding that windows auth is not supported in wcf docker images. This would be extremely valuable to have this supported.

Administrator password

I need the administrator password for launching a WCF host console (service crash when trying to open port because run as non-admin). But the administrator password is neither mention in the documentation of the dotnet-framework image nor in the windowsservercore image.

Where can I find this default password ?

Consider including Microsoft.VisualStudio.Workload.WebBuildTools in dotnet-framework-build image

Hi

Adding Microsoft.VisualStudio.Workload.WebBuildTools to the vs_BuildTools.exe install command in the dotnet-framework-build image would allow the builder image to be used more easily for publishing web deployments.

e.g.

FROM microsoft/dotnet-framework-build:4.7.1 as builder

WORKDIR /app
COPY . ./
RUN ["nuget.exe", "restore"]
RUN ["msbuild.exe", "Foo.sln", "/p:Configuration=Release", "/p:DeployOnBuild=true", "/p:PublishProfile=Disk"]

FROM microsoft/aspnet:4.7.1
COPY --from=builder /app/published /inetpub/wwwroot

Consider setting the backtick as the escape character in the Dockerfiles

Using the backtick as the escape character in Windows based Dockerfiles has several advantages. See the Dockerfile Reference for details. While it is not necessary, I believe it would be beneficial for Microsoft Dockerfiles to use the backtick escape character over the default backslash since they are often referenced and copied by many users. Using the backtick will reduce the chances of users encountering unintentional issues (e.g. COPY testfile.txt c:\)

This is already being used in the .NET Core Docker repos.

error in documentation - Dockerfile

Dockerfile line 3 should be "bin\Release" .
without the double quotes, it gives the following error
GetFileAttributesEx binRelease: The system cannot find the file specified

Create more extensive automated tests for SDK images

Some of the secondary components that are included in the build images are not covered by the automated tests that run as part of CI. Examples include VS Test Agent, Nuget CLI, PATH ENV contains the expected paths, etc.

Add build images for ASP.NET projects

The microsoft/dotnet-framework-build images are great, but it would be good to add a set for building web projects, targeting relevant .NET framework versions.

Currently users can build their own on top of these images by adding WebDeploy and the web build workload, but it would be nice to have official versions.

Sample for .NET 3.5:

# escape=`
FROM microsoft/dotnet-framework-build:3.5-windowsservercore-ltsc2016 AS builder
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# Install web workload
RUN Invoke-WebRequest -UseBasicParsing https://download.visualstudio.microsoft.com/download/pr/100196686/e64d79b40219aea618ce2fe10ebd5f0d/vs_BuildTools.exe -OutFile vs_BuildTools.exe; `
    Start-Process vs_BuildTools.exe -ArgumentList  '--add', 'Microsoft.VisualStudio.Workload.WebBuildTools', '--quiet', '--norestart', '--nocache' -NoNewWindow -Wait

# Install WebDeploy
RUN Install-PackageProvider -Name chocolatey -RequiredVersion 2.8.5.130 -Force; `
    Install-Package -Name webdeploy -RequiredVersion 3.6.0 -Force

Add .NET Framework 3.5 Builder Image

We recently added builder images. These images are specific to .NET Framework 4.x and have no allowance for building .NET Framework 2.0 and 3.x applications. That is obvious in microsoft/dotnet-framework-docker-samples#16.

We should create 3.5 images. I'm thinking that they should be based on the 3.5 image, add the 4.latest runtime and then otherwise look identical to the 4.x builder images.

NuGet version is not the same in the 1709 and ltsc2016 build images

See the differences:
https://github.com/Microsoft/dotnet-framework-docker/blob/master/4.7.1-windowsservercore-1709/build/Dockerfile#L7
https://github.com/Microsoft/dotnet-framework-docker/blob/master/4.7.1-windowsservercore-ltsc2016/build/Dockerfile#L7

Unable to rebuild 3.5 docker image

Hello I was hoping to be able to rebuild the 3.5 docker image on my desktop. I'm unable to build this because I'm missing the install directory. Will you please checkin your install directory so that we can recreate the docker image locally?

The dotnet-framework:4.7 image is ~12GB in size

Leveraging the dotnet-framework:4.7 as a base image for some dotnet applications however the size of the base image 12GB.

I understand its built on top of windowsservercore image but still a framework and runtime with 12GB is difficult to wrap my head around. I'm thinking about extracting the framework and runtime and build it off nanoservercore or using scratch. Am I missing something or some other existing image that is a lightweight version of just the dotnet framework and runtime?

Thanks.

Full framework Docker builds should use a similar cleanup logic as CI

1. Perform an official build of dotnet-framework-docker-pipebuild

2. Observe the Docker cleanup logic

Actual: Cleanup is performed by VSTS build steps that invoke docker system prune -a -f

Expected: Use a consistent cleanup pattern between CI and official builds. This means use the cleanup logic in build-and-test.ps1, and invoke this script with the appropriate arguments in CI and official builds. Refer to #79

Advantages of the proposed approach is -

• Single cleanup logic that can be used by CI and Official builds. Thus, reduces the maintenance costs.

• Official builds steps are simplified. build-and-test.ps1 encapsulates the logic of pulling ImageBuilder assemblies, and running the build-test within a container. Official build steps that try to achieve the same, should be replaced by a single step that invokes build-and-test.ps1. Thus, a similar pattern of build-test is followed in CI and official builds.

@MichaelSimons FYI

Issue while pulling "microsoft/dotnet-framework:3.5-windowsservercore-1709" image

Hello everyone,

I have an issue while I want do pull "microsoft/dotnet-framework:3.5-windowsservercore-1709" Image.
I have tried to pull the image from 3 differents computer and I still have the same Issue :

PS C:\Windows\system32> docker pull microsoft/dotnet-framework:3.5-windowsservercore-1709
3.5-windowsservercore-1709: Pulling from microsoft/dotnet-framework
5847a47b8593: Pull complete
9f887ccb8077: Pull complete
6f01d475c669: Extracting [==================================================>] 331.7MB/331.7MB
c10fd66f80df: Download complete
64761d42b426: Download complete
failed to register layer: re-exec error: exit status 1: output: time="2018-01-29T15:21:44Z" level=error msg="hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\\?\C:\ProgramData\Docker\windowsfilter\1002394cad81a62abcc5fd3bf8561c93da7d3ebbf542918e5286e0cc74e47d1a flavour=1 folder=C:\Windows\TEMP\hcs214503879"
hcsshim::ImportLayer failed in Win32: The system cannot find the file specified. (0x2) layerId=\?\C:\ProgramData\Docker\windowsfilter\1002394cad81a62abcc5fd3bf8561c93da7d3ebbf542918e5286e0cc74e47d1a flavour=1 folder=C:\Windows\TEMP\hcs214503879

Pulling "microsoft/windowsservercore:1709" works:
PS C:\Windows\system32> docker pull microsoft/windowsservercore:1709
1709: Pulling from microsoft/windowsservercore
5847a47b8593: Pull complete
9f887ccb8077: Pull complete
Digest: sha256:895ff031c39003a474365b9326dfa95b8f689434f16573943fcc38abed1d3a9b
Status: Downloaded newer image for microsoft/windowsservercore:1709

Pulling "microsoft/dotnet-framework:3.5-windowsservercore-ltsc2016" also works:
PS C:\Windows\system32> docker pull microsoft/dotnet-framework:3.5-windowsservercore-ltsc2016
3.5-windowsservercore-ltsc2016: Pulling from microsoft/dotnet-framework
3889bb8d808b: Pull complete
449343c9d7e2: Pull complete
f5deee6e1b63: Pull complete
153fdc43d57d: Pull complete
bfeb4c571e9e: Pull complete
Digest: sha256:3e3523155044acaaa6a848104c9fcf1ccd3d4f706a8549cf020174217f20a93e
Status: Downloaded newer image for microsoft/dotnet-framework:3.5-windowsservercore-ltsc2016

Thanks for your help

Best regards
Thomas

Build images don't support building SDK styled projects

The build images (e.g microsoft/dotnet-framework-build:4.7.1) don't support building SDK styled projects (e.g. the Full Fx 4.7 sample Docker project). In order to support these projects the .NET Core SDK would need to be added.

Consider merging .NET Framework Runtime and Builder Docker repos

We recently produced builder images for .NET Framework. Folks have been asking for those images for a long time, so that's good. We chose to add docker source assets for the builder images within this GitHub repo. Conversely, we chose to create a different Docker repo than the .NET Framework runtime repo for image assets. This is the same model as microsoft/aspnetcore-build.

For .NET Core, we chose a differently model, to share the same Docker repo and GitHub repo for both the runtime and builder/SDK images.

We decided to talk about this asymmetry in our approaches. Here are our take-aways:

Pros on using a single Docker repo for runtime + builder (SDK) assets:

• Most of our samples use multi-stage-build, which then pull from a single repo. That's simpler.
• Forces a single tag scheme.
• Any difference in support (like chip or OS) between runtime and builder is obvious.
• Builder and SDK together results in higher pull counts on a single repo, which pushes a given repo higher in the ranking in various Docker views where pull count is important. This isn't a vanity thing but a way of rising above the crowd around us.
• For .NET Core, we think of the SDK as the "getting started" distro while we seem to think of the Runtime as the "getting started" distro for .NET Framework. This leads to potential discontinuity in naming across .NET Core and .NET Framework if we we were to have separate runtime and builder repos with only one of them getting the "good" short name.

Pros on separate Docker repos:

• Smaller set of tags offered per repo, but the same set of tags to learn in aggregate.
• More focused meaning of a Docker repo, meaning a smaller set of tags to search through for a given repo.

A major take-away is that the microsoft/dotnet repo has been highly successful. By pull counts, it is far and away the most popular of our repos, with almost 10x pull traffic relative to the next .NET Docker repo. We think that this is in part due to the whole (runtime and SDK) of .NET Core being available in one place. Effectively, we nailed the discoverability problem. We're now wondering if we should do the same thing with microsoft/dotnet-framework, that is make the SDK/builder images available there as well. We want to make .NET Docker use/adoption easier and more convenient. Will this help with that?

We'd like your feedback.

The time-stamp portion of the stable tags in the build repo should be changed

The time-stamp portion of the stable tags (e.g. 4.7.1-2017.12-windowsservercore-1709) in the build repo have a couple issues.

1. They only include year and month therefore they don't support more than one release per month.
2. The time-stamp portion in general is a little hard to separate from the actual version. The both include numbers and dots.

Proposal:
Follow the time-stamp convention used in the ubuntu and debian repos - 20171225. Therefore a build tag would be something like 4.7.1-20171225-windowsservercore-1709

build images have pending assemblies to ngen

Run the following cmd

docker run --rm microsoft/dotnet-framework-build:4.7.1 C:\windows\microsoft.net\framework64\v4.0.30319\ngen.exe display

This will indicate there are many assemblies that have been queued to be ngen'd but ngen was never run. The assemblies should be ngen'd as part of the image so that first use of the build tools within the image is faster.

Ngen update doesn't check status code

I just noticed that we aren't checking exit codes when chaining together exe invocations.

https://github.com/Microsoft/dotnet-framework-docker/blob/master/4.7.1/Dockerfile#L7-L8

I'm not familiar with cmd, but the PowerShell equivalent would read something like this

RUN set COMPLUS_NGenProtectedProcess_FeatureEnabled=0; \
    if($LASTEXITCODE -ne 0){ Exit $LASTEXITCODE } ; \
    & 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen' update ; \
    if($LASTEXITCODE -ne 0){ Exit $LASTEXITCODE } ; \
    & 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen' update ; \
    if($LASTEXITCODE -ne 0){ Exit $LASTEXITCODE } ; \
    & 'C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen' update ; \
    if($LASTEXITCODE -ne 0){ Exit $LASTEXITCODE } ; \
    & 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen' update ;

Create tests that are run as part of CI that verify LCU is applied correctly

Currently this is done through a manual process. Would be valuable to automate this and have it run as part of CI.

microsoft/dotnet-framework images now support Windows Server 1709

microsoft/dotnet-framework images now support Windows Server 1709

Windows Server Version 1709 was released earlier this month. microsoft/windowsservercore images have been updated to support Windows Server 1709. These images can be identified with the 1709 tag.

The following repos have been updated:

• microsoft/aspnet
• microsoft/dotnet-framework
• microsoft/wcf

Details

• microsoft/dotnet-framework-docker #31
• microsoft/dotnet-framework-docker #34
• microsoft/dotnet-framework-docker #32

.NET Framework Docker images now support Windows Server 1709, the latest version of Windows Server.

.NET Framework 3.5 and 4.7.1 images are available for Windows Server 1709. Windows Server 1709 includes the .NET Framework 4.7.1. .NET Framework 4.6.2 and .NET Framework 4.7 images are only available with Windows Server 2016 images. You can see an example of 1709-based images in the following example.

You can identify Windows Server 1709-based .NET Framework images with the tag substring windowsservercore-1709 and Windows Server 2016 images with the tag substring windowsservercore-10.0.14393. You will likely notice that the 1709-based images are easier to identify than the Windows Server 2016 ones.

Changes have been made in Windows Server 1709 that affect the compatibility of Windows container images. The practical impact is that Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creative Update hosts cannot load Windows Server 1709 images. Windows 10 Fall Creative Update and Windows Server 1709 can load both original Windows Server 2016 and Windows Server 1709 images. Windows Server 1709 requires Hyper-V isolation (docker run --isolation=hyperv) in order to load Windows Server 2016 images.

Given the compatibility differences with Windows container images, .NET Framework images will adopt manifest lists so that a single logical tag, like 4.7.1, can be used on both older and newer Windows 10 and Windows Server versions. docker pull microsoft/dotnet-framework:4.7.1 will pull a Windows Server 2016 image on Windows Server 2016, Windows 10 Anniversary Update, and Windows 10 Creators Update machines. The same command will pull a Windows Server 1709 based image on Windows Server 1709 and Windows 10 Fall Creators Update machines. The same rules apply to FROM lines. .NET Core Docker images use this same feature to support Linux and Windows hosts and AMD64 and ARM32 hosts with the same logical tag, like 2.0-runtime.

The following tags will be updated to use manifest lists:

• latest
• 4.7.1
• 3.5

You need Docker 17.10 or later to use Windows-version-specific manifest list tags. The following change from the Docker 17.10 release notes is the one that enables this functionality.

• Add support for Windows version filtering on pull moby/moby#35090

You are only recommended to use manifest tags if you want flexibility for development and deployment environments. That's what manifest tags deliver. In general, you should select the most specific tag you can. The more specific the tag, the more predictable the result of each docker pull and docker build will be.

3.5 Runtime images contain unnecessary installer files

The microsoft/dotnet-framework:3.5-windowsservercore-1709 and microsoft/dotnet-framework:3.5-windowsservercore-ltsc2016 images contain installer files that are significant in size.

...
ADD install /build
RUN DISM /Online /Add-Package /PackagePath:C:\build\microsoft-windows-netfx3-ondemand-package.cab & \
    DISM /Online /Add-Package /PackagePath:C:\build\patch\Windows10.0-KB3213986-x64.cab  & \
    rd /s /q C:\build
...

Even though the installer files are deleted within the Dockerfile, because they are not deleted within the layer that they were created, the net result is that when the image is pulled the installer files are included within one of the layers. You can see this by looking at the layers.

> docker history microsoft/dotnet-framework:3.5-windowsservercore-ltsc2016
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
0bffe236f9e8        3 weeks ago         cmd /S /C set COMPLUS_NGenProtectedProcess...   985MB
<missing>           3 weeks ago         cmd /S /C DISM /Online /Add-Package /Packa...   1.11GB
<missing>           3 weeks ago         cmd /S /C #(nop) ADD dir:28ab8efa444c3f324...   1.32GB
<missing>           3 weeks ago         Install update 10.0.14393.1884                  2.72GB
<missing>           11 months ago       Apply image 10.0.14393.0                        7.68GB

> docker history microsoft/dotnet-framework:3.5-windowsservercore-1709
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
cb1fd09e4366        3 weeks ago         cmd /S /C set COMPLUS_NGenProtectedProcess...   1.06GB
<missing>           3 weeks ago         cmd /S /C DISM /Online /Add-Package /Packa...   864MB
<missing>           3 weeks ago         cmd /S /C #(nop) ADD dir:7cb14cb951c64e01e...   464MB
<missing>           4 weeks ago         Install update 10.0.16299.64                    962MB
<missing>           2 months ago        Apply image 10.0.16299.15                       4.62GB

microsoft/dotnet-framework latest tag updated to 4.7.1

microsoft/dotnet-framework latest tag updated to 4.7.1

The .NET Framework 4.7.1 was released earlier this month. The microsoft/dotnet-framework latest tag was also updated.

The .NET Framework 4.7.1 is represented by the microsoft/dotnet-framework:4.7.1 tag.

Details

• microsoft/dotnet-framework-docker #28
• microsoft/dotnet-framework-docker #27

The .NET Framework 4.7.1 image is now available as a Docker image. The latest tag points to the same image.

The following repos have been updated:

• microsoft/aspnet
• microsoft/dotnet-framework
• microsoft/wcf

The microsoft/dotnet-framework-samples repo has not yet been updated.

We recommend that you use version-specific tags for production apps. For experimentation or while an application is in development, using the latest tag is a fine practice.

We recently found a significant performance issue with .NET Framework Docker images. The .NET Framework 4.7.1 image includes the fix for that problem.

Unable to clone ssh-based GIT URIs

Not sure what happened, but up until last week, I was able to clone git repositories via SSH-based URIs in my Windows containers based on this image. Now, suddenly without warning, when I go to clone - even a public repository, I get this error:

C:\>git clone [email protected]:atrauzzi/praxis.git
git clone [email protected]:atrauzzi/praxis.git
Cloning into 'praxis'...
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Here's a simple Dockerfile that can be used to reproduce the issue:

FROM microsoft/dotnet-framework:4.7.1-windowsservercore-1709
SHELL ["powershell"]

RUN Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
RUN choco install --yes git

RUN refreshenv

I'm just not sure at this point. The only suspicious thing is that if I try to run the mingw based ssh.exe, it prints a blank line and then exits.

cc.

• https://forums.docker.com/t/unable-to-run-git-inside-a-windows-container/42803
• https://serverfault.com/questions/887752/unable-to-clone-ssh-based-git-uris-in-a-windows-container
• https://social.msdn.microsoft.com/Forums/en-US/4d2578c6-c380-4657-9dff-9f5eeb570cd3/git-clone-doesnt-work-in-container?forum=windowscontainers
• git-for-windows/git#1403

Offer image for .NET 4.5

Since .NET 4.6x is an in-place update and Windows Server Core ships with that, no docker image exists (that I can find) with .NET 4.5. For folks who are targeting .NET 4.5 and have light-up code to emulate .NET 4.6 behaviors, the only sure way of testing that is on a machine that does not have .NET 4.6 installed.

Can we get a docker image that has .NET 4.5 instead of 4.6, please?

Problem of setting Volume in Dockerfile

Hi,

I have one question about how to set Volume in Dockerfile. What we want to do is to map a folder in host to a folder(volume) in docker, so that the file written in docker can be accessed outside docker. We try kinds of formats, such as ".:\app", "[.:/app]", in Dockerfile, but seems it can not work correctly.

The error message is : "Unrecognised volume spec: invalid volume specification: '.:\app'".

Would you please let us know how to set the Volume of Dockerfile ?

Thanks a lot!

Cleanup Docker assets in CI

Repro:

1. Submit a PR
2. Wait for CI to finish

Actual: Docker assets (containers, images) are not cleaned up.

Expected: Docker assets produced during the check should be cleaned up always. This means cleanup whether the test gracefully exits or hits an exception.
CI invokes build-and-test.ps1 (https://github.com/Microsoft/dotnet-framework-docker/blob/master/build-and-test.ps1). Add a cleanup logic in this script. Refer to dotnet/dotnet-docker-nightly#529

ltsc2016 Dockerfiles should use microsoft/windowsservercore:ltsc2016 in FROM

Currently the ltsc2016 Dockerfiles use the following FROM

FROM microsoft/windowsservercore

It would arguably be better to use a tag that explicitly calls out the Windows Server version (e.g. microsoft/windowsservercore:ltsc2016)

4.7 Image Release

• Latest Image now points to 4.7
• These images have a new layering design outlined in our design repo.

Update Dockerfiles to use COPY instruction rather than ADD

To conform with Dockerfile best practices, the COPY instruction is preferred over ADD. All Microsoft Dockerfiles should be following the best practices as they are often referred upon and copied.

'Could not find Windows Runtime type 'Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher'.'

I have created one .Net Core Console App for reading Bluetooth messages and i have referenced Widows.winmd for using BluetoothLEAdvertisementWatcher (Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher). I am getting this "System.TypeLoadException: Could not find Windows Runtime type 'Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher'" error while running docker container.

Dockerfile:

FROM microsoft/dotnet:2.0-runtime-nanoserver-1709 AS base
WORKDIR /app

FROM microsoft/dotnet:2.0-sdk-nanoserver-1709 AS build
WORKDIR /src
COPY *.sln ./
COPY ConsoleApp1/ConsoleApp1.csproj ConsoleApp1/
RUN dotnet restore
COPY . .
WORKDIR /src/ConsoleApp1
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "ConsoleApp1.dll"]

Dockerfile links in Docker Hub are incorrect

The Dockerfile links in the README.md are not defined correctly.

-       [`4.6.2`, `latest` (*4.6.2/Dockerfile*)](4.6.2/Dockerfile)
-       [`3.5` (*3.5/Dockerfile*)](3.5/Dockerfile)

They are relative links which don't work when the README.md is displayed in Docker Hub. This results in 404s. The README.md should be using absolute paths.

authentication required ?

I tried a simple Dockerfile as

FROM mirosoft/donet-framework
WORKDIR windows-cs-test
COPY csc\helloworld.exe .
ENTRYPOINT ["helloworld.exe"]

and used

docker build -t testdotnet .

Sending build context to Docker daemon 36.25 MB
Step 1/4 : FROM mirosoft/donet-framework
unauthorized: authentication required

Anything I missed please ?

Thx

Ken

Provide better visibility creating ASP.NET apps in README

The current README doesn't do a good job of directing readers how to create ASP.NET apps using the dotnet-framework Docker image. We need to fix that.

At the very least, we should direct people to: https://github.com/Microsoft/dotnet-framework-docker-samples/tree/master/aspnetapp. I think we can do more than that.

/cc @kendrahavens, @glennc

How to install Visual C++ 2015 Redistributable to this image?

I have an ASP.NET application that requires native libraries to run. How could I install Microsoft Visual C++ 2015 Redistributable into this image?

Is it possible to have the latest Dotnet Core SDK on the microsoft/dotnet-framework-build?

Currently the microsoft/dotnet-framework-build has the following Dotnet Core SDK:

PS C:\> dotnet --info
.NET Command Line Tools (2.1.2)

Product Information:
 Version:            2.1.2
 Commit SHA-1 hash:  5695315371

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.2\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.3
  Build    : a9190d4a75f4a982ae4b4fa8d1a24526566c69df

Is it possible to get the latest version installed? i.e.

.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.4\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

I would like a single docker container that has both the .NET Framework and .NET Core SDK (2.1.4) installed. At the moment I need to take microsoft/dotnet-framework-build, and then layer on the .NET Core SDK.

If this is something that you would consider, I am happy to put forward a PR.

Add support for building .NET Framework applications with Docker

Microsoft should produce Docker images that can be utilized to build .NET Framework applications.

.NET Framework Docker Performance Issue Resolved

.NET Framework Docker Performance Issue Resolved

Multiple people have reported that .NET Framework performance in Docker images is poor. In the cases reported, performance was an order of magnitude slower than expected.

This issue has now been resolved for microsoft/dotnet-framework images. It was due to incorrectly generated NGEN images. They are now correctly generated and expected performance has been restored.

Details

• dotnet-framework-docker #27

The .NET Framework uses NGEN as a primary mechanism for startup performance. .NET Framework assemblies are compiled to native code with the NGEN tool as part of the .NET Framework setup process. The benefit of these files is that they can be loaded and executed without any additional significant extra work required by the Common Language Runtime (CLR). The lack of additional work means that performance is very good.

NGEN image generation interacts with a Windows subsystem that is not correctly supported in Windows containers. NGEN images are generated in Windows containers, but they are not valid. Fortunately, the CLR can still run in the presence of invalid images, but code execution is much slower.

We are in the process of fixing Windows containers so that NGEN will work correctly. In the interim, we have updated the dotnet-framework/ images to correctly generate NGEN images. The microsoft/windowsservercore/ images still have the performance problem that was initially reported. We are working on updating Windows containers so that NGEN works as expected. You are recommended to use the dotnet-framework/ base image if you can, so that you can get better performance.

One of the developers that reported the performance issue shared basic performance results. The first two rows are the before state. The last row is the dotnet-framework image after the fix. The improvement is quite significant.

Runing powershell -command (measure-command { powershell -command exit }).TotalSeconds in various images on our CI server produced this table of timings:

time (s)	image
10.7212372	microsoft/windowsservercore
8.3278793	microsoft/dotnet-framework:4.7
0.6426073	microsoft/dotnet-framework:4.7 (after fix)
0.1642161	microsoft/dotnet-framework:4.7.1-windowsservercore-1709