Incremental Roslyn Source Generators: Using 3rd-Party Libraries – Part 6

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.

In diesem Artikel:

Incremental Roslyn Source Generators: Using 3rd-Party Libraries – Part 6
Pawel Gerr ist Architekt und Consultant bei Thinktecture. Er hat sich auf .NET Core Backends spezialisiert und kennt Entity Framework von vorne bis hinten.

More information about the Smart Enums and the source code can be found on GitHub:

I recommend to read part 5 of the series because this article is based on the results of the previous one.

In this article, the Source Generator will generate C# code based on the content of JSON, deserialized using the library Newtonsoft.Json. I choose Newtonsoft.Json over System.Text.Json because the latter comes with the framework and is available by default, i.e., it doesn’t suit well as an example.

Expected Results

The DemoCodeGenerator, implemented in the previous part of this series, will generate not just the property Items but a few attributes as well.

				
					namespace DemoConsoleApplication
{
   [Translation("en", "Product category")]
   [Translation("de", "Produktkategorie")]
   partial class ProductCategory
   {
      ...
				
			

JSON will be the source for the translations.

				
					{
  "ProductCategory": {
    "en": "Product category",
    "de": "Produktkategorie"
  }
}

				
			

The TranslationAttribute, as with the EnumGenerationAttribute, is implemented in the project DemoLibrary because both of them are going to be published along with the production code. (See part 1 for more information)

				
					namespace DemoLibrary;

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class TranslationAttribute : Attribute
{
   public string Language { get; }
   public string Translation { get; }

   public TranslationAttribute(string language, string translation)
   {
      Language = language;
      Translation = translation;
   }
}

				
			

Refactoring

For readers coming from Part 5 of this series, a few preparations are necessary to be able to tell apart the important changes from the refactorings.

The method Generate of the interface ICodeGenerator gets an additional argument translations.

				
					public interface ICodeGenerator : IEquatable<ICodeGenerator> 
{ 
      string Generate(DemoEnumInfo enumInfo, IReadOnlyDictionary<string, string> translations);
      ...
				
			

The DemoCodeGenerator is using a StringBuilder for generation of the C# code, so it is easier to render additional code in between. The code is split before partial class {name} for future generation of the TranslationAttribute.

				
					   public string Generate(DemoEnumInfo enumInfo, IReadOnlyDictionary<string, string> translations) 
   { 
      var ns = enumInfo.Namespace; 
      var name = enumInfo.Name; 
 
      var sb = new StringBuilder(@$"// <auto-generated /> 
#nullable enable 
 
// generation counter: {Interlocked.Increment(ref _counter)} 
 
using System.Collections.Generic; 
using DemoLibrary; 
 
{(ns is null ? null : $@"namespace {ns} 
{{")}"); 
 
      // TODO: TranslationAttribute

      sb.Append(@$" 
   partial class {name} 
   {{ 
      private static IReadOnlyList<{name}>? _items; 
      public static IReadOnlyList<{name}> Items => _items ??= GetItems(); 
 
      private static IReadOnlyList<{name}> GetItems() 
      {{ 
         return new[] {{ {String.Join(", ", enumInfo.ItemNames)} }}; 
      }} 
   }} 
{(ns is null ? null : @"} 
")}"); 
 
      return sb.ToString(); 
   } 
				
			

Adding 3rd-Party Library

A 3rd-party library installed via NuGet requires a few adjustments, so the Source Generator finds the required DLLs when (a) the Source Generator itself is installed via NuGet and (b) the Source Generator is referenced directly via project reference.

After installation of the NuGet package to DemoSourceGenerator.csproj, the package reference needs the attribute PrivateAssets set to all, so it stays a development dependency and is not rolled out to production. Additionally, the attribute GeneratePathProperty must be set to true to get a path to the assets of the NuGet package. The path is built from the package name by replacing the . with _ and by prefixing it with Pkg

				
					<Project Sdk="Microsoft.NET.Sdk">
   ...
   <ItemGroup>
      ...
      
      <PackageReference Include="Newtonsoft.Json"
                        Version="13.0.1"
                        PrivateAssets="all"
                        GeneratePathProperty="true" /> 
 
      <None Include="$(PkgNewtonsoft_Json)\lib\netstandard2.0\*.dll"
            Pack="true"
            PackagePath="analyzers/dotnet/cs"
            Visible="false" /> 
   </ItemGroup>
   
</Project>

				
			

As with the DLL of the Source Generator, all dependencies must be copied to analyzers/dotnet/cs when building a NuGet package.

If the Source Generator is not referenced directly by another project, then no further adjustments of the DemoSourceGenerator.csproj are necessary. Otherwise, the compiler needs a hint of where to search for further dependencies. Each dependency must be specified using the TargetPathWithTargetPlatformMoniker.

				
					<Project Sdk="Microsoft.NET.Sdk"> 
   ...
 
    
   <PropertyGroup> 
      <GetTargetPathDependsOn>
          $(GetTargetPathDependsOn);GetDependencyTargetPaths
      </GetTargetPathDependsOn> 
   </PropertyGroup> 
 
   <Target Name="GetDependencyTargetPaths"> 
      <ItemGroup> 
         <TargetPathWithTargetPlatformMoniker
            Include="$(PKGNewtonsoft_Json)\lib\netstandard2.0\Newtonsoft.Json.dll"
            IncludeRuntimeDependency="false" /> 
      </ItemGroup> 
   </Target> 
 
</Project> 

				
			

Parsing JSON

The last step is to parse JSON in DemoSourceGenerator and pass the translations to the code generators.

There are 2 flaws in this demo: JSON is hard-coded, and there is no try-catch when parsing JSON. Both issues are going to be addressed in the next part of this series.

				
					[Generator] 
public class DemoSourceGenerator : IIncrementalGenerator 
{ 
   private static readonly IReadOnlyDictionary<string, string> _noTranslations
        = new Dictionary<string, string>(); 
 
   private const string _TRANSLATIONS = @" 
{ 
   ""ProductCategory"": { 
      ""en"":  ""Product category"", 
      ""de"": ""Produktkategorie"" 
   } 
}"; 
 
   ...
 
   private static void GenerateCode( 
      SourceProductionContext context, 
      (DemoEnumInfo, ImmutableArray<ICodeGenerator>) tuple) 
   { 
      var (enumInfo, generators) = tuple; 
 
      if (generators.IsDefaultOrEmpty) 
         return; 
 
      var translationsByClassName = JsonConvert.DeserializeObject<
            Dictionary<string, IReadOnlyDictionary<string, string>>>(_TRANSLATIONS); 
 
      foreach (var generator in generators.Distinct()) 
      { 
         if (translationsByClassName is null
            || !translationsByClassName.TryGetValue(enumInfo.Name, out var translations)) 
        {
            translations = _noTranslations; 
        }

         var ns = enumInfo.Namespace is null ? null : $"{enumInfo.Namespace}."; 
         var code = generator.Generate(enumInfo, translations); 
 
         if (!String.IsNullOrWhiteSpace(code)) 
            context.AddSource($"{ns}{enumInfo.Name}{generator.FileHintSuffix}.g.cs", code); 
      } 
   } 
} 

				
			

The DemoCodeGenerator generates attributes according to the provided translations.

				
					public sealed class DemoCodeGenerator : ICodeGenerator 
{ 
   ...
   
   public string Generate(DemoEnumInfo enumInfo, IReadOnlyDictionary<string, string> translations) 
   { 
      ...
 
{(ns is null ? null : $@"namespace {ns} 
{{")}"); 
 
      GenerateTranslationAttributes(sb, translations); 
 
      sb.Append(@$" 
   partial class {name} 
      ...
   } 
 
   private static void GenerateTranslationAttributes( 
      StringBuilder sb, 
      IReadOnlyDictionary<string, string> translations) 
   { 
      foreach (var kvp in translations) 
      { 
         sb.Append(@" 
   [Translation(""").Append(kvp.Key).Append("\", \"").Append(kvp.Value).Append("\")]"); 
      } 
   } 
 
				
			

Summary

Referencing and using other NuGet packages inside a Source Generator works almost the same as with any other project. But your Source Generator might be not the only one using a 3rd-party dependency. A project referencing multiple Source Generators with incompatible dependencies will run into issues.

Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Diese Artikel könnten Sie interessieren
.NET
Incremental Roslyn Source Generators: Using Additional Files – Part 7

Incremental Roslyn Source Generators: Using Additional Files – Part 7

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.
21.03.2023
.NET
Understanding and Controlling the Blazor WebAssembly Startup Process

Understanding and Controlling the Blazor WebAssembly Startup Process

There are a lot of things going on in the background, when a Blazor WebAssembly application is being started. In some cases you might want to take a bit more control over that process. One example might be the wish to display a loading screen for applications that take some time for initial preparation, or when users are on a slow internet connection. However, in order to control something, we need to understand what is happening first. This article takes you down the rabbit hole of how a Blazor WASM application starts up.
07.03.2023
.NET
Adding Superpowers to your Blazor WebAssembly App with Project Fugu APIs

Adding Superpowers to your Blazor WebAssembly App with Project Fugu APIs

Blazor WebAssembly is a powerful framework for building web applications that run on the client-side. With Project Fugu APIs, you can extend the capabilities of these apps to access new device features and provide an enhanced user experience. In this article, learn about the benefits of using Project Fugu APIs, the wrapper packages that are available for Blazor WebAssembly, and how to use them in your application.

Whether you're a seasoned Blazor developer or just getting started, this article will help you add superpowers to your Blazor WebAssembly app.
28.02.2023
.NET
Blazor WebAssembly in Practice: Maturity, Success Factors, Showstoppers

Blazor WebAssembly in Practice: Maturity, Success Factors, Showstoppers

ASP.NET Core Blazor is Microsoft's framework for implementing web-based applications, aimed at developers with knowledge of .NET and C#. It exists alongside other frameworks such as ASP.NET Core MVC. About two and a half years after the release of Blazor WebAssembly and based on our experiences from many customer projects at Thinktecture, we want to have a close look at the following questions: What is the current state of the framework? How can you successfully use Blazor? And where does it have limitations?
24.11.2022
.NET
Blazor WebAssembly: Debugging gRPC-Web with Custom Chrome Developer Tools

Blazor WebAssembly: Debugging gRPC-Web with Custom Chrome Developer Tools

If you are working with Blazor, gRPC is a big issue for transferring data from APIs to clients. One issue of developing with gRPC-Web is debugging the transmitted data because the data is in an efficient binary message format. In this article, I will show you how to solve this problem with the help of my NuGet.
17.11.2022
.NET
Entity Framework Core: User-defined Fields and Tables

Entity Framework Core: User-defined Fields and Tables

The requirement to store additional fields, unknown at development time, in a relational database is not new. Nonetheless, none of the projects I know of are willing to change the database structure at runtime. What if there is a project which needs dynamically created fields and doesn't want or cannot use entity–attribute–value model or switch to No-SQL databases?
20.09.2022