c# msbuild .net-core visual-studio-2017 csproj

c# - ¿Cómo se dirige una biblioteca de clases de.NET Core con csproj?



msbuild .net-core (4)

De hecho, seleccioné Class Library (.NET Core).

Esa no es la plantilla de proyecto que desea si su biblioteca necesita trabajar en múltiples objetivos de plataforma. Con esta plantilla de proyecto, su biblioteca solo se puede usar en un proyecto dirigido a .NETCore. Se retiró el enfoque de la biblioteca PCL, ahora debe elegir un estándar .NET.

Para hacerlo, inicie el proyecto con la plantilla de proyecto "Biblioteca de clases (.NET Standard)". Ahora tiene la opción de elegir la versión .NETStandard. La cuadrícula de compatibilidad actual está aquí .

Esperemos que mantengan ese artículo vinculado actualizado. Esto está cambiando, .NETStandard 2.0 fue clavado pero aún no se envía. Dirigido para el segundo trimestre de 2017, probablemente a fines de la primavera, actualmente se muestra como un 97% terminado. Escuché a los diseñadores decir que no se recomienda usar 1.5 o 1.6, no es lo suficientemente compatible con 2.0

Cuando .NET Core todavía usaba el formato project.json , podía crear una biblioteca de clases dirigida a múltiples marcos (por ejemplo, net451, netcoreapp1.0).

Ahora que el formato oficial del proyecto es csproj usando MSBuild, ¿cómo se especifican los marcos múltiples para apuntar? Estoy tratando de buscar esto desde la configuración del proyecto en VS2017, pero solo puedo apuntar a un solo marco desde los marcos .NET Core (ni siquiera enumera las otras versiones completas de .NET Framework que tengo instaladas) :

Hice una guía para principiantes sobre el marco de red de múltiples objetivos y el núcleo de red .

El enfoque más simple es hacer que un objetivo netcore / netstandard funcione primero, luego edite el archivo csproj y siga estos pasos para los otros objetivos:

  1. Aprenda sobre las secciones condicionales en su archivo csproj, para que pueda declarar diferentes dependencias para cada objetivo. Crear secciones condicionales para cada objetivo.
  2. Agregue <Reference />s para System. * Dlls para cualquier objetivo de netframework simplemente leyendo lo que dicen los mensajes de error de compilación que faltan.
  3. Trate las dependencias de NuGet <PackageReference />s en los casos en que no sean las mismas para cada objetivo. El truco más fácil es revertir temporalmente a la orientación única para que la GUI maneje las referencias Nuget correctamente por usted.
  4. Trate el código que no se compila en todos los objetivos, aprendiendo una variedad creativa de técnicas, soluciones y ahorradores de tiempo.
  5. Sepa cuándo reducir sus pérdidas cuando el costo de agregar más objetivos es demasiado alto.

Necesita editar manualmente el archivo del proyecto y agregar s al TargetFramework predeterminado y básicamente cambiarlo a TargetFrameworks . Entonces mencionas el Moniker con un ; separador.

También puede poner las referencias del paquete Nuget en un ItemGroup condicional manualmente o usando el Administrador de paquetes VS Nuget.

Así es como debería verse su .csproj:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFrameworks>netstandard1.6;net452</TargetFrameworks> </PropertyGroup> <ItemGroup Condition="''$(TargetFramework)'' == ''net452''"> <PackageReference Include="Microsoft.Azure.DocumentDB"> <Version>1.12.0</Version> </PackageReference> </ItemGroup> <ItemGroup Condition="''$(TargetFramework)'' == ''netstandard1.6''"> <PackageReference Include="Microsoft.Azure.DocumentDB.Core"> <Version>1.1.0</Version> </PackageReference> </ItemGroup> </Project>

Otra solución que hago en estos días debido a la falta de documentación es que creo un proyecto en VS2015 y formo el proyecto.json usando la documentación disponible y el intellisense, luego abro la solución en VS2017 y uso la actualización incorporada. Luego miraré el archivo csproj para descubrir cómo hacer que esa configuración suceda.

Múltiples objetivos más esotéricos sin un Moniker :

Microsoft:

No se recomiendan PCL +

Aunque se admiten PCL, los autores de paquetes deberían admitir netstandard en su lugar. El .NET Platform Standard es una evolución de las PCL y representa la portabilidad binaria a través de las plataformas que usan un solo nombre que no está vinculado a una estática como los nombres portátiles-a + b + c.

Si desea apuntar a un Perfil portátil, no tiene un nombre predefinido, por lo que los Perfiles portátiles tampoco pueden inferir TargetFrameworkIdentifier , TargetFrameworkVersion y TargetFrameworkProfile . Además, una constante del compilador no se define automáticamente. Finalmente, debe agregar todas las referencias de ensamblaje; ninguna se proporciona de forma predeterminada.

Este ejemplo a continuación está tomado de un proyecto que usó la palabra clave dynamic por lo que además necesitó el ensamblado Microsoft.CSharp , por lo que puede ver cómo son referencias para diferentes objetivos.

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFrameworks>netstandard1.5;net40;portable40-net45+sl5+win8+wp8</TargetFrameworks> </PropertyGroup> <PropertyGroup Condition="''$(TargetFramework)''==''portable40-net45+sl5+win8+wp8''"> <TargetFrameworkIdentifier>.NETPortable</TargetFrameworkIdentifier> <TargetFrameworkVersion>v4.0</TargetFrameworkVersion> <TargetFrameworkProfile>Profile158</TargetFrameworkProfile> <DefineConstants>$(DefineConstants);PORTABLE158</DefineConstants> </PropertyGroup> <ItemGroup Condition="''$(TargetFramework)''==''netstandard1.5''"> <PackageReference Include="Microsoft.CSharp" Version="4.3.0" /> <PackageReference Include="System.ComponentModel" Version="4.3.0" /> </ItemGroup> <ItemGroup Condition="''$(TargetFramework)''==''net40''"> <Reference Include="Microsoft.CSharp" /> </ItemGroup> <ItemGroup Condition="''$(TargetFramework)''==''portable40-net45+sl5+win8+wp8''"> <Reference Include="Microsoft.CSharp" /> <Reference Include="System" /> <Reference Include="System.Core" /> <Reference Include="System.Windows" /> </ItemGroup> </Project>