roslyn: Generators - analyzer using references causing problems CS8785
I have an idea for an analyzer I’d like to add, reusing functionality that is already packaged in a netstandard2.0 package.
Repro is here: https://github.com/protobuf-net/protobuf-net.Grpc/pull/85/ - the interesting projects are:
- src/generators/protobuf-net.Generator (not the Grpc one!!!)
- toys/PlayContracts
In my analyzer csproj I have the two expected refs, plus a commented out one for the tool I want to use:
<PackageReference Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="3.6.0-3.20207.2" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.0.0-beta2.final" PrivateAssets="all" />
<!--<PackageReference Include="protobuf-net.Reflection" Version="3.0.0-alpha.143" PrivateAssets="all" />-->
The analyzer currently just lists the additional files (I have a <AdditionalFiles Include="test.proto" />
). With the above reference commented out, everything kinda works; however, if I uncomment the <PackageReference>
and do nothing else, it stops working completely, citing:
Severity Code Description Project File Line Suppression State Warning CS8785 Generator ‘Protogen’ failed to generate source. It will not contribute to the output and compilation errors may occur as a result. PlayContracts (netstandard2.0) C:\Code\protobuf-net.Grpc\toys\PlayContracts\CSC 1 Active
(the actual “do the thing” code is there but commented out)
This may simply be a packaging thing, but… it isn’t obvious how to fix this; I’ve tried numerous things - with/without the PrivateAssets
hint, with <Analyzer>
dll references vs project references to the analyzer, etc. It could be as simple as a dll version conflict, but I can’t find any way of getting the info out to tell me what exploded.
Any guidance @chsienki ?
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 10
- Comments: 36 (19 by maintainers)
Was about to submit a repro for this because it seems counter-intuitive that you can’t simply reference some other otherwise uncontroversial
netstandard2.0
assembly in your source generator library, without it failing with an obscure warning.I guess the least horrible thing to do here would be to post-build copy the package references to the analyzer build folder?
Currently working on a design to resolve this. Agree it needs to be solved
@jmarolf I’m not entirely sure what that means in practice as either an author or consumer. When you say nuget doesn’t know… so: how does one most correctly ship an analyzer? Is this:
Or am I misunderstanding the problem?
using VS 2022 v 17.0.4 with this no longer works:
@sharwell The dependency conflicts issue is a deal breaker. Not only would it be annoying and fragile to manually add and maintain the recursive dependencies of a library like NSwag, but even if it works for me, I can’t guarantee that another user of my generator will not have a conflict with some other analyzer. As currently designed, I don’t see non-trivial source generators ever being practical.
And trying to ILMerge that single dependency quickly descended into madness:
I think the only sane solution is for Roslyn to run analyzers and code generators on .NET Core only.
Sounds like @jmarolf can guess what the error is. We have work to do to actually surface the errors, for now they’re just swallowed unless you have a debugger on it.
Current ‘best guidance’ (very loosely speaking) is to
Debugger.Launch()
in your initialize method. Then you can attach and see what’s actually failing during a compilation.