¿Hay alguna forma de publicar una biblioteca estándar de .NET sin producir un .nupkg en Visual Studio 2019?

Tengo entendido que cuando publica una biblioteca estándar de .NET, el comportamiento esperado es producir un archivo .nupkg.

Tengo bibliotecas estándar .Net internas que mantengo para usar en proyectos internos. Un flujo de trabajo típico sería publicar las bibliotecas y luego copiar los archivos publicados en proyectos consumidores. ¿No es así como debería hacer las cosas? Estoy un poco confundido por la falta de opciones al publicar una biblioteca estándar de .NET, ya que no hay .nupkgopción para publicar en una forma diferente.

Lo que quiero obtener de la publicación es solo una colección de archivos de biblioteca necesarios en el directorio de publicación (no dentro de a nupkg). ¿Hay alguna forma de hacer esto?

Tengo entendido que cuando publica una biblioteca estándar .Net, el comportamiento esperado es producir un .nupkg. Lo que quiero obtener de la publicación es solo una colección de archivos de biblioteca necesarios en el directorio de publicación (no dentro de un nupkg). ¿Hay alguna forma de hacer esto?

Para proyectos normales de .net framework, si hace referencia a un paquete nuget y lo compila. Luego obtienes una carpeta de salida (bin \ debug o bin \ release) con Project.dll y Package.dll en ella. Y eso es lo que quieres.

Pero para el .net standardproyecto, solo generará el archivo Project.dllde forma predeterminada. También se pretende comportamiento, ver comment1 , comment2 . Y es por eso que sugiero que deba editar manualmente xx.csprojpara obtener su comportamiento esperado durante la compilación. Eso es por diseño que no copiará las dependencias nuget a la salida, y esta es la solución alternativa que puede satisfacer sus necesidades.

En cuanto a por qué publish output is a xx.nupkgcuando hace clic con el botón derecho en el nodo del proyecto => Publicar en VS IDE (proyecto estándar .net), consulte este documento : El vehículo de distribución principal para los ensamblajes de referencia estándar .NET son los paquetes NuGet. Supongo que es por eso que la salida de Publish es xx.nupkg, es difícil de decir, pero podría ser por diseño ...

Editar:

¿Hay alguna forma de publicar una biblioteca estándar .Net sin producir un .nupkg en Visual Studio 2019?

Si se refiere a la opción Publicar para el proyecto estándar .net (haga clic con el botón derecho en el nombre del proyecto estándar .net en el Explorador de soluciones => Publicar). Me temo que la respuesta es negativa. Esta opción es por diseño y por ahora no publish a folder with all referenced assembliesse admiten otras opciones similares . Es posible que deba agregar una solicitud de función en DC .

Espero que mis aclaraciones sirvan de ayuda y si no entiendo algo, no dudes en corregirme :(

Un flujo de trabajo típico sería publicar las bibliotecas y luego copiar los archivos publicados en proyectos consumidores. ¿No es así como debería hacer las cosas?

No. Esa es la peor forma de hacer las cosas.

Si / como no está usando paquetes Nuget generados localmente, debería usar referencias de proyecto :

Cuando tiene un proyecto que produce un ensamblaje, debe hacer referencia al proyecto y no usar una referencia de archivo. La ventaja de una referencia de proyecto a proyecto es que crea una dependencia entre los proyectos en el sistema de compilación.

Cada solución que contiene un proyecto que hace referencia a una o más de sus bibliotecas internas también debe contener las bibliotecas (y las bibliotecas internas a las que hacen referencia esas bibliotecas) en la solución.

Revisaré esto creando algunos proyectos desechables sobre la marcha, pero las técnicas también se aplican al código existente; solo las agregaría a la solución en lugar de crear otros nuevos:

• Crear ClassLibrary1segmentación .NET Standard 2.0
• Agregar un nuevo proyecto a la solución: ClassLibrary2dirigido a .NET Standard 2.0
• Instalemos un paquete popular de Nuget para ClassLibrary2:Newtonsoft.Json
• Haga clic derecho en ClassLibrary1en el explorador de soluciones, haga clic Addy luego haga clic en Reference. En la pestaña del proyecto, marque ClassLibrary2y haga clic en Aceptar. ClassLibrary1ahora tiene una referencia de proyecto ClassLibrary2y se ha agregado lo siguiente a ClassLibrary1.csproj:

  <ItemGroup>
    <ProjectReference Include="..\ClassLibrary2\ClassLibrary2.csproj" />
  </ItemGroup>

• Agregue un proyecto de aplicación de consola .NET, ConsoleApp1

• Agregue una referencia de proyecto para ClassLibraryqueConsoleApp1

• Guarda la solución

• Construya, con una configuración de lanzamiento, la solución

• Todo lo que necesitamos está en la carpeta bin de la aplicación de consola, y no hay una carpeta Nupkg a la vista:

• Si creamos otra solución y le agregamos nuestras bibliotecas, o reutilizamos esta solución, y luego le agregamos una aplicación de consola .NET Core, y ClassLibrary1hacemos que esa aplicación tome una referencia de proyecto y compile, nuevamente no hay Nupkg en ninguna parte de la carpeta. árbol.

• Sin embargo, publicamos aplicaciones .NET Core. A mí, al menos, me gusta publicar mis aplicaciones .NET Core (para uso interno) como 'autónomas'. Para hacer esto, hago clic derecho en la aplicación .NET Core en el Explorador de soluciones, hago clic Publishy elijo Foldercomo destino. Hago clic en Create Profiley luego Editcambio el modo de implementación a self-contained, y luego guardo. Luego publico la aplicación ( no las bibliotecas) y obtengo todos los archivos que necesito en mi carpeta de publicación, incluidas las bibliotecas internas y .NET Core (no se preocupe, la DLL de Newtonsoft también está allí, simplemente no está visible en la captura de pantalla):

Las únicas veces que obtengo un paquete Nuget creado son:

• si publico explícitamente las bibliotecas internas, o

• si tengo <GeneratePackageOnBuild>true</GeneratePackageOnBuild>en el archivo del proyecto [ ejemplo ]

Hacerlo de la "manera Nuget" es un enfoque excelente y válido si está distribuyendo las bibliotecas a través de un paquete privado; pero como eso no es lo que quieres hacer, ¡no publiques las bibliotecas! En su lugar, tome las referencias del proyecto, lo que significa agregar las bibliotecas a las soluciones que las consumen