netcore net .net asp.net-core dnx .net-core

.net - netcore - install net core



¿Cuáles son mis opciones para compartir código entre proyectos DNX/ASP.NET 5(project.json/xproj) y otros proyectos C#(csproj) dentro de una única solución? (1)

Guión

Estoy experimentando con Visual Studio 2015 RC, específicamente considerando cambiar al nuevo marco ASP.NET 5, la estructura del proyecto y el nuevo DNX que ejecuta las aplicaciones ASP.NET 5.

Mi empleador tiene muchas soluciones existentes dirigidas a .NET Framework 4.5.2. En nuestras soluciones existentes de Visual Studio podríamos tener los siguientes proyectos:

[Solution] Sample.sln [Folder] src [Project] ClassLibrary.csproj [Project] WindowsService.csproj [Project] WebApplication.csproj [Folder] test [Project] ClassLibrary.UnitTests.csproj ...

En este escenario, ClassLibrary.csproj es una biblioteca de clase C # que contiene código compartido. Es una dependencia de / referenciada tanto por WindowsService.csproj como por WebApplication.csproj .

No estamos intentando específicamente apuntar a .NET Core, dnxcore50 . En esta etapa, estamos felices de apuntar a .NET Framework, dnx451 . Sin embargo, estamos absolutamente tratando de aprovechar las nuevas características de ASP.NET 5 y la estructura del proyecto asociado.

A continuación hay algunas opciones que he pensado, pero ambas tienen problemas.

Opción 1

Cuando reemplazamos el proyecto WebApplication.csproj anterior con un nuevo proyecto ASP.NET 5 DNX, WebApplication-dnx , aún podemos hacer referencia al ClassLibrary.csproj de este nuevo proyecto DNX y del proyecto existente WindowsService.csproj . Sin embargo surgen algunos problemas:

  1. Este enfoque significa que cualquier cambio en el código en ClassLibrary.csproj necesita una reconstrucción para que sea visible en el WebApplication-dnx . Esto no es sorprendente, pero significa que no obtenemos todos los beneficios de compilación desde la fuente para WebApplication-dnx .

  2. No podemos dirigirnos fácilmente a otros marcos, por ejemplo, dnxcore50 . Como se mencionó anteriormente, este no es un objetivo específico en esta etapa.

opcion 2

Si reemplazamos ClassLibrary.csproj con un proyecto de biblioteca de clases DNX ^ ClassLibrary-dnx entonces los problemas en la opción 1 no se aplican. Este enfoque parecería ser más acorde con la forma en que el tiempo de ejecución de .NET y las tecnologías asociadas como ASP.NET se empaquetarán en el futuro.

Sin embargo, no puedo encontrar una forma de hacer referencia a ClassLibrary-dnx desde WindowsService.csproj . Si este enfoque es viable, me imagino que la solución tiene algo que ver con la opción de nivel de proyecto para Produce outputs on build y luego hacer referencia al .nupkg o tal vez incluso al .dll que se produce durante la compilación. Sin embargo, no puedo ver una forma limpia de lograr esto a través de las herramientas.

^ Los proyectos de biblioteca de clases DNX se llaman Class Library (Package) en VS 2015 RC. Este tipo de proyecto se llamaba anteriormente ASP.NET Class Library en los CTP.

Resumen

Basado en la información anterior que estoy buscando:

  1. Algunos comentarios a mis opciones de escenario y problemas.

  2. Sugerencias para otras opciones que no he pensado.

  3. Tal vez una indicación de qué enfoque se debe utilizar para avanzar.


Echa un vistazo a lo que hace EntityFramework .

Se enfocan en 3 TFM: net45, .NETPortable, Version = v4.5, Profile = Profile7, frameworkAssemblies y tienen csproj y xproj en la misma carpeta .

Básicamente, para cada proyecto tienes dos archivos de proyecto.

Sin embargo, no puedo encontrar una forma de hacer referencia a ClassLibrary-dnx desde WindowsService.csproj.

Desafortunadamente, eso no es posible, todavía. Solo puede hacer referencia a csproj desde xproj, no al revés. Tiene dos alternativas: (1) tiene tanto xproj como csproj como EF o (2) hace referencia al paquete NuGet de csproj.

Si desea hacer la alternativa (2), puede configurar la salida del xproj en una carpeta y agregarla como fuente NuGet.