Dotnet-docker: [Question] .NET core on Windows Server Core

[charisk]

I can see images for .NET core on nanoserver and .NET framework on Server Core, but I cant' find an image for .NET core on Windows Server Core? Is there a reason for that?

[MichaelSimons]

The reason a Nano Server image exists for .NET Core is because it is the best Windows Server container environment to run your .NET Core apps on. It is a much smaller SKU - smaller attack surface area, better performance, etc. .NET Framework has a Windows Server Core image because it is the only Windows Server container environment it is supported on.

What is your reason for wanting a .NET Core Windows Server Core based image?

[charisk]

I've got a .NET core app that calls out to PowerShell and needs full fat PowerShell instead of PowerShell core.

[MichaelSimons]

The current recommendation for scenarios like this would be to role your own Windows Server Core image which included .NET Core. You could start with the current .NET Core Nano Server Dockerfiles and change the FROM.

If there is enough demand for such images, we would certainly reconsider our decision.

[charisk]

Cool, thanks Michael!

[ronanmoriarty]

I'd like to reopen this to put forward another use case for having .NET Core on Windows Server Core images. I'm trying to run some UI tests in a .NET Core container but can't install dependencies (in my case, Chrome, for use with Chromedriver) because nanoserver images don't support MSI installers. As it's just for testing purposes, I'm less concerned about image size or attack surfaces - these images are for use purely in my build pipeline rather than in Production. I could definitely follow Michael's suggestion about copying the Dockerfile and just changing the FROM statement, but it feels like a reasonable case that you might want to support out of the box. You could have the two, with a recommendation towards the nanoserver-based version for performance and security reasons.

At the moment I'm weighing up copying the Dockerfile and changing the FROM statement, versus changing my acceptance test project back to targeting .NET Framework instead (so they can run against a Windows Server Core image). I'm open to other suggestions / workarounds. Thanks!

[MichaelSimons]

@ronanmoriarty, can you explain the UI tests you are running? What type of UI is this? What technology was the UI created with? Have you tried out your UI tests with WindowServerCore to know that everything works in your testing/product stack?

[ronanmoriarty]

The UI I'm trying to test is an ASP.NET Core website, but that's in a separate container from my tests, running on an image I created based on microsoft/dotnet:2.1-runtime - that tech stack isn't the issue - I can browse to that site running in that container from my host (Windows 10 Pro, 1803).

The problem I'm having is running _the tests themselves_ in a _separate_ container - these tests were written in a test dll targeting .NET Core 2.1, and they use ChromeDriver. These UI tests run fine when I run them directly on my host, pointing at the ASP.NET Core website running in the separate container. The tests pass when running on my host, as I have Chrome installed on my host.

To simplify dependencies when trying to run tests on build agents though, I'd like to move these tests from running directly a build agent, to running in a container on the build agent. I can't use a WindowServerCore image, as per your suggestion, as that won't have "dotnet test" available on it. However if I try to use microsoft/dotnet:2.1-sdk, that doesn't have Chrome installed, as required by my ChromeDriver tests. And because it's a nanoserver-based image, I can't use PowerShell to install Chrome. Am I making sense?

[ronanmoriarty]

@MichaelSimons Any thoughts on this? In short, I want to run headless-Chrome tests inside a microsoft/dotnet:2.1-sdk container, but can't, because I can't install Chrome on the container, because there's no PowerShell.

[MichaelSimons]

@ronanmoriarty - PowerShell is on the radar to add into the SDK images (https://github.com/dotnet/dotnet-docker/issues/360). We are waiting on some changes from the PowerShell team before this can be done. You can workaround this yourself by installing PowerShell yourself as a stopgap. You can find instructions on how to install here.

What I was trying to figure out from you is whether or not you have verified what you want to do (UI tests) is actually accomplish-able from within a container. What I am suggesting is that you create your own dotnet image based on WindowsServerCore in order to prove this out. As I suggested earlier in this issue, you can easily take the microsoft/dotnet Dockerfiles and change the from image as necessary. In your case take this Dockerfile and change this FROM instruction to reference a windowsservercore image.

[ronanmoriarty]

Hi Michael, thanks for the update! I probably didn't explain myself very well before, but I did try using the underlying Dockerfile, as you've suggested, only changing the FROM to WindowsServerCore, but I've ran into a few permissions problems on the statement trying to update the PATH to include C:\Program Files\dotnet - I suspect I'll be able to resolve it with a little bit more time, but thought I'd check with you about this in parallel. If I don't get that working soon I'll try your other suggestion to install PowerShell.

I'm not 100% certain that I'll be able to get the UI tests running in a container - I'll know better when I get your workaround above working to build an image with .NET Core SDK and Chrome installed. I've got regular .NET Core tests running fine in other containers, with test output written to volumes for collection by my CI server, so I suspect I should be able to get this running at some point - the tests are using Chrome in headless manner, so that should help.

I can't seem to find any other people trying to run tests in containers - I'm not sure why, as it seems like it could simplify build agent setup. Thanks for all your help, and I look forward to seeing PowerShell included!

[MichaelSimons]

@ronanmoriarty - regarding the permissions problem - can you share what your Dockerfile looks like and tell me what environment you are building on? Include the output of docker info.

[ronanmoriarty]

Sorry, the permissions issue was my own fault - after changing the FROM statement as suggested, I edited the original Dockerfile to remove the multitargeting as the installer and final images were both based on WindowServerCore after changing the FROM statement.

Starting again, when I copy the Dockerfile and only change the second FROM statement, that's all works fine. I'm still having a few issues with Webdriver but that's for me to figure out now! Thanks for all your help!

[nfriend]

Just to add another (somewhat related) use case for a full Windows Server Core version - I'd like the ability to run Chrome in headless mode in order to generate PDF reports using Puppeteer Sharp. Based on my limited testing, it seems that Chrome only runs on Windows Server Core, not Nano Server.

I would guess there are many other similar cases where Nano Server is not sufficient - it would be nice to be able to simply switch the base image from Nano Server to Windows Server Core in these cases.