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


Escenario

Estoy experimentando con Visual Studio 2015 RC, específicamente mirando el cambio a la nueva ASP.NET 5 framework, estructura del proyecto y el nuevo DNX que se ejecuta ASP.NET 5 aplicaciones.

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 clases C# que contiene código compartido. Es una dependencia de / referenciado por WindowsService.csproj y WebApplication.csproj.

No estamos tratando específicamente de 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 estructura del proyecto asociado.

A continuación se presentan algunas opciones que he pensado, pero ambos tienen problemas.

Opción 1

Cuando reemplazamos el proyecto WebApplication.csproj anterior con un nuevo ASP.NET 5 DNX project WebApplication-dnx entonces todavía podemos hacer referencia a la ClassLibrary.csproj tanto de este nuevo proyecto DNX como 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 ser visible en el WebApplication-dnx en ejecución. Esto no es sorprendente, pero significa que no obtenemos beneficios completos de compilación desde el código fuente para WebApplication-dnx.

  2. No podemos apuntar fácilmente a otros frameworks, por ejemplo dnxcore50. Como se mencionó anteriormente, esto no es específicamente un objetivo en esta etapa.

Opción 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 parece estar más en consonancia con la forma en que el tiempo de ejecución de. NET y las tecnologías asociadas, tales como ASP.NET será empaquetado en el futuro.

Sin embargo, no puedo encontrar una manera de hacer referencia a ClassLibrary-dnx de WindowsService.csproj. Si este enfoque es viable, imagino que la solución tiene algo que ver con la opción a 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 construcción. Sin embargo, no puedo ver una forma limpia de lograr esto a través de las herramientas.

^ Los proyectos de la 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 CTPs.

Resumen

Basado en la información anterior estoy buscando:

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

  2. Sugerencias para otras opciones que no he pensado de.

  3. Tal vez una indicación de qué enfoque debe utilizarse en el futuro.

Author: Matt Brooks, 2015-05-20

1 answers

Echa un vistazo a lo que hace EntityFramework.

Se dirigen a 3 TFMS: net45, .NETPortable, Version = v4.5, Profile=Profile7, frameworkAssemblies y tienen tanto csproj como xproj en la misma carpeta.

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

Sin embargo, no puedo encontrar una manera 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) tener tanto xproj como csproj como EF o (2) hacer referencia al paquete NuGet de csproj.

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

 22
Author: Victor Hurdugaci,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-02-14 13:26:09