asp.net core - ¿Cómo puedo crear una biblioteca de clases.NET Core y hacer referencia a ella desde un proyecto.NET 4.6?

asp.net-core compatibility

Question

Quiero:

• Haga una biblioteca de clases que defina algunas interfaces y clases simples de ayuda genérica. Se basará en colecciones genéricas e IQueryable<T> pero no en dependencias de terceros (bueno, JetBrains.Annotations ).
• Ser capaz de hacer referencia a esa biblioteca de clases desde cualquier lugar (específicamente UWP, net46 y ASP.Net Core RC2)
• Idealmente, use el sistema project.json en todo momento, aunque estoy preparado para sacrificar eso si es necesario.
• Publique la biblioteca terminada en un feed de NuGet y, desde allí, utilícela en otras aplicaciones.

Al crear el proyecto de mi biblioteca de clases en Visual Studio 2015.2, encontré la plantilla de la Class Library (.NET Core) , que indica

Una plantilla de proyecto para crear una biblioteca de clases como un paquete NuGet que puede apuntar a cualquier plataforma

Cualquier plataforma! Brillante ... Pero no puedo hacerlo funcionar. Después de muchos problemas, actualmente tengo el siguiente project.json (probablemente ya lo he roto por completo):

{
"title": "My Really Useful Class Library",
"copyright": "Copyright © 2015-16 Tigra Astronomy, all rights reserved",
"description": "Really neat stuff",
"language": "en-GB",
"version": "1.0.0-*",
"dependencies": {
    "JetBrains.Annotations": "10.1.4",
    },
"frameworks": {
    "netstandard1.5": {
        "imports": "dnxcore50",
        "dependencies": {
            "NETStandard.Library": "1.5.0-rc2-24027",
            "System.Linq.Expressions": "4.0.11-rc2-24027"
            }
        }
    "net46": {
        "frameworkAssemblies": {
            "System.Collections": "4.0.*"
            },
        "dependencies": {}
        }
    },
    "buildOptions": {
        "xmlDoc": true
        }
}

Lo siguiente que hice fue crear mi proyecto .NET Framework 4.6 en la misma solución e intentar hacer referencia a la biblioteca de clases. Me permite agregar la referencia pero obtengo errores de compilación, símbolos no resueltos, R # no está contento, etc.

Supongo que no lo estoy haciendo bien (no es de extrañar, en realidad, ya que estoy hurgando en la oscuridad)

He leído algunos de los documentos sobre TFM, marcos y bibliotecas, pero ninguno de ellos tiene mucho sentido.

¿Qué es lo que realmente necesito poner en el project.json mi biblioteca de clases, para poder hacer referencia a él desde mi aplicación .net framework 4.6, y también desde las aplicaciones UWP y ASP.NET Core RC2? ¿Es este realmente el enfoque correcto o he empezado con el pie equivocado?

Answer 1

En este momento hay dos formas de crear proyectos en C #: xproj y csproj . Suponiendo que estemos usando project.json para los dos, eso todavía funciona de manera diferente para los tipos de proyectos, para xproj , el project.json contiene todo lo necesario para construir el proyecto; para csproj , solo contiene las dependencias de nuget.

Dicho esto, algunos tipos de proyectos, como UWP, no se pueden compilar con xproj debido a que se necesita un canal de compilación más complicado de lo que xproj / project.json . (Por cierto, este fue un motivo clave para volver a msbuild).

También hay dos formas de crear una biblioteca de clases basada en .NET Standard: puede usar xproj con project.json , como lo ha hecho, o puede crear un proyecto csproj "Portable Class Library" de csproj . Con VS 2015 Update 3 RC, puede cambiar el PCL para apuntar a una versión estándar de .NET ( netstandard1.x lugar de un perfil PCL, 259, etc.).

Si usa una csproj de clases basada en csproj para apuntar a netstandard1.x , las cosas deberían funcionar para usted al agregar referencias de proyectos. Tenga en cuenta que UWP actualmente admite hasta netstandard1.4 función del mapa de la plataforma . El desafío es si desea utilizar un project.json basado en xproj / project.json en su lugar. Una razón clave para usar xproj hoy es habilitar la compilación cruzada entre varios marcos de destino. Es decir, cree más de una salida de su proyecto. Eso es diferente a crear una salida única a la que se pueda hacer referencia desde cualquier proyecto compatible. Ambos tienen sus usos, depende de tus necesidades.

Si decide crear una xproj de clases basada en xproj , hay una solución alternativa que puede usar para hacer referencia a ella desde un proyecto UWP o cualquier otro tipo de proyecto compatible si el cuadro de diálogo "Agregar referencias" no funciona (lo cual no funciona como csproj -> xproj está bastante roto). En lugar de usar el cuadro de diálogo, edite su UWP csproj para que apunte a la salida del xproj esta manera:

<Reference Include="System.Reactive.Interfaces">
  <HintPath>../System.Reactive.Interfaces/bin/$(Configuration)/netstandard1.0/System.Reactive.Interfaces.dll</HintPath>
</Reference>

El fragmento de código anterior se toma del Rx.NET UWP Test Runner here

Si hace esto, también deberá agregar la dependencia de compilación de su proyecto UWP a su xproj ya que MSBuild / Visual Studio no lo sabrá y construirá las cosas en el orden incorrecto. Para hacer esto, haga clic con el botón derecho en su proyecto UWP en el Explorador de soluciones, luego seleccione "Crear dependencias -> Dependencias de proyecto". En ese cuadro de diálogo, marque la casilla de su xproj para asegurarse de que VS / MSbuild sepa cómo compilarlo primero.

Puede ver la solución completa de Rx.NET aquí, que incluye las referencias xproj->xproj y las referencias UWP -> xproj que mencioné anteriormente.

Answer 2

Las nuevas plantillas de proyecto / .xproj funcionan de manera un poco diferente. Las nuevas bibliotecas de clases (y las plantillas de aplicaciones) producen paquetes nuget, en lugar de conjuntos simples.

Dentro de ese paquete nuget todos los objetivos están empaquetados en él. Dicho esto, agregue el nuevo proyecto de la misma forma que agrega cualquier otro paquete de nuget: coloque el nuget en una fuente de nuget, haga referencia a esto en Visual Studio y luego recupérelo.

Si no tiene un servidor nuget en ejecución (Visual Studio Team Services + NuGet package, myget, auto-alojado) también puede poner los paquetes en una carpeta (local o de red compartida) y agregar esta carpeta como fuente de nuget.

Si eso es "demasiado" mucho trabajo, también puede crear dos proyectos en una carpeta: A * .csproj y a * .xproj. El * .csproj tiene como objetivo el Framework .NET 4.6 y el * .xproj se mantiene como se señaló anteriormente y tiene múltiples objetivos. Con esta configuración, normalmente puede hacer referencia al proyecto de la forma en que lo usó anteriormente (si están en la misma solución), simplemente agregando una referencia.