3 ms·
I agree, .NET Standard limitation unnecessarily complicates development experience. I think it's because some tools (Visual Studio) is still use legacy .NET Fra
by zigzag312 10mo ago
I agree, .NET Standard limitation unnecessarily complicates development experience. I think it's because some tools (Visual Studio) is still use legacy .NET Framework. I don't understand why they didn't integrate them via out of process architecture into these tools, since source generators didn't exist in the legacy framework anyway.
I sometimes generate code from plain CLI projects (avoiding source generators altogether), as whole debugging and DX is so much better.
- tryfinally 10mo agoYou add PolySharp to your source generator project to get back some of the modern C# features. https://github.com/Sergio0694/PolySharp https://github.com/Sergio0694/PolySharp
- daeken 10mo agoYeah, I went with that approach for most of the code generation in the emulator I'm currently working on. Source generators handle a few core things, but more advanced compilation tasks went to just ahead of time generation; couldn't get my parser combinator library to play nicely with .NET Standard, so that was just a dead-end.
- octopoc 10mo ago.NET standard isn’t the biggest issue with making source generators. You can’t add dependencies to your project, which is an absolutely huge oversight IMO.
- olidb 10mo agoYou can add dependencies, it's just important, that you also add the dependencies to the project where the source generator is used: SourceGenerator.csproj: <ProjectReference Include="..\Dependency.csproj" /> FinalProject.csproj: <ProjectReference Include="..\Dependency.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" /> <ProjectReference Include="..\SourceGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" /> And I also recommend to add "<LangVersion>latest</LangVersion>" to SourceGenerator.csproj to use new features like raw string literals.