Bonne question. Pour votre problème spécifique, il semble que vos dépendances résolues ne correspondent pas. Lorsque de telles choses se produisent, c'est probablement parce que vous exécutez votre application sur un dnx incompatible. Nous faisons toujours de très gros changements de rupture, donc si jamais vous voyez une méthode manquante de type manquant, il y a de fortes chances que vous ayez fini par exécuter des betaXpackages et betaYdnx ou vice versa.
Plus précisément, les interfaces neutres d'assemblage ont été supprimées dans la version bêta4, mais il semble que l'application que vous exécutez les utilise toujours.
Nous avons prévu de faire en sorte que les packages puissent marquer le dnx minimum dont ils ont besoin pour s'exécuter pour rendre le message d'erreur plus clair. De plus, avec le temps, les changements décisifs disparaîtront.
En général, cependant, j'ai l'impression qu'il est temps d'écrire un guide sur la façon de diagnostiquer des problèmes comme celui-ci lors de l'utilisation du dnx (car il est assez différent de .NET existant).
Les dépendances dans lesquelles vous insérez project.jsonsont uniquement de niveau supérieur. Les versions sont également toujours des minimums (c'est comme un package NuGet). Cela signifie que lorsque vous spécifiez, Foo 1.0.0-beta4vous spécifiez vraiment Foo >= 1.0.0-beta4. Cela signifie que si vous demandez MVC 0.0.1et que les versions minimales de votre flux configuré sont MVC 3.0.0, vous obtiendrez celle-là. Nous ne flotterons JAMAIS votre version à moins que vous ne le spécifiiez. Si vous demandez 1.0.0 et qu'il existe, vous obtiendrez 1.0.0 même si des versions plus récentes existent. La spécification de versions vides est TOUJOURS mauvaise et ne sera pas autorisée dans les versions ultérieures.
Nous présentons une nouvelle fonctionnalité à nuget appelée versions flottantes. Aujourd'hui, cela ne fonctionne que sur la balise d'avant-première, mais dans la prochaine version, cela fonctionnera sur plus de parties de la version. Ceci est similaire à la syntaxe npm et gem pour la spécification des plages de versions dans le fichier de spécification du package.
1.0.0-*- Signifie me donner la version LA PLUS ÉLEVÉE correspondant au préfixe (selon les règles de contrôle de version sémantique ) OU s'il n'y a pas de version correspondant à ce préfixe, utilisez le comportement normal et obtenez-moi la version LA PLUS BASSE> = la version spécifiée.
Lorsque vous exécutez la restauration dans les dernières versions, un fichier appelé project.lock.json. Ce fichier aura la fermeture transitive des dépendances pour tous les frameworks cibles définis dans project.json.
Quand quelque chose comme ça échoue, vous pouvez faire ce qui suit:
Jetez un œil aux dépendances résolues à l'aide de kpm list. Cela vous montrera les versions résolues des packages référencés par votre projet et quelle dépendance l'a entraîné. Par exemple, si A -> B, cela affichera:
UNE
-> B
B
->
Sortie réelle de la liste KPM:
Liste des dépendances pour 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
* signifie dépendance directe.
Si vous avez un studio visuel fonctionnel (qui rompt avec DNX pour le moment), vous pouvez regarder le nœud des références. Il a les mêmes données représentées visuellement:
Regardons à quoi ressemble un échec de dépendance:
Voici le 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.0n'existe pas. Ainsi, l'exécution de la restauration kpm montre ce qui suit:
Lors du diagnostic de l'échec de la restauration, examinez les requêtes HTTP effectuées, elles vous indiquent les sources de package configurées que kpm a recherchées. Remarquez dans l'image ci-dessus, il y a une CACHErequête. Il s'agit de la mise en cache intégrée basée sur le type de ressource (nupkg ou nuspec) et a un TTL configurable (regardez kpm restore --help). Si vous souhaitez forcer kpmà atteindre les sources NuGet distantes, utilisez l' --no-cacheindicateur:
Ces erreurs apparaissent également dans Visual Studio dans la fenêtre de sortie du journal du gestionnaire de packages:
Note secondaire!
Sources de paquet
Je décrirai la façon dont NuGet.config fonctionne actuellement (ce qui changera probablement à l'avenir). Par défaut, vous avez un NuGet.config avec la source NuGet.org par défaut configurée globalement dans%appdata%\NuGet\NuGet.Config . Vous pouvez gérer ces sources globales dans Visual Studio ou avec l'outil de ligne de commande NuGet. Vous devriez toujours regarder vos sources efficaces (celles répertoriées dans la sortie de kpm) lorsque vous essayez de diagnostiquer des échecs.
En savoir plus sur NuGet.config ici
Retour à la réalité:
Lorsque les dépendances ne sont pas résolues, l'exécution de l'application vous donnera ceci:
> 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)
Le moteur d'exécution essaie essentiellement de valider que l'ensemble du graphe de dépendances est résolu avant d'essayer de s'exécuter. S'il suggère de courirkpm restore c'est parce qu'il ne trouve pas les dépendances répertoriées.
Une autre raison pour laquelle vous pourriez obtenir cette erreur est si vous exécutez la mauvaise saveur dnx. Si votre application ne spécifie que dnx451 et que vous essayez d'exécuter le CoreCLR dnx, vous pouvez rencontrer un problème similaire. Faites très attention au cadre cible dans le message d'erreur:
Pour courrir:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
Lorsque vous essayez de courir, vous devez vous rappeler que le mappage mental de CLR au cadre cible défini dans votre project.json.
Cela apparaît également dans Visual Studio sous le nœud de références:
Les nœuds marqués en jaune ne sont pas résolus.
Ceux-ci apparaissent également dans la liste des erreurs:
Bâtiment
Ces erreurs apparaissent également lors de la construction. Lors de la construction à partir de la ligne de commande, la sortie est très détaillée et peut être extrêmement utile lors du diagnostic des problèmes:
> 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
La sortie affiche tous les assemblys passés dans le compilateur à partir de packages et de références de projet. Lorsque vous commencez à avoir des échecs de compilation, il est utile de regarder ici pour vous assurer que le package que vous utilisez fonctionne réellement sur cette plate-forme cible.
Voici un exemple de package qui ne fonctionne pas sur 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 version 3.0.0 n'a pas d'assemblys qui s'exécutent sur dnxcore50 (jetez un œil au dossier lib du package décompressé). Quand nous courons kpm build:
Notez qu'il dit "en utilisant le package Microsoft.Owin.Host.SystemWeb" mais il n'y a pas de "Fichier:". Cela pourrait être la raison d'un échec de construction.
Ici se termine mon vidage cérébral