This week, we released an update to our Docker Tools for Visual Studio. This was based on a bunch of feedback we’ve heard from you .It does change some of the experience to date, so I wanted to provide some insight to why.

The tools up to version 0.9.* focused on packaging and publishing your ASP.NET 5 (core) application, running it in a container, hosting in an Azure VM Container Host. We support both Linux and Windows Container scenarios.

The 0.9.* tools are a great way for the entry developer to get started as they get some basic container scenarios enabled for them without changing too much about their development workflow. However, we’ve been working with a number of customers that are hitting various limitations.

Based on customer feedback, below are a list of the issues we’ve been hearing, and what we’re proposing:

• Running containers through the UI is great, but I need to customize the scripts with Vagrant, Mesos, or Marathon functionality
  0.10.* moved to a PowerShell script scaffolded into your project. See Developing In Containers below
• I need to run multiple containers for my project including RedisCach/MongoDB or my WebAPI and want to use docker-compose
  0.10.* moved to using docker-compose
• I need to target different environments: debug w/debugging configurations, such as volume mapping and ultimately breakpoint debugging. And release, which optimizes the image for staging and production hosting
  0.10.* uses multiple dockerfile.[config] and docker-compose.[config].yml files
• I need to target different container hosts, that use different certs
  The 0.9.* tools were developed before we fully understood docker-machine. Docker-machine has a local store for each hosts certs enabling you to switch between them by executing docker-machine env [hostname] from a Command/PowerShell/Bash prompt. The 0.10.* iteration defers container targeting to docker-machine active. docker-machine does have several limitations, such as importing existing container hosts, however this is the manner Docker recommends for managing various hosts. The docker-machine team has been hearing the feedback and working to complete the docker-machine scenarios, so our tools are standardizing on docker-machine rather than coming up with an alternative solution
• As I get beyond hello world, I need a set of dockerfiles, compose files and scripts that prep and run a collection of containers
  yo docker has some early ideas we’ve been iterating upon, but for the Visual Studio developer, see the Developing In Containers description below
• In addition to Azure, I’d like to use a local container host or another host in my environment
  While you can use the custom option, between the multiple host/cert issues, and trying to figure out what values to place in the custom text boxes, developers, including the lesser Scotts have been confused and frustrated with some blocking bugs. Getting VirtualBox to work reliably isn’t the easiest either.
  Starting with 0.10.*, container host targeting defers to docker-machine which standardizes on the way developers working with docker have come to expect. We’re still planning to support specific host targeting, however we use docker-machine to switch hosts, getting all the benefits offered by docker-machine multi-host targeting.
  VirtualBox has gotten a little better, and the Docker-machine folks have even started to give some Windows CMD and PowerShell love by providing the relevant commands for switching to the proper host with docker-machine env [hostname]
• Windows Containers are difficult to get working consistently
  We’ve been working with the Windows Container/Hyper-V team to stabilize the Windows Container scenarios. Linux Containers have been out for a while so there aren’t many moving parts. Windows Containers are still early and there are many moving parts as we build the best Cloud/Container OS. The majority of challenges with Windows Containers relates to properly provisioning them in the first place and capture the certs for a secured connection.
  There are a number of workarounds in our tooling scenarios for provisioning Windows Container Hosts that have caused us far too much fragility, including the lack of docker-machine create support. Long term, we don’t believe provisioning a container host is something we think should be uniquely done from the Visual Studio tools, rather they would be done in the Azure Portal directly, or through a command line similar to docker-machine create, or the Azure CLI.
  There’s some bigger changes coming that will make things more reliable, faster and standard, so we’ve been balancing getting the developing in container experiences working, which will work for Windows as well, compared to patching a set of scenarios that will change in their implementation.
  That said, we do know it’s frustrating and do plan to stabilize the Windows development scenarios as the new components come together
• Where’s the dockerfile syntax handling? It’s in VS Code, why not Visual Studio
  As it turns out, the implementation for VS Code language services are different compared to Visual Studio. We do have a docker language service in our backlog, but figured developers aren’t blocked at this point editing the docker files, particularly as we scaffold out the baseline. But, developing in a container, that’s a bit more difficult for developers to hook themselves. So, stay tuned.

Developing in Containers

As customers move beyond simple hello world container scenarios, they’ve hit the issues listed above. And while we started thinking about ways to solve them, after talking with mac/linux developers and startups already using docker in production, what we found was developers really wanted to develop in a container, as part of their inner loop. They like scripts to manage their environment, but want help scaffolding the scripts as their tedious to get right.

Publishing to a container, after they’ve been developing for a while means they’re deferring problems such as taking a dependency on the wrong NuGet package or coding to a behavior that’s different on their Windows 8/10 development machine compared to their Windows Nano or Linux host they plan to deploy to.

The fact that we develop in one environment, but plan from the outset to deploy to another environment is a bit strange if you think about it. We know there are differences, we hope the underlying frameworks abstract those, yet we look for specific behaviors from that target OS and we know that as much as we try, there are always differences that leak through. And, it’s those small nuances that cause us the most headache to troubleshoot and resolve later on.

As we looked at what Linux/Mac developers were doing we didn’t want to forget the expectations our Windows/Visual Studio developers have for great UI/Tooling. Exploring with yo docker and building on the work we did with Connected Services, we went with the scaffolding approach, with prompted UI. We provide the baseline functionality, scaffold files into your project based on some questions you might answer, which become your files. No more “can’t touch this” style coding where we put code in your project that you must compile, but if you change anything you lose the support of the tooling or we simply overwrite your changes.

3 Steps

We’re taking a 3 step approach to transitioning your development from your development machine to developing directly in a container

1. Run my code in a container
   switch F5 from my development machine to running in a container
2. Edit & Refresh
   Allow me to make changes to my code, without having to rebuild the container each time
3. Breakpoint debugging
   Set a breakpoint, hit F5, …just as I have today

Version 0.10.0 – Edit & Refresh – Linux

With the latest version of our Docker Tools for Visual Studio we now support the following scenarios:

• Docker assets for Debug and Release configurations are added to the project
• A PowerShell script added to the project to coordinate the build and compose of containers, enabling you to extend them while keeping the Visual Studio designer experiences
• F5 in Debug config, launches the PowerShell script to build and run your docker-compose.debug.yml file, with Volume Mapping configured
• F5 in Release config launches the PowerShell script to build and run your docker-compose.release.yml file, with an image you can verify and push to your docker registry for deployment to other environment

Some Q&A on Docker Tools for Visual Studio 0.10.0

• Q: I see support for Linux. When will you support Windows?
• A: The Developing in Container scenario, for Edit & Refresh relies on the Volume Mapping feature of Docker and running the containers in a local container host. While we have Linux running locally with VirtualBox, we don’t have Windows running locally on Win 10. So unless you have an early preview of Windows Server 2016, you don’t yet have this scenario.
• Q: Why does the PowerShell script get displayed?
• A: This is just an early way to get things launched. We will hide the PowerShell script and send the output to the Output Window when we get the debugger hooked up
• Q: Why am on the B&W side of the rainbow with the docker files?
• A: We have the docker language service on our backlog. We felt we should prioritize the F5 experiences for now.
• Q: The PowerShell script launches, shows some red text, but quickly closes without running the containers
• A: You have an error somewhere. The first thing to do is stop the PowerShell script from closing to see the error
  Open PropertieslaunchSettings.json file
  in the Docker section, edit the commandLineArgs name/value pair and add -noexit
  “commandLineArgs”: “-noexit -ExecutionPolicy RemoteSigned …
• Q: When I add another environment variable to the docker-compose files, I get an error when docker-compose runs. I see t in the Output window
• A: By default, the editor for .yml files is a json editor. When you hit carriage return on the previous line, Visual Studio converts your spaces to tabs. .yml files don’t support tabs and the yml parser is failing validation. You can change your Visual Studio editor defaults to not insert tabs for now. Once we implement the docker language service, we’ll keep spaces as spaces
• Q: Why is this release 0.10? When will 1.0 be released?
• A: Having a 1.0 release implies a commitment to the stability and consistent in behavior, and a handoff to our premier support teams. As we’re still working through the way we’re enabling container development, we’re making pretty frequent changes, and we’re not fully integrated into the e2e experiences, such as launching a PowerShell script. We’re also dependent on the ASP.NET 5/Core components, Windows Containers which haven’t released and we’re working with Docker on some new tooling. Once we get these dependencies released and we complete step 3, we’ll see if we’re ready to declare 1.0
• Q: If it’s not 1.0, can I use this for production projects?
• A: Our tools don’t have any runtime components, and the files scaffolded into your projects are your code to enhance. So, yes, as much as you feel comfortable with Docker and ASP.NET 5/core, you should feel just as comfortable with the pre-release Docker Tools for Visual Studio