I love code. I love to design code. I love to write code. I even love to write about writing code. I’m the kind of guy that comes in from my day job, as a coder, kisses the wife, has dinner, plays with the kids, then proceeds to spend the rest of the evening thinking about code, or writing about code, or, if I’m really lucky, actually coding. Yep, I’m that guy …
Since I write so much code, and since I’ve done that for so many years now, I’ve managed to build up a fair collection of whatsits, whatnots, and thingamajigs in my developer’s toolkit. None of it is of Earth shattering importance. Most of it is just stuff I think is cool. But in all candor, It seems a shame to leave most of it one my hard drive when others might benefit from it. So, a couple of decades ago, I started doing just that. First, by writing for traditional print publications, like Visual C++ Developer magazine, then, later, for websites like codeproject.com. Finally, I started my own blog, at codegator.com, and I’ve been blogging here, off and on, since 2005.
At some point, I also started wrapping my code into NUGET packages. Fast forward to today and CODEGATOR has any number of NUGET packages available for downloading on the nuget.org website (the actual number varies from month to month). We’ve also got corresponding GIT repositories for each of those packages, on the githug.com website.
I build each NUGET package with an automated Azure CI/CD build pipeline. Each one of those pipelines builds our code, tests it, deploys it to nuget.org website, then generates developer docs from the xml comments. Those developer docs are also deployed back to the corresponding GIT repository, as part of the overall build. Oh, and each repository also has a readme that quickly summarizes the purpose of the package.
All in all, my little toolkit has grown into a decent collection of NUGET packages code for use on everything from backend server projects, to web stuff, to more traditional desktop development. There’s also a fair collection of general purpose libraries and just plain “good to know” stuff in those packages.
In this blog I’ll spend time covering the CODEGATOR NUGET packages in detail. I’ll provide insights into what I was thinking when I designed the code, demonstrate how best to use the code in a project, I’ll also dive into the internals, whenever possible. My hope is, along the way, we’ll all have some fun and, hopefully, come away a little smarter in the process.
All of my code is, of course, open source and perfectly free to use. I would appreciate a mention if you use my code, but it’s not required. Technically, I publish my code using the MIT open source license, which pretty much allows you to do almost anything with it.
I don’t support my code, at least not in a traditional sense. I make nothing off CODEGATOR. It’s all a labor of love and that means I’ve only got so much free time to allocate to it. Still, if you spot a bug then tell me about it and I’ll do by best to find a solution – if there is one.
On word of warning before I end this post. My code should always be considered a work in progress. None of it should be considered “production ready”. That’s because here at CODEGATOR, I spend a great deal of time experimenting. That means I create lots of breaking changes and it’s not at all uncommon for abstractions to popup in one NUGET package, and then, next month, to popup on another package because … Well, because I changed it around, for whatever reason. To be sure, I try to prevent breaking changes, as much as possible, but – and this is important – I will change this code around without warning and if you link to my NUGET packages for anything other than exploratory purposes, then don’t say I didn’t warn you when your build breaks.
Bottom line, if you like something in a CODEGATOR package, copy it to your project so you’ll know it won’t change with the next release. Fair enough? I hope so.