Jak mogę zdiagnozować brakujące zależności (lub inne awarie modułu ładującego) w dnx?

Próbuję uruchomić zmodyfikowaną wersję przykładu HelloWeb dla ASP.NET vNext na DNX przy użyciu Kestrel. Rozumiem, że jest to bardzo na plusie, ale mam nadzieję, że zespół ASP.NET przynajmniej utrzyma działanie najprostszej możliwej aplikacji internetowej :)

Środowisko:

• Linux (Ubuntu, prawie)
• Mono 3.12.1
• DNX 1.0.0-beta4-11257 (mam też dostępne 11249)

Kod „aplikacji internetowej”, w Startup.cs:

using Microsoft.AspNet.Builder;
public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.UseWelcomePage();
    }
}

Konfiguracja projektu, w project.json:

{
  "dependencies": {
    "Kestrel": "1.0.0-beta4",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta4",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4",
    "Microsoft.AspNet.StaticFiles": "1.0.0-beta4",
    "Microsoft.Framework.Runtime": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Common": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Loader": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Interfaces": "1.0.0-beta4",
  },
  "commands": {
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
  },
  "frameworks": {
    "dnx451": {}
  }
}

kpm restore wydaje się działać dobrze.

Kiedy jednak próbuję uruchomić, pojawia się wyjątek sugerujący, że Microsoft.Framework.Runtime.IApplicationEnvironmentnie można go znaleźć. Wiersz poleceń i błąd (nieco przeformatowany)

.../HelloWeb$ dnx . kestrel
System.IO.FileNotFoundException: Could not load file or assembly 
'Microsoft.Framework.Runtime.IApplicationEnvironment,
  Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'Microsoft.Framework.Runtime.IApplicationEnvironment,
  Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
    (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke 
    (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder,
     System.Object[] parameters, System.Globalization.CultureInfo culture)
    [0x00000] in <filename unknown>:0

Chociaż oczywiście moją najpilniejszą potrzebą jest naprawienie tego, byłbym również wdzięczny za porady, jak przejść, aby zdiagnozować, co się dzieje, aby móc samodzielnie naprawić podobne problemy w przyszłości. (Prawdopodobnie sprawi to również, że to pytanie będzie bardziej przydatne również dla innych).

Znalazłem Microsoft.Framework.Runtime.IApplicationEnvironmentw Microsoft.Framework.Runtime.Interfacesźródle zestawu i wygląda na to, że ostatnio się nie zmieniło. Nie jest jasne, dlaczego wyjątek pokazuje nazwę tak, jakby była całym zestawem samym w sobie, a nie tylko interfejsem w innym zestawie. Zgaduję, że może to być spowodowane neutralnymi interfejsami montażu , ale nie jest to jasne z błędu. ( [AssemblyNeutral]nie żyje, więc to nie to ... )

Dobre pytanie. W przypadku Twojego konkretnego problemu wygląda na to, że masz niezgodność w rozwiązanych zależnościach. Kiedy zdarzają się takie rzeczy, jest to prawdopodobnie spowodowane tym, że uruchamiasz aplikację na niezgodnym pliku dnx. Wciąż wprowadzamy bardzo duże zmiany, więc jeśli kiedykolwiek zauważysz, że brakuje metody lub typu, prawdopodobnie skończyłeś uruchomieniem betaXpakietów i betaYdnx lub odwrotnie.

Mówiąc dokładniej, interfejsy Assembly Neutral zostały usunięte w wersji beta4, ale wygląda na to, że aplikacja, którą uruchomiłeś, nadal ich używa.

Planujemy zrobić to tak, aby pakiety mogły oznaczać minimalne dnx, których wymagają do uruchomienia, aby komunikat o błędzie był bardziej przejrzysty. Z biegiem czasu przełomowe zmiany zanikną.

Ogólnie jednak wydaje mi się, że nadszedł czas, aby napisać poradnik dotyczący diagnozowania takich problemów podczas korzystania z dnx (ponieważ różni się on od istniejącego .NET).

Zależności, w które wkładasz, project.jsonsą tylko na najwyższym poziomie. Wersje są również zawsze wartościami minimalnymi (podobnie jak pakiet NuGet). Oznacza to, że kiedy określasz Foo 1.0.0-beta4, naprawdę określasz Foo >= 1.0.0-beta4. Oznacza to, że jeśli poprosisz, MVC 0.0.1a minimalna wersja w skonfigurowanym kanale wynosi MVC 3.0.0, otrzymasz tę. NIGDY nie udostępniamy również Twojej wersji, chyba że ją określisz. Jeśli poprosisz o 1.0.0 i istnieje, otrzymasz 1.0.0, nawet jeśli istnieją nowsze wersje. Określanie pustych wersji jest ZAWSZE złe i będzie niedozwolone w późniejszych kompilacjach.

Wprowadzamy nową funkcję nuget o nazwie wersje pływające. Dziś działa tylko na tagu przedpremierowym, ale w następnej wersji będzie działać na większej liczbie części wersji. Jest to podobne do składni npm i gem do określania zakresów wersji w pliku specyfikacji pakietu.

1.0.0-*- Oznacza, że ​​daj mi NAJWYŻSZĄ wersję pasującą do prefiksu (zgodnie z regułami wersjonowania semantycznego ) LUB jeśli nie ma wersji pasującej do tego prefiksu, użyj normalnego zachowania i uzyskaj NAJNIŻSZĄ wersję> = określona wersja.

Kiedy uruchomisz przywracanie w najnowszych kompilacjach, zapisze plik o nazwie project.lock.json. Ten plik będzie miał przechodnie zamknięcie zależności dla wszystkich platform docelowych zdefiniowanych w project.json.

Gdy coś takiego zawiedzie, możesz wykonać następujące czynności:

Przyjrzyj się rozwiązanym zależnościom za pomocą kpm list. To pokaże rozwiązane wersje pakietów, do których odwołuje się twój projekt i jaka zależność go wciągnęła. Np. Jeśli A -> B, pokaże:

ZA
  -> B.
b
 ->

Rzeczywiste dane wyjściowe listy KPM:

Lista zależności dla ClassLibrary39 (C: \ Users \ davifowl \ Documents \ Visual Studio 14 \ Projects \ ClassLibrary39 \ src \ ClassLibrary39 \ project.json)

[Target framework DNX,Version=v4.5.1 (dnx451)]

 framework/Microsoft.CSharp 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/mscorlib 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System.Core 4.0.0.0
    -> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0

[Target framework DNXCore,Version=v5.0 (dnxcore50)]

*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0
 System.Runtime 4.0.20-beta-22709
    -> ClassLibrary39 1.0.0

* oznacza bezpośrednią zależność.

Jeśli masz działające studio wizualne (które obecnie zrywa z DNX), możesz spojrzeć na węzeł odwołań. Zawiera te same dane przedstawione wizualnie:

Spójrzmy, jak wygląda awaria zależności:

Oto plik project.json

{
    "version": "1.0.0-*",
    "dependencies": {
        "Newtonsoft.Json": "8.0.0"
    },

    "frameworks" : {
        "dnx451" : { 
            "dependencies": {
            }
        },
        "dnxcore50" : { 
            "dependencies": {
                "System.Runtime": "4.0.20-beta-22709"
            }
        }
    }
}

Newtonsoft.Json 8.0.0nie istnieje. Tak więc uruchomienie przywracania kpm pokazuje następujące informacje:

Podczas diagnozowania, kiedy przywracanie mogło się nie powieść, spójrz na wykonane żądania HTTP, które informują, jakie skonfigurowane źródła pakietów szukały kpm. Zauważ, że na powyższym obrazku jest CACHEżądanie. Jest to wbudowane buforowanie oparte na typie zasobu (nupkg lub nuspec) i ma konfigurowalne TTL (patrz kpm restore --help). Jeśli chcesz wymusić kpmuderzenie w zdalne źródła NuGet, użyj --no-cacheflagi:

Te błędy są również wyświetlane w programie Visual Studio w oknie danych wyjściowych dziennika menedżera pakietów:

Dygresja!

Źródła pakietów

Opiszę sposób, w jaki NuGet.config działa teraz (co prawdopodobnie zmieni się w przyszłości). Domyślnie masz NuGet.config z domyślnym źródłem NuGet.org skonfigurowanym globalnie w %appdata%\NuGet\NuGet.Config. Możesz zarządzać tymi globalnymi źródłami w programie Visual Studio lub za pomocą narzędzia wiersza polecenia NuGet. Podczas próby zdiagnozowania awarii należy zawsze spojrzeć na efektywne źródła (te wymienione w danych wyjściowych kpm).

Przeczytaj więcej o NuGet.config tutaj

Powrót do rzeczywistości:

Gdy zależności są nierozwiązane, uruchomienie aplikacji da ci to:

> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
   Newtonsoft.Json 8.0.0

Searched Locations:
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
  C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll

Try running 'kpm restore'.

   at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
   at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)

Środowisko wykonawcze zasadniczo próbuje sprawdzić, czy cały wykres zależności jest rozwiązany przed próbą uruchomienia. Jeśli sugeruje uruchomienie, oznacza kpm restoreto, że nie może znaleźć wymienionych zależności.

Innym powodem, dla którego możesz otrzymać ten błąd, jest to, że używasz niewłaściwego smaku dnx. Jeśli twoja aplikacja określa tylko dnx451 i spróbujesz uruchomić CoreCLR dnx, możesz zobaczyć podobny problem. Zwróć szczególną uwagę na platformę docelową w komunikacie o błędzie:

Do biegania:

dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}

Kiedy próbujesz uruchomić, pamiętaj, że mapowanie mentalne z CLR na platformę docelową zdefiniowane w Twoim project.json.

To również pojawia się w programie Visual Studio w węźle odwołań:

Węzły oznaczone na żółto są nierozwiązane.

Te również pojawiają się na liście błędów:

Budynek

Te błędy pojawiają się również podczas budowania. Podczas budowania z wiersza poleceń dane wyjściowe są bardzo szczegółowe i mogą być niezwykle przydatne podczas diagnozowania problemów:

> kpm build

Building ClassLibrary39 for DNX,Version=v4.5.1
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json

  Using Assembly dependency framework/mscorlib 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll

  Using Assembly dependency framework/System 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll

  Using Assembly dependency framework/System.Core 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll

  Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll


Building ClassLibrary39 for DNXCore,Version=v5.0
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json

  Using Package dependency System.Console 4.0.0-beta-22709
    Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
    File: lib\contract\System.Console.dll

  Using Package dependency System.IO 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
    File: lib\contract\System.IO.dll

  Using Package dependency System.Runtime 4.0.20-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
    File: lib\contract\System.Runtime.dll

  Using Package dependency System.Text.Encoding 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
    File: lib\contract\System.Text.Encoding.dll

  Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
    File: lib\contract\System.Threading.Tasks.dll

Dane wyjściowe pokazują wszystkie zestawy przesłane do kompilatora z pakietów i odwołań do projektów. Gdy zaczniesz otrzymywać błędy kompilacji, warto zajrzeć tutaj, aby upewnić się, że pakiet, którego używasz, faktycznie działa na tej platformie docelowej.

Oto przykład pakietu, który nie działa na dnxcore50:

{
    "version": "1.0.0-*",
    "dependencies": {
        "Microsoft.Owin.Host.SystemWeb": "3.0.0"
    },

    "frameworks": {
        "dnx451": {
            "dependencies": {
            }
        },
        "dnxcore50": {
            "dependencies": {
                "System.Console": "4.0.0-beta-22709"
            }
        }
    }
}

Microsoft.Owin.Host.SystemWeb w wersji 3.0.0 nie ma żadnych zestawów działających na dnxcore50 (spójrz na folder lib rozpakowanego pakietu). Kiedy biegamy kpm build:

Zauważ, że jest napisane „using Package Microsoft.Owin.Host.SystemWeb”, ale nie ma „File:”. Może to być przyczyną niepowodzenia kompilacji.

Tutaj kończy się mój zrzut mózgu

Nadal nie wiem do końca, co było nie tak, ale mam teraz serię kroków, aby przynajmniej ułatwić wypróbowywanie różnych rzeczy:

• W razie wątpliwości zainstaluj ponownie dnx
  • Pomocne może być usunięcie pamięci podręcznej pakietów
• Sprawdź, ~/.config/NuGet.configczy używasz odpowiednich źródeł danych NuGet

Skończyło się na tym, że użyłem następującego wiersza poleceń, aby przetestować różne opcje w dość czysty sposób:

rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel

Wygląda na to, że mój problem był naprawdę spowodowany instalacją niewłaściwych wersji zależności. Numer wersji programu "1.0.0-beta4"jest najwyraźniej zupełnie inny niż "1.0.0-beta4-*". Na przykład Kestrelzależność zainstalowała wersję 1.0.0-beta4-11185, gdy została określona jako 1.0.0-beta4, ale wersja 1.0.0-beta4-11262 z rozszerzeniem -*na końcu. Chciałem beta4wyraźnie określić, aby uniknąć przypadkowego użycia wersji beta3 z rozszerzeniem

Następująca konfiguracja projektu działa poprawnie:

{
  "dependencies": {
    "Kestrel": "1.0.0-beta4-*",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta4-*",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4-*",
  },
  "commands": {
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
  },
  "frameworks": {
    "dnx451": {}
  }
}

Można ustawić var env nazwie DNX_TRACEaby 1zobaczyć mnóstwo info Więcej diagnostycznego. Ostrzegam, to dużo więcej informacji!

Aby to działało, zmodyfikowałem mój project.json… teraz wygląda tak:

{
"dependencies": {
    "Kestrel": "1.0.0-*",
    "Microsoft.AspNet.Diagnostics": "1.0.0-*",
    "Microsoft.AspNet.Hosting": "1.0.0-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-*",
    "Microsoft.AspNet.StaticFiles": "1.0.0-*"
},
"commands": {
    "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5001",
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
    }
}

Wydawało się, że kluczem była sekcja dotycząca ram.

Zmiana nazwy również zmieniła sposób k webdziałania, tak że teraz dnx . weblubdnx . kestrel

Aktualizacja - trochę więcej informacji

Co dziwne, po uruchomieniu bez zdefiniowanych frameworków poszło i dostałem kilka dodatkowych rzeczy, gdy to zrobiłem kpm restore:

...
Installing Microsoft.Framework.Logging 1.0.0-beta4-11001
Installing Microsoft.Framework.Logging.Interfaces 1.0.0-beta4-11001
Installing Microsoft.Framework.DependencyInjection.Interfaces 1.0.0-beta4-11010
Installing Microsoft.Framework.DependencyInjection 1.0.0-beta4-11010
Installing Microsoft.Framework.ConfigurationModel 1.0.0-beta4-10976
Installing Microsoft.Framework.ConfigurationModel.Interfaces 1.0.0-beta4-10976
Installing Microsoft.AspNet.Hosting.Interfaces 1.0.0-beta4-11328
Installing Microsoft.AspNet.FeatureModel 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http 1.0.0-beta4-11104
Installing Microsoft.AspNet.FileProviders.Interfaces 1.0.0-beta4-11006
Installing Microsoft.Framework.Caching.Interfaces 1.0.0-beta4-10981
Installing Microsoft.AspNet.FileProviders 1.0.0-beta4-11006
Installing Microsoft.AspNet.Http.Core 1.0.0-beta4-11104
Installing Microsoft.AspNet.WebUtilities 1.0.0-beta4-11104
Installing Microsoft.Net.Http.Headers 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http.Interfaces 1.0.0-beta4-11104
Installing Microsoft.Framework.Runtime.Interfaces 1.0.0-beta4-11257
Installing Microsoft.AspNet.Server.Kestrel 1.0.0-beta4-11262
Installing Microsoft.Net.Http.Server 1.0.0-beta4-11698
Installing Microsoft.Net.WebSockets 1.0.0-beta4-11698
Installing Microsoft.Net.WebSocketAbstractions 1.0.0-beta4-10915
Installing Microsoft.Framework.WebEncoders 1.0.0-beta4-11104
Installing Microsoft.Framework.OptionsModel 1.0.0-beta4-10984
Installing Microsoft.AspNet.Http.Extensions 1.0.0-beta4-11104
Installing Microsoft.AspNet.Diagnostics.Interfaces 1.0.0-beta4-12451
Installing Microsoft.AspNet.RequestContainer 1.0.0-beta4-11328

.. wtedy wszystko poszło dobrze. Następnie wróciłem do sekcji frameworka

"frameworks": {
    "dnx451": {}
}

.. i nadal działało, a wcześniej wyrzucał błąd!

Bardzo dziwne!

(Biegnę 1.0.0-beta4-11257)

Dalsza aktualizacja

Uruchomiłem nową instancję Ubuntu i otrzymałem ten sam błąd co ty. Pomyślałem, że problem może być spowodowany tylko próbą pobrania pakietów z, nuget.orga nie myget.org(która ma nowsze rzeczy), więc upuściłem a NuGet.Configdo katalog główny projektu ..

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/" />
    <add key="NuGet" value="https://nuget.org/api/v2/" />
  </packageSources>
</configuration>

.. wydaje się, że naprawiło to dla mnie poprzez pobranie poprawnych wersji (po kolejnej kpm restore).

Obecnie wszystkie moje package.jsonwersje kończą się na"-rc2-*"

(Jedynymi wyjątkami, które widziałem do tej pory, są Microsoft.Framework.Configurationpakiety, które muszą być albo "1.0.0-rc1-*"albo "1.0.0-*")

Jeśli chodzi o „pociągi wersji”, o których wspomina @davidfowl, wydaje się, że DUŻO bólu zniknęło między wersjami beta8 i rc2.

dnvm upgrade -u -arch x64 -r coreclr

Miałem najwięcej szczęścia coreclrz tymi 2 kanałami NuGet:

"https://www.myget.org/F/aspnetvnext/"
"https://nuget.org/api/v2/"

Kiedy zrobić nie brakuje problemów pakiet 90% czasu, że to ci sami sprawcy:

Newtonsoft.Json
Ix-Async
Remotion.Linq

W większości przypadków mogę to obejść, wymuszając główny kanał NuGet.org:

dnu restore;
dnu restore -s https://nuget.org/api/v2

Oto mój działający config.json:

{
"dependencies": {
    "Microsoft.AspNet.Diagnostics": "1.0.0-rc2-*",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc2-*",
    "Microsoft.AspNet.Hosting": "1.0.0-rc2-*",
    "Microsoft.AspNet.Http": "1.0.0-rc2-*",
    "Microsoft.AspNet.Http.Abstractions": "1.0.0-rc2-*",
    "Microsoft.AspNet.Mvc.Core": "6.0.0-rc2-*",
    "Microsoft.AspNet.Mvc.Razor": "6.0.0-rc2-*",
    "Microsoft.AspNet.Owin": "1.0.0-rc2-*",
    "Microsoft.AspNet.Routing": "1.0.0-rc2-*",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc2-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-rc2-*",
    "Microsoft.AspNet.Session": "1.0.0-rc2-*",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc2-*",
    "EntityFramework.Commands": "7.0.0-rc2-*",
    "EntityFramework.Core": "7.0.0-rc2-*",
    "EntityFramework.InMemory": "7.0.0-rc2-*",
    "EntityFramework.MicrosoftSqlServer": "7.0.0-rc2-*",
    "EntityFramework.MicrosoftSqlServer.Design": "7.0.0-rc2-*",
    "EntityFramework.Relational": "7.0.0-rc2-*",
    "EntityFramework7.Npgsql": "3.1.0-beta8-2",
    "Microsoft.Extensions.Logging.Abstractions": "1.0.0-rc2-*",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc2-*",
    "Microsoft.Extensions.DependencyInjection": "1.0.0-rc2-*",
    "Microsoft.Extensions.DependencyInjection.Abstractions": "1.0.0-rc2-*",
    "Microsoft.Framework.Configuration.CommandLine": "1.0.0-*",
    "Microsoft.Framework.Configuration.EnvironmentVariables": "1.0.0-*",
    "Microsoft.Framework.Configuration.Json": "1.0.0-*"
},
"commands": {
    "ef": "EntityFramework.Commands",
    "dev": "Microsoft.AspNet.Hosting --ASPNET_ENV Development --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
    "dnxcore50": {}
}
}

Miałem również problemy z brakującymi zależnościami, próbując uspokoić odniesienia dnxcore50 i dnx451.

Jeśli rozumiem to prawo „zależności”: {} są współdzielone między frameworkami.

Następnie „zależności”: {} w ramach „struktur”: są specyficzne dla tej struktury.

dnxcore50 to modułowe środowisko uruchomieniowe (samodzielne), więc zawiera w zasadzie wszystkie podstawowe środowiska wykonawcze potrzebne do uruchomienia programu, w przeciwieństwie do klasycznego środowiska .net, w którym podstawowe zależności są rozproszone w innych miejscach.

Powiedziawszy to, że chcę trzymać się minimalnego podejścia, w pewnym momencie zdecydowałem się hostować na Macu lub Linuksie.

Aktualizacja Napotkała dziwne problemy z zależnościami w widokach cshtml, na razie po prostu poszła z dnx451.

To jest mój project.json

{
"webroot": "wwwroot",
"version": "1.0.0-*",

"dependencies": {
    "System.Runtime": "4.0.10",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "Microsoft.AspNet.Server.IIS": "1.0.0-beta6-12075",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta6-12457",
    "Microsoft.Framework.DependencyInjection": "1.0.0-beta4",
    "Microsoft.Framework.DependencyInjection.Interfaces": "1.0.0-beta5"
 },

"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://admin.heartlegacylocal.com"  },

"frameworks": {
"dnx451": { }
 }
},

"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
],
"exclude": [
  "wwwroot",
  "node_modules",
  "bower_components"
  ]
}