Balancing change: feedback + learning / impact to customers = change

I was reading a post about the frustration a customer had around the constant change. First, I do apologize for the frustration as it is difficult to continually learn new things when the things you've learned keep changing. With each change, we balance the impact it will have on our existing customers, the challenges they're currently facing, what we're learning from our previous releases, and the impact we can have for new customers.
While I won't speak for Docker, I can speak to the tooling we provide in VS, which is the same basic model Docker follows as well. The Visual Studio Container Tools are currently in beta/pre-release. With the release of VS 2017, we'll consider this our 1.0 official release. Before we release any major release, we are willing to make significant changes. The pre-release moniker implies major changes may, or likely will occur; as we're learning. We of course have two basic models to work with. Only release major releases, hope we get it right and deal with the consequences of not. Or, release major releases with a commitment of upgrade and support, and provide interim releases that are building up to the next major release. The interim releases are a view into what we're thinking and doing. Many companies like Docker achieve this with beta and stable channels: https://docs.docker.com/docker-for-windows/ As we release Visual Studio Container Tools in Visual Studio 2017, we're working to have this same model. If you install the "stable" channel from Visual Studio, you'll get a stable release of tools. As we release major versions, we'll provide some sort of upgrade path. How depends on the change of course.

So, first. Thanks for all the feedback and patience. Working with containers is a major shift in how we develop software. We're working hard to maintain the docker experience customers expect, while providing the productive experiences developers have come to expect from Visual Studio. We want to be careful to not change the the technology to match the tools, but rather shape the tools to match the technology.

Steve

Comments

• Anonymous
  March 07, 2017
  hi there,currently, I am trying to set up visual studio code IDE with docker compose for my project. Upon bring up the project, I encountered the error: for web Cannot create container for service web: C: drive is not shared. Please share it in Docker for Windows Settings. Hence, I did so. After I hit the Apply button on the docker settings UI with C drive checked, it just kept updating drives and never ended. I dunno how and what to do for the next. Do you have any idea about that? thanks
• Anonymous
  June 05, 2017
  The comment has been removed
• Anonymous
  June 05, 2017
  Thanks Jim,Generally, we are working to improve our documentation. While we strive to make the tools work in an obvious way, the changes to keep up with the quickly changing platforms does make it harder to follow. Specific to your comment: the docs you have seen do reflect the older tooling, when we only had Linux scenarios working. The original intent was to provide powershell/cmd scripts, equivalent to .sh scripts. We've since moved away from scripts and are working to use the multi-stage build dockerfiles. Even in our VS 2017 Container Tooling scenarios, we no longer need scripts. Thanks for the feedback,Steve
• Anonymous
  June 07, 2017
  Thanks for the reply Steve - I've finally gotten to the bottom of my own frustration ;) I have an ASP net core (Net Framework) application and the "add docker" option isn't there. That's what led me searching for all the articles on the web and ending up reading a lot of Linux specific things. I even failed to get to the end of this video (https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2017-Launch/T111) which made me assume Linux was the only option supported - but when i reviewed it with more patience (around 9 mins in) I found windows containers are indeed included). Do you happen to know why "Add docker" isn't present for .net core (Net Framework) projects?
  • Anonymous
    June 07, 2017
    Hi Jim,Sorry for the frustration. Up until recently, we hadn't thought we would support ASP.NET Core on .NET FX once 2.0 was released. The belief is customers wanted a small, cloud optimized OS and Runtime. Windows Nano server fits that bill, but only supports .NET Core. The features customers wanted from .NET FX, over .NET Core 1.0 would be implemented in .NET Standard 2.0. So, if a developer was targeting ASP.NET Core, they'd target .NET Core on Nano or Linux. Recently, at build, community feedback asked us to target .NET Core on .NET FX. The updated plan is to add ASP.NET Core support over .NET FX on Windows Server, but it hasn't been moved from a backlog to committed work just yet, so I can't say when this will come online.I am curious what you need from .NET FX that requires you to pull in the larger, compatible Windows Server Core base image.Steve
    • Anonymous
      June 08, 2017
      Thanks again for the reply, much appreciated. It may be just my confusion - I must admit it has been hard to keep up with the changes and we move slowly in my organisation. We wanted to adopt asp .net core - but we have a lot of frameworks and dependent assemblies that we did not want to rewrite. We hoped that net Core (Net Framework) which i think you call NetFX would fit that bill - the future proof of .net core without having to revisit our dependent code. Presumably once ASP .net core 2.X is available that will solve our issue for us and enable Windows Container Targetting with Docker? Thanks for the extra explanation - its all moving very fast and it might well just be my lack of understanding!