Buena pregunta. Para su problema específico, parece que tiene una falta de coincidencia en sus dependencias resueltas. Cuando suceden cosas como esta es probable porque esté ejecutando su aplicación en un dnx incompatible. Todavía estamos haciendo grandes cambios importantes, por lo que si alguna vez ve que falta un método del tipo que falta, es probable que termine ejecutando betaXpaquetes y betaYdnx o viceversa.
Incluso más específicamente, las interfaces de montaje neutral se eliminaron en beta4, pero parece que la aplicación que está ejecutando todavía las está utilizando.
Tenemos planes de hacerlo para que los paquetes puedan marcar el dnx mínimo que requieren para ejecutarse para que el mensaje de error sea más claro. Además, a medida que pasa el tiempo, los cambios importantes desaparecerán.
Sin embargo, en general, siento que es hora de que escriba una guía sobre cómo diagnosticar problemas como este al usar el dnx (ya que es bastante diferente al .NET existente).
Las dependencias que ingresas project.jsonson solo de nivel superior. Las versiones también son siempre mínimas (es como un paquete NuGet). Esto significa que cuando especificas Foo 1.0.0-beta4realmente estás especificando Foo >= 1.0.0-beta4. Esto significa que si solicita MVC 0.0.1y las versiones mínimas en su feed configurado es MVC 3.0.0, obtendrá esa. También NUNCA hacemos flotar su versión a menos que usted la especifique. Si solicita 1.0.0 y existe, obtendrá 1.0.0 incluso si existen versiones más recientes. Especificar versiones vacías SIEMPRE es malo y no se permitirá en versiones posteriores.
Hay una nueva característica que estamos presentando a nuget llamada versiones flotantes. Hoy solo funciona en la etiqueta de prelanzamiento, 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 versión en el archivo de especificación del paquete.
1.0.0-*- Significa darme la versión MÁS ALTA que coincida con el prefijo (de acuerdo con las reglas de versiones semánticas ) O si no hay una versión que coincida con ese prefijo, use el comportamiento normal y obtenga la versión MÁS BAJA> = la versión especificada.
Cuando ejecute la restauración en las últimas compilaciones, escribirá un archivo llamado project.lock.json. Este archivo tendrá el cierre transitivo de dependencias para todos los marcos de destino definidos en project.json.
Cuando algo como esto falla, puede hacer lo siguiente:
Echa un vistazo a las dependencias resueltas usando kpm list. Esto le mostrará las versiones resueltas de los paquetes a los que hace referencia su proyecto y qué dependencia lo incorporó. Por ejemplo, si A -> B, mostrará:
UNA
-> B
si
->
Salida de la lista KPM real:
Listado de 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 estudio visual en funcionamiento (que rompe con DNX en este momento), puede mirar el nodo de referencias. Tiene los mismos datos representados visualmente:
Veamos cómo se ve una falla 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.0no existe Entonces ejecutar kpm restore muestra lo siguiente:
Cuando diagnostique cuándo pudo haber fallado la restauración, mire las solicitudes HTTP realizadas, le informan qué fuentes de paquetes configuradas buscó kpm. Observe en la imagen de arriba que hay una CACHEsolicitud. Este es el almacenamiento en caché integrado basado en el tipo de recurso (nupkg o nuspec) y tiene un TTL configurable (mirar kpm restore --help). Si desea forzar kpma golpear las fuentes remotas de NuGet, use la --no-cachebandera:
Estos errores también aparecen en Visual Studio en la ventana de salida del registro del administrador de paquetes:
Nota al margen!
Fuentes de paquete
Describiré la forma en que NuGet.config funciona en este momento (lo que probablemente cambiará en el futuro). Por defecto, tiene un NuGet.config con la fuente predeterminada de NuGet.org configurada globalmente en %appdata%\NuGet\NuGet.Config. Puede administrar estas fuentes globales en Visual Studio o con la herramienta de línea de comandos NuGet. Siempre debe mirar sus fuentes efectivas (las que figuran en la salida de kpm) al intentar diagnosticar fallas.
Lea más sobre NuGet.config aquí
De vuelta a la realidad:
Cuando las dependencias no se resuelven, 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 validar que todo el gráfico de dependencia se resuelva antes de intentar ejecutarse. Si sugiere ejecutar kpm restorees porque no puede encontrar las dependencias enumeradas.
Otra razón por la que puede obtener este error es si está ejecutando el sabor dnx incorrecto. Si su aplicación solo especifica dnx451 e intenta ejecutar CoreCLR dnx, es posible que vea un problema similar. Presta 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 correr, usted debe recordar que la cartografía mental, de CLR para marco objetivo definido en su project.json.
Esto también aparece en Visual Studio en el nodo de 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 construir desde la línea de comandos, el resultado es muy detallado 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
El resultado muestra todos los ensamblados pasados al compilador desde paquetes y referencias de proyectos. Cuando comience a tener fallas de compilación, es útil mirar aquí para asegurarse de que el paquete que está utilizando realmente funcione 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 (eche un vistazo a la carpeta lib del paquete descomprimido). Cuando corremos kpm build:
Observe que dice "usando el paquete Microsoft.Owin.Host.SystemWeb" pero no hay "Archivo:". Este podría ser el motivo de un error de compilación.
Aquí termina mi cerebro volcado