search

mwpowellhtx / BumpAssemblyVersions

A flexible way of Bumping Assembly Versions with a rich set of instructions how to do so.
GNU General Public License v3.0
4 stars 0 forks source link

The "BumpVersion" task failed unexpectedly. #4

Closed carstencodes closed 4 years ago

carstencodes commented 4 years ago

I am using the .NET core SDK 2.2.401 on linux (ubuntu 18.04, x64) and the BumpAssemblyVersion package version 1.3.1.

When I build the application using dotnet build -f netcoreapp2.2 -c Release, I get the following error:

Build FAILED.

The "BumpVersion" task failed unexpectedly. System.ArgumentException: An item with the same key has already been added. Key: Days Since 1/1/00 [/home/user/dev/app.csproj] at System.Collections.Generic.Dictionary2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) [/home/user/dev/app.csproj] at System.Collections.Generic.Dictionary2.Add(TKey key, TValue value) [/home/user/dev/app.csproj] at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable1 source, Func2 keySelector, Func2 elementSelector, IEqualityComparer1 comparer) [/home/user/dev/app.csproj] at Bav.VersionProviderTemplateRegistry.get_Providers() in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\Providers\VersionProviderTemplateRegistry.cs:line 42 [/home/user/dev/app.csproj] at Bav.VersionProviderTemplateRegistry.g__GetRegistry|7_0() in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\Providers\VersionProviderTemplateRegistry.cs:line 67 [/home/user/dev/app.csproj] at Bav.VersionProviderTemplateRegistry.get_Registry() in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\Providers\VersionProviderTemplateRegistry.cs:line 79 [/home/user/dev/app.csproj] at Bav.VersionProviderExtensionMethods.get_NoOp() in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\VersionProviderExtensionMethods.cs:line 60 [/home/user/dev/app.csproj] at Bav.VersionProviderExtensionMethods.ToVersionProvider(ITaskItem item, String providerRequest, DateTime timestamp) in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\VersionProviderExtensionMethods.cs:line 75 [/home/user/dev/app.csproj] at Bav.BumpVersionDescriptor..ctor(ITaskItem item) in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\BumpVersionDescriptor.cs:line 36 [/home/user/dev/app.csproj] at Bav.DescriptorExtensionMethods.ToDescriptor(ITaskItem item, TaskLoggingHelper log) in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\DescriptorExtensionMethods.cs:line 38 [/home/user/dev/app.csproj] at System.Linq.Enumerable.SelectArrayIterator2.MoveNext() [/home/user/dev/app.csproj] at System.Collections.Generic.LargeArrayBuilder1.AddRange(IEnumerable1 items) [/home/user/dev/app.csproj] at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable1 source) [/home/user/dev/app.csproj] at System.Linq.Enumerable.ToArray[TSource](IEnumerable1 source) [/home/user/dev/app.csproj] at Bav.BumpVersion.TriedExecuteResults()+MoveNext() [/home/user/dev/app.csproj] at System.Collections.Generic.LargeArrayBuilder1.AddRange(IEnumerable1 items) [/home/user/dev/app.csproj] at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable1 source) [/home/user/dev/app.csproj] at Bav.BumpVersion.Execute() in G:\Source\BumpAssemblyVersions\Working\src\BumpAssemblyVersions\BumpVersionTask.cs:line 372 [/home/user/dev/app.csproj] at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/home/user/dev/app.csproj] at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/home/user/dev/app.csproj] 0 Warning(s) 1 Error(s)

Here is my app.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="BumpAssemblyVersions" Version="1.3.1">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

  <PropertyGroup>
    <Version>1.0.0.0</Version>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <AssemblyFileVersion>1.0.0.0</AssemblyFileVersion>
    <FileVersion>1.0.0.0</FileVersion>
    <PackageVersion>1.0.0.0</PackageVersion>
  </PropertyGroup>

  <ItemDefinitionGroup>
    <BumpVersionSpec>
      <DefaultVersion>0.0.0.0</DefaultVersion>
      <CreateNew>true</CreateNew>
      <UseUtc>true</UseUtc>
      <MayReset>true</MayReset>
      <MajorProviderTemplate>ShortYearVersionProvider</MajorProviderTemplate>
      <MinorProviderTemplate>MonthVersionProvider</MinorProviderTemplate>
      <PatchProviderTemplate>DayVersionProvider</PatchProviderTemplate>
      <BuildProviderTemplate>IncrementVersionProvider</BuildProviderTemplate>
    </BumpVersionSpec>
  </ItemDefinitionGroup> 

  <ItemGroup>
    <BumpVersionSpec Include="AssemblyFileVersion"/>
  </ItemGroup>

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <AssemblyName>dotnet-slnvu</AssemblyName>
    <IsTool>true</IsTool>
    <ToolCommandName>slnvu</ToolCommandName>
    <PackageOutputPath>./nupkg</PackageOutputPath>
  </PropertyGroup>

</Project>

What am I doing wrong? Or did I find a bug?

mwpowellhtx commented 4 years ago

@carstencodes Interesting, I am looking into it. In the meantime, I am not certain what the verbosity may do for the specification. Usually, I specify things along these lines.

<BumpVersionSpec DefaultVersion="0.0.0.0" CreateNew="true" UseUtc="true" MayReset="true" MajorProviderTemplate="ShortYear" MinorProviderTemplate="Month" PatchProviderTemplate="DayVersion" BuildProviderTemplate="Increment" />

And then, sometimes I bump differently depending on my Build Configuration, i.e.

<BumpVersionSpec DefaultVersion="0.0.0.0" CreateNew="true" UseUtc="true" MayReset="true" MajorProviderTemplate="ShortYear" MinorProviderTemplate="Month" PatchProviderTemplate="DayVersion" BuildProviderTemplate="Increment" Condition="'$(Configuration)' == 'Release'" />
mwpowellhtx commented 4 years ago

@carstencodes Output during the build should be along these lines, from one of my CLI tools:

4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'Version' from '1.0.4.14226' to '1.0.4.14227'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'AssemblyVersion' from '1.0.4.14226' to '1.0.4.14227'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'FileVersion' from '1.0.4.14226' to '1.0.4.14227'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'PackageVersion' from '1.0.4.14226' to '1.0.4.14227'

Based on the specification:

<BumpVersionSpec Include="Version" BuildProviderTemplate="Increment" Condition="'$(Configuration)' == 'Debug'" />
<BumpVersionSpec Include="AssemblyVersion" BuildProviderTemplate="Increment" Condition="'$(Configuration)' == 'Debug'" />
<BumpVersionSpec Include="FileVersion" BuildProviderTemplate="Increment" Condition="'$(Configuration)' == 'Debug'" />
<BumpVersionSpec Include="PackageVersion" BuildProviderTemplate="Increment" Condition="'$(Configuration)' == 'Debug'" />

The difference I see is no Include="...". As far as I know, this is required for any ItemGroup item, and furnishes the version keys.

mwpowellhtx commented 4 years ago

@carstencodes To clarify, I am not doing anything that fancy, merging specifications, etc. Literally each item defines a self-contained bump in and of itself. So, try the above, and let me know how that works for you. Cheers.

mwpowellhtx commented 4 years ago

Closing. If it is still an issue, re-open. Thanks.

carstencodes commented 4 years ago

@mwpowellhtx This is the reason I used an ItemDefinitionGroup (see documentation, which defines a template for building items.

I know stripped my project down to

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="BumpAssemblyVersions" Version="1.3.1">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>
  <ItemGroup>
    <BumpVersionSpec Include="AssemblyFileVersion" DefaultVersion="0.0.0.0" CreateNew="true" UseUtc="true" MayReset="true" MajorProviderTemplate="ShortYearVersionProvider" MinorProviderTemplate="MonthVersionProvider" PatchProviderTemplate="DayVersionProvider" BuildProviderTemplate="IncrementVersionProvider" />
  </ItemGroup>
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>

</Project>

which should match your configuration.

Unfortunately, the issue remains, when I run dotnet build -f netcoreapp2.2 -v diag on my machine.

00:38:43.846     1>Target "BumpAssemblyVersionsBeforeBuild: (TargetId:14)" in file "/home/user/.nuget/packages/bumpassemblyversions/1.3.1/build/BumpAssemblyVersions.targets" from project "/home/user/dev/app.csproj" (target "BeforeBuild" depends on it):
                   Using "CallTarget" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
                   Task "CallTarget" (TaskId:10)
                     Task Parameter:Targets=GeneralBumpAssemblyVersions (TaskId:10)
00:38:43.853     1>Target "GeneralBumpAssemblyVersions: (TargetId:15)" in file "/home/user/.nuget/packages/bumpassemblyversions/1.3.1/build/BumpAssemblyVersions.targets" from project "/home/user/dev/app.csproj" (target "BumpAssemblyVersionsBeforeBuild" depends on it):
                   Using "BumpVersion" task from assembly "/home/user/.nuget/packages/bumpassemblyversions/1.3.1/build/../tasks/netstandard2.0/BumpAssemblyVersions.dll".
                   Task "BumpVersion" (TaskId:11)
                     Task Parameter:Configuration=Debug (TaskId:11)
                     Task Parameter:
                         Bumps=
                             AssemblyFileVersion
                                     BuildProviderTemplate=IncrementVersionProvider
                                     CreateNew=true
                                     DefaultVersion=0.0.0.0
                                     MajorProviderTemplate=ShortYearVersionProvider
                                     MayReset=true
                                     MinorProviderTemplate=MonthVersionProvider
                                     PatchProviderTemplate=DayVersionProvider
                                     UseUtc=true
                                     Visible=False (TaskId:11)
                     Task Parameter:ProjectFullPath=/home/user/dev/app.csproj (TaskId:11)

So, the issue remains - at least with .NET Core SDK 2.2.401 on Ubuntu 18.04.3 x64

carstencodes commented 4 years ago

@mwpowellhtx Unfortunately, I cannot re-open the issue.

mwpowellhtx commented 4 years ago

@carstencodes Thanks for that feedback. Bumps are working here on Windows side, from Visual Studio build. I will try to repro with dotnet build and see what happens.

mwpowellhtx commented 4 years ago

@carstencodes So far cannot repro, but my Tool is also targeting netcoreapp2.1, not netcoreapp2.2.

Depending on BumpAssemblyVersions 1.3.1 same as you, with, dotnet build >Code.Generation.Roslyn.Tool.log, let the project file drive the target framework, in the log.

  'Code.Generation.Roslyn.Tool.csproj': Bumped 'Version' from '1.0.4.14228' to '1.0.4.14229'
  'Code.Generation.Roslyn.Tool.csproj': Bumped 'AssemblyVersion' from '1.0.4.14228' to '1.0.4.14229'
  'Code.Generation.Roslyn.Tool.csproj': Bumped 'FileVersion' from '1.0.4.14228' to '1.0.4.14229'
  'Code.Generation.Roslyn.Tool.csproj': Bumped 'PackageVersion' from '1.0.4.14228' to '1.0.4.14229'
  'Code.Generation.Roslyn.Engine.csproj': Bumped 'Version' from '1.0.4.14227' to '1.0.4.14228'
  'Code.Generation.Roslyn.Engine.csproj': Bumped 'AssemblyVersion' from '1.0.4.14227' to '1.0.4.14228'
  'Code.Generation.Roslyn.Engine.csproj': Bumped 'FileVersion' from '1.0.4.14227' to '1.0.4.14228'
  'Code.Generation.Roslyn.Engine.csproj': Bumped 'PackageVersion' from '1.0.4.14227' to '1.0.4.14228'
  'Code.Generation.Roslyn.csproj': Bumped 'Version' from '1.0.4.14225' to '1.0.4.14226'
  'Code.Generation.Roslyn.Attributes.csproj': Bumped 'Version' from '1.0.4.14222' to '1.0.4.14223'
  'Code.Generation.Roslyn.Attributes.csproj': Bumped 'AssemblyVersion' from '1.0.4.14222' to '1.0.4.14223'
  'Code.Generation.Roslyn.csproj': Bumped 'AssemblyVersion' from '1.0.4.14225' to '1.0.4.14226'
  'Code.Generation.Roslyn.Attributes.csproj': Bumped 'FileVersion' from '1.0.4.14222' to '1.0.4.14223'
  'Code.Generation.Roslyn.Attributes.csproj': Bumped 'PackageVersion' from '1.0.4.14222' to '1.0.4.14223'
  'Code.Generation.Roslyn.csproj': Bumped 'FileVersion' from '1.0.4.14225' to '1.0.4.14226'
  'Code.Generation.Roslyn.csproj': Bumped 'PackageVersion' from '1.0.4.14225' to '1.0.4.14226'

I will try with the ItemDefinitionGroup convention that you mentioned. Sounds interesting and would like to see if that works.

mwpowellhtx commented 4 years ago

@carstencodes Coming back with two observations.

  1. Are you building against a Visual Studio 2019 or analog environment? In particular, ItemDefinitionGroup appears to be an MSBuild 16.x thing, where are I am working in a 2017 environment at the moment, with MSBuild 15.x, which apparently does not have ItemDefinitionGroup yet.

  2. Not sure what the support for netcoreapp2.2 is, yet, whether this would play well with that. As far as I know, I have through NetCore.App 2.1.x installed on my machine, and it seems to support that just fine.

In general, I've been working on a path forward into 2019, but have not gotten that far yet. It is definitely in my queue and should be addressed soon. That to say, I'm not sure what the implications are for MSBuild 16.x and why it might be treating targets differently than MSBuild 15.x.

I welcome contributions that help move it forward in a more ubiquitous, especially x-plat way. For instance, you mentioned Ubuntu (Linux), for example.

carstencodes commented 4 years ago

@mwpowellhtx ItemDefinitionGroups aren't a new thing. They have been introduced at least with the vcxproj file format in VS2010, since the C++ compilation makes much use of it.

I'll try my best to help you moving on.

carstencodes commented 4 years ago

I think I got it: The line https://github.com/mwpowellhtx/BumpAssemblyVersions/blob/27d0b5388a23f326a49847e246717d754a2aa8b4/src/BumpAssemblyVersions/Providers/DeltaDaysVersionProviderBase.cs#L23 gives the error.

I'm using an english local on my linux machine.

When I run a program like

using System;

namespace test
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine($"{new DateTime(1900, 1, 1):d}");
            Console.WriteLine($"{new DateTime(2000, 1, 1):d}");
        }
    }
}

the output is

1/1/00
1/1/00

This explains, that DeltaDays1900VersionProvider and DeltaDays2000VersionProvider will produce the same key in the dictionary. This will explain the crash on load.

mwpowellhtx commented 4 years ago

@carstencodes This could be fixed, yes. However, in your original code, you had this:

<BumpVersionSpec Include="AssemblyFileVersion" DefaultVersion="0.0.0.0" CreateNew="true" UseUtc="true" MayReset="true" MajorProviderTemplate="ShortYearVersionProvider" MinorProviderTemplate="MonthVersionProvider" PatchProviderTemplate="DayVersionProvider" BuildProviderTemplate="IncrementVersionProvider" />

I do not see any DeltaDays providers. For giggles I will try to repro the precise set of options.

The errors I am getting re: ItemDefinitionGroup indicate that this is an MSBuild 16 thing, not an MSBuild 15 thing. It would not surprise me that this was yet another gap in the whole dotnet re-casting saga.

mwpowellhtx commented 4 years ago

@carstencodes This is the output I receive when I pasted in your specification in my projects:

4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'Version' from '1.0.4.14230' to '19.8.19.0'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'AssemblyVersion' from '1.0.4.14230' to '19.8.19.0'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'FileVersion' from '1.0.4.14230' to '19.8.19.0'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'PackageVersion' from '1.0.4.14230' to '19.8.19.0'

Works just fine. I think this is probably a run-time issue. What is your dotnet --info? You should have SDK 2.1 installed (?). Or that supports netcoreapp2.1; I am a bit fuzzy where those requirements are concerned, especially what is doable across platforms.

And if I rebuild a couple of times just to verify the Increment is happening, which it does.

4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'Version' from '19.8.19.0' to '19.8.19.1'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'AssemblyVersion' from '19.8.19.0' to '19.8.19.1'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'FileVersion' from '19.8.19.0' to '19.8.19.1'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'PackageVersion' from '19.8.19.0' to '19.8.19.1'

And...

4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'Version' from '19.8.19.1' to '19.8.19.2'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'AssemblyVersion' from '19.8.19.1' to '19.8.19.2'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'FileVersion' from '19.8.19.1' to '19.8.19.2'
4>'Code.Generation.Roslyn.Tool.csproj': Bumped 'PackageVersion' from '19.8.19.1' to '19.8.19.2'
carstencodes commented 4 years ago

@mwpowellhtx I don't need to create DeltaDays Providers.

The Name of a provider is used to create a dictionary for the providers in https://github.com/mwpowellhtx/BumpAssemblyVersions/blob/27d0b5388a23f326a49847e246717d754a2aa8b4/src/BumpAssemblyVersions/Providers/VersionProviderTemplateRegistry.cs#L43

If two providers are using the same name, like it happens when the two providers have the same name created from the same string representation of two different dates, the dictionary cannot be created and the registry cannot be created entirely.

This explains the stacktrace above.

mwpowellhtx commented 4 years ago

@carstencodes Yes, the names of the providers you actually used. Your example code works for me, I could not reproduce it. That is not to say there is a separate issue in the DeltaDays providers, but that is a separate issue. Unable to reproduce, in fact, in my response above, works fine for me.

carstencodes commented 4 years ago

@mwpowellhtx I tried it on windows and it worked. So this is a linux or unix issue.

But I must disagree, since the Providers properties uses the GetProviders, which itself instantiates any type delivered by GetProviderTypes, which itself returns every instantiatable VersionTemplateProvider class. So, even if they are not used, the DeltaDaysProviders are instantiated and added to the dictionary of providers. Can you agree on that?

I would use only windows builds, if I could, but my gitlab runners are in fact all linux based and hence I must stick to linux build machines.

carstencodes commented 4 years ago

For details see https://github.com/dotnet/coreclr/issues/16960

mwpowellhtx commented 4 years ago

@carstencodes This is a separate issue, and I cannot reproduce it under a Windows build given your specification. Interesting CLR note, however.

carstencodes commented 4 years ago

@mwpowellhtx thx for clarification

mwpowellhtx commented 4 years ago

@carstencodes We think this is now resolved. See issue and comments. Watch for a package update, let us know how it goes. Cheers, and thanks for the interest!

carstencodes commented 4 years ago

Hello, I can confirm that the issue resolved now with v1.4.0. Thx

mwpowellhtx commented 4 years ago

Great to hear, thanks again @carstencodes .