Wouldn't it? Also imagine, every time you do a build inside of something like Visual Studio, being able to test and distribute that in its own container.
The tangential benefits/integrations start to get really interesting.
yes this would be interesting. We have application severs with multiple windows apps running on them with different versions of the .Net framework. I had to pull teeth with our SysAdmin to get the .Net upgraded on the server. It would be nice to have a container for each so I (as a dev) could run the each app with it's own needed dependencies instead of having to install them on the server.
This is already happening in .NET land independently of this announcement. ASP.NET vNext Katana (1) completes the move away from a perspective monolithic framework and instead individual NuGet packages. Ie - when you deploy your app you deploy your assemblies and into that folder goes everything needed to run the app independently, including and up to .NET core assemblies or BCLs.
Your app is a folder and that folder contains everything needed to run the application even up to the point of self-hosting with OWIN - IIS is not needed anymore!
So the point is Windows server is going to be non-CLI docker manager here to make it easier deploy Linux server apps on Windows ? Or am I missing something here ?
Microsoft is adding the raw ability (think: cgroups and namespaces ala Linux) in to the Windows Kernel to enable strict process isolation/sandboxing/etc.
Docker will sit on top of that and provide the same client API you're accustomed to, but run Windows based images natively.
The tangential benefits/integrations start to get really interesting.