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


133

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 ... )


z ciekawości, czy chodziło Ci o link do github.com/aspnet/Home/wiki/Assembly-Neutral-Interfaces dla twojego łącza neutralnych interfejsów montażowych, czy gdzieś indziej? Jak jest obecnie zepsuty
cgijbels

@cgijbels: Dzięki - tak naprawdę miałem na myśli link do davidfowl.com/assembly-neutral-interfaces, ale twój link prawdopodobnie jest lepszy ...
Jon Skeet

Nie ma już neutralnych interfejsów montażowych @JonSkeet.
holownik

@tugberk: Gosh, naprawdę? To interesujące - czy masz link, który mógłbym umieścić w edycji?
Jon Skeet

Odpowiedzi:


144

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:

Węzeł odwołań

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:

wprowadź opis obrazu tutaj

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:

Przywracanie KPM --no-cache

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

wprowadź opis obrazu tutaj

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ń: Nierozwiązane zależności

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

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

Lista błędów nierozwiązanych zależności

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:

Brakujące zestawy w dnxcore50

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


Próbuję użyć listy dnu, jak sugerujesz, do ustalenia, dlaczego dnx nie może rozwiązać zależności. Ale pojawia się czerwony komunikat „Nie można zlokalizować pliku project.json”. Zestaw znajduje się w folderze artefaktów, wygenerowanym przez zaznaczenie opcji „Produkuj dane wyjściowe podczas kompilacji”. Jakieś sugestie, jak postępować?
Mike Scott

Co ma z tym wspólnego folder artefaktów? Czy odwołałeś się do zależności w project.json? Czy ten pakiet, do którego się odwołujesz, jest dostępny w skonfigurowanym źródle treści?
davidfowl

17

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": {}
  }
}

6
Dzieje się tak, ponieważ -*zawsze zapewnia najnowszą wersję wstępną, a bez niej uzyskujesz najniższą wersję, która spełnia wszystkie zależności (jak zwykle w przypadku NuGet). Ten test ma kilka przykładów.
Alexander Köplinger

2
@ AlexanderKöplinger: Dzięki, to ma sens. Więc ... beta4 to najwcześniejsza beta4, podczas gdy ... beta4- * to najnowsza beta4, prawda?
Jon Skeet

4
"frameworks": {"dnx451": {}}Naprawiono to dla mnie, nie ma potrzebydnxcore50
vicentedealencar

Twoje pierwsze polecenie pomogło mi również ominąć utknięcie w wersji beta5. Próbowałem uruchomić dnvm upgrade-self, to nie zaktualizowałoby do najnowszej wersji. Uruchomienie wiersza poleceń VS jako admin pokazało wersję dnvm jako rc1..., ale kiedy nie była jako admin beta5.... Po rc2...wydaniu polecenia monity poleceń administratora i innych użytkowników były wyświetlane jako (najnowsza) wersja.
JabberwockyDecompiler

Dla tych, którzy używają mono i zastanawiają się, czy wybrać, dnx451czy dnxcore50ta odpowiedź pomogła mi nieco lepiej zrozumieć ten temat: stackoverflow.com/a/30846048/89590 Krótka odpowiedź: dnx451jest odpowiednia dla mono.
Nate Cook

8

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


@JonSkeet BTW, pozostałe odpowiedzi (w tym Twoja odpowiedź własna) zawierają świetne informacje na temat diagnozowania i naprawy napotkanego problemu. Utrzymałem tę odpowiedź bardzo krótko, ponieważ jest to tylko kolejna inna odpowiedź, która może prowadzić do większej liczby wskazówek, dlaczego problem wystąpił w pierwszej kolejności.
Eilon

Jak najbardziej - doceniam to :)
Jon Skeet

3

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).


1
Wracaj do części „dnx. Kestrel” - rzeczywiście, stąd polecenie, które pokazałem :) W tej konfiguracji pojawia się inny błąd: System.TypeLoadException: Nie można załadować typu „Microsoft.Framework.DependencyInjection.LoggingServiceCollectionExtensions” z zestawu „Microsoft. Framework.Logging, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null '. Której wersji DNX używasz?
Jon Skeet

1
Kiedy po raz pierwszy otrzymałem polecenie „dnx. Web”: `System.InvalidOperationException: Nie udało się rozwiązać następujących zależności dla platformy docelowej 'DNX, wersja = v4.5.1' i zasugerowano listę brakujących elementów.
Stephen Pope

Ciekawy. Przy okazji, na jakiej platformie to jest?
Jon Skeet

Czy wykonałeś polecenie „source ~ / .bashrc”, aby ponownie załadować zmienne środowiskowe po aktualizacji DNX? Musiałem też zrobić "aktualizację dnvm" + "dnvm użyj domyślnego"
Stephen Pope

DNX nie został zaktualizowany przez .bashrc ... prawdopodobnie dlatego, że wczoraj zbudowałem go ręcznie. Spróbuję zamiast tego użyć zaktualizowanych instrukcji ...
Jon Skeet

2

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": {}
}
}

Powyższa lista nie pochodzi z config.json, ale raczej z project.json, ale nadal głosowałem za nią, ponieważ zawierała przydatne zależności, o których wcześniej nie wiedziałem.
Ron C

1

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"
  ]
}
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.