Fix alpine file ownership issues with newer docker
Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
This reverts commit f9b939fe89.
That fix caused a regression that prevented a single `/property` option to
define multiple properties using the `/property:First=foo;Second=bar` syntax.
Users that want literal semicolons in the property values should use escaped
quotes around the property value, e.g. `/property:Prop='"foo;bar;baz"'`.
Fixes#9369.
Currently, dotnet will crash with an `ArgumentNullException` if `USERPROFILE`
(Windows) or `HOME` (macOS and Linux) is not set in the environment. This
is because there is a missing null check after retrieving the environment
variable's value. Additionally, if either variable is set to an empty string,
a `.dotnet` directory is created in the current directory where dotnet is being
run.
This commit fixes this by printing a graceful error informing the user the home
directory could not be determined and to set `DOTNET_CLI_HOME` to the directory
to use. This variable will be respected before `USERPROFILE` or `HOME`. It is
likely that CI environments where `HOME` is not set can use `DOTNET_CLI_HOME`
to specify a local temporary location; by using this variable rather than
setting `HOME`, it is guaranteed to only affect dotnet.
It was discussed that we should perhaps fallback to some temporary location if
the home directory could not be determined, but NuGet currently requires `HOME`
to be set to work. Because of this, it was decided that we should just handle
this case gracefully and provide a way for users to override the home directory
without relying on `USERPROFILE`/`HOME` entirely.
Closes#8053.
