Waldo Codes

For a few years I've been refactoring a database centric application. The codebase is very large. The core application is ASP.NET Web Forms. Originally written in the time when all you needed for an app was third party user controls and a database. Our team has broken four microservices and a new UI project out from the original ASP.NET app. This is were todays story begins.

If you work on a monolithic application with one project/solution file, you can open your project and get to work. You don't have to think about what projects you need to have running for the application to work. Moving to microservices solves some issues and it creates a few. Debugging becomes a pain. How do you best debug microservices? Searching online, I've pulled up some Stack Overflow posts asking this same question.

Debug multiple MicroServices in Visual Studio Local Development Experience when Working with MicroServices

A list of conclusions: – Use Docker – Write unit tests, and integration tests – Log everything then read the log files

If all our projects lived in .net core, Docker might have worked for us. The core application being Web Forms requires a large Windows Server Docker image. The only way to run the app in that container is with a full IIS instance. Debugging requires attaching to the running process manually each time. Not a very slick process. Docker Compose looks great, so once we have everything moved to .net core that might be a better solution.

We write unit tests and integration tests, but sometimes you need to connect some UI and debug some code. Log files are great, but they don't replace the debugger.

If the codebase you are working on is well architected, you may be able to debug micro services in isolation. Our codebase has enough seams that we don't need to run all the microservices at once. Yet, we can rarely do a debug session with only one running.

The obvious answer is to open all the projects in Visual Studio and start debugging. How good are the specs on your dev machine? One Visual Studio instance can take over a gig of ram. The difference between starting one of our projects in Visual Studio vs. donet run was 1.3 gigs vs. 450mb.

For our situation a hybrid approach would be best. Some way to select which code to debug in Visual Studio, and which to run in the background to support debugging.

Our team created a small console application to launch or projects. The first few iterations were cumbersome. With a few tweaks it grew into a decent yet simple solution. If you're interested its out on GitHub. The launcher is targeted to Visual Studio, but the dev environment is configurable. I haven't tried it, but I'm guessing configuring it for Visual Studio code should work as well.

For now this is meeting our needs. As we continue to refactor we'll continue to evaluate how this is working. If you're in a similar boat with debugging microservices, give it a try. Or if you have a better solution leave a comment and clue me in.