Jeremy Davis
Sitecore, C# and web development
A while back I wrote about the transition from T4 templates to using Roslyn Source Generators for generating code in .Net Core solutions. While that worked for me, and I was able to get it to do what I needed, I was never really happy with all the output source as literal strings in the generator code. Recently I had another potential use for generated code, so I decided to try and fix this issue...
There are certain "rules of programming" that I keep hearing about in my career. One that came up in an interesting work debate recently was "you should never use regular expressions to parse HTML". Don't get me wrong - there can be a lot of useful knowledge wrapped up in these rules, but should we always follow them to the letter? I think it's an interesting question...
Recently I found myself looking at a Visual Studio project where the build was not behaving in the way I expected. So I was forced to try a few debugging techniques to work out what was up. And in the process of trying to resolve the problem, I discovered an interesting tool to help with scenarios like this. So if you find yourself stuck with a misbehaving MSBuild script here are a couple of ideas:
I was looking at writing a tool in .Net 7 the other day which would benefit from having an option to load and unload plugin extensions. Reloadable plugins could be a bit tricky in .Net 4, but doable. But that's changed dramatically in more recent framework versions, in some ways that are better and interesting.
My recent post about messing up with inheritance came out of some work to migrate some (fairly old) T4 Template code generation to .Net's newer Source Generators feature. Excluding my own mistakes, this process wasn't as easy as I'd hoped. So it seemed like a good topic to jot some notes down about, in case others are facing similar challenges...
The other day I had a scenario where I wanted to be able to display the date an app was built in its UI. While you can always fall back to a "just make that a string in your code" approach, after a bit of digging I discovered a better way. It turns out recent .Net code has some clever patterns to help with this...
I've been migrating a big chunk of .Net 4 code to .Net 7 recently. One of the few large changes I had to make was to replace some boilerplate generation that used T4 Templates with a Source Generator. (As T4 isn't entirely supported in latest .Net) But these work very differently, so that change involved a good chunk of work. But I messed this up in a way that caused a subtle bug. And while I may well get to writing about Source Generators later, that silly bug is also worth writing up. Even if it's just to remind me not to make the same mistake in the future...
There's been a lot going on with language development in C# over the last couple of years. But despite all the current change for things like record types and generic maths, there are some changes from older versions that I somehow missed. This week social media put me on to the concept of contextual filters for exception handling. What's that? Read on...
I was hacking up an app as a personal project recently, and decided to try out the latest preview (Number 7) of ASP.Net Core for .Net 7. I happened to be deploying this project to a server which had never run ASP.Net Core before, and that deployment left me scratching my head for some time. So in case this issue hits others, here's what happened to me:
I've spent a bit of time looking at how Regular expressions are changing in the upcoming .Net 7 release. While they do have a bit of a reputation for making people's lives worse (so much there's a well known programmer joke about it) they do have a place in your developer toolbox. So what caught my eye in the new features, and how does code get better with this new version?
