In upgrading an older service to CoreWCF I ran into some Pinvoke code for 'RawPrinting' (DllImport "winspool.Drv") with an unexpected return value that was causing nothing to print. I suppose this could make an interesting article - identify why this code worked under .NET Framework 4.61 and not .NET Core 6+, show the subtle code changes between .NET versions and maybe offer a clever PowerShell one-liner that would fix this problem in all of your code... I did none of that - I quickly made an honest assessment that my DllImports were copy and pasted, that I have only the most basic knowledge of how Pinvoke/IntPtr/Dllimports 'really' work and that exploring the details of various interop printing structures was unlikely to really be all-things-considered worth the time. In the end vague memories and web searches led me to Vanara: A set of .NET libraries for Windows implementing PInvoke calls to many native Windows APIs with supporting wrappers. Several minutes of light refactoring later printing was working again! (Oh and yes - this was all in service of pushing ZPL to the wonder, and occasional terror, that is our Zebra tag printers...)

At work over the past two decades we basically maxed out at 4 in-house developers - always with some part time positions - but right now I'm the sole in-house Dev/IT person. A big challenge with over 2 decades worth of in-house development is figuring out how to move things forward. Recently I took some inspiration from larger dev organizations and made the last commit in a branch that combines 137 projects under one solution. You can easily find information online about monorepo and monolith (usually vs micro-service) setups -> in the big picture our codebase is small and I am currently a team of 1, a much much much simpler situation than anything you will read about - but since our code base has traditionally been divided into silos I am hoping with this change to:

• Take Maximum Advantage of Tooling - assuming you are on a reasonably capable dev machine Visual Studio+Resharper is happy to show you references, apply refactorings and show you errors from ALL 137 projects! Forget remembering what else your code change might impact - just have it all in front of you.

• One Version - different syntax across language versions, library versions across framework versions, constantly changing external libraries and confusing problems referencing one library from another because of versions - all of these things cost painfully valuable time as projects spread out over years and decades of different versions... My hope is that having everything accessible in one solution makes keeping everything at one version possible.

• Latest Versions - I know that staying on one version is at best a hopeful goal - but in truth I have a more ambitious goal: stay on 'latest'. Sure, every upgrade is a chance for some painful bug - but every update is also a chance that your programs improve with zero effort or new opportunities emerge. I have no idea why some of my database related code is running better under .NET 6 and latest EF - but it is, and in many projects it cost me basically zero time... My best guess is that in many cases the time to make upgrades will pay off in only having to do it once - upgrading Automapper to the next version even with breaking changes isn't that bad, having to figure it out multiple times with months/years in-between with upgrades from different versions involved each time is costly.

• Constant Updates: What I have watched at work is that software that stagnates not only make life hard for devs but also causes process stagnation - this could be about the latest big-new-thing but is just as likely to be about small/quick changes: adding a shortcut key, coding a new warning when a user does something that works but is usually wrong, or a new report for a new problem. There are only so many resources (especially time) but both software and processes benefit when software can keep moving forward. In this setup the app with the shortcut key is already open, updated and ready to go in Visual Studio and adding the shortcut key might be an 'actual' 5 minute or less project! Right now it might be a 5 minute project - or it might be a half day to figure out which repo, checking it out and make sure the right build tools are installed, find the config file that was missed in the commit a year ago, try to upgrade packages but instead fall into a mire of version/package conflicts, figure out internal updates, etc...

• Let Go of Believing You Know - In the 'old days' between number of people, fresh code and operational setup there was a period of time when the best skill may have been knowing who to talk to about some code. Over the years as decisions, software, people and processes have spread out over years, decades, of time - there is no one to ask, you just have to read the code, and that holds true even if you wrote the code! The single solution approach puts all the code in front of you - exactly what you need if you can't hold it all in your head.

We have plenty of code not in the current 137 project solution, legacy problems to solve and business challenges ahead - it isn't that I think this is a magic solution to our, or anyone's, problems - but I'm writing about it because I'm excited to find a way to improve and move forward even if it isn't a silver-bullet-everything solution to all software issues.

Mojave Sonoran Trail: A 625 Mile Thru-Hiking Route Introduction & Guide - always interesting to see something new and I have to say that even with 2 decades in the Southwest this route touches on MANY areas that I never considered exploring - worth checking out although I'd watch the first few YouTube videos before getting too excited as some of the scrambling looked a little intimidating to me!

• YouTube Mojave Sonoran Trail
• SeekingLost: Hiking, Backpacking, Outdoor Adventures & Photography Seeking Lost: Thru-Hiking & Backpacking Adventures.

Advanced Outdoor Technologies - I do love a good front-pack setup and this new-to-me company is making some interesting gear! I haven't ever seen these bags in person but at a glance they to be designed with a smart 'depth' - having tried a decent number of front packs this is key if you want to be able to see your feet (and you really do want to see you feet)... I currently use a Pajaro GRANDE Field Bag as a front pack, mainly for my camera.