Dockerfile does not use caching for package restore

[AlexChesser]

Per the discussion inside my OmniSharp pull request OmniSharp/generator-aspnet#531 the current state of the dockerfile in the aspnet/home repo does not use docker caching on DNU RESTORE (soon to be dotnet restore)

A small fix to the sample dockerfile can make the compile time of "second deploy" in docker 23x faster

old-speed for every deploy & first deploy under new method: ~3m30s
Start: 06:03:13.313
Finish: 06:06:40.640

new-speed - second & subsequent deploys if dependencies are unchanged: ~9s
Start: 06:00:36:036
Finish: 06:00:45:045

I also posted the FULL LOG of the difference over here: aspnet/aspnet-docker#123

[AlexChesser]

It turns out this is actually a regression/fix from a previous commit.

037ba1d

[tlk]

I think this is related #936 & #948

[AlexChesser]

I run it on my machine. Not sure why we ever did the copy of the project.json then copy the rest and run. That seems less than optimal. I will update the other sample and it should be good.
@glennc in #936 (comment)

The reason we copy the project.json and do a "dotnet restore" before copying and compiling the rest of the project is for the massive performance gains when developing. (cached build = 0:09, fresh = 3:30)

If dependencies are unchanged a new docker-build/run will complete in seconds as opposed to minutes. (See benchmarks from comment 1 in the thread)

The team over at Omnisharp OmniSharp/generator-aspnet#531 seemed to like the idea, but pointed me here.

Copying project.json, restoring, then copying app would overwrite the project.lock.json with one from my build context. Which would not work because it would overwrite the lock file that was created in restore with the one from the context. This probably doesn't break people if everything lines up 100% but is not really correct.
@glennc in #948

In practice, in my tests, this has not been a problem. However that doesn't mean it might not be.
I'd be willing to add the extra steps of making a temp copy of the .lock.json file then overwriting after the add step.

It is a little more convoluted but it will make a developer's life a LOT easier over the course of a project's lifecycle. 4 minute compile time per change is coffee break time, while 9 seconds feel OK.

or run restore a second time to re-write the .lock.json file locally. That would also be much faster as the packages would already be downloaded.

@ahmetalpbalkan, @glennc Thoughts?

Ohh! Just noticed this as well: https://channel9.msdn.com/Blogs/Seth-Juarez/Steve-Lasker-on-Docker-Tools-for-Visual-Studioif you watch at 8:30, Steve Lasker also prefers to run the copy project.json option enabled.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.