dotnet new on Fedora26 fails to run first time experience

[jkotalik]

Steps to reproduce

1. Install fresh instance of Fedora 26
2. Run steps listed here https://www.microsoft.com/net/core/preview#linuxfedora until dotnet new console -o hwapp

Expected behavior

Dotnet new creates an application with restore succeeding.

Actual behavior

Dotnet new fails to restore, due to the first time experience not being run.

Fix

Instead of placing it in /opt/dotnet, I directly installed it to ~/.dotnet and added .dotnet to my path. I didn't use sudo at all, which I believe caused the issue.

Environment data

dotnet --info output:

[livarcocc]

Can you say what error you are getting? Is the folder where you install dotnet a folder that you have write access to? With your user? That's required for the first run experience to run. Alternatively, you can disable the first run experience entirely and have your packages be downloaded from the web.

[jkotalik]

Here is the error I am getting. I also have write access to the folder with this user (user is an administrator).

[livarcocc]

The problem here is that you are using a non-coherent build. Meaning, that the lzma archive produced by ASP.NET and shipped in the CLI does not contain that version of the package yet.

In that case, just add a NuGet.Config with a feed pointing to <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />. This is a point in time thing and if you go to the CLI page on github, we are actually displaying the version number of the latest coherent build. You can try that as well.

[jkotalik]

This is a coherent build. I just checked preview2 and this process did work on there. The first time experience is not occurring for preview3. I'm going to test on Debian to see if this persists across distros.

[livarcocc]

@johnbeisner can you confirm that build 2.0.0-preview3-006805 is coherent and contains packages for the runtime that ships in the CLI in its offline cache? I wonder if we declared this one coherent due to the bug in ASP.NET.

[jkotalik]

Repro'd with Debian 8. Preview2 worked with this setup while preview3 failed to start the first time experience.

[jkotalik]

I see that in the latest builds you added an error message with recommend steps to fix:

1. Re-run this command with elevated access.
2. Disabled the first run experience by setting the environment variable DOTNET_SKIP_FIRST_TIME_EXPERIENCE to true.
3. Copy the .NET Core SDK to a non-protected location and use it from there.

Just to clarify, why should a user disable the first time run experience if the first time experience wasn't run (why set it true instead of false).