Cool, guys! finally, much better than t4. I recommend the next topic - "Roslyn API for dummies". I know it not so easy. I want to create my own generators, and it can help developers.
Would love to be able to see the generated source (i.e. Go to Definition), but I think an absolute must is a better indication of generator compilation failure. I've been playing around with the feature and would occasionally get a compiler error of "the generator failed to generate code", but with no real reason how, why, or where it was failing. Step-through debugging would be awesome.
looks good, but I already made a basic ViewModel a few years ago :) and it supports values comparison and notifications for related properties. Making classes from CSV looks interesting. Maybe I miss something, but does it support JSON or XML files? May I store more complicated objects, such as car class and aggregated engine class?
AOP modifies existing code. Postsharp writes IL and weaves it into the IL that is already there. Source generators can never modify code. With Postsharp you can for example apply an Attribute to an auto-property and have Postsharp implement INotifyPropertyChanged. A source generator cannot do that, so you have to create a field instead and apply an Attribute to that and also make your Type partial. But source generators (as shown in this video) will run during compilation, so stuff added by the generator will immediately show up in Intellisense and all that. That's pretty cool also.
Great stuff, but how can I debug the code generator? I tried to launch two instances of Visual Studio, from one I attached to the other, but the breakpoints do not hit. Does anyone have experience with it?
This is a great feature, that I'm looking forward to using. Having said that, the CSV example is somewhat disappointing, since the same capability was 99% possible without the source generator feature. The missing 1% was not having to save the CSV for changes to show up in intellisense, which isn't really all that compelling IMO. I think the AdditionalFiles mechanism is still going to require a lot of MSBuild knowledge to use robustly. How to communicate *which* files should be consumed by a source generator? Create an AdditionalFile with a well-known name for a generator which lists the other additional files that generator should consume. That is going to require some MSBuild know-how to wire up in a nuget. Not an issue per-se, but I envision some guidance will be needed around how to do this reliably.
Cool, guys! finally, much better than t4. I recommend the next topic - "Roslyn API for dummies". I know it not so easy. I want to create my own generators, and it can help developers.
Would love to be able to see the generated source (i.e. Go to Definition), but I think an absolute must is a better indication of generator compilation failure. I've been playing around with the feature and would occasionally get a compiler error of "the generator failed to generate code", but with no real reason how, why, or where it was failing. Step-through debugging would be awesome.
Wow, what a magic? Love this new Source Generator tool. Its really magic. Best wishes for future improvement. Thanks for this amazing new tool.
Good old Skype! Can't wait to get my hands on C#9 as a whole
looks good, but I already made a basic ViewModel a few years ago :) and it supports values comparison and notifications for related properties.
Making classes from CSV looks interesting. Maybe I miss something, but does it support JSON or XML files? May I store more complicated objects, such as car class and aggregated engine class?
Does this overlap with AOP? How does this differ from a AOP library like Postsharp?
AOP modifies existing code. Postsharp writes IL and weaves it into the IL that is already there.
Source generators can never modify code.
With Postsharp you can for example apply an Attribute to an auto-property and have Postsharp implement INotifyPropertyChanged. A source generator cannot do that, so you have to create a field instead and apply an Attribute to that and also make your Type partial.
But source generators (as shown in this video) will run during compilation, so stuff added by the generator will immediately show up in Intellisense and all that. That's pretty cool also.
AOP library rewrites your source code - and that is not good for fidelity.
Great stuff, but how can I debug the code generator? I tried to launch two instances of Visual Studio, from one I attached to the other, but the breakpoints do not hit. Does anyone have experience with it?
12:09 WTF moment. Magic @_@
Code starts around 8:30.
Is it possible to use CodeGenerators to produce code not in C#? For example generate TypeScript interfaces from api models?
I don't think so considering it's built on the c# sdk. The demoed product is a feature of C#.
Source generators essentially generate code-behind C# classes that are placed in /obj/. Similar to "Foo.g.cs" in XAML.
C# 💪
This is a great feature, that I'm looking forward to using.
Having said that, the CSV example is somewhat disappointing, since the same capability was 99% possible without the source generator feature. The missing 1% was not having to save the CSV for changes to show up in intellisense, which isn't really all that compelling IMO.
I think the AdditionalFiles mechanism is still going to require a lot of MSBuild knowledge to use robustly. How to communicate *which* files should be consumed by a source generator? Create an AdditionalFile with a well-known name for a generator which lists the other additional files that generator should consume. That is going to require some MSBuild know-how to wire up in a nuget. Not an issue per-se, but I envision some guidance will be needed around how to do this reliably.
Agree that the CSV example should not have been presented. Hopefully it doesn't get abused and become an unnecessary layer of indirection.
Interesting point re CSV files.
Could you suggest a more relevant example that would better represent this new feature?
Magic!
Wow! Love this.... 🤩😍
UWP? Isn’t that platform dead?