RecordGenerator v0.3 – automatic and simple

Complete rewrite

After publishing v0.2 and using it a few times, I’ve become increasingly annoyed by these additional generated files. They got into source control, they were unnecessary, I never wanted to look into them and were completely out of place. And some time later, while reading through issues in roslyn or csharplang repos I stumbled upon a mention of build-time code generation helper library (a little framework if you wish).

Enter CodeGeneration.Roslyn. This great project was exactly what I needed to achieve my ultimate goal – create record generation where necessary code is added during compilation and not persisted in source control.


I’ve started using this project combining it with what I’ve already got in RecordGenerator to progress another project of mine: wham (GodMode’s foundation piece). I’ve got it pretty far now and I’ll certainly share this or that soon. But recently I thought: hey, maybe now that I get how CodeGeneration.Roslyn works, I’ll update RecordGenerator to use it!

And so, 1.5 weeks ago I’ve started to rewrite my project. It was quite an undertaking – I believe not even a single line of code stayed unchanged. GitHub says that the whole update actually removed twice as many LoCs as it added (-5,376, +2,278). Mostly because now I didn’t have to check record-generating-codefix’s output. I’ve split components into three projects, created new tests and actually improved amount of features available through generation.

Current state

There are four packages:

  • Amadevus.RecordGenerator which is a top-level package pulling in all other necessary packages and adding dotnet-codegen DotNetCliTool reference through build target
  • Amadevus.RecordGenerator.Attributes defines RecordAttribute in global namespace making usage a breeze
  • Amadevus.RecordGenerator.Generators is responsible for code generation itself
  • Amadevus.RecordGenerator.Analyzers currently contains just a single analyzer that checks your [Record]-type is declared as partial (otherwise the compilator will error on generated file). A codefix for that diagnostic is provided so fixing it is as simple as Ctrl+. and Enter.

Installation instructions and documentation is available in new project website thanks to GitHub Pages: There’s even a path for diagnostic help links – but for some reason Visual Studio ignores it and defaults to Bing search. I suspect it might ignore these links for unsigned (no-strong-name) assemblies – but currently I do not plan on researching this area.

I encourage you to give it a try, now it’s amazingly simple, automated and just works.

NOTE: it works only in SDK-based csproj projects targeting netstandard1.0+/net45+. To use SDK-csproj, you need to work in VS2017+, VSCode or using CLI tools.

One thought on “RecordGenerator v0.3 – automatic and simple”

  1. Hello, not sure if this is the best forum, or a better way to contact you apart from the Github (also, perhaps not the best forum)…

    Thanks so much for the conversation in, admittedly, a broad issue… But, here I have a generators question.

    I want to understand how generators in general function, especially in the context of a unit test. With the understanding that what you are doing in RecordGenerators is quite a bit different than what I am doing in my FlagsEnumeration. I just want to gain some helpful insights in terms of what the Roslyn-based generators are doing and what I can expect.

    Intuitively, and in a brief summary, I would half-expect that the elements generated contribute to the binary image of the assembly under test, and so I should be able to vet the Type, instance(s), etc, for the expected generated bits.

    My work with Enumerations, pulling forward into the .NET Standard/Core paradigm, including work with analyzers, code fixes, and generators, is approaching completion, I think, and I hope to get it published here perhaps within a week or two. But, you know how that goes at times…

    That being said, if there are nuances about that, please feel free to share, etc.

    Thanks again!

Leave a Reply

Your email address will not be published. Required fields are marked *