¿Cómo puedo diagnosticar las dependencias faltantes (u otras fallas del cargador) en dnx?

Estoy tratando de ejecutar una versión modificada de la muestra HelloWeb para ASP.NET vNext en DNX usando Kestrel. Entiendo que esto es muy mucho en la punta de lanza, pero espero que el equipo de ASP.NET sería, al menos, mantener el trabajo más simple aplicación web posible :)

Ambiente:

• Linux (Ubuntu, más o menos)
• Mono 3.12.1
• DNX 1.0.0-beta4-11257 (también tengo 11249 disponible)

Código de "aplicación web", en Startup.cs:

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

Configuración del proyecto, en 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 Parece funcionar bien.

Sin embargo, cuando intento ejecutar, recibo una excepción que sugiere que Microsoft.Framework.Runtime.IApplicationEnvironmentno se puede encontrar. Línea de comando y error (algo reformateado)

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

Aunque, obviamente, mi necesidad más urgente es solucionar esto, también agradecería consejos sobre cómo avanzar para diagnosticar lo que está mal para poder solucionar problemas similares yo mismo en el futuro. (También es probable que esta pregunta sea más útil para otros también).

Lo he encontrado Microsoft.Framework.Runtime.IApplicationEnvironmenten la Microsoft.Framework.Runtime.Interfacesfuente de ensamblaje , y eso no parece haber cambiado recientemente. No está claro por qué la excepción muestra el nombre como si fuera un conjunto completo en sí mismo, en lugar de solo una interfaz dentro de otro conjunto. Supongo que esto puede deberse a interfaces de montaje neutrales , pero el error no lo aclara. ( [AssemblyNeutral]está muerto, así que no es así ... )

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

Todavía no sé del todo qué estaba mal, pero ahora tengo una serie de pasos para al menos hacer que sea más fácil probar cosas:

• En caso de duda, reinstale dnx
  • Eliminar el paquete de caché puede ser útil
• Compruebe ~/.config/NuGet.configpara asegurarse de que está utilizando los feeds NuGet correctos

Terminé usando la siguiente línea de comando para probar varias opciones de una manera razonablemente limpia:

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

Parece que mi problema se debió realmente a las versiones incorrectas de las dependencias que se están instalando. Al "1.0.0-beta4"parecer, un número de versión es bastante diferente a "1.0.0-beta4-*". Por ejemplo, la Kestreldependencia instaló la versión 1.0.0-beta4-11185 cuando se acaba de especificar como 1.0.0-beta4, pero la versión 1.0.0-beta4-11262 con -*el final. Quería especificar beta4explícitamente para evitar usar accidentalmente una versión beta3 con el

La siguiente configuración del proyecto funciona 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": {}
  }
}

Puede configurar una variable de entorno llamada DNX_TRACEa 1para ver una TONELADA más información de diagnóstico. ¡Ten cuidado, es mucha más información!

Para que funcione, modifiqué mi project.json... ahora se ve así:

{
"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 clave parecía ser la sección de marcos.

También el cambio de nombre cambió cómo k webfunciona para que sea ahora dnx . webodnx . kestrel

Actualización - poco más información

Curiosamente, después de ejecutar sin marcos definidos, fue y obtuve un montón de cosas adicionales cuando lo hice 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

.. entonces funcionó bien. Luego volví a la sección del marco

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

.. y todavía funcionó, mientras que antes arrojaría un error!

¡Muy raro!

(Estoy corriendo 1.0.0-beta4-11257)

Actualización adicional

Creé una nueva instancia de Ubuntu, y obtuve el mismo error que tú. Pensé que el problema podría ser causado por solo tratar de obtener paquetes nuget.orgy no myget.org(que tiene las cosas más nuevas), así que me metí en NuGet.Configel raíz del proyecto ..

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

.. esto parece haberme solucionado al obtener las versiones correctas (después de otra kpm restore).

En estos días, todas mis package.jsonversiones terminan en"-rc2-*"

(Solo las excepciones que he visto hasta ahora son los Microsoft.Framework.Configurationpaquetes, que deben ser "1.0.0-rc1-*"o "1.0.0-*")

Con respecto a los "trenes de versiones" que @davidfowl menciona, parece que mucho dolor ha desaparecido entre beta8 y rc2.

dnvm upgrade -u -arch x64 -r coreclr

He tenido más suerte coreclrcon estos 2 feeds NuGet:

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

Cuando hago hayan desaparecido los problemas de paquetes, el 90% de las veces son estos mismos culpables:

Newtonsoft.Json
Ix-Async
Remotion.Linq

La mayoría de las veces, puedo evitarlos forzando el feed principal de NuGet.org:

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

Aquí está mi config.json de trabajo:

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

Tenía problemas de falta de dependencia también al tratar de apaciguar las referencias dnxcore50 y dnx451.

Si entiendo este derecho "dependencias": {} se comparten entre los marcos.

Entonces "dependencias": {} dentro de los "marcos": son específicos de ese marco.

dnxcore50 es un tiempo de ejecución modular (autónomo), por lo que básicamente contiene todos los tiempos de ejecución principales necesarios para ejecutar un programa a diferencia del marco de trabajo .net clásico, donde hay dependencias centrales dispersas en otros lugares.

Dicho esto, quería mantener el enfoque mínimo en caso de que decidiera alojar en Mac o Linux en algún momento.

La actualización se encontró con problemas de dependencia extraños con vistas cshtml, solo fui con dnx451 por ahora.

Este es mi proyecto.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"
  ]
}