Roslyn: Source Generators support .NET Standard 2.1?

[lthoa]

Source Generators only support being loaded into consuming libraries as .NET Standard 2.0 components today.
I really need it to support .NET Standard 2.1 to use Grpc.Net.Client.Web.
Do you have any solution to use Grpc.Net.Client.Web (netstandard2.1) with Source Generator?
Do you have a plan for .NET Standard 2.1?

Thank you.

[RikkiGibson]

/cc @chsienki

[sharwell]

.NET Standard 2.1 can be used under the following conditions:

1. The generator will work during builds with .NET tooling (e.g. dotnet build or dotnet msbuild), but will not work for builds with .NET Framework tooling (e.g. msbuild)
2. The generator will _not_ work for IDE scenarios, which includes builds within Visual Studio and all IntelliSense functionality

The second limitation in particular seems sufficiently problematic to say that the scenario is not recommended.

[lthoa]

.NET Standard 2.1 can be used under the following conditions:

1. The generator will work during builds with .NET tooling (e.g. dotnet build or dotnet msbuild), but will not work for builds with .NET Framework tooling (e.g. msbuild)
2. The generator will _not_ work for IDE scenarios, which includes builds within Visual Studio and all IntelliSense functionality

The second limitation in particular seems sufficiently problematic to say that the scenario is not recommended.

Thank you, But I am using Visual Studio :(

[RikkiGibson]

It feels like ideally the part of the functionality of Grpc.Net.Client.Web that is required at generation time could be spun off into a netstandard2.0 package.

[lthoa]

the functionality of Grpc.Net.Client.Web

Thank @RikkiGibson ,
I have also thought of this solution. Create the function of Grpc.Net.Client.Web source code using T4.
My projects have previously used T4 to generate source code. But the T4 also has its limitations that made me switch to Source Generators.

[sharwell]

@lthoa It's not clear what the limitation here is. According to https://github.com/grpc/grpc-dotnet/issues/905, Grpc.Net.Client.Web doesn't target netstandard2.0 because it doesn't support the HttpResponseMessage.TrailingHeaders property. However, this limitation would not apply to source generators because the source generator can't use HttpClient _at all_. Source generators are not allowed to perform I/O operations outside of the APIs provided by the compiler.

[lthoa]

Thank @sharwell ,

I really like Source Generators and want to use it but we don't have a channel to discuss or learn so I have to ask you here.
Sorry for bothering you

I need to generate classes that inherits from an interface. That interface is netcoreapp3.1 library.

// netcoreapp3.1 liblary already exist
public interface IDataMigration
{
        ISchemaBuilder SchemaBuilder { get; set; }
}

// Using Source Generators
public class ObjectMigrations : IDataMigration
{     
     // code
}

Is posible to use Source Generators with Visual Studio in this case?
Can you help me.

Thank you,

[PathogenDavid]

@lthoa It's a bit hard to understand what you're trying to accomplish from that limited example, but are you trying to use reflection to inspect IDataMigration to generate ObjectMigrations? You should use the symbol metadata provided by the compiler instead. (IE: Compilation.GetTypeByMetadataName) It doesn't seem like your source generator should actually need a reference to the library containing IDataMigration unless I'm missing something.

You might find it useful to look at @davidwengier's "Auto Notify" sample here: https://sourcegen.dev/ (Select it from the dropdown.)

[davidwengier]

@lthoa Your source generator outputs code that is compiled in the context of the project that consumes it. So if your consuming project can see the IDataMigration interface, then you can generate source that requires it without your source generator needing to reference the library that it is contained in.

A good example of this is the "Dependency Injection" sample in sourcegen.dev as it can generate code that creates instances of Foo and returns references to IFoo, but those types don't exist anywhere in the generator itself.

[lthoa]

Thank you very much @PathogenDavid, @davidwengier .
I will try sourcegen.dev now

[RikkiGibson]

That's a really cool project @davidwengier 😄

[trampster]

Given that Source Generators seem ideal for serializers and serializers need Span to be efficient, And .net Standard 2.0 doesn't support Span

I'm working on a Source Generator Json Serailizer and I need .net Standard 2.1 to be able to make a performant serializer. This limitation is a huge problem for me.

[PathogenDavid]

@trampster The actual source generator does not necessarily need access to the types used in the code it emits.

Also you can use System.Memory to access Span<T> and related types in older frameworks.

[RikkiGibson]

Indeed, if the compiler or extensions needed to actually load netstandard2.1 libraries and not just their metadata, it would be very difficult to develop applications that use such a library using Visual Studio 😉

[trampster]

I assume this is because Visual Studio still targets .net framework and has not be ported to .net core/.NET 5, when can we expect Visual Studio to move to .net core/.NET 5?

[sharwell]

@trampster the source generator and the code produced by the source generator do not need to run on the same framework. You can use a netstandard2.0 source generator to produce code that only runs on netstandard2.1.

[trampster]

@sharwell thanks, I got that from @RikkiGibson comment.

My source generator was depending on a .net standard 2.1 lib. I have broken that dependency for now by pulling in only the source file I need rather than the whole project, but it's far from ideal.

Please answer my question, is this limitation caused by Visual Studio not having been ported to .net core/.NET 5. And if so when can we expect this to happen so this limitation can be lifted.

[sharwell]

The compiler supports execution on .NET Framework even from the command line. While I cannot guarantee that this will not change, I would be very surprised to see this change in version 3.x.