Andrew MacNeill - AKSEL Solutions

https://devblogs.microsoft.com/visualstudio/the-new-javascript-typescript-experience-in-vs-2022-preview-3/ The promise noted in this announcement sounds very exciting. Sure, you can do most of this already with VS Code - but encouraging this type of development directly in Visual Studio is awesome. The one thing I would like to see is built-in support for Cypress - my e2e testing tool of choice. ( Https://www.cypress.it ) - which is a great tool for Vue and React apps.

Error handling is an integral part of application development. Unless you are like myself and never release code with bugs :) , the need for clients to tell you what's wrong is important. I've seen a number of error handlers in the past, dating all the way back to Pat Adam's famous FP2ERROR routine (back from 1991). Most systems log their errors and then pick them up as part of a diagnostic push. Unfortunately, reporting these errors back to the developer require some effort by the client. Doug Hennig has introduced a new VFPX project for adding easy error handling and reporting. While it does include a few dependencies, it offers a nice support-centric dialog for clients to report errors. https://doughennig.blogspot.com/2021/07/new-errorhandler-vfpx-project.html If you AREN'T getting automatic feedback from your clients when they get an error, now there's no excuse.

https://devblogs.microsoft.com/visualstudio/load-only-the-projects-you-need-with-solution-filters/ While I don't have a hundreds of projects in a solution, our larger application definitely has a few that don't need to be loaded each time (test apps, etc). It's a great feature but not very discoverable - I can see why they needed a blog post for it. Maybe the VS Team can come up with a better way.

Sometimes the Internet is great - you can find exactly what you're looking for, quickly and easily. Other times, it takes you down a rabbit hole of different sites that may provide the right answer but, more often than not, the 90% rule is often true.  So when we decided to consolidate our multiple git repos into a single repo on Azure Devops, I figured this should be relatively easy. Note: it isn't built into git and while the final process isn't that tough to follow, finding the best answer was extremely frustrating and time-consuming. After several wrong paths, I came across this post . This covered the process in great detail - including some safety steps to ensure you don't overwrite incorrect files. I'm finding that sometimes the dev posts on Medium are just as good as StackOverflow but provide the necessary context that may not be available there. I want to note it here as it took a very long time to find that article. The key is the --allow-unrelated-histori