$ docker run -it microsoft/dotnet:latest
# dotnet new
# dotnet restore
# dotnet run
You can run asp.net apps from this container too as they have packaged libuv into a nuget package. $ docker run -it microsoft/dotnet:latest
# dotnet new
# dotnet restore
# dotnet run
You can run asp.net apps from this container too as they have packaged libuv into a nuget package.That way each subsequent run in DEVELOPMENT will happen in seconds as opposed to minutes.
I've been trying to get a PR Shepparded though the MS open source process for months.
https://github.com/aspnet/Home/issues/1312
https://github.com/OmniSharp/generator-aspnet/issues/527
old-speed for every deploy & first deploy under new method:
~3m30s
new-speed - second & subsequent deploys if dependencies are unchanged:
~9s
I've tried to get it into the right place from a few different angles, but at the end of the day (after some discussions with the MS team) I think they want to leave this quality-of-life improvement out in favor of making sure the base-template is "pure" (actually a perfectly acceptable choice IMO, different priority for the tool provider vs. the front-line-dev)ANYWAYS, 9 seconds vs 4 minutes per recompile is a BIG deal. You'll thank yourself and drink way fewer cups of coffee over the course of a day.
I've been playing with docker and dotnet since they gave a demo at Build 2015... if I could figure out a way to quit my job and just do open-source docker tooling, kubernetes, mesos, and dotnetcore I would do it in a heartbeat. I'd love to create the architecture for the "bootstrap" of scalable dotnetcore microservices.
I only do a from-scratch restore and compile whenever I do a "final container" build to actually push/deploy. In that case, I want it doing a full restore, plus it already has some mechanism to capture the publish output from my build container and dump it into a more minimal runtime container.
On the other hand, what you're doing "locks in" your dependencies at a single point in time when you build your intermediate base layer. That may be desired for orthogonal reasons.
HOWEVER back to the "use docker inheritance" thing. Absolutely a preference with many valid options available to you.
In the one I'm proposing your "company level" shared docker file would be (roughly, this is from memory scratch so a bit more of a gist than runnable code)
filename shared_company_image
from microsoft/aspnet
RUN dotnet new my_temp && dotnet restore && rm my_temp
then every internal project would run from shared_company_image
COPY . /app
WORKDIR /app
RUN ["dnu", "restore"]
You'll see that in this scenario you're actually running DNU restore twice, but because they've already been downloaded ONCE in the above image, the second image only downloads MISSING and UPDATED deps and you save massive amounts of time for every developer at setup & startup.It's almost like doing CSS bundling and minification.
There's an added bonus for internal IT teams (I guess) that in the shared image you could also "slurp in" other tools or patches that your team feels are critical.
Anyways, I agree that it's preference based, but this one adds a bit of weight in terms of saving frontline developer hours.
In my own dev-flow "docker run" happens pretty often, so if there's a way I'm missing to cut the number of those down, I'd be interested in hearing it.
edit: I should mention I'm working under an agency scenario with dozens of websites and hundreds of developers - we try and make ourselves extremely portable from one project to the next. I've currently got around 15 that I'm actively managing and I may have to parcel out just a couple hours work at a time for a developer.
Does not work on OS X following these instructions: https://www.microsoft.com/net/core#macosx
There's a slack room which might be able to provider further support: http://tattoocoder.com/aspnet-slack-sign-up
See open issues: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/k...