He estado leyendo sobre .NET Core y parece realmente genial.
Solo hay una cosa que me hace pensar y no la he leído en ninguna parte: cuando configuro mi aplicación web asp.net 5 para apuntar a .NET Core y la implemento, esta aplicación no depende EN ABSOLUTO de .NET framework instalado en la máquina que lo va a alojar?
Quiero decir, ¿los ensamblajes implementados ya contienen CLR, BCL y las dependencias del proyecto? Entonces puedo tener varias aplicaciones web alojadas en una sola máquina con diferentes versiones de .NET Core, ¿verdad?
Quiero decir, ¿los ensamblajes implementados ya contienen CLR, BCL y las dependencias del proyecto?
Se envían con las dependencias que estén en su archivo project.json . Si elige implementar CoreCLR, el tiempo de ejecución se enviará con su aplicación para que las diferentes aplicaciones puedan ejecutarse en cualquier versión del marco que consuman, una al lado de la otra. El punto es que todo el BCL se empaqueta lentamente en paquetes NuGet separados que se envían con su aplicación, eliminando paso a paso la necesidad de implementar el BCL completo.
Algunas de las otras respuestas cubren el aspecto de dependencia de BCL, pero es importante distinguir que existe el tiempo de ejecución y la BCL (biblioteca de clases base). En el mundo heredado (no dnx), las líneas a menudo se difuminaban porque tanto el tiempo de ejecución como el bcl se instalaban juntos en el nivel del sistema.
El dnx proporciona el punto de lanzamiento de la aplicación. Incluye el tiempo de ejecución, el compilador Just In Time, el compilador de código de bytes (Roslyn), bibliotecas de bajo nivel no administradas y una pequeña cantidad de código administrado. Es importante tener en cuenta que el dnx se identifica por entorno (windows, linux, mac, freebsd, etc.), arquitectura (x86, x64, arm, etc.) y tiempo de ejecución (actualmente coreclr o clr). También está versionado y este control de versiones es independiente de la versión bcl. Es posible que se necesiten versiones más nuevas de dnx para resolver errores, mejorar el rendimiento y agregar funciones.
Por lo tanto, la máquina host necesitará el dnx adecuado (definido por la arquitectura, el entorno, el tiempo de ejecución y, potencialmente, la versión en caso de cambios importantes). Hay más de una forma de obtener el dnx en el host. Una opción sería incluirlo con la aplicación (usando dnu publish -runtime ). Otra opción sería usar dnvm para instalarlo 'globalmente'. De cualquier manera, el tiempo de ejecución es un requisito.
Como nota al margen, el dnx para el tiempo de ejecución completo (no central) es solo una fachada. Es un método para hacer que las aplicaciones dnx funcionen de la misma manera, independientemente de si se dirigen al marco completo o al marco central. Puede notar que la carpeta dnx para el marco completo (es decir, dnx-clr-win-x64.1.0.0-beta4) tiene solo unos 10 MB. Si el marco completo no está instalado, la aplicación fallará en tiempo de ejecución. En esencia, el dnx para el marco completo es solo un fragmento que necesita que el marco completo esté realmente instalado en GAC como parte de la instalación en todo el sistema para que funcione.
Según tengo entendido, el paquete implementado puede depender de .NET Execution Environment (DNX) . Pero puede publicar su paquete de una manera específica con --runtime key, por lo que DNX también está incluido.