In previous part we lerned how to pass parameters to a Source Generator. In this article we need this knowledge to pass futher parameters to implement logging.
In this article we will see how to pass configuration parameters to a Roslyn Source Generator to control the output or enable/disable features.
In this article we will see how to reduce the resource consumption of a Source Generator when running inside an IDE by redirecting the code generation to RegisterImplementationSourceOutput.
With the version 4.3.1 of Microsoft.CodeAnalysis.* Roslyn provides a new high-level API – the method “ForAttributeWithMetadataName”. Although it is just 1 method, still, it addresses one of the biggest performance issue with Source Generators.
In the previous article the Source Generator itself needed a 3rd-party library Newtonsoft.Json in order to generate new source code. The JSON-strings were hard-coded inside the Source Generator for simplicity reasons. In this article we will see how to process not just .NET code, but also other files, like JSON or XML.
We previously talked about how to change the source code generation based on current project dependencies. In this article, the Source Generator itself needs a 3rd-party library, in our case Newtonsoft.Json. This library is a development dependency and will not be rolled out to production.
The Roslyn Source Generator, implemented in the previous articles of the series, emits some C# code without looking at the dependencies of the current .NET (Core) project. In this article our DemoSourceGenerator should implement a JsonConverter, but only if the corresponding library (e.g. Newtonsoft.Json) is referenced by the project.
In Part 1 of this series we’ve implemented a simple Incremental Source Generator. Although we looked at all mandatory phases of an IIncrementalGenerator, still, the consideration was quite superficial. One of the biggest advantages of the new API, which makes the Source Generator an incremental one, is the built-in memoization, i.e. caching. To take full advantage from it, we have to make some preparations so Roslyn knows what to cache and how to compare the results of each phase.
This article is the 3rd part of a series about Roslyn Source Generators & co. In the 1st article, of this series, we built an Incremental Source Generator to generate a new property Items of a Smart Enum. In the 2nd article, we added a Roslyn Analyzer and a Code Fix to prevent common mistake(s) and to help out the developers when using this Source Generator. All the code we have written so far was tested manually by executing the code and looking at the outcome. It is time to implement some automated tests to ensure the correct behavior.
This article is the second part of a series about Roslyn Source Generators & co. In the previous article we built an Incremental Source Generator that extends a custom class by creating and initializing the new property Items. This new property returns all items of a Smart Enum. Although the Source Generator is fully functional, I still don’t consider the current state as ‘finished’. During implementation of the Source Generator, we made several assumptions, which means the developers must know the internals to use it properly. If the author of the Source Generator is the only consumer of this tool, then we can leave it as it is. If not, then it would be a bold decision to expect others to have the same knowledge as the author. In this case, I highly recommend adding a Roslyn Analyzer to guide the developers in the right direction.
