Comment puis-je diagnostiquer les dépendances manquantes (ou d'autres échecs de chargeur) dans dnx?


133

J'essaie d'exécuter une version modifiée de l' exemple HelloWeb pour ASP.NET vNext sur DNX à l'aide de Kestrel. Je comprends que cela est très bien sur le bord des saignements, mais j'espère que l'équipe ASP.NET serait au moins maintenir le fonctionnement de l' application web la plus simple possible :)

Environnement:

  • Linux (Ubuntu, à peu près)
  • Mono 3.12.1
  • DNX 1.0.0-beta4-11257 (j'ai aussi 11249 disponible)

Code "application Web", dans Startup.cs:

using Microsoft.AspNet.Builder;
public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.UseWelcomePage();
    }
}

Configuration du projet, dans 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 semble fonctionner correctement.

Quand j'essaye de courir, cependant, j'obtiens une exception suggérant que Microsoft.Framework.Runtime.IApplicationEnvironmentne peut pas être trouvée. Ligne de commande et erreur (quelque peu reformatée)

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

Bien que mon besoin le plus urgent soit évidemment de résoudre ce problème, j'apprécierais également des conseils sur la façon de procéder pour diagnostiquer ce qui ne va pas afin de pouvoir résoudre moi-même des problèmes similaires à l'avenir. (Cela rendra également cette question plus utile aux autres.)

J'ai trouvé Microsoft.Framework.Runtime.IApplicationEnvironmentdans la Microsoft.Framework.Runtime.Interfacessource de l' assembly , et cela ne semble pas avoir changé récemment. On ne sait pas pourquoi l'exception montre le nom comme s'il s'agissait d'un assembly entier en soi, plutôt que simplement d'une interface dans un autre assembly. Je suppose que cela peut être dû à des interfaces neutres pour l' assemblage , mais ce n'est pas clair d'après l'erreur. ( [AssemblyNeutral]est mort, donc ce n'est pas ça ... )


par curiosité, vouliez-vous créer un lien vers github.com/aspnet/Home/wiki/Assembly-Neutral-Interfaces pour votre lien d'interfaces neutres d'assemblage ou ailleurs? Comme il est actuellement cassé
cgijbels

@cgijbels: Merci - Je voulais en fait créer un lien vers davidfowl.com/assembly-neutral-interfaces mais votre lien est probablement meilleur ...
Jon Skeet

Les interfaces neutres d'assemblage @JonSkeet ont maintenant disparu.
tugberk

@tugberk: Mon Dieu, vraiment? C'est intéressant - avez-vous un lien que je pourrais inclure dans une modification?
Jon Skeet

Réponses:


144

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:

Noeud Références

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:

entrez la description de l'image ici

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:

Restauration de KPM - sans cache

Ces erreurs apparaissent également dans Visual Studio dans la fenêtre de sortie du journal du gestionnaire de packages:

entrez la description de l'image ici

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: Dépendances non résolues

Les nœuds marqués en jaune ne sont pas résolus.

Ceux-ci apparaissent également dans la liste des erreurs:

Liste des erreurs dépendances non résolues

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:

Assemblages manquants sur dnxcore50

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


J'essaie d'utiliser la liste dnu comme vous le suggérez, pour déterminer pourquoi dnx ne peut pas résoudre une dépendance. Mais j'obtiens un rouge "Impossible de localiser project.json". L'assemblage se trouve dans le dossier des artefacts, généré en cochant "Produire des sorties lors de la construction". Des suggestions sur la façon de procéder?
Mike Scott

Quel est le rapport entre le dossier des artefacts et quoi que ce soit? Avez-vous référencé la dépendance dans project.json? Le package que vous référencez est-il disponible sur un flux configuré?
davidfowl

17

Je ne sais toujours pas tout à fait ce qui n'allait pas, mais j'ai maintenant une série d'étapes pour au moins faciliter les choses:

  • En cas de doute, réinstallez dnx
    • Souffler le cache du paquet peut être utile
  • Vérifiez ~/.config/NuGet.configque vous utilisez les bons flux NuGet

J'ai fini par utiliser la ligne de commande suivante pour tester diverses options de manière raisonnablement propre:

rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel

Il semble que mon problème soit vraiment dû aux mauvaises versions des dépendances installées. Un numéro de version de "1.0.0-beta4"est apparemment assez différent de "1.0.0-beta4-*". Par exemple, la Kestreldépendance a installé la version 1.0.0-beta4-11185 lorsqu'elle est juste spécifiée comme 1.0.0-beta4, mais la version 1.0.0-beta4-11262 avec le -*à la fin. Je voulais spécifier beta4explicitement pour éviter d'utiliser accidentellement une version beta3 avec le

La configuration de projet suivante fonctionne correctement:

{
  "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
C'est parce que -*vous donne toujours la dernière version préliminaire, tandis que sans elle, vous obtenez la version la plus basse qui satisfait toutes les dépendances (comme d'habitude avec NuGet). Ce test a quelques exemples.
Alexander Köplinger

2
@ AlexanderKöplinger: Merci, c'est logique. Donc ... beta4 est le premier beta4, tandis que ... beta4- * est le dernier beta4, non?
Jon Skeet

4
"frameworks": {"dnx451": {}}l'avait-il réparé pour moi, pas besoin dednxcore50
vicentedealencar

Votre première commande m'a également aidé à surmonter le blocage de la version beta5. J'ai essayé de courir dnvm upgrade-self, cela ne passerait pas à la dernière version. L'exécution de l'invite de commande VS en tant qu'administrateur montrait la version de dnvm comme rc1..., mais lorsqu'elle n'était pas en tant qu'administrateur, elle l'était beta5.... Après votre commande, les invites de commande admin et non admin sont affichées comme la rc2...(dernière) version.
JabberwockyDecompiler

Pour ceux qui utilisent mono et se demandent si choisir dnx451ou dnxcore50cette réponse m'a aidé à comprendre un peu plus ce sujet: stackoverflow.com/a/30846048/89590 Réponse courte: dnx451convient pour mono.
Nate Cook du

8

Vous pouvez définir une variable d'environnement nommée DNX_TRACEà 1pour afficher une TON plus d'informations de diagnostic. Attention, c'est beaucoup plus d'infos!


@JonSkeet BTW les autres réponses (y compris votre auto-réponse) contiennent de grandes informations sur le diagnostic et la réparation du problème spécifique que vous avez rencontré. J'ai gardé cette réponse très brève parce que c'est juste une autre réponse différente qui pourrait conduire à plus d'indices sur la raison pour laquelle le problème s'est produit en premier lieu.
Eilon

Absolument - j'apprécie ça :)
Jon Skeet

3

Pour le faire fonctionner, j'ai modifié mon project.json.. il ressemble maintenant à:

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

La clé semblait être la section des cadres.

De plus , le changement de nom changé la façon dont k webfonctionne de telle sorte que son entreprise dnx . weboudnx . kestrel

Mise à jour - un peu plus d'informations

Curieusement, après avoir fonctionné sans framework défini, il est allé et a obtenu un tas de choses supplémentaires quand je l'ai fait 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

.. alors ça a bien fonctionné. Puis je suis retourné dans la section framework

"frameworks": {
    "dnx451": {}
}

.. et cela fonctionnait toujours, alors qu'avant, cela provoquait une erreur!

Très étrange!

(Je cours 1.0.0-beta4-11257)

Mise à jour supplémentaire

J'ai créé une nouvelle instance d'Ubuntu et j'ai eu la même erreur que vous .. Je pensais que le problème pouvait être causé par le fait d'essayer uniquement d'obtenir des packages de nuget.orget non myget.org(ce qui a les nouvelles choses), alors j'ai laissé tomber un NuGet.Configdans le racine du projet.

<?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>

.. cela semble l'avoir résolu pour moi en obtenant les versions correctes (après l'autre kpm restore).


1
Re la partie "dnx. Kestrel" - en effet, d'où la commande que j'ai montrée :) Avec cette configuration, j'obtiens une erreur différente: System.TypeLoadException: Impossible de charger le type 'Microsoft.Framework.DependencyInjection.LoggingServiceCollectionExtensions' de l'assembly 'Microsoft. Framework.Logging, Version = 1.0.0.0, Culture = neutre, PublicKeyToken = null '. Quelle version de DNX utilisez-vous?
Jon Skeet

1
Quand j'ai fait "dnx. Web" la première fois que j'ai obtenu: `System.InvalidOperationException: Impossible de résoudre les dépendances suivantes pour le cadre cible 'DNX, Version = v4.5.1' et il a suggéré une liste des choses qu'il manquait.
Stephen Pope

Intéressant. Sur quelle plate-forme est-ce?
Jon Skeet

Avez-vous fait 'source ~ / .bashrc' pour recharger les variables d'environnement après avoir mis à niveau DNX? J'ai aussi dû faire "dnvm upgrade" + "dnvm use default"
Stephen Pope

DNX n'avait pas été mis à jour par .bashrc ... peut-être parce que je l'ai construit manuellement hier. Je vais essayer d'utiliser les instructions mises à jour à la place ...
Jon Skeet

2

Ces jours-ci, toutes mes package.jsonversions se terminent par"-rc2-*"

(Les seules exceptions que j'ai vues jusqu'à présent sont les Microsoft.Framework.Configurationpackages, qui doivent être soit "1.0.0-rc1-*"ou "1.0.0-*")

Concernant les "trains de versions" que @davidfowl mentionne, il semble que BEAUCOUP de douleur ait disparu entre beta8 et rc2.

dnvm upgrade -u -arch x64 -r coreclr

J'ai eu le plus de chance coreclravec ces 2 flux NuGet:

"https://www.myget.org/F/aspnetvnext/"
"https://nuget.org/api/v2/"

Quand je fais ont des problèmes de manque paquet, 90% du temps , ce sont ces mêmes coupables:

Newtonsoft.Json
Ix-Async
Remotion.Linq

La plupart du temps, je peux contourner ces problèmes en forçant le flux principal de NuGet.org:

dnu restore;
dnu restore -s https://nuget.org/api/v2

Voici mon config.json de travail:

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

La liste ci-dessus ne provient pas de config.json mais plutôt de project.json mais j'ai quand même voté pour parce que la liste m'a fourni des dépendances utiles que je ne connaissais pas auparavant.
Ron C

1

J'avais également des problèmes de dépendance en essayant d'apaiser les références dnxcore50 et dnx451.

Si je comprends bien ce droit, les "dépendances": {} sont partagées entre les frameworks.

Ensuite, les "dépendances": {} dans les "frameworks": sont spécifiques à ce framework.

dnxcore50 est un runtime modulaire (autonome) donc il contient essentiellement tous les runtimes de base nécessaires pour exécuter un programme contrairement au framework .net classique où vous avez des dépendances de base éparpillées ailleurs.

Cela dit, je voulais m'en tenir à l'approche minimale au cas où je décidais d'héberger sur mac ou linux à un moment donné.

Mettez à jour Ran dans des problèmes de dépendance étranges avec les vues cshtml, vient de passer avec dnx451 pour le moment.

Ceci est mon projet.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"
  ]
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.