Gute Frage. Für Ihr spezifisches Problem sieht es so aus, als ob Ihre aufgelösten Abhängigkeiten nicht übereinstimmen. Wenn solche Dinge passieren, liegt es wahrscheinlich daran, dass Sie Ihre Anwendung auf einem inkompatiblen DNX ausführen. Wir nehmen immer noch große Änderungen vor. Wenn Sie also jemals feststellen , dass eine Methode vom Typ fehlt, werden Sie wahrscheinlich betaXPakete und betaYdnx ausführen oder umgekehrt.
Insbesondere wurden Assembly Neutral Interfaces in Beta4 entfernt, aber es sieht so aus, als ob die Anwendung, die Sie ausführen, sie noch verwendet.
Wir haben vor, dies so zu gestalten, dass Pakete den Mindest-DNX markieren können, den sie ausführen müssen, um die Fehlermeldung deutlicher zu machen. Auch im Laufe der Zeit werden die brechenden Veränderungen nachlassen.
Im Allgemeinen ist es jedoch an der Zeit, einen Leitfaden zur Diagnose solcher Probleme bei der Verwendung von dnx zu schreiben (da dies ziemlich anders ist als bei vorhandenem .NET).
Abhängigkeiten, die Sie eingeben, project.jsonsind nur oberste Ebene. Versionen sind auch immer Mindestversionen (es ist wie bei einem NuGet-Paket). Dies bedeutet, dass Sie bei der Angabe Foo 1.0.0-beta4wirklich angeben Foo >= 1.0.0-beta4. Dies bedeutet, wenn Sie nachfragen MVC 0.0.1und die Mindestversion für Ihren konfigurierten Feed ist MVC 3.0.0, erhalten Sie diese. Wir veröffentlichen Ihre Version auch NIEMALS , es sei denn, Sie geben sie an. Wenn Sie nach 1.0.0 fragen und es existiert, erhalten Sie 1.0.0, auch wenn neuere Versionen existieren. Die Angabe leerer Versionen ist IMMER schlecht und wird in späteren Builds nicht zugelassen.
Es gibt eine neue Funktion, die wir in Nuget einführen: Floating-Versionen. Heute funktioniert es nur mit dem Prerelease-Tag, in der nächsten Version jedoch mit mehr Teilen der Version. Dies ähnelt der npm- und gem-Syntax zum Angeben von Versionsbereichen in der Paketspezifikationsdatei.
1.0.0-*- Bedeutet, dass ich die HÖCHSTE Version habe, die mit dem Präfix übereinstimmt (gemäß den Regeln für die semantische Versionierung ) ODER wenn es keine Version gibt, die mit diesem Präfix übereinstimmt, verwenden Sie normales Verhalten und erhalten Sie die NIEDRIGSTE Version> = die angegebene Version.
Wenn Sie die Wiederherstellung in den neuesten Builds ausführen, wird eine Datei namens aufgerufen project.lock.json. Diese Datei hat den transitiven Abschluss von Abhängigkeiten für alle in definierten Ziel-Frameworks project.json.
Wenn so etwas fehlschlägt, können Sie Folgendes tun:
Schauen Sie sich die aufgelösten Abhängigkeiten mit an kpm list. Dies zeigt Ihnen die aufgelösten Versionen von Paketen, auf die Ihr Projekt verweist, und welche Abhängigkeit es ausgelöst hat. Wenn beispielsweise A -> B angezeigt wird, wird Folgendes angezeigt:
EIN
-> B.
B.
->
Tatsächliche Ausgabe der KPM-Liste:
Auflisten von Abhängigkeiten für ClassLibrary39 (C: \ Benutzer \ davifowl \ Dokumente \ Visual Studio 14 \ Projekte \ 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
* bedeutet direkte Abhängigkeit.
Wenn Sie ein funktionierendes visuelles Studio haben (das derzeit mit DNX bricht), können Sie sich den Referenzknoten ansehen. Es hat die gleichen Daten visuell dargestellt:
Schauen wir uns an, wie ein Abhängigkeitsfehler aussieht:
Hier ist die 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.0existiert nicht. Das Ausführen der kpm-Wiederherstellung zeigt also Folgendes:
Wenn Sie diagnostizieren, wann die Wiederherstellung möglicherweise fehlgeschlagen ist, sehen Sie sich die gestellten HTTP-Anforderungen an. Dort erfahren Sie, in welchen konfigurierten Paketquellen kpm gesucht hat. Beachten Sie, dass im obigen Bild eine CACHEAnforderung vorliegt. Dies ist das integrierte Caching, das auf dem Ressourcentyp (nupkg oder nuspec) basiert und über eine konfigurierbare TTL verfügt (siehe kpm restore --help). Wenn Sie kpmdas Aufrufen der Remote-NuGet-Quellen erzwingen möchten , verwenden Sie das folgende --no-cacheFlag:
Diese Fehler werden auch in Visual Studio im Protokollausgabefenster des Paketmanagers angezeigt:
Randnotiz!
Paketquellen
Ich werde beschreiben, wie NuGet.config jetzt funktioniert (was sich wahrscheinlich in Zukunft ändern wird). Standardmäßig haben Sie eine NuGet.config mit der standardmäßig global konfigurierten NuGet.org-Quelle in %appdata%\NuGet\NuGet.Config. Sie können diese globalen Quellen in Visual Studio oder mit dem NuGet-Befehlszeilentool verwalten. Sie sollten immer Ihre effektiven Quellen (die in der kpm-Ausgabe aufgeführten) betrachten, wenn Sie versuchen, Fehler zu diagnostizieren.
Lesen Sie hier mehr über NuGet.config
Zurück zur Realität:
Wenn Abhängigkeiten nicht gelöst sind, erhalten Sie beim Ausführen der Anwendung Folgendes:
> 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)
Die Laufzeit versucht grundsätzlich zu überprüfen, ob das gesamte Abhängigkeitsdiagramm aufgelöst ist, bevor versucht wird, es auszuführen. Wenn es vorgeschlagen wird, ausgeführt zu werden, liegt kpm restorees daran, dass die aufgelisteten Abhängigkeiten nicht gefunden werden können.
Ein weiterer Grund, warum Sie diesen Fehler erhalten könnten, ist, wenn Sie die falsche dnx-Variante ausführen. Wenn Ihre Anwendung nur dnx451 angibt und Sie versuchen, den CoreCLR-dnx auszuführen, tritt möglicherweise ein ähnliches Problem auf. Achten Sie in der Fehlermeldung genau auf das Ziel-Framework:
Zum Laufen:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
Wenn Sie versuchen zu laufen, sollten Sie sich daran erinnern, dass die mentale Zuordnung von clr zum Zielframework in Ihrem definiert ist project.json.
Dies wird auch in Visual Studio unter dem Referenzknoten angezeigt:
Die als gelb markierten Knoten sind nicht aufgelöst.
Diese werden auch in der Fehlerliste angezeigt:
Gebäude
Diese Fehler treten auch beim Erstellen auf. Beim Erstellen über die Befehlszeile ist die Ausgabe sehr ausführlich und kann bei der Diagnose von Problemen äußerst nützlich sein:
> 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
Die Ausgabe zeigt alle Assemblys, die aus Paketen und Projektreferenzen an den Compiler übergeben wurden. Wenn Sie Build-Fehler erhalten, sollten Sie hier nachsehen, ob das von Ihnen verwendete Paket tatsächlich auf dieser Zielplattform funktioniert.
Hier ist ein Beispiel für ein Paket, das unter dnxcore50 nicht funktioniert:
{
"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 Version 3.0.0 enthält keine Assemblys, die auf dnxcore50 ausgeführt werden (siehe lib-Ordner des entpackten Pakets). Wenn wir rennen kpm build:
Beachten Sie, dass dort "using Package Microsoft.Owin.Host.SystemWeb" steht, aber nicht "File:". Dies könnte der Grund für einen Buildfehler sein.
Hier endet mein Brain Dump