I'd like to share a recent puzzle I solved involving Visual Studio and Docker Compose.
I've been working with a service that needs to do some setup work when running locally. It generates and shares certificates, creates users, sets permissions, and more. To handle these tasks, I developed a suite of bash scripts. I'm a firm believer in plug-and-play projects - clone it, run it, and you're good to go!
When I tried to run this service through Visual Studio using Docker Compose, I hit a wall. The logs from my bash scripts were nowhere to be found, and other services that depended on this one refused to start.
The interesting thing is, when I ran Docker Compose outside of Visual Studio, everything worked like a charm. This led me to discover that the auto-generated docker-compose.vs.debug.g.yml file in Visual Studio overrides the ENTRYPOINT to keep the container running to be able to attach the debugger. Essentially, a helpful feature was unintentionally blocking my custom scripts.
Unfortunately, there's no perfect fix for this yet (see this open issue on Microsoft's DockerTools GitHub repository:
github.com/microsoft/DockerT…). However, by adding another docker-compose.vs.debug.yml override file and tweaking the metadata, I was able to bypass the issue and get my service up and running.
So if you ever encounter a similar ENTRYPOINT override challenge in Visual Studio, remember this post! For more details on customizing the debug compose file, check out the official docs:
learn.microsoft.com/en-us/vi…
#visualstudio #dockercompose #docker #dotnet2023 #lessonslearned #codecraftingtips