¿Cómo puedo diagnosticar dependencias faltantes (u otros fallos del cargador) en dnx?

Buena pregunta. Para su problema específico, parece que tiene un desajuste en sus dependencias resueltas. Cuando suceden cosas como esta, es probable que se deba a que está ejecutando su aplicación en un dnx incompatible. Todavía estamos haciendo cambios de ruptura muy grandes, por lo que si alguna vez ve que falta un método o un tipo, es probable que termine ejecutando betaX paquetes y betaY dnx o viceversa.

Aún más específicamente, Las interfaces neutrales de Ensamblaje se eliminaron en beta4, pero parece que la aplicación que está ejecutando todavía los está usando.

Tenemos planes para hacerlo de manera que los paquetes puedan marcar el dnx mínimo que requieren para ejecutarse para que el mensaje de error sea más claro. También a medida que pasa el tiempo, los cambios de ruptura se apagarán.

En general, sin embargo, siento que es hora de escribir una guía sobre cómo diagnosticar problemas como este cuando se usa dnx (ya que es bastante diferente a. NET existente).

Las dependencias que pones en project.json son de nivel superior solo. Las versiones también son siempre mínimos (es como un paquete NuGet). Esto significa que cuando especificas Foo 1.0.0-beta4 realmente estás especificando Foo >= 1.0.0-beta4. Esto significa que si pides MVC 0.0.1 y la versión mínima en tu feed configurado es MVC 3.0.0, obtendrás esa. También NUNCA flotamos tu versión a menos que la especifiques. Si pide 1.0.0 y existe, obtendrá 1.0.0 incluso si existen versiones más recientes. Especificar versiones vacías es SIEMPRE malo y será no se permite en versiones posteriores.

Hay una nueva característica que estamos introduciendo en nuget llamada versiones flotantes. Hoy solo funciona en la etiqueta de presentación, pero en la próxima versión funcionará en más partes de la versión. Esto es similar a la sintaxis npm y gem para especificar rangos de versiones en el archivo de especificación del paquete.

1.0.0-* - Me da la versión MÁS ALTA que coincide con el prefijo (de acuerdo con reglas de versionado semántico) O si no hay ninguna versión que coincida con prefijo, utilice el comportamiento normal y obtener la versión MÁS baja > = la versión especificada.

Cuando ejecute restore en las últimas compilaciones, escribirá un archivo llamado project.lock.json. Este archivo tendrá el cierre transitivo de dependencias para todos los frameworks de destino definidos en project.json.

Cuando algo como esto falla, puedes hacer lo siguiente: {[28]]}

Eche un vistazo a las dependencias resueltas usando kpm list. Esto le mostrará las versiones resueltas de los paquetes referenciados por su proyecto y lo que la dependencia tiró en. por ejemplo, si A - > B, mostrará:

A
  -> B
B
 ->

Salida real de la lista de KPM:

Listando dependencias para 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

* significa dependencia directa.

Si tiene un visual studio en funcionamiento (que rompe con DNX en este momento), puede mirar el nodo references. Tiene los mismos datos representados visualmente:

Veamos cómo se ve un fallo de dependencia:

Aquí está el proyecto.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 no existe. Así que al ejecutar kpm restore se muestra lo siguiente:

Cuando se diagnostica cuando la restauración puede haber fallado, mire las solicitudes HTTP realizadas, le dicen qué fuentes de paquetes configuradas buscaron kpm. Observe en la imagen de arriba, hay una solicitud CACHE. Este es el almacenamiento en caché integrado basado en el tipo de (nupkg o nuspec)y tiene un TTL configurable (mira kpm restore --help). Si desea forzar kpm para golpear las fuentes NuGet remotas, use la bandera --no-cache:

Estos errores también aparecen en Visual Studio en la ventana de salida del registro del gestor de paquetes:

Nota al margen!

Fuentes de paquetes

Voy a describir la forma NuGet.la configuración funciona ahora mismo (lo que probablemente cambiará en el futuro). Por defecto tienes un NuGet.config con el predeterminado NuGet.org fuente configurada globalmente en %appdata%\NuGet\NuGet.Config. Puede administrar estas fuentes globales dentro de visual studio o con la herramienta de línea de comandos NuGet. Siempre debe mirar sus fuentes efectivas (las enumeradas en la salida de kpm) cuando intente diagnosticar fallas.

Leer más sobre NuGet.config aquí

De vuelta a la realidad:{[28]]}

Cuando las dependencias no están resueltas, ejecutar la aplicación le dará esto:

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

El tiempo de ejecución básicamente intenta para validar que todo el gráfico de dependencias se resuelve antes de intentar ejecutarse. Si sugiere ejecutar kpm restore es porque no puede encontrar las dependencias listadas.

Otra razón por la que podría obtener este error es si está ejecutando el tipo dnx incorrecto. Si su aplicación solo especifica dnx451 e intenta ejecutar el dnx de CoreCLR, es posible que vea un problema similar. Preste mucha atención al marco de destino en el mensaje de error:

Para correr:

dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}

Cuando usted está tratando de ejecutar, usted debe recordar que el mapeo mental de clr a marco de destino definido en su project.json.

Esto también se muestra en Visual Studio bajo el nodo referencias:

Los nodos marcados como amarillos no están resueltos.

Estos también aparecen en la lista de errores:

Edificio

Estos errores también aparecen al construir. Al compilar desde la línea de comandos, la salida es muy detallada y puede ser extremadamente útil al diagnosticar problemas:

> 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 salida muestra todos los ensamblados pasados al compilador desde paquetes y referencias de proyectos. Cuando empiezas a tener errores de compilación, es útil mirar aquí para asegurarte de que el paquete que estás usando realmente funciona en esa plataforma de destino.

Aquí hay un ejemplo de un paquete que no funciona en 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 versión 3.0.0 no tiene ningún ensamblado que se ejecute en dnxcore50 (tome un mira la carpeta lib del paquete descomprimido). Cuando ejecutamos kpm build:

Observe que dice " usando el paquete Microsoft.Owin.Host.SystemWeb " pero no hay "File:". Esta podría ser la razón de un fallo de construcción.

Aquí termina mi volcado cerebral{[28]]}