150 votes

Réglage du numéro de version pour .NET de Base des projets - CSPROJ - pas de JSON projets

Cette question est très proche de Réglage du numéro de version pour .NET de Base des projets, mais pas la même. À l'aide de la dernière version stable de .NET de Base au moment de la rédaction (1.1) et VS2017, .NET de Base a changé à partir de JSON en fonction des fichiers de projet pour CSPROJ fichiers.

Donc, ce que je suis en train de faire c'est de créer un environnement CI où je voudrais être en mesure de modifier quelque chose avant un build pour mon timbre construit avec le numéro de version correct.

Si j'utilise les attributs, les vieux (SharedAssemblyInfo.cs truc):

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

quelque part dans le projet, j'obtiens
CS0579 - Duplicate 'System.Reflection.AssemblyFileVersionAttribute'
et
CS0579 - Duplicate 'System.Reflection.AssemblyVersionAttribute'
erreurs lors de la construction.

Lorsque creusant un peu, je trouve qu'il y a un fichier qui ressemble à ça générés pendant le processus de génération (il n'existe pas avant que je build) 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.

Question - Comment dois-je faire ce peu?
Je vois donc qu'il faut en quelque sorte être généré à partir des valeurs saisies dans les propriétés du projet 'l'ensemble de la page, mais je ne sais pas quelle est la bonne façon serait de modifier ces valeurs sur mon implant de la machine.

Idéalement, je voudrais être en mesure de spécifier toutes ces informations dans mon (Jenkins) CI script, mais je me contenterais juste pour être en mesure de définir le numéro de version.

EDIT - Plus d'Infos
Après la lecture de la première réponse, je voulais préciser que je suis en créant à la fois des services et des packages NuGET - et je préfère avoir 1 mode de gestion des versions de tout, qui serait comme l'ancien JSON projet où je pourrais juste mettre à jour un fichier unique.

Mise à JOUR Je vais avec le script d'une modification du fichier CSPROJ qui à mon avis est plutôt hacky que la section j'ai besoin de modifier ressemble à 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>

Donc, le problème, c'est qu'il y a plusieurs 'PropertyGroup' éléments; les autres semblent être étiqueté - mais ne sachant pas comment la CSPROJ est mis ensemble, je ne peux pas dire que ce sera toujours le cas.

Je suis en train de travailler sur l'hypothèse que les renseignements sur le colis sera toujours rempli, sinon, la valeur des balises (ci-dessus) n'apparaissent pas dans le fichier XML - alors je peux utiliser un script pour mettre à jour les valeurs en place. Si la valeur des balises n'étaient pas là, je n'aurais pas d'idée claire de ce qui PropertyGroup élément à insérer les valeurs dans (et aussi quel ordre, comme cela semble être important; modification de l'ordre qui m'a empêché de charger le projet dans VS2017).

Je suis toujours en tenue pour une meilleure solution que celle-là!

Mise à jour: Après que quelqu'un marquage de cette question comme un possible double (Auto gestion des versions de Visual Studio à 2017.NET de Base)) - je n'avais pas vu cette question avant et maintenant il semble être presque la même sauf que je ne veux juste définir le numéro de version. Aussi, les réponses à cette question ne résout pas mon problème - demande seulement ce que j'ai demandé à ma question. La accepté de répondre à ma question est exactement la réponse que j'ai besoin pour résoudre mon problème - ainsi, alors que l'autre question qui est venu en premier et s'affiche de la même - il ne m'aide pas du tout. Peut-être un mod peut vous aider?

151voto

Martin Ullrich Points 5894

Vous pouvez remplacer n'importe quel bien de la ligne de commande en passant /p:PropertyName=Value comme arguments au dotnet restore, dotnet build et dotnet pack.

Actuellement, la Version la composition fonctionne comme ceci: Si Version n'est pas définie, utilisez VersionPrefix (valeur par défaut: 1.0.0 si la fonction unset () et - s'il est présent - append VersionSuffix.

Tous les autres version sont alors, par défaut, quelle que soit Version est.

Ainsi, par exemple, vous pouvez configurer <VersionPrefix>1.2.3</VersionPrefix> dans votre csproj puis appelez dotnet pack --version-suffix beta1 pour produire un YourApp.1.2.3-beta1.nupkg (si vous avez de référence du projet que vous souhaitez la version suffixe à être appliquée à des ainsi, vous devez appeler dotnet restore /p:VersionSuffix=beta1 avant cela, c'est un bug connu de l'outillage).

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

Pour une référence complète de prises en charge assemblée attributs, je vous suggère de regarder le code source de la construction de la logique ici (les valeurs entouré d' $() sont les propriétés utilisées). Et depuis que je suis déjà en train de discuter à propos de la source, c' est la logique qui compose la version et quelques autres propriétés.

125voto

Chris McKenzie Points 1023
dotnet build /p:AssemblyVersion=1.2.3.4

Cela fonctionne pour vous?

9voto

Anh Phan Tuan Points 31

MsBuild 2017 va générer un peu de montage info si vous manquant dans le fichier de Projet.

Si vous pouvez lire le msbuild fichier cible, vous pouvez la regarder:

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

Vous verrez que vous pouvez utiliser de la propriété dans vous fichier de projet pour désactiver l'assembly généré info pour éviter le double avec vos outils.

  • <GenerateAssemblyInfo> (Cette propriété sur/hors tension tous les générer de l'assemblée info)
  • <GenerateAssemblyCompanyAttribute>
  • <GenerateAssemblyConfigurationAttribute>
  • <GenerateAssemblyCopyrightAttribute>
  • <GenerateAssemblyDescriptionAttribute>
  • <GenerateAssemblyFileVersionAttribute>
  • <GenerateAssemblyInformationalVersionAttribute>
  • <GenerateAssemblyProductAttribute>
  • <GenerateAssemblyTitleAttribute>
  • <GenerateAssemblyVersionAttribute>
  • <GenerateNeutralResourcesLanguageAttribute>

8voto

Thomas Points 3698

Pour répondre à votre question directement: Le nouveau SDK pour msbuild est auto générer une assemblée info fichier. Vous pouvez supprimer que l'utilisation de msbuild directives (voir le par exemple: invoquer dotnet migrate sur un projet.json en fonction du projet).

Mais laissez-moi vous dire ma manipulation: j'ai eu plusieurs projets de partage de la même version. J'ai ajouté un version.props le fichier qui contient un groupe de propriétés, y compris un élément nommé" VersionPrefix. Ce fichier j'ai inclus via le fichier csproj (Include déclaration). J'ai également retiré AssemblyInfo.cs fichiers et de laisser le SDK générer pour moi.

J'ai modifier l' version.props le fichier lors de la construction.

4voto

Ignas Points 1662

J'utilise Jenkins + Octopus pour l'IC, et à la suite travaillé assez bien:

  1. Avoir une pré-construction Powershell script qui peut prendre de CI, de construire le nombre comme un param par défaut, ou de quelque chose de prédéfini.
  2. Séparé nuspec le fichier dans le projet pour la CI.
  3. Le pre-build script de mise à jour de nuspec le fichier avec la version la plus récente version.
  4. Publier le projet avec Jenkins.
  5. Appelez Nuget manuellement avec un nuspec le fichier de #2.
  6. Pousser l' nuget package pour le Poulpe.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X