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.
(personal opinions/preferences here:) I wouldn't really recommend rebuilding your container from scratch as a way of doing normal daily development. Why not just mount your source into the container as a volume and do rebuilds from there? You can even mount in the nuget cache so that it persists between development sessions.
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.
a mounted volume and possibly using dotnet-watch within the actual container may be an effective choice, but at the lat time I was working with it, "dnx watch" was broken in docker files with Glenn C's last comment being something to the effect of "i'll fix this after the dust around dotnet-cli settles" (again, totally fair, I discovered the bug during RC1 and overlapping with the dotnet-cli announcement)
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.
I greatly prefer using docker for reasons like this. Otherwise, I'm not sure what's going on. I just ran through those instructions on my Mac. After installing that package and starting a new shell, `dotnet` was working.
(I and more authoritative individuals can help more in Slack without cluttering up this thread too much.) If the Installer did its job, you should have /usr/local/share/dotnet on your $PATH and it should contain a `dotnet` binary among some other items.
