the runtimeidentifiers netcore net how dotnet asp asp.net-core continuous-integration .net-core versioning

asp.net-core - how - runtimeidentifiers netcore



Establecer el número de versión para proyectos.NET Core-CSPROJ-no proyectos JSON (7)

Uso Jenkins + Octopus para CI, y el siguiente funcionó bastante bien:

  1. Tenga una secuencia de comandos previa a la compilación de Powershell que pueda tomar el número de compilación de CI como parámetro o predeterminado a algo preestablecido.
  2. Tener un archivo nuspec separado en el proyecto para CI.
  3. La secuencia de comandos de nuspec actualizará el archivo nuspec con la última versión de compilación.
  4. Publicar proyecto con Jenkins.
  5. Llame a Nuget manualmente con un archivo nuspec desde # 2.
  6. nuget paquete nuget a Octopus.

Esta pregunta es muy similar a Establecer el número de versión para proyectos .NET Core , pero no es lo mismo. Utilizando la última versión estable de .NET Core en el momento de escribir (1.1) y VS2017, .NET Core ha cambiado de archivos de proyecto basados ​​en JSON a archivos CSPROJ.

Entonces, lo que intento hacer es configurar un entorno de CI donde me gustaría poder modificar algo antes de una construcción para sellar mis compilaciones con el número de versión correcto.

Si utilizo los atributos como este el antiguo (truco SharedAssemblyInfo.cs):

[assembly: AssemblyFileVersion("3.3.3.3")] [assembly: AssemblyVersion("4.4.4.4")]

en algún lugar del proyecto, obtengo
CS0579 - Duplicate ''System.Reflection.AssemblyFileVersionAttribute''
y
CS0579 - Duplicate ''System.Reflection.AssemblyVersionAttribute''
errores al construir.

Al profundizar un poco, descubro que hay un archivo que se parece a este generado durante el proceso de compilación (no existe antes de compilar) en /obj/Debug/netcoreapp1.1 :

//------------------------------------------------------------------------------ // <auto-generated> // This code was generated by a tool. // Runtime Version:4.0.30319.42000 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // </auto-generated> //------------------------------------------------------------------------------ using System; using System.Reflection; [assembly: System.Reflection.AssemblyCompanyAttribute("TestApplication")] [assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")] [assembly: System.Reflection.AssemblyDescriptionAttribute("Package Description")] [assembly: System.Reflection.AssemblyFileVersionAttribute("1.1.99.0")] [assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.1.99")] [assembly: System.Reflection.AssemblyProductAttribute("TestApplication")] [assembly: System.Reflection.AssemblyTitleAttribute("TestApplication")] [assembly: System.Reflection.AssemblyVersionAttribute("1.1.99.0")] // Generated by the MSBuild WriteCodeFragment class.

Pregunta - ¿Cómo hago este bit?
Así que puedo ver que esto debe generarse de alguna manera a partir de los valores ingresados ​​en la página de paquete de propiedades del proyecto, pero no sé cuál sería la manera correcta de cambiar estos valores en mi máquina CI.

Idealmente, me gustaría poder especificar toda esta información en mi script (de Jenkins) CI, pero me conformaría con solo poder establecer el número de versión.

EDITAR - Más información
Después de leer la primera respuesta, quería dejar en claro que estoy creando ambos servicios y paquetes NuGET, y preferiría tener 1 forma de versionar todo, que sería como el viejo proyecto JSON donde podría actualizar un solo archivo .

ACTUALIZACIÓN Voy con el scripting de un cambio al archivo CSPROJ que en mi opinión es bastante hacky ya que la sección que necesito modificar se ve así ...

<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp1.1</TargetFramework> <Version>1.0.7777.0</Version> <AssemblyVersion>1.0.8888.0</AssemblyVersion> <FileVersion>1.0.9999.0</FileVersion> <Company>MyCompany</Company> <Authors>AuthorName</Authors> <Product>ProductName</Product> <Description /> <Copyright>Copyright © 2017</Copyright> </PropertyGroup>

Entonces, el problema aquí es que hay múltiples elementos ''PropertyGroup''; los otros parecen estar etiquetados, pero al no saber cómo se arma el CSPROJ, no puedo decir que este sea siempre el caso.

Estoy trabajando en la premisa de que los detalles del paquete siempre se completarán, de lo contrario las etiquetas de valor (arriba) no aparecen en el XML, entonces puedo usar un script para actualizar los valores en su lugar. Si las etiquetas de valor no estuvieran allí, no tendría una idea clara del elemento PropertyGroup en el que insertar los valores (y también el orden, ya que esto parece ser importante; cambiar el orden me impidió cargar el proyecto en VS2017).

¡Todavía estoy esperando una solución mejor que esta!

Actualización: después de que alguien marque esta pregunta como posible duplicado ( Auto Versioning en Visual Studio 2017 (.NET Core) ) - No había visto esta pregunta antes y ahora parece casi igual, excepto que no solo quiero establecer el número de versión. Además, las respuestas a esta pregunta no resuelven mi problema, solo me pregunta qué hice en mi pregunta. La respuesta aceptada a mi pregunta es exactamente la respuesta que necesito para resolver mi problema, por lo tanto, aunque la otra pregunta fue la primera y parece la misma, no me sirve de nada. Tal vez un mod puede ayudar?

Para responder a su pregunta directamente: el nuevo SDK para msbuild genera automáticamente un archivo de información de conjunto. Puede suprimir eso usando directivas msbuild (para verlo por ejemplo: invocar dotnet migrate en un proyecto basado en project.json).

Pero déjame decirte mi manejo: tuve varios proyectos compartiendo la misma versión. version.props un archivo version.props que contenía un grupo de propiedades que incluía un elemento denominado VersionPrefix . Este archivo lo incluí a través del archivo csproj (instrucción Include ). También eliminé todos los archivos AssemblyInfo.cs y dejé que el SDK los generara para mí.

version.props archivo version.props durante la compilación.

MsBuild 2017 generará cierta información de ensamblaje si los extrañas en el archivo del proyecto.

Si puede leer el archivo objetivo de msbuild, puede mirar:

[VS Install Dir] /MSBuild/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.GenerateAssemblyInfo.targets

Verá que puede usar alguna propiedad en su archivo de proyecto para deshabilitar la información de ensamblaje generada y evitar que se duplique con las herramientas generadas.

  • <GenerateAssemblyInfo> (Esta propiedad activará / desactivará todos los datos de ensamblaje)
  • <GenerateAssemblyCompanyAttribute>
  • <GenerateAssemblyConfigurationAttribute>
  • <GenerateAssemblyCopyrightAttribute>
  • <GenerateAssemblyDescriptionAttribute>
  • <GenerateAssemblyFileVersionAttribute>
  • <GenerateAssemblyInformationalVersionAttribute>
  • <GenerateAssemblyProductAttribute>
  • <GenerateAssemblyTitleAttribute>
  • <GenerateAssemblyVersionAttribute>
  • <GenerateNeutralResourcesLanguageAttribute>

Como he respondido aquí , he creado una herramienta de CLI llamada dotnet-setversion que puede usar para versionar proyectos * .csproj-style .NET Core.

Durante una construcción de CI, puede usar GitVersion u otra herramienta para determinar un número de versión para su proyecto y luego invocar dotnet-setversion $YOUR_VERSION_STRING en el directorio raíz de su proyecto.

dotnet build /p:AssemblyVersion=1.2.3.4

Eso funciona para ti?

Puede anular cualquier propiedad de la línea de comando pasando /p:PropertyName=Value como argumentos a dotnet restore , dotnet build y dotnet pack .

Actualmente, la composición de la versión funciona así: si la Version está configurada, use VersionPrefix (por defecto es 1.0.0 si no está configurada) y, si está presente, VersionSuffix .

Todas las otras versiones son predeterminadas para cualquier Version .

Entonces, por ejemplo, puede establecer <VersionPrefix>1.2.3</VersionPrefix> en su csproj y luego llamar al dotnet pack --version-suffix beta1 para producir un YourApp.1.2.3-beta1.nupkg (si tiene una referencia de proyecto que también quiere aplicar el sufijo de versión, necesita llamar a dotnet restore /p:VersionSuffix=beta1 antes de eso - este es un error conocido en las herramientas).

Por supuesto, también puede usar variables personalizadas, vea este problema de GitHub para algunos ejemplos.

Para una referencia completa de los atributos de ensamblaje soportados, sugiero que mire el código fuente de la lógica de compilación aquí (los valores rodeados con $() son las propiedades utilizadas). Y como ya estoy hablando de la fuente, esta es la lógica que compone la versión y algunas otras propiedades.