Dotnet-docker: Remove onbuild Dockerfiles

[MichaelSimons]

The onbuild Dockerfiles should be removed for the following reasons.

1. Users who are new to Docker get confused by the onbuild tags and are using them incorrectly. Users see the tag and think it should be used for building their apps but do not understand the onbuild docker concept. Because of this, users are redefining what onbuild already does as shown in the sample below. As a result of this users have two copies of their app in the image. Additionally this patterns results in restoring the packages twice. Lastly this usage breaks the optimization that is in place to skip package restore when only cs files are changed. Trying to explain to users the onbuild concept has proven to be rather difficult.

FROM microsoft/dotnet:1.0.0-preview2-onbuild

COPY ./src/AspNetCoreAuthentication/project.json /app/
COPY ./NuGet.Config /app/
WORKDIR /app/
RUN dotnet restore
ADD ./src/AspNetCoreAuthentication/ /app/

EXPOSE 3308
ENTRYPOINT ["dotnet", "run"]

1. The current onbuild implementation is not ideal. It does not actually build the app until it is run. This is less than ideal for scenarios in which the image is run multiple times. You shouldn't have to compile the app each time you want to run it. It should get built into the image. Fixing this however is not trivial because the ENTRYPOINT needs to know the name of the resulting assembly to run. Ideally CLI would provide the desired functionality to implement this but they don't currently have it.

The current belief is that the onbuild images are adding confusion more than they are adding value, therefore they should be removed. Writing the necessary logic to copy and build a .NET Core project within a Dockerfile is pretty simple so the onbuild image is not saving the user a whole lot.

[Yantrio]

This is a poor reason to remove functionality that is used by many people. I think if the users are confusing it, then improve documentation somehow, don't just remove it.

[MichaelSimons]

@Yantrio, thank you for the feedback. Would you be willing to share the scenario in which the onbuild image was adding value for you? Is defining your own Dockerfile that does the equivalent something you have considered? Can you explain why you would prefer an onbuild image versus having your own Dockerfile?