Updated: Jun 24
Ken McAndrew, Senior Consultant
I've been undertaking a "Helix recipe" project for my company of late, looking at some of the best ideas out there to come up with a starter kit of sorts for Helix with Sitecore. Because of the ease in configuration and to reduce the number of projects in Visual Studio, I've been integrating Unicorn into the mix. And while TDS has code generation features built into it (although you still have to provide the T4 templates), Unicorn doesn't have anything "out of the box" for that.
A few years ago, however, someone did take a stab at it with the RainbowCodeGeneration Github project.
It hasn't been updated in three years, but I still see it discussed, and recently an upgrade project crossed my desk that was using it with Sitecore 8. I'm trying to tailor this to 9.3 (the latest as of this writing), and I wanted to see about using it with my recipe project.
I've become a fan of fluent configuration when it comes to Glass, though I know others like the attribute configuration. Some may like good old Sitecore API calls. But in all cases, having the template and field IDs is a big plus because while the names are changeable, the IDs aren't (I mean, unless you delete the field and recreate it, but I can't help everything!). Code generation means the field name would change, sure, but it'd generate a compile error if you need to refactor the name, whereas specifying the ID as a string value yourself could leave junk behind. So while you could take this and generate many scenarios, I'm concentrating on simply getting the IDs for templates and fields.
The sample in the RainbowCodeGeneration project was set for Sitecore 9 and Unicorn 4, but the later versions of Sitecore have gotten more complex, and when I tried using the samples and updating the references to 9.3, I kept getting errors where the code was looking for different missing assemblies. In addition, modern Helix projects are switching to the SDK project format and the package references model for NuGet. But the samples rely on references in the old "packages" folder, and the default location for package references is an app data folder in your computer profile...not exactly shareable in source control.
Read the full blog by clicking here.