asp.net core - downloads - Establecer el número de versión para proyectos.NET Core

asp.net core 2.1 tutorial

Question

¿Cuáles son las opciones para establecer una versión de proyecto con proyectos .NET Core / ASP.NET Core?

Encontrado hasta ahora:

• Establezca la propiedad de la version en project.json . Fuente: Descripción general de DNX , Trabajar con proyectos DNX . Esto parece configurar AssemblyVersion , AssemblyFileVersion y AssemblyInformationalVersion menos que sea anulado por un atributo (ver el siguiente punto).

• Establecer los atributos AssemblyVersion , AssemblyFileVersion , AssemblyInformationalVersion también parece funcionar y anular la propiedad de version especificada en project.json .

  Por ejemplo, incluir ''version'':''4.1.1-*'' en project.json y establecer [assembly:AssemblyFileVersion("4.3.5.0")] en un archivo .cs dará como resultado AssemblyVersion=4.1.1.0 , AssemblyInformationalVersion=4.1.1.0 y AssemblyFileVersion=4.3.5.0

Está estableciendo el número de versión a través de los atributos, por ejemplo, AssemblyFileVersion , aún soportado?

¿Me he perdido algo? ¿Hay otras formas?

Contexto

El escenario que estoy viendo es compartir un solo número de versión entre múltiples proyectos relacionados. Algunos de los proyectos están utilizando .NET Core (project.json), otros están utilizando .NET Framework completo (.csproj). Todos son lógicamente parte de un sistema único y tienen versiones juntas.

La estrategia que utilizamos hasta ahora es tener un archivo SharedAssemblyInfo.cs en la raíz de nuestra solución con los atributos AssemblyVersion y AssemblyFileVersion . Los proyectos incluyen un enlace al archivo.

Estoy buscando maneras de lograr el mismo resultado con los proyectos .NET Core, es decir, tener un solo archivo para modificar.

Answer 1

utilice el archivo externo version.txt con la versión y el paso de prebuild para publicar esta versión en los proyectos

Answer 2

No estoy seguro de si esto ayuda, pero puede establecer sufijos de versión en tiempo de publicación. Nuestras versiones generalmente son impulsadas por la fecha, por lo que los desarrolladores no tienen que recordar actualizarlas.

Si tu json tiene algo así como "1.0- *"

"dotnet publish --version-sufijo 2016.01.02" lo convertirá en "1.0-2016.01.02".

Es importante cumplir con los estándares "semvar", de lo contrario obtendrá errores. La publicación de Dotnet te dirá.

Answer 3

¿Por qué no cambiar el valor en el archivo project.json? Usando CakeBuild podrías hacer algo como esto (es probable que las optimizaciones sean posibles)

Task("Bump").Does(() => {
    var files = GetFiles(config.SrcDir + "**/project.json");
    foreach(var file in files)
    {
        Information("Processing: {0}", file);

        var path = file.ToString();
        var trg = new StringBuilder();
        var regExVersion = new System.Text.RegularExpressions.Regex("/"version/":(//s)?/"0.0.0-//*/",");
        using (var src = System.IO.File.OpenRead(path))
        {
            using (var reader = new StreamReader(src))
            {
                while (!reader.EndOfStream)
                {
                    var line = reader.ReadLine();
                    if(line == null)
                        continue;

                    line = regExVersion.Replace(line, string.Format("/"version/": /"{0}/",", config.SemVer));

                    trg.AppendLine(line);
                }
            }
        }

        System.IO.File.WriteAllText(path, trg.ToString());
    }
});

Luego, si tiene, por ejemplo, un proyecto UnitTest que toma una dependencia del proyecto, use "*" para la resolución de la dependencia.

Además, realice el bache antes de realizar la dotnet restore . Mi orden es la siguiente:

Task("Default")
  .IsDependentOn("InitOutDir")
  .IsDependentOn("Bump")
  .IsDependentOn("Restore")
  .IsDependentOn("Build")
  .IsDependentOn("UnitTest");

Task("CI")
  .IsDependentOn("Default")
  .IsDependentOn("Pack");

Enlace al script completo de compilación: https://github.com/danielwertheim/Ensure.That/blob/3a278f05d940d9994f0fde9266c6f2c41900a884/build.cake

Los valores reales, por ejemplo, la version proviene de la importación de un archivo build.config separado, en el script de compilación:

#load "./buildconfig.cake"

var config = BuildConfig.Create(Context, BuildSystem);

El archivo de configuración se ve así (tomado de https://github.com/danielwertheim/Ensure.That/blob/3a278f05d940d9994f0fde9266c6f2c41900a884/buildconfig.cake ):

public class BuildConfig
{
    private const string Version = "5.0.0";

    public readonly string SrcDir = "./src/";
    public readonly string OutDir = "./build/";    

    public string Target { get; private set; }
    public string Branch { get; private set; }
    public string SemVer { get; private set; }
    public string BuildProfile { get; private set; }
    public bool IsTeamCityBuild { get; private set; }

    public static BuildConfig Create(
        ICakeContext context,
        BuildSystem buildSystem)
    {
        if (context == null)
            throw new ArgumentNullException("context");

        var target = context.Argument("target", "Default");
        var branch = context.Argument("branch", string.Empty);
        var branchIsRelease = branch.ToLower() == "release";
        var buildRevision = context.Argument("buildrevision", "0");

        return new BuildConfig
        {
            Target = target,
            Branch = branch,
            SemVer = Version + (branchIsRelease ? string.Empty : "-b" + buildRevision),
            BuildProfile = context.Argument("configuration", "Release"),
            IsTeamCityBuild = buildSystem.TeamCity.IsRunningOnTeamCity
        };
    }
}

Answer 4

Si aún desea tener el Nivel de solución SharedVersionInfo.cs , puede hacerlo agregando estas líneas a su archivo project.json :

"buildOptions": {
  "compile": {
    "includeFiles": [
      "../../SharedVersionInfo.cs"
    ]
  }
}

Su camino relativo puede variar, por supuesto.