search

AArnott / CodeGeneration.Roslyn

Assists in performing Roslyn-based code generation during a build.
Microsoft Public License
408 stars 59 forks source link

Please update your CSharp reference #77

Closed mwpowellhtx closed 5 years ago

mwpowellhtx commented 6 years ago

The Microsoft.CodeAnalysis.CSharp reference is out of date and seems most likely the culprit as to why my Generators are not working.

Otherwise, my generators work just fine for me under unit test; that is, I can gen up a TransformationContext, work with my own Roslyn Compilation result, and Generate a member list. No problem.

Sidebar, ideally, breaking changes notwithstanding, NuGet should respect the >=base-version, but if there is a specific version, you can specify a version range in your <PackageReference/>. The same range syntax applies as with NuSpec file format, apparently. To what versions, however, I cannot say, and is a matter you need to work out.

Minimally I would suggest a two pronged update for you. First, identify the breaking change, use that version as a max version in the range, and publish that update. That would at least make it obvious for folks like myself wanting to do code generation that there is a hard version constraint. Then, see if you cannot track to the latest version, and provided you can, or without too much difficulty (i.e. those breaking change(s), mind you), publish that update following up.

In the meantime, I need to see if I can reference a version of that package; hopefully it doesn't break too much in my own code that I am depending upon or have otherwise made assumptions around.

mwpowellhtx commented 6 years ago

@AArnott Just following up; I backtracked my version to 2.2.0 and my tests still work; although I'm not certain what bits we would be missing out on otherwise, at least not without more in depth analysis of the package release notes.

mwpowellhtx commented 6 years ago

@AArnott Actually, Microsoft.CodeAnalysis.CSharp is even current through version 2.8.2 at the time of this follow up.

amis92 commented 6 years ago

@mwpowellhtx The versions of the Csharp package generally mean what version of Csharp is supported by it: https://github.com/dotnet/roslyn/wiki/NuGet-packages#versioning

Roslyn introduces no breaking changes to the public API, so that's not a problem. The problem is, as I've described in https://github.com/mwpowellhtx/Kingdom.Collections/issues/1 that no matter what version CodeGeneration.Roslyn depends on, Generators are stuck with it, because Generators are plug-ins that get loaded only after the dotnet-codegen itself is run (and that means Microsoft.CodeAnalysis.CSharp is loaded too, with version that CG.R depends on).

I don't know any solution that could help this, but the immediate fix is to just update the Roslyn reference each time new version comes out :)

mwpowellhtx commented 6 years ago

The problem is that there is a propagating dependency in CodeGeneration.Roslyn on Microsoft.CodeAnalysis.CSharp that permits the consumer to upgrade their CSharp dependency. However, apparently, this is a problem when it comes time for dotnet-codegen to actually do its thing, revealed in a version mismatch. So, it would be easy for CodeGeneration.Roslyn to introduce a firm, if controlled, version range in order to prohibit this from being the case, i.e. [0,2.2]. Short of that, whatever sort of maintenance cycle CodeGeneration.Roslyn should be on is completely up to y'all. I'm just the consumer reporting the issue.