T4 vs source generators: T4 can't access your syntax tree. Access to the syntax tree *the primary* advantage of source generators. The two source generator examples that MS first blogged: CSV and "moustache" gen, were entirely possible to implement without the Source Generator feature, using only MSBuild. T4 is basically the same thing. Source Generators can access anything about your project. But it is up to you to communicate that information to the SG via AdditionalFiles. You can have an MS build task that runs before compilation that ships whatever information is needed from the project down to the SG. You can implement T4 via Source generators, but you can't (necessarily) implement the capabilities of source generators via T4.
Which preview version of Visual Studio are you using to have the live updates? I'm using 16.9 preview 1 and I still have to quit VS and reload to see the changes...
Are there examples or guidance available for how to connect to a database or external API in order to model generated classes off of either data or schema information, while maintaining secrets via e.g. a configuration provider? I’m assuming this is possible by injecting the dependencies-such as a connection string, API key, or even a data access library-to the source generator project, but haven’t dived into the architecture enough to confirm what an appropriate composition root would be. Or would this data instead need to be first persisted as a static dependency-such as a local CSV or JSON file-to ensure access at compile time? (Obviously, any such data would also need to be aggressively cached for the sake of performance, instead of querying the database each time the generator is triggered.)
The compiler constructs the instance of your generator and its lifetime is completely out of your hands, and there is no DI capabilities. Reading from a database or web service as part of compilation is a very bad idea for performance, so I doubt any feature request will go far, but you can always ask! The way to get data into the system to inform the generation is using AdditionalFiles so you would have to write some msbuild tasks for get that data, and output the right items, in order to use them in a generator.
Links for this video... (see 13:44) github.com/davidwengier/sourcegeneratortemplate github.com/chsienki/kittitas sourcegen.dev roslynquoter.azurewebsites.net
💓 11:58 Useful links: ▶ github.com/DavidWengier/SourceGeneratorTemplate ▶ github.com/chsienki/kittitas ▶ sourcegen.dev/ Thanks very much for an excellent presentation.
Looks like this is against reflection, metadata, algorithm,... by putting a lot of deadly simple code into automation. So as before you fear of writing a lot of code like that manually. You use reflection, metadata, algorithm,.... to minimize the work of typing and the amount of repetitive code or garbages in your project. With this new feature you can automate the manual work 😄 and still have best performance of the final built code. It's still a feature and we don't have to use all the features while developing.
Bruh. This is the most jankiest code I've seen written in the longest time. Hole-lee-shit is that entire GitHub project a massive turd. Hopefully this feature won't get tossed in the bin by Microsoft and we can enjoy the functionality sometime within the next fucking decade. Do us all a favor and stop hyping shit until IT WORKS. Jesus, this is how we got the clusterfuck that is Python.
Great demo! I foresee some fantastic use cases for a source-generator. Can't wait to try them out
Excellent presentation and demonstration! Really cool stuff.
I think one could use t4 Runtime Text Template to make it easier to develop Source Generators, instead of using StringBuilders
T4 vs source generators:
T4 can't access your syntax tree. Access to the syntax tree *the primary* advantage of source generators. The two source generator examples that MS first blogged: CSV and "moustache" gen, were entirely possible to implement without the Source Generator feature, using only MSBuild. T4 is basically the same thing.
Source Generators can access anything about your project. But it is up to you to communicate that information to the SG via AdditionalFiles. You can have an MS build task that runs before compilation that ships whatever information is needed from the project down to the SG.
You can implement T4 via Source generators, but you can't (necessarily) implement the capabilities of source generators via T4.
Amazing demo! Can't wait to play with this :)
Source generators is very useful when combined with C# 9's new record types.
Really cool technology. Great video! CODE GENERATORS RULE!
what if Enum is built on long (EnumType : long) - e.g. for some complicated flags type? You are assuming only ints or subsets are used
David please can you update your course of T4 in Pluralsight
Which preview version of Visual Studio are you using to have the live updates? I'm using 16.9 preview 1 and I still have to quit VS and reload to see the changes...
Can I use it to generate files that should no be compiled by cs e.g. a typescript file?
No, only C# source files can be generated at the moment.
I haven't watched the full video, but I'm wondering if there's any security concerns here. Would code be able to slip in undetected, for example? hm.
Are there examples or guidance available for how to connect to a database or external API in order to model generated classes off of either data or schema information, while maintaining secrets via e.g. a configuration provider? I’m assuming this is possible by injecting the dependencies-such as a connection string, API key, or even a data access library-to the source generator project, but haven’t dived into the architecture enough to confirm what an appropriate composition root would be. Or would this data instead need to be first persisted as a static dependency-such as a local CSV or JSON file-to ensure access at compile time? (Obviously, any such data would also need to be aggressively cached for the sake of performance, instead of querying the database each time the generator is triggered.)
The compiler constructs the instance of your generator and its lifetime is completely out of your hands, and there is no DI capabilities. Reading from a database or web service as part of compilation is a very bad idea for performance, so I doubt any feature request will go far, but you can always ask!
The way to get data into the system to inform the generation is using AdditionalFiles so you would have to write some msbuild tasks for get that data, and output the right items, in order to use them in a generator.
Most of that went right over my head.
Blazor will greatly benefit from this
Thanks for the video. I have a question, do you use some extension to have this pretty comparison operator signs ≥ ≤ ≠?
They are called ligatures. You can use any Ligature supporting font for that. I think he is using Fira Code font.
Love the legos the guy has in the background :)
What is the link to the EnumValidator source code?
goto sourcegen.dev
then select load sample at the top
@@FunWithBits Thanks :)
Links for this video... (see 13:44)
github.com/davidwengier/sourcegeneratortemplate
github.com/chsienki/kittitas
sourcegen.dev
roslynquoter.azurewebsites.net
💓 11:58 Useful links:
▶ github.com/DavidWengier/SourceGeneratorTemplate
▶ github.com/chsienki/kittitas
▶ sourcegen.dev/
Thanks very much for an excellent presentation.
Looks like this is against reflection, metadata, algorithm,... by putting a lot of deadly simple code into automation. So as before you fear of writing a lot of code like that manually. You use reflection, metadata, algorithm,.... to minimize the work of typing and the amount of repetitive code or garbages in your project. With this new feature you can automate the manual work 😄 and still have best performance of the final built code. It's still a feature and we don't have to use all the features while developing.
very well information. thanks
links from slides
github.com/davidwengier/sourcegeneratortemplate
github.com/chsienki/kittitas
sourcegen.dev/
Seems great.
looks complicated. I should use inside something.
So I can't produce viruses anymore?...bummer
Do I need to be bald to be good at writing code?
You are soo funny, surely you will be bald best programmer one day 👍
btw this not new... many lower language are compiled down to c or web base compiled to js .... nothing new here ;)
What you mentioned is "transpiling". Here is something like "compiling injection". They are different.
Too much Talk. Show me the Code.
Bruh. This is the most jankiest code I've seen written in the longest time. Hole-lee-shit is that entire GitHub project a massive turd. Hopefully this feature won't get tossed in the bin by Microsoft and we can enjoy the functionality sometime within the next fucking decade. Do us all a favor and stop hyping shit until IT WORKS. Jesus, this is how we got the clusterfuck that is Python.