web-dev-qa-db-fra.com

Comment diagnostiquer les dépendances manquantes (ou autres défaillances du chargeur) dans dnx?

J'essaie d'exécuter une version modifiée de exemple HelloWeb pour ASP.NET vNext sur DNX à l'aide de Kestrel. Je comprends que cela est très très avancé, mais j’espère que l’équipe ASP.NET maintiendra au moins 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 11249 disponible aussi)

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.

Cependant, lorsque j'essaie de courir, une exception m'indique que Microsoft.Framework.Runtime.IApplicationEnvironment ne peut pas être trouvé. 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, de toute évidence, mon besoin le plus pressant soit de résoudre ce problème, j'aimerais également obtenir des conseils sur la manière de diagnostiquer ce qui ne va pas afin que je puisse résoudre moi-même des problèmes similaires à l'avenir. (Cela devrait également rendre cette question plus utile aux autres.)

J'ai trouvé Microsoft.Framework.Runtime.IApplicationEnvironment dans Microsoft.Framework.Runtime.Interfaces source d'assemblage , et cela ne semble pas avoir changé récemment. On ne voit pas très bien pourquoi l'exception affiche le nom comme s'il s'agissait d'une assemblée entière en soi, plutôt que d'une simple interface dans une autre assemblée. Je suppose que cela peut être dû à interfaces neutres de l’assemblage , mais ce n’est pas clair. ( [AssemblyNeutral] est mort, alors ce n'est pas ça ... )

c#asp.net-corednx
130
Jon Skeet

Bonne question. Pour votre problème spécifique, il semble que vos dépendances résolues ne concordent pas. Lorsque de telles choses se produisent, c'est probablement parce que vous exécutez votre application sur un dnx incompatible. Nous sommes toujours en train de faire de très gros changements, donc si jamais vous voyez une méthode manquante, il est probable que vous utilisiez betaX packages et betaY dnx ou vice-versa.

Encore plus spécifiquement, Assembly Neutral Interfaces ont été supprimés de la version 4, mais il semble que l'application que vous exécutez les utilise toujours.

Nous prévoyons de faire en sorte que les packages marquent le minimum de dnx dont ils ont besoin pour rendre le message d'erreur plus clair. De plus, à mesure que le temps passe, les changements radicaux vont s'estomper.

En général, j’ai le sentiment qu’il est temps que j’écrive un guide sur la façon de diagnostiquer de tels problèmes lors de l’utilisation du dnx (car il est très différent du .NET existant).

Les dépendances que vous avez insérées dans project.json ne sont que de premier niveau. Les versions sont également toujours minimales (c'est comme un paquet NuGet). Cela signifie que lorsque vous spécifiez Foo 1.0.0-beta4, vous spécifiez réellement Foo >= 1.0.0-beta4. Cela signifie que si vous demandez MVC 0.0.1 et que les versions minimales de votre flux configuré est MVC 3.0.0, vous l'obtiendrez. Nous avons également JAMAIS la mise à jour de votre version, à moins que vous ne la spécifiiez. Si vous demandez la version 1.0.0 et qu'elle existe, vous obtiendrez la version 1.0.0 même s'il existe de nouvelles versions. Spécifier des versions vides est TOUJOURS mauvais et sera interdit dans les versions ultérieures.

Nous introduisons dans nuget une nouvelle fonctionnalité appelée version flottante. Aujourd'hui, cela ne fonctionne que sur la balise de pré-publication, mais dans la prochaine version, cela fonctionnera sur plusieurs parties de la version. Ceci est similaire à la syntaxe npm et gem pour spécifier des plages de version dans le fichier de spécification de package.

1.0.0-* - Cela signifie que la version la plus élevée correspond au préfixe (selon règles de versioning sémantiques ) OR s'il n'existe aucune version correspondant à ce préfixe, utilisez le comportement normal et obtenez moi la version la plus BAS> = la version spécifiée.

Lorsque vous exécutez la restauration dans les dernières versions, un fichier nommé project.lock.json sera écrit. Ce fichier aura la fermeture transitive de dépendances pour tous les frameworks cibles définis dans project.json.

Lorsque quelque chose comme ceci échoue, vous pouvez procéder comme suit:

Examinez les dépendances résolues avec kpm list. Cela vous montrera les versions résolues des paquetages référencés par votre projet et la dépendance qui l’a entraîné. si A -> B, cela montrera:

 A 
 -> B 
 B 
 ->

Sortie réelle de la liste de KPM:

Liste des dépendances pour ClassLibrary39 (C:\Utilisateurs\davifowl\Documents\Visual Studio 14\Projets\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 en état de fonctionnement (qui fonctionne actuellement avec DNX), vous pouvez consulter le nœud de références. Il a les mêmes données représentées visuellement:

References node

Regardons à quoi ressemble une défaillance 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.0 n'existe pas. Donc, exécuter kpm restore montre ce qui suit:

enter image description here

Lors du diagnostic de l'échec de la restauration, examinez les requêtes HTTP effectuées. Elles vous indiquent les sources de paquets configurées dans lesquelles kpm a regardé. Notez que, dans l'image ci-dessus, il existe une requête CACHE. Ceci est la mise en cache intégrée basée sur le type de ressource (nupkg ou nuspec) et a un configurable TTL (regardez kpm restore --help). Si vous voulez forcer kpm à utiliser les sources NuGet distantes, utilisez l'indicateur --no-cache:

KPM restore --no-cache

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

enter image description here

Note de côté!

Sources de paquets

Je vais décrire le fonctionnement actuel de NuGet.config (qui changera probablement à l'avenir). Par défaut, vous disposez d'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 à l'aide de l'outil de ligne de commande NuGet. Vous devez toujours examiner vos sources effectives (celles répertoriées dans la sortie kpm) lorsque vous essayez de diagnostiquer des échecs.

En savoir plus sur NuGet.config here

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 tente de valider que le graphique de dépendance entier est résolu avant de tenter de s’exécuter. S'il suggère d'exécuter kpm restore, c'est 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 version de dnx. Si votre application spécifie uniquement dnx451 et que vous essayez d'exécuter le dnx CoreCLR, un problème similaire risque de se produire. 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 d’exécuter, vous devez vous rappeler cette cartographie mentale de la structure clr vers la structure cible définie dans votre project.json.

Cela apparaît également dans Visual Studio sous le nœud de références: Unresolved dependencies

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

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

Error list unresolved dependencies

Bâtiment

Ces erreurs apparaissent également lors de la construction. Lors de la génération à partir de la ligne de commande, le résultat est très détaillé et peut s'avérer extrêmement utile pour diagnostiquer les 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 à rencontrer des échecs de construction, il est utile de regarder ici pour vous assurer que le paquet que vous utilisez fonctionne réellement sur cette plate-forme cible.

Voici un exemple de paquet 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 ne possède aucun assemblage qui s'exécute sur dnxcore50 (consultez le dossier lib du paquet décompressé). Quand on lance kpm build:

Missing assemblies on dnxcore50

Remarquez qu'il est écrit "à l'aide du package Microsoft.Owin.Host.SystemWeb" mais il n'y a pas "Fichier:". Cela pourrait être la raison d'un échec de la construction.

Ici se termine mon dépotoir de cerveau

144
davidfowl

Je ne sais toujours pas entièrement 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 des paquets peut être utile
  • Cochez ~/.config/NuGet.config pour vous assurer que vous utilisez les bons flux NuGet.

J'ai fini par utiliser la ligne de commande suivante pour tester diverses options de manière relativement 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 en cours d'installation. Un numéro de version de "1.0.0-beta4" est apparemment très différent de "1.0.0-beta4-*". Par exemple, la dépendance Kestrel a installé la version 1.0.0-beta4-11185 uniquement lorsque vous indiquez 1.0.0-beta4, mais la version 1.0.0-beta4-11262 avec le -* à la fin. Je voulais spécifier explicitement beta4 afin d'éviter d'utiliser accidentellement une version bêta3 avec le

La configuration de projet suivante fonctionne bien:

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

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

8
Eilon

Pour que cela fonctionne, 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 a modifié le fonctionnement de k web pour qu'il soit maintenant dnx . web ou dnx . kestrel.

Mise à jour - bit plus d'infos

Bizarrement, après avoir exécuté avec aucun framework défini, il est allé chercher un tas de choses supplémentaires quand j'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 revenu dans la section cadre

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

.. et ça marchait toujours, alors qu'avant ça ferait une erreur!

Très étrange!

(Je cours 1.0.0-beta4-11257)

Mise à jour supplémentaire

J'ai créé une nouvelle instance Ubuntu et obtenu la même erreur que vous .. Mon idée était que le problème pouvait être causé par le fait qu’elle essayait uniquement d’obtenir les paquets de nuget.org et non de myget.org (qui a le nouvelles choses) donc je suis tombé dans un NuGet.Config dans la 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 avoir résolu le problème en obtenant les versions correctes (après un autre kpm restore).

3
Stephen Pope

Ces jours-ci, toutes mes versions de package.json se terminent par "-rc2-*"

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

En ce qui concerne les "versions de trains" mentionnées par @davidfowl, 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 sur coreclr avec ces 2 flux NuGet:

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

Quand j'ai do ai des problèmes de paquets manquants, 90% du temps, ce sont les mêmes coupables:

Newtonsoft.Json
Ix-Async
Remotion.Linq

La plupart du temps, je peux les contourner 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": {}
}
}
2
CrazyPyro

J'avais aussi des problèmes de dépendance en essayant de calmer 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), il contient donc toutes les runtimes de base nécessaires pour exécuter un programme contrairement au framework .net classique dans lequel vous avez des dépendances de base dispersées ailleurs.

Donc, cela dit, je voulais rester fidèle à l'approche minimale, car j'ai décidé d'héberger sur mac ou linux à un moment donné.

Mise à jour Nous sommes habitués à dnx451 pour l'instant avec des problèmes de dépendance étranges avec des vues cshtml.

C'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"
  ]
}
1
C0r3yh