dotnet / dotnet-docker-nightly Goto Github PK

Steps to reproduce the issue

~/s/f/core-dotnetcore   dotnetcore *$…  docker run --rm -ti -v (pwd):/root/ -v /home/paul/.aws:/root/.aws -p 8282:8282 microsoft/dotnet-nightly:2.0-sdk bash
root@3a23c05bbe43:/# mkdir /tmp/paul
root@3a23c05bbe43:/# cd /tmp/paul
root@3a23c05bbe43:/tmp/paul# dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /tmp/paul/paul.csproj...
Restore succeeded.

root@3a23c05bbe43:/tmp/paul# dotnet restore
  Restoring packages for /tmp/paul/paul.csproj...
/usr/share/dotnet/sdk/2.0.0-preview2-006215/NuGet.targets(98,5): warning : Dependency specified was Microsoft.NETCore.App (>= 2.0.0-preview2-25324-03) but ended up with Microsoft.NETCore.App 2.0.0-preview2-25401-01. [/tmp/paul/paul.csproj]
  Lock file has not changed. Skipping lock file write. Path: /tmp/paul/obj/project.assets.json
  Restore completed in 172.73 ms for /tmp/paul/paul.csproj.
  
  NuGet Config files used:
      /root/.nuget/NuGet/NuGet.Config
  
  Feeds used:
      https://api.nuget.org/v3/index.json
      /root/.dotnet/NuGetFallbackFolder
root@3a23c05bbe43:/tmp/paul# dotnet build
Microsoft (R) Build Engine version 15.3.246.41955 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  paul -> /tmp/paul/bin/Debug/netcoreapp2.0/paul.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.21
root@3a23c05bbe43:/tmp/paul# dotnet publish 
Microsoft (R) Build Engine version 15.3.246.41955 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  paul -> /tmp/paul/bin/Debug/netcoreapp2.0/paul.dll
  paul -> /tmp/paul/bin/Debug/netcoreapp2.0/publish/
root@3a23c05bbe43:/tmp/paul# dotnet bin/Debug/netcoreapp2.0/publish/paul.dll
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.0.0-preview2-25401-01' was not found.
  - Check application dependencies and target a framework version installed at:
      /
  - Alternatively, install the framework version '2.0.0-preview2-25401-01'.
root@3a23c05bbe43:/tmp/paul# 

Expected behavior

At the very least, I'd expect that to print "Hello World!"

Actual behavior

That error

Additional information (e.g. issue happens only occasionally)

Happens consistently. I was actually trying to get a compile version of an app that uses the SignalR packages from the aspnet-dev myget repo, and stumbled around that error for hours before I decided it must be more insidious than my narrow knowledge of .netcore2.0

I doubt this is a docker issue, it's something peculiar to the nightly image. I even tried creating a new image with the latest preview that I could discover (006236), but that has the same issue.

Output of docker version

$ docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.8.1
 Git commit:   89658bed64
 Built:        Fri May  5 22:40:58 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.8.1
 Git commit:   89658bed64
 Built:        Fri May  5 22:40:58 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info

docker info        
Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 191
Server Version: 17.05.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.11.3-2-zen
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.6GiB
Name: chulak
ID: Q5R4:VMTX:45AB:E37M:QBFM:3IDF:Z6AL:DDKK:3CGT:RYIM:KI3P:34LS
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: pms1969
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Currently the multi-arch based tags refer to debian:jessie based images. Microsoft should be providing the most secure base images that it can - which is believed to be debian:stretch. The jessie based images should still be available via a -jessie suffixed tag.

Getting the error below

docker run --rm -it microsoft/dotnet-preview 
dotnet new 
dotnet restore

error: Could not find a part of the path '/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/root/proc/189/fd/97'.

The Dockerfile links in nanoserver-insider readme are broken. They are relative links which are not supported on Docker Hub/Store.

Can you also provide an image with debian:stretch-slim as the base image, instead of debian:stretch to minimize the image size for both ARM and x64?

You can find more information on the Debian Docker store page (https://store.docker.com/images/debian); specifically under the "<suite>-slim variants" heading.

"These tags are an experiment in providing a slimmer base (removing some extra files that are normally not necessary within containers, such as man pages and documentation), and are definitely subject to change."

This is very helpful in scenarios where multiple containers are in use in environments with limited resources (i.e. Raspberry Pi). Using jessie vs. jessie-slim as an example, you can see this removes 50MB from the base, which is roughly 1/3 of the overall storage required.

Unit tests for the 2.* jessie images were lost as part of #415. They should be added back

The logic within image-builder that explicitly pulls the FROM images during a build needs to be updated to support multi-stage builds. Multi-stage build Dockerfiles may have multiple FROM commands. image-builder should be explicitly pulling each one of the base images.

I'd recommend clearing the apt cache in the same RUN invocation that you update it in. It ensures that you don't wind up making everyone download a copy of your apt cache.

example:
https://github.com/colemickens/polykube/blob/637b17dec481e8fba86d0628c13469efd019d485/dotnet/dockerfiles/dotnet-base/Dockerfile#L10

The Dockerfile in this repo is currently using an "scm" buildpack-deps image. According to the buildpack-deps repo, the scm images add "various source control management tools". These tools add significant size to the image and may not be critical for the base .NET Docker image.

We could perhaps use a smaller buildpack-deps image like jessie-curl, which is 42 MB smaller than jessie-scm. We could then install just one or two source management tools on top of it (such as Git) rather than all of the ones installed by the jessie-scm image. To reduce the size even further, we could use debian:jessie as the base image and then just install curl and use that instead of wget.

We should also consider making this change in https://github.com/dotnet/dotnet-docker, although the situation is somewhat different there because we plan to have a separate "slim" dotnet-docker image with minimal dependencies.

In preparation for 2.0 releasing, the latest tags should be moved.

This repo has several images which have multiple tags; for example, 1.0.1-runtime and 1.0-runtime point to the same image. For some images, we are assigning the same image multiple tags, either by the build hooks or the Nano Server VSTS build definitions. For other images, we have multiple entries in the Docker Hub Build Settings for the same Dockerfiles to be built with different tags.

In the former case, the image digests are the same (meaning the tags point to the exact same image). In the latter case, the expectation is that the images should have different digests but contain the same layers. However, this is currently not the case for some images; for example, microsoft/dotnet-nightly:1.0-sdk-msbuild and microsoft/dotnet-nightly:1.0.1-sdk-msbuild contain three different layers, which can be seen with the docker inspect command. This means that users who pull both tags will have separate layers for them on their machines, which takes up a substantial amount of extra space and increases download times.

FROM microsoft/dotnet-nightly:2.1-runtime-deps-alpine

# Install .NET Core
ENV DOTNET_VERSION 2.1.0-preview1-25919-02
ENV DOTNET_DOWNLOAD_URL https://dotnetcli.blob.core.windows.net/dotnet/Runtime/$DOTNET_VERSION/dotnet-runtime-$DOTNET_VERSION-alpine.3.6-x64.tar.gz
ENV DOTNET_DOWNLOAD_SHA 7a8b081c890226ba7220c654dc833752f837171c2fe449367d24c2980db3a809012478a67423fd46264e5d2f0389a6890077f8dd25a1fc4aeecb25deb84d72a4

RUN apk add --no-cache --virtual .build-deps \
        openssl \
    && wget -O dotnet.tar.gz $DOTNET_DOWNLOAD_URL \
    && echo "$DOTNET_DOWNLOAD_SHA  dotnet.tar.gz" | sha512sum -c - \
    && mkdir -p /usr/share/dotnet \
    && tar -C /usr/share/dotnet -xzf dotnet.tar.gz \
    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet \
    && rm dotnet.tar.gz \
    && apk del .build-deps

The three ENV instructions are not necessary. The various official Docker images are not consistent on this pattern - some have it and others don't. Since the purpose of supporting Alpine is to have an efficient and slime image, IMO we should remove the URL and SHA layers. Their value is limited. I believe there is value in preserving the DOTNET_VERSION as this easily identifies the version of the primary component. Seeing this called out in the Dockerfile and when viewing Docker image layers is useful.

If this change is made, it should be used across all new Dockerfiles going forward in order to have consistency. Additionally, the update-dependency tool will need to be updated accordingly.

The workaround that was added for moby/moby#20818 should be removed. The fix for this issue was released with Docker 1.11.0.

Currently, 1.1-sdk-msbuild images perform a nuget cache warmup, however, this warmup does not include packages that are new to netcoreapp1.1.

This leads to restore errors when building inside the sdk image:

Unable to resolve 'Microsoft.NETCore.Runtime.CoreCLR (>= 1.1.0)' for '.NETCoreApp,Version=v1.1'.

cc @MichaelSimons @naamunds

Currently this repo only produces images for the preview channel of CLI. It should also produce images for the futures channel, and potentially other channels or build labels of CLI, such as latest vs. LKG. This work also entails triggering the DockerHub builds from CLI builds as appropriate.

PowerShell is now pwsh as per https://github.com/PowerShell/PowerShell/releases/tag/v6.0.0-beta.9

Starting from this release, the PowerShell Core executable is renamed to be pwsh

PowerShell version v6.0.0-beta.6 is used in this repo. For example at (https://github.com/dotnet/dotnet-docker-nightly/blob/master/test/Dockerfile.linux.testrunner#L29). If we were to upgrade to v6.0.0-beta.9 or newer, then make sure to use pwsh in place of of PowerShell.

Originally we had named this image dotnet-preview to match the fact that the image uses the .NET CLI Preview channel but with the advent of "preview1" as a version name in the CLI we risk confusion. We should find a better name-- something like "nightly". @blackdwarf @glennc do you have suggestions.

As part of the repo rename (see #14), the dotnet-preview Docker Hub repo has been superseded by the dotnet-nightly Docker Hub repo. The old repo has been frozen, and the plan is to delete it after a period of time which allows developers who are using the repo to react to the change.

With the introduction of the offline feature, the dotnet CLI builds a local package cache on first use. The dotnet Dockerfile should trigger this to happen. This takes some time therefore it will be a savings for all users of the image. Additionally having the package cache in the base image will save disc space for scenarios in which base image is used multiple times on the same machine as the base layer will be shared.

Dockerfile should do a checksum verification on the CLI files downloaded.

Steps to reproduce the issue

1. Invoke several CI jobs. For example, submit a couple dummy PRs.
2. Wait for a CI job to fail due to an error at Invoke-WebRequest command. For example, https://ci.dot.net/job/dotnet_dotnet-docker-nightly/job/master/job/NanoServer_2.0_prtest/215/console

Expected behavior

No Invoke-WebRequest failures.

Actual behavior

Invoke-WebRequest command fails on a CI machine. Once this failure occurs, all subsequent jobs on the machine will fail at the same Invoke-WebRequest.

Only workaround available is to delete the machine, and let CI recreate a new one.

This isn't trivial as there isn't an ARM SDK image therefore the current utest pattern doesn't work - use the platform SDK image to build an app that is tested with the platform runtime images.

This repo was created to host Windows Insider builds for the Windows Server 1709 release. Now that the release is GA, the repo's readme is out of date and the Dockerfile links are broken. Would it make sense to update the readme to indicate it is obsolete because of the 1709 release? After some time goes by it may make sense to delete it or it could be left in the obsolete state with the possibility of using it during the next release cycle.

$ docker run --rm -it microsoft/dotnet-nightly:2.0.0-preview1-sdk
root@d00d8750608d:/# dotnet --version
2.0.0-preview2-005905

cc @MichaelSimons

This may require creating Windows Server 2016 1709 VMs to use - not sure if any exist.

Once dotnet/cli#2565 is fixed, the Dockerfile should be updated to utilize the CLI Debian package instead of extracting the tarball and manually installing the dependencies.

The rel prefix in the tag names is confusing. This comes from the CLI channel/branch but doesn't add value here. The prefix should be dropped.

See https://github.com/dotnet/cli/issues/3088. The clang-3.5 dependency has been removed and lldb is going to be made optional.

The microsoft/nanoserver-insider-dotnet images should get rebuilt now the .NET Core 2.0 has RTM'd. These builds should be done on the latest nanoserver-insider builds.

The latest nightly build of the 1.1 SDK is 1.1.0-preview1-005089 and latest 1.1 runtime is 1.1.3-servicing-001554-00, but the dotnet-nightly images still use the stable releases.

Latest SDK: https://github.com/dotnet/cli/tree/rel/1.1.0#installers-and-binaries
Latest runtime: https://github.com/dotnet/core-setup#daily-builds

Steps to reproduce the issue

1. docker pull microsoft/dotnet-nightly:2-runtime-jessie
2. docker run -it --rm microsoft/dotnet-nightly:2-runtime-jessie
3. cat /etc/os-release

Expected behavior

Should see that the container is based on Debian Jessie

Actual behavior

The container is based on Debian Stretch

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

This is a result of the fix for #321.

The image-builder tool provides all of the needed functionality to build the repo. There is no need to have logic within the repo that reads the manifest to figure out what to build.

Steps to reproduce the issue

1. Open a Dockerfile for Nano Server. For example, https://github.com/dotnet/dotnet-docker-nightly/blob/master/2.0/sdk/nanoserver/amd64/Dockerfile
2. Observe that the escape directive is not specified. This means / (backslash) will be the default escape character.

Expected behavior

Use the escape directive, as suggested at (https://docs.docker.com/engine/reference/builder/#escape) to ` (backtick).

Filtering logic uses a wildcard to match any character(s) after the specified, if any, version and OS filters.

$buildFilter = "$VersionFilter*/*/$OSFilter*"

Refer https://github.com/dotnet/dotnet-docker-nightly/pull/490/files#diff-5eb43610b02eda87c0c4550f32a64b09R26

This logic was written this way since 1.* folder structure does not align with 2.*. After alignment, this logic can be cleaned up as follows -

$buildFilter = ''
if (-not [string]::IsNullOrEmpty($versionFilter))
{
$buildFilter = "$versionFilter/$buildFilter"
}
if (-not [string]::IsNullOrEmpty($OsFilter))
{
$buildFilter += "$buildFilter/$OsFilter/"
}

RuntimeReleasePrefix is used as the cli release prefix
CliReleasePrefix is used as the Dockerfile version folder the tool runs on.

This suggestion was made as part of #467 (review). This is something we should consider for all Windows based Dockerfiles.

Need to change tag names from 2.0.0-preview2 to 2.0.0-preview3 to match the .NET Core artifacts contained in the images.

This demand is bad and should be removed.
https://github.com/dotnet/dotnet-docker-nightly/blob/master/build-pipeline/dotnet-docker-linux-arm32v7-images.json#L197

This type of demand is bad as it doesn't allow for scaling when additional identical machines are added/removed from the pool.

To fix this, capabilities should be created that identify the machine configuration attributes required by the varioius build definitions. This demand should then be refactored to rely on these capabilities instead.

The .NET CLI has changed the channel they are using for Preview2. The Dockerfile needs to be updated accordingly.

Steps to reproduce the issue

1. Login to a vanilla Ubuntu 16.04.3 LTS instance.

Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-98-generic x86_64)

2. Ensure latest docker-ce version is installed.

root@ship02:/home/ahazelwood# docker --version
Docker version 17.09.0-ce, build afdb6d4

3. Create a local Dockerfile

root@ship02:/home/ahazelwood# cat Dockerfile
FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
ENTRYPOINT ["/bin/bash"]

4. Run: docker build . -t testah

root@ship02:/home/ahazelwood# docker build . -t testah
Sending build context to Docker daemon  14.34kB
Step 1/3 : FROM microsoft/dotnet:2.0-runtime
 ---> c73382e1bbf7
Step 2/3 : WORKDIR /app
 ---> e7c12683c292
Removing intermediate container 5f02eb55c496
Step 3/3 : ENTRYPOINT /bin/bash
 ---> Running in 31dddb3f96ba
 ---> 61b80806a390
Removing intermediate container 31dddb3f96ba
Successfully built 61b80806a390
Successfully tagged testah:latest

5. Run the container and issue the command dotnet --version

root@ship02:/home/ahazelwood# docker run -it testah
root@bd50671c6ca1:/app# dotnet --version
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

Expected behavior

I would expect the latest version to get printed from the console.

Actual behavior

Error message as stated in point 5 above.

Additional information (e.g. issue happens only occasionally)

I was attempting to create a custom dotnet core console app from my windows machine within a linux container. However, whenever I attempt to run my container with the following docker container, I get the output below.

FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY ./bin /app
ENTRYPOINT ["dotnet", "CI.Processing.ProcessTest.dll"]

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found.
  - Check application dependencies and target a framework version installed at:
      /
  - Alternatively, install the framework version '2.0.0'.

Output of docker version

root@ship02:/home/ahazelwood# docker version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info

root@ship02:/home/ahazelwood# docker info
Containers: 10
 Running: 8
 Paused: 0
 Stopped: 2
Images: 12
Server Version: 17.09.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-98-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 6
Total Memory: 9.732GiB
Name: ship02
ID: XYF3:R35G:JFAH:YC22:OH46:4SQX:6XR3:VJYK:T44D:LKR5:VWZK:7PUE
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

The CLI build for 1876 succeeded but there is no new build triggered in Docker Hub. Hand installing the CLI Debian package (https://dotnetcli.blob.core.windows.net/dotnet/beta/Installers/Latest/dotnet-ubuntu-x64.latest.deb) yields a dotnet --version of 1.0.0-beta-001793 (ie an older version). Possibly there was an issue in the Debian package upload?

Create tag-details.md

Benefits of adding tag-details.md

• Help provide more info on the breakdown of what is in each Docker image
• Help explain the naming conventions behind tag schema
• Other repos use this solution to help new users understand their repo

This is a regression - ef38757#diff-6d015b054fda67c172395b42424cf656R113

The result is the tests are using the incorrect sdk tag in some scenarios.

https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=829537&_a=summary
and
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=829543&_a=summary

The changes made with dotnet/dotnet-docker@d492ac0 should be ported to the nightly README.md

2.1 Dockerfiles should be created

@dagood commented on Tue Jul 18 2017

https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=867429
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=867430
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=868035
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=868041

...Looking for the Shared Framework CLI '2.0.0-preview3-fnl-006787' depends on.
##[error]Failed to update dependencies:
...Response status code does not indicate success: 404 (The specified blob does not exist.).

The CLI dotnet/versions thrashing issue (https://github.com/dotnet/cli/issues/7020) is still alive and making this complicated. Now it's also thrashing between -preview3-fnl- and -preview3-, which is probably much more of a problem than x64 vs x86 legs thrashing.

@MichaelSimons

@dagood commented on Fri Jul 28 2017

@MichaelSimons Is this actionable for FR, or should this be tracked in a Docker github repo?

@MichaelSimons commented on Fri Jul 28 2017

This should be tracked in https://github.com/dotnet/dotnet-docker-nightly (I'll move the issue). The underlying issue is that -fnl- builds don't have associated binaries in the CLI blob storage.

Steps to reproduce the issue

1. Open manifest.json, and navigate to https://github.com/dotnet/dotnet-docker-nightly/blob/master/manifest.json#L76
2. Notice that tag contains $(nanoServerVersion)

Expected behavior

There isn't any customer usage scenario of these images. Hence these images are no longer needed to be built.

Hi.

I'm unable to use this image successfully and I'm not sure if it's just because it's a Work-in-Progress, or if I did something wrong, of if it's an unknown bug.

I get this error message when running dotnet restore on the hello-world project with this docker image (using the one published a few hours ago)
Unable to resolve 'Microsoft.NETCore.App (>= 1.0.0-rc2-3002376)' for '.NETCoreApp,Version=v1.0'

WDYT?

Attaching log

$ docker run -it microsoft/dotnet-preview
root@3e2e4ab17174:/# mkdir hello-world
root@3e2e4ab17174:/# cd hello-world/
root@3e2e4ab17174:/hello-world# dotnet new
Created new C# project in /hello-world.
root@3e2e4ab17174:/hello-world# dotnet restore -v Verbose
trace: Running non-parallel restore.
trace: Reading project file /hello-world/project.json.
log  : Restoring packages for /hello-world/project.json...
trace: Restoring packages for .NETCoreApp,Version=v1.0...
info :   GET https://api.nuget.org/v3-flatcontainer/microsoft.netcore.app/index.json
info :   NotFound https://api.nuget.org/v3-flatcontainer/microsoft.netcore.app/index.json 507ms
trace: Resolving conflicts for .NETCoreApp,Version=v1.0...
error: Unable to resolve 'Microsoft.NETCore.App (>= 1.0.0-rc2-3002376)' for '.NETCoreApp,Version=v1.0'.
info : Committing restore...
log  : Writing lock file to disk. Path: /hello-world/project.lock.json
log  : /hello-world/project.json
log  : Restore failed in 1941ms.

Errors in /hello-world/project.json
    Unable to resolve 'Microsoft.NETCore.App (>= 1.0.0-rc2-3002376)' for '.NETCoreApp,Version=v1.0'.

NuGet Config files used:
    /root/.nuget/NuGet/NuGet.Config

Feeds used:
    https://api.nuget.org/v3/index.json