Q&A on Container Development in Visual Studio 2019: Debugging Pains, Tips, Tools and More
Container development provides many benefits, such as platform independence and portability, improved productivity, greater efficiency and more. However, consultant/trainer Benjamin Day says the "dirty little secret" about container development is that it can be a huge pain.
Day says things can get tricky when the app you're building on your machine isn't really running on that machine, but rather in a container.
Thankfully, your favorite IDE can alleviate that pain with some great features, and Day is going to explain them to attendees of the Live! 360 conference coming up in November at the Royal Pacific Resort at Universal Orlando in a Fast Focus presentation titled "Building & Debugging Container-based Apps with VS2019." We caught up with Day to find out more about container-based development with VS2019.
What's the No. 1 reason that troubleshooting/fixing bugs in containerized applications can be so challenging?
Well, first let's think about what's happening when you're debugging an ordinary, non-containerized app that you're writing on your machine: You're logged in on your workstation, your code is on your workstation, your compiler tools and your IDE are on your workstation, and when you run your app to debug it, the app is running on your workstation.
"It's that isolation that makes debugging hurt. You don't have easy access to what's running inside of that container. "
Benjamin Day, Consultant/Trainer
Everything is on your workstation. It's all on one box. The whole idea with a container is that you're packaging the code and the execution environment configuration together so that it can run somewhere else in an isolated way. Containers are meant to be separated from other stuff. Containers aren't exactly virtual machines but the concept is similar -- the container is a virtual entity that's running in isolation from the host operating system.
It's that isolation that makes debugging hurt. With your regular app, everything is on one box – the code, tools, and executing app are all on one machine. With a containerized app, your code and tools are on one machine (your workstation) and the application is executing inside a container. The container and the apps running inside it might as well be on a different machine. That means that you don't have easy access to what's running inside of that container.
Enter the Visual Studio 2019 container tools. Visual Studio knows how to talk to, for example, Docker so that you can start your application in a container and put breakpoints on your application code that allow you to debug your running application. Just press F5 and you're off and running.
What are your favorite features in the VS2019 container tools?
Well, I don't know about you but I haven't memorized all the syntax of Docker and Kubernetes. So when I want to containerize an existing app, thinking about writing my Docker and Kubernetes files from scratch makes me want to take a nap. Being able to take some existing code, right-click the project, and say "Add Docker Support" is great because it generates the config files for me. And then when I need to make edits, there's the IntelliSense support. It makes everything a whole lot easier.
Is there a top tip you can share when it comes to troubleshooting container applications with Visual Studio 2019?
If you're working with ASP.NET Core, do yourself a favor and open your csproj file in a text editor.
I bounce back and forth between developing on Windows with Visual Studio 2019 and developing on MacOS with VSCode and Visual Studio for Mac. The tooling is just plain different between the two operating systems. (Surprise!) I need to make sure that everything works cross-platform and I feel like the most common thing I fight with is file paths. VS2019 helps me to not have to have everything memorized, but at the same time, I don't always know exactly what it's doing.
If you start getting path errors when you're running (for example) "docker build," open your csproj file and look for a property value called "DockerfileContext." All your paths in your Dockerfile are going to be relative to that value. So if stuff suddenly stops working when you try to use the command line tools or when you hop over to a different operating system, it probably has something to do with that.
What are the top factors that you take into consideration when deciding whether an application should be containerized?
The first question I'd ask myself and my team would be "why do we want to do this?" I mean, all the "cool kids" are into containers but it adds complexity. Do we really want to take on that complexity? Do we need to take on that complexity? Could you do the same thing with an Azure App Service and then skip the container stuff? If you're not doing a microservice architecture with multiple things that need to be scaled with serious uptime and redundancy requirements, you might just be able to skip containers entirely.
For people not yet using Visual Studio 2019, do you recommend they upgrade to 2019 in order to make this kind of troubleshooting easier?
Yes! But my answer to this would always be yes because it's a career management/skills thing and a productivity thing. I always want to stay up to date with the latest and greatest tools. And for productivity, if something can help make my work a little bit easier and a little bit faster, in my mind, it's worth the upgrade. Plus, if you're just thinking about getting going with containers -- even if you aren't going to use them in production any time soon -- why try to learn using the old tools? UPGRADE!!!
Becky Nagel is the vice president of Web & Digital Strategy for 1105's Converge360 Group, where she oversees the front-end Web team and deals with all aspects of digital strategy. She also serves as executive editor of the group's media Web sites, and you'll even find her byline on PureAI.com, the group's newest site for enterprise developers working with AI. She recently gave a talk at a leading technical publishers conference about how changes in Web technology may impact publishers' bottom lines. Follow her on twitter @beckynagel.