Jak mogę zdiagnozować brakujące zależności (lub inne awarie Ładowarki) w dnx?

Dobre pytanie. W przypadku konkretnego problemu wygląda na to, że masz niedopasowanie w rozwiązanych zależnościach. Kiedy takie rzeczy się zdarzają, prawdopodobnie dlatego, że używasz aplikacji na niekompatybilnym dnx. Wciąż wprowadzamy bardzo duże zmiany, więc jeśli kiedykolwiek zauważysz brakujące metody lub brakujące typy, są szanse, że uruchomisz betaX pakiety i betaY dnx lub odwrotnie.

Jeszcze dokładniej, neutralne Interfejsy montażowe zostały usunięte w beta4, ale to wygląda na to, że uruchomiona aplikacja nadal ich używa.

Mamy w planach zrobić to tak, aby Pakiety mogły oznaczać Minimalne dnx wymagane do uruchomienia, aby Komunikat o błędzie był bardziej jasny. Również w miarę upływu czasu, zmiany łamiące zanikną.

Zależności, które wkładasz do {[9] } to najwyższy poziom tylko. Wersje są również zawsze minima (to tak jak pakiet NuGet). Oznacza to, że kiedy podajesz Foo 1.0.0-beta4, to tak naprawdę podajesz Foo >= 1.0.0-beta4. Oznacza to, że jeśli poprosisz o MVC 0.0.1, a minimalna wersja w skonfigurowanym kanale to MVC 3.0.0, otrzymasz tę. My również nigdy nie wyświetlamy Twojej wersji, chyba że ją podasz. Jeśli poprosisz o 1.0.0 i On istnieje, otrzymasz 1.0.0 nawet jeśli istnieją nowsze wersje. Podanie pustych wersji jest zawsze złe i będzie zakazany w późniejszych wersjach.

Jest nowa funkcja, którą wprowadzamy do nuget o nazwie floating versions. Dziś działa tylko na tagu prerelease, ale w następnej wersji będzie działać na kolejnych częściach wersji. Jest to podobne do składni npm i Gem do określania zakresów wersji w pliku specyfikacji pakietu.

1.0.0-* - czyli podaj mi najwyższą wersję pasującą do prefiksu (zgodnie z semantycznymi regułami wersjonowania) lub jeśli nie ma wersji pasującej do tego prefix, użyj normalnego zachowania i daj mi najniższą wersję > = podaną wersję.

Po uruchomieniu restore w najnowszych kompilacjach, zostanie zapisany plik o nazwie project.lock.json. Plik ten będzie miał Transitional closure of dependencies for all target framework defined in project.json.

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

Przyjrzyj się rozwiązanym zależnościom używając kpm list. To pokaże Ci 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, wyświetli się:

A
  -> B
B
 ->

Rzeczywisty wynik 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 visual studio (które zrywa teraz z DNX), możesz spojrzeć na węzeł reference. Ma te same dane reprezentowane wizualnie:

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

{
    "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.0 nie istnieje. Tak więc uruchamianie kpm restore pokazuje, co następuje:

Podczas diagnozowania, kiedy przywracanie mogło się nie udać, spójrz na żądania HTTP wykonane, mówią ci, w jakich skonfigurowanych źródłach pakietów wyglądał kpm. Zauważ, że na powyższym obrazku jest CACHE żądanie. Jest to wbudowane buforowanie oparte na typie resource (nupkg lub nuspec) i ma konfigurowalny TTL (patrz kpm restore --help). Jeśli chcesz zmusić kpm do naciśnięcia zdalnego źródła NuGet, Użyj flagi --no-cache:

Te błędy pojawiają się również w Visual Studio w oknie wyjściowym dziennika menedżera pakietów:

Uwaga!

Źródła Pakietów

Opiszę sposób NuGet.config działa już teraz (co prawdopodobnie zmieni się w przyszłości). Domyślnie masz NuGet.config with the default NuGet.org źródło skonfigurowane 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 poleceń NuGet. Podczas diagnozowania błędów zawsze należy spojrzeć na swoje skuteczne źródła (te wymienione w wyjściu kpm).

Czytaj więcej o NuGet.config here

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)

Runtime w zasadzie próbuje aby sprawdzić, czy cały wykres zależności został rozwiązany przed próbą uruchomienia. Jeśli sugeruje uruchomienie kpm restore, to dlatego, że nie może znaleźć wymienionych zależności.

Innym powodem, dla którego możesz uzyskać ten błąd, jest to, że używasz niewłaściwego smaku dnx. Jeśli aplikacja podaje tylko dnx451 i próbujesz uruchomić CoreCLR dnx, może wystąpić podobny problem. Zwróć szczególną uwagę na ramy docelowe w komunikacie o błędzie:

Do biegania:

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

Kiedy próbujesz uruchomić, powinieneś pamiętać, że mentalne mapowanie z clr do docelowego frameworka zdefiniowanego w twoim project.json.

To również pojawia się w Visual Studio pod węzłem reference:

Węzły oznaczone jako żółte 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 linii poleceń, wyjście jest bardzo wyraziste i może być bardzo przydatne przy diagnozowaniu 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

Wyjście pokazuje wszystkie złożenia przekazane do kompilatora z Pakietów i odniesień do projektów. Kiedy zaczynasz otrzymywać błędy kompilacji, warto zajrzeć tutaj, aby upewnić się, że pakiet, którego używasz, faktycznie działa na tej docelowej platformie.

{
    "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.Gospodarz.SystemWeb Wersja 3.0.0 nie ma żadnych zespołów, które działają na dnxcore50 (weź spójrz na rozpakowany folder lib pakietu). Kiedy biegniemy kpm build:

Zauważ, że jest napisane " używanie pakietu Microsoft.Owin.Gospodarz.SystemWeb "ale nie ma"File:". To może być przyczyną niepowodzenia budowy.

Here ends my brain dump