Version mismatch in Generators assembly dependencies

[amis92]

So, I've taken a look at your code, and found the cause. You've referenced Microsoft.CodeAnalysis.CSharp package with higher version than what CodeGeneration.Roslyn does.

Just removing that reference fixes the pipeline:

Kingdom.Collections/src/Kingdom.Collections.Enumerations.Generators/Kingdom.Collections.Enumerations.Generators.csproj

Line 50 in 3d90ed1

<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="2.8.0" />

The problem is that the framework task tool (CodeGeneration.Roslyn) gets loaded as an app first (along with it's dependencies including CodeAnalysis - Roslyn). Then it tries to load your generator assembly, but since your assembly depends on a higher version of Roslyn than already loaded in AppDomain, it fails. I do not know why there's no error, but that's the cause.

Connected issue: AArnott/CodeGeneration.Roslyn#76

[mwpowellhtx]

@amis92 What???? Why? Is there a breaking change, then, in the later version? Sans breaking changes, shouldn't the NuGet migration path otherwise be seamless? At any rate, probably something worth following up with CodeGeneration.Roslyn to upgrade.

[mwpowellhtx]

@amis92 Except I cannot remove the reference, I think. On account of I am using that reference directly. Pretty certain of that at any rate.

[mwpowellhtx]

@amis92 I filed a CodeGeneration.Roslyn issue following up. I'll see if I can backtrack to <PackageReference ... Version="2.2.0" /> in the meantime without too much difficulty.

[mwpowellhtx]

@amis92 Well, the good news is that I can backtrack; my test still runs seamlessly. Notwithstanding what the CodeGeneration folks want to do with that.

[mwpowellhtx]

Committed and pushed.

[mwpowellhtx]

Thanks so much @amis92 👍 for identifying that issue. Is there some sort of logging or something that helped to clue you in?

[amis92]

I know this issue because I've already had to deal with it in my project :)

Because CodeGeneration.Roslyn brings the Csharp package through a dependency, it's simpler to remove the reference, but either way it works.

[mwpowellhtx]

Thanks, I'll look into that. I'm not sure I can, though, because of direct dependency.

[mwpowellhtx]

@amis92 Happy to report that I can even do a hard integration test of the feature in addition to unit test of the generator itself in the context of the same unit test assembly. Generated code is successful. Which, it seems, generation even occurs in the context of the decorated declaration, i.e. the namespace. Good stuff!

// ------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
// ------------------------------------------------------------------------------

namespace Kingdom.Collections
{
    public partial class CardinalDirection
    {
        private CardinalDirection(byte[] bytes): base (bytes)
        {
        }

        public static CardinalDirection operator ~(CardinalDirection other) => other?.BitwiseNot();
        public static CardinalDirection operator &(CardinalDirection a, CardinalDirection b) => a?.BitwiseAnd(b);
        public static CardinalDirection operator |(CardinalDirection a, CardinalDirection b) => a?.BitwiseOr(b);
        public static CardinalDirection operator ^(CardinalDirection a, CardinalDirection b) => a?.BitwiseXor(b);
    }
}