ASP.NET Core - Problemy podczas debugowania przez Docker w Visual Studio 2015

Question

Mam do czynienia z problemami podczas uruchamiania mojej aplikacji zbudowanej na ASP.NET Core przy użyciu Docker w Visual Studio. Moja aplikacja wykorzystuje tylko framework dnxcore50. Mój plik project.json jest:

{ 
    "version": "1.0.0-*", 
    "compilationOptions": { 
    "emitEntryPoint": true 
    }, 
    "dependencies": { 
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final", 
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final", 
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final", 
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final" 
    }, 
    "frameworks": { 
    "dnxcore50": { } 
    }, 
    "exclude": [ 
    "wwwroot", 
    "node_modules" 
    ], 
    "publishExclude": [ 
    "**.user", 
    "**.vspscc" 
    ], 
    "commands": { 
    "web": "Microsoft.AspNet.Server.Kestrel" 
    } 
} 

Próbowałem następujących sposobów:

1. Kiedy moje punkty dnvm z czasem przebiegu DNX-coreclr-win-x64.1.0.0-RC1-update1 jako pokazano na rysunku poniżej.

Moja aplikacja buduje pomyślnie. Ale otrzymuję następujący błąd na prowadzenie/debugowanie aplikacji na docker i mój wniosek utknie w „miejscu Otwarcia http://192.168.99.100:5000” Szczegóły

błąd: obecne ramy wykonawcze nie jest kompatybilny z „aplikacji” The Obecne ramy docelowej Runtime: 'DNX, Version = V4.5.1 (dnx451)' proszę upewnić się, że środowisko wykonawcze mecze ramy określone w project.json

2. jak sugeruje powyższy komunikat o błędzie istnieje niedopasowanie w ramach, zmieniłem domyślne i aktywne środowisko wykonawcze na dnx-coreclr-linux-x64.1.0.0-rc1-update1 przez zmodyfikowanie domyślnego aliasu i wykonanie polecenia dnvm use default -p. Następnie restartuję mój VS (aby upewnić się, że zmiany są widoczne w VS).

Jednak moja aplikacja nadal opiera się na DNX wersji V4.5.1 jak zasugerowano w dziennikach kompilacji poniżej:

1> Information: [LoaderContainer]: Load name=Microsoft.Dnx.Tooling 
1> Information: [PathBasedAssemblyLoader]: Loaded name=Microsoft.Dnx.Tooling in 2ms 
1> Information: [Bootstrapper] Runtime Framework: DNX,Version=v4.5.1 
1> Microsoft .NET Development Utility Mono-x64-1.0.0-rc1-16231 

Stąd wniosek ponownie nie powiedzie się uruchomić z tego samego błędu jak w punkcie 1.

Dodatkowo, po zmianie domyślnego środowiska uruchomieniowego, przywracanie dnu przestaje działać z linii poleceń i daje z następującym błędem:

'dnu' is not recognized as an internal or external command, operable program or batch file.

Co ciekawe, polecenie przywracania "dnu" nadal działa z VS (zgodnie z sugestiami zawartymi w dziennikach kompilacji VS).

3. Następnie próbuje zmieniać dnvm wykonawczego do dnx-mono.1.0.0-RC1-update1. Ale to nie powiedzie się z następującym błędem:

Cannot find dnx-mono.1.0.0-rc1-update1.1.0.0-rc1-update1, do you need to run 'dnvm install default'? At C:\Program Files\Microsoft DNX\Dnvm\dnvm.ps1:1659 char:9 + throw "Cannot find $runtimeFullName, do you need to run '$Com ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (Cannot find dnx...stall default'?:String) [], Run timeException + FullyQualifiedErrorId : Cannot find dnx-mono.1.0.0-rc1-update1.1.0.0-rc1-update1, do you nee d to run 'dnvm install default'?

Co Runtime muszę użyć do uruchomienia docker z VS i jak mogę ją zmienić? Poproś o pomoc w rozwiązaniu problemu.

Aktualizacja I w końcu udało się rozwiązać ten problem poprzez zmianę pliku doker pierwszej linii do FROM microsoft/aspnet:1.0.0-rc1-update1-coreclr OD microsoft/aspnet:1.0.0-rc1-update1. Dzięki @bertt za cynk.

Answer 1

co znajduje się w pierwszym wierszu pliku dockerfile? powinien być "Z microsoft/aspnet: 1.0.0-rc1-update1-coreclr" dla CoreClr

Answer 2

Czytałem o tym w podobny post tutaj na stackoverflow

problemem może być to, że Kestrel słucha tylko localhost domyślnie.

Możesz zmienić swoją dockerfile zawierające:

ENTRYPOINT ["dnx", "web", "--server.urls", "http://0.0.0.0:5000"] 

lub alternatywnie tylko modyfikując ostatnią część swojej project.json do

"commands": { 
    "web": "Microsoft.AspNet.Server.Kestrel --server.urls http://0.0.0.0:5000" 
    } 

może również pracować.