aspnet / aspnet-docker

[Archived] ASP.NET Core Docker images for 1.x. Go to https://github.com/dotnet/dotnet-docker for 2.1 and up.
https://asp.net
719 stars 171 forks source link

ASP.NET Core stores not correctly included in Windows images #412

Closed mjrousos closed 6 years ago

mjrousos commented 6 years ago

Steps to reproduce the issue

  1. Create new ASP.NET Core 2.0 MVC app in Visual Studio 2017 and select the 'Docker support' check box. Select Windows as the OS.
  2. After creating the project, run docker-compose up from the project's directory on the command line.

Expected behavior

MVC app launches in a Nano Server container.

Actual behavior

Container fails to launch:

webapplication25_1  | Error:
webapplication25_1  |   An assembly specified in the application dependencies manifest (WebApplication25.deps.json) was not found:
webapplication25_1  |     package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.2'
webapplication25_1  |     path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'
webapplication25_1  |   This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
webapplication25_1  |     aspnetcore-store-2.0.6.xml
webapplication25_webapplication25_1 exited with code 2147516556

Additional information

It appears that the ASP.NET Core stores that should be copied in Nano Server images are not copied correctly. If I connect to the container directly (docker run -it microsoft/aspnetcore:2.0-nanoserver-1709 cmd.exe), it appears to contain the 2.0.0 store but not the later versions:

C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.antiforgery>dir
 Volume in drive C has no label.
 Volume Serial Number is AEC4-B89B

 Directory of C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.antiforgery

11/07/2017  02:07 AM    <DIR>          .
11/07/2017  02:07 AM    <DIR>          ..
11/07/2017  02:07 AM    <DIR>          2.0.0
               0 File(s)              0 bytes
               3 Dir(s)  21,209,595,904 bytes free

Output of docker info

Containers: 5
 Running: 1
 Paused: 0
 Stopped: 4
Images: 54
Server Version: 18.03.0-ce
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 16299 (16299.15.amd64fre.rs3_release.170928-1534)
Operating System: Windows 10 Pro
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 31.89GiB
Name: MJR-Dev-1
ID: IJQL:TQKN:7LGS:2ZII:OXSB:ENPL:AD5E:JJAK:LUZ3:MXNC:HSCU:5S4X
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 34
 System Time: 2018-04-23T14:46:54.5291574-04:00
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
natemcmaster commented 6 years ago

Can you try updating your image and tell me if the error persists?

docker pull microsoft/aspnetcore:2.0-nanoserver-1709
mjrousos commented 6 years ago

Thanks, @natemcmaster, that seems to have solved the problem. After pulling microsoft/aspnetcore:2.0-nanoserver-1709 and re-building my app's image, it launched as expected.

Can we version the aspnetcore image to match the ASP.NET Core store libraries included (microsoft/aspnetcore:2.0.7) so that people don't run into this?

natemcmaster commented 6 years ago

A tag already exists for microsoft/aspnetcore:2.0.7-nanoserver-1709. We publish the <major>.<minor> tags as a convenience to those who want their CI to run docker pull and automatically roll up to the latest patch, without having to change the FROM in their dockerfile. See https://hub.docker.com/r/microsoft/aspnetcore/ for a full list of tags.

Closing for now as it appears there's no action on our end.

mjrousos commented 6 years ago

Yea, having the <major>.<minor> tags makes sense as a convenience. The real problem is that the VS templates (which depend on the ASP.NET Core store being up-to-date) were using those instead of more precise tags. I'll follow-up with the VS folks.