web-dev-qa-db-fra.com

Définition du numéro de version des projets .NET Core - CSPROJ - et non des projets JSON

Cette question est très similaire à Définition du numéro de version pour les projets .NET Core , mais pas identique. Utilisant la dernière version stable de .NET Core au moment de la rédaction (1.1) et de VS2017, .NET Core est passé des fichiers de projet basés sur JSON aux fichiers CSPROJ.

Donc, ce que j'essaie de faire, c’est de configurer un environnement CI dans lequel je voudrais pouvoir modifier quelque chose avant de créer un correctif afin d’apposer le bon numéro de version à mes compilations.

Si j'utilise les attributs comme celui-ci, l'ancien (astuce SharedAssemblyInfo.cs):

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

quelque part dans le projet, je reçois
CS0579 - Duplicate 'System.Reflection.AssemblyFileVersionAttribute'
et
CS0579 - Duplicate 'System.Reflection.AssemblyVersionAttribute'
erreurs lors de la construction.

En creusant un peu, je trouve qu’il existe un fichier ressemblant à celui-ci généré pendant le processus de construction (il n’existait pas avant la construction) dans \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.

Question - Comment puis-je faire ce bit?
Je vois donc que cela doit en quelque sorte être généré à partir des valeurs entrées dans la page de package des propriétés du projet, mais je ne sais pas quel serait le bon moyen de modifier ces valeurs sur ma machine CI.

Idéalement, j'aimerais pouvoir spécifier toutes ces informations dans mon script CI (Jenkins), mais je me contenterais de pouvoir définir le numéro de version.

EDIT - Plus d'infos
Après avoir lu la première réponse, je souhaitais préciser que je créais à la fois des services et des packages NuGET - et je préférerais disposer d’un moyen de gestion des versions, qui ressemblerait à l’ancien projet JSON. il suffit de mettre à jour un seul fichier.

[~ # ~] update [~ # ~] Je vais écrire avec un script une modification du fichier CSPROJ qui, à mon avis, est plutôt hacky comme section J'ai besoin de modifier les apparences comme ceci ...

<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>

Le problème ici est qu’il existe plusieurs éléments 'PropertyGroup'; les autres semblent étiquetés - mais ne sachant pas comment le CSPROJ est mis en place, je ne peux pas dire que ce sera toujours le cas.

Je travaille sur la prémisse que les détails du paquet seront toujours renseignés, sinon les balises value (ci-dessus) n'apparaissent pas dans le XML - je peux donc utiliser un script pour mettre à jour les valeurs en place. Si les balises de valeur n'existaient pas, je n'aurais aucune idée précise de l'élément dans lequel PropertyGroup dans lequel insérer les valeurs (ni de l'ordre, car cela semble important; le fait de modifier cet ordre m'a empêché de charger le projet dans VS2017).

Je tiens toujours à une meilleure solution que celle-ci!

Mise à jour: après que quelqu'un ait marqué cette question comme un doublon possible ( Versioning automatique dans Visual Studio 2017 (.NET Core) ) - Je n'avais pas vu cette question auparavant et la lecture semble à peu près la même chose sauf que je ne veux pas juste définir le numéro de version. En outre, les réponses à cette question ne résolvent pas mon problème - ne demande que ce que j'ai demandé dans ma question. La réponse acceptée à ma question est exactement la réponse dont j'ai besoin pour résoudre mon problème - alors que l'autre question est apparue en premier et a la même apparence - elle ne m'aide pas du tout. Peut-être qu'un mod peut aider?

asp.net-corecontinuous-integration.net-coreversioning
40
Jay

Vous pouvez remplacer n'importe quelle propriété de la ligne de commande en passant /p:PropertyName=Value Comme arguments à dotnet restore, dotnet build Et dotnet pack.

Actuellement, la composition de la version fonctionne comme suit: Si Version est non défini, utilisez VersionPrefix (la valeur par défaut est 1.0.0 si non définie) et - si présent - append VersionSuffix.

Toutes les autres versions sont alors définies par défaut sur ce que Version est.

Ainsi, par exemple, vous pouvez définir <VersionPrefix>1.2.3</VersionPrefix> Dans votre csproj, puis appeler dotnet pack --version-suffix beta1 Pour générer un YourApp.1.2.3-beta1.nupkg (Si vous avez une référence de projet à laquelle vous souhaitez appliquer le suffixe de version eh bien, vous devez appeler dotnet restore /p:VersionSuffix=beta1 avant cela - c'est un bogue connu dans l'outillage).

Bien sûr, vous pouvez également utiliser des variables personnalisées, voir ce problème de GitHub pour quelques exemples.

Pour une référence complète des attributs d'assemblage pris en charge, je suggère de consulter le code source de la logique de construction ici (les valeurs entourées de $() sont les propriétés utilisées). Et puisque je parle déjà de la source, this est la logique qui compose la version et quelques autres propriétés.

51
Martin Ullrich
dotnet build /p:AssemblyVersion=1.2.3.4

Est-ce que ça marche pour toi?

35
Chris McKenzie

Pour répondre directement à votre question: le nouveau SDK de msbuild génère automatiquement un fichier d’information sur l’assemblage. Vous pouvez supprimer cela en utilisant les directives msbuild (pour le voir par exemple: invoke dotnet migrate sur un projet basé sur project.json).

Mais laissez-moi vous raconter ma manipulation: plusieurs projets partageant la même version. J'ai ajouté un version.props fichier contenant un groupe de propriétés comprenant un élément nommé VersionPrefix. J'ai inclus ce fichier via le fichier csproj (instruction Include). J'ai aussi enlevé tous les AssemblyInfo.cs fichiers et laissez le SDK les générer pour moi.

Je modifie le version.props fichier pendant la construction.

7
Thomas

J'utilise Jenkins + Octopus pour CI, et la suite a très bien fonctionné:

  1. Avoir un script pré-build Powershell pouvant prendre le numéro de build de CI comme paramètre ou, par défaut, quelque chose de prédéfini.
  2. Avoir un fichier nuspec séparé dans le projet pour CI.
  3. Le script de pré-génération mettrait à jour le fichier nuspec avec la dernière version de construction.
  4. Publier le projet avec Jenkins.
  5. Appelez Nuget manuellement avec un fichier nuspec à partir de # 2.
  6. Poussez le paquetage nuget vers Octopus.
3
Ignas

Dans mon cas, la clé principale était /property:Version=1.2.3.4. Et la ligne de commande suivante a fait le travail:

dotnet build SolutionName.sln -c Release /property:Version=1.2.3.4

Ceci remplacera la version par défaut de Assembly.

3
maytham-ɯɐɥʇʎɐɯ

MsBuild 2017 générera des informations d'assemblage si vous les manquez dans le fichier de projet.

Si vous pouvez lire le fichier cible msbuild, vous pouvez consulter:

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

Vous verrez que vous pouvez utiliser certaines propriétés dans votre fichier de projet pour désactiver les informations d'assemblage générées afin d'éviter les doublons avec vos outils générés.

  • <GenerateAssemblyInfo> _ (Cette propriété active ou désactive toutes les informations relatives à l'assemblage)
  • <GenerateAssemblyCompanyAttribute>
  • <GenerateAssemblyConfigurationAttribute>
  • <GenerateAssemblyCopyrightAttribute>
  • <GenerateAssemblyDescriptionAttribute>
  • <GenerateAssemblyFileVersionAttribute>
  • <GenerateAssemblyInformationalVersionAttribute>
  • <GenerateAssemblyProductAttribute>
  • <GenerateAssemblyTitleAttribute>
  • <GenerateAssemblyVersionAttribute>
  • <GenerateNeutralResourcesLanguageAttribute>
3
Anh Phan Tuan

Comme j'ai déjà répondu ici , j'ai créé un outil CLI appelé dotnet-setversion que vous pouvez utiliser pour le contrôle de version de projets .NET Core de type .csproj.

Lors de la construction d'un CI, vous pouvez utiliser GitVersion ou un autre outil pour déterminer le numéro de version de votre projet, puis appeler dotnet-setversion $YOUR_VERSION_STRING dans le répertoire racine de votre projet.

1
Tagc

Passer/p: PropertyName = La valeur en tant qu'arguments ne fonctionne pas pour moi (ASP.Net Core 2.0 Web App). J'ai trouvé les tâches de construction du contrôle de version du manifeste sur le marché: https://marketplace.visualstudio.com/items?itemName=richardfennellBM.BM-VSTS-Versioning-Task

0
Michael Giger