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.

Leave a Reply

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