search

AArnott / CodeGeneration.Roslyn

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

Build breaks on .NET Standard 2.1 #145

Closed dominikjeske closed 5 years ago

dominikjeske commented 5 years ago

I know that .NET Standard 2.1 is not final but on current bits on test project https://github.com/jaredthirsk/CodeGeneration.Roslyn.Walkthrough when change to .NET Standard 2.1 build is breaking.

amis92 commented 5 years ago

@bigdnf and which project did you change to target netstandard2.1?

dominikjeske commented 5 years ago

I have changed all projects - I also see that CodeGeneration.Roslyn is very sensitive for setting TargetFramework. For example when project is compiling in netstandard1.6 and changing to 2.0 it stars breaking and even cleaning project is not fixing the problem. It looks like VS have some caching because it is still saying something about not compatible with 1.6. When downloading project again and change to 2.0 before first compile build is successful. I tried it with 2.1 but in this case even clean project is not compiling.

amis92 commented 5 years ago

@bigdnf as stated multiple times in README, the generator has to be in a netcoreapp2.1-compatible project. netstandard2.1 definitely isn't.

The client/consumer (the project that has generated code) can target anything, however when the generator is in the same solution as consumer, the consumer has to be able to reference the generator project. If a generator targets netstandard2.0, consumer can target anything that'll be compatible with it.

dominikjeske commented 5 years ago

The whole point of this issue is about new netstandard 2.1 - I know that currently documentation says about netstandard 2.0 and .net core 2.1 because it was written when netstandard 2.1 was not available. The problem is indeed only in generator project because consumer can be switch to 2.1.

I only wanted to raise issue about new netstandard 2.1 – I’m wondering is there any breaking changes in upcoming .net that can break this super library or maybe this library depends on some specific SDK?

amis92 commented 5 years ago

You can see a deeper description of how it works in wiki pages. In short, the engine that loads generators as "plugins" is targeting netcoreapp2.1, hence any plugin must be compatible/executable on that target as well.

After netcoreapp3.0 hits the public release, we may consider targeting it, thus enabling netstandard2.1 support as well. We'll also probably move to using the Local Tools feature instead of DotNetCliToolReference, and a different architecture of plugins as well. It's all very much fluent.

dominikjeske commented 5 years ago

Thank for info.