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