Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cannot run "dotnet new console" #4605

Closed
MrPaul3 opened this issue Apr 23, 2020 · 16 comments
Closed

cannot run "dotnet new console" #4605

MrPaul3 opened this issue Apr 23, 2020 · 16 comments
Labels
area-tutorials Issues related to getting started tutorials needs-more-info Not enough information has been provided. Please share more detail as requested.

Comments

@MrPaul3
Copy link

MrPaul3 commented Apr 23, 2020

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/create
Operating System: windows

Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.

C:\Users\Rick\Documents\VSCodeNetCoreTest> dotnet new console -o myApp
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download

THIS IS THE ERROR . I HAVE ALREADY INSTALLED .NET CORE SDK COMMANDS BUT THEY ARE STILL SHOWING

@TobiasNils
Copy link

TobiasNils commented Apr 23, 2020

Got the same Problem in toolbox on Linux Fedora Workstation 32 after installing dotnet-sdk-3.1 without errors.
Solved it by:

  1. Looking up the directory the packages should be installed in using dotnet --info:
    Output excerpt:
        Microsoft.AspNetCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
        Microsoft.NETCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]```
    Note that the other packages are in `/usr/lib64/dotnet/shared/`
    
  2. Download the corresponding sdk-versions archive from https://aka.ms/dotnet-download as suggested by the error, extract the archive and find a folder sdkalongside shared
  3. Copy the content of thesdk-folder to respective /path/to/dotnet/sdk

After that, dotnet --info looks like

 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     fedora
 OS Version:  32
 OS Platform: Linux
 RID:         fedora.32-x64
 Base Path:   /usr/lib64/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  3.1.201 [/usr/lib64/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download```

@omajid
Copy link
Member

omajid commented Apr 23, 2020

@TobiasNils something funny is going on here.

Got the same Problem in toolbox on Linux Fedora Workstation 32 after installing dotnet-sdk-3.1 without errors.

Did you install from the Microsoft repository? Fedora 32 includes .NET Core 3.1 in the main Fedora repositories. Installing dotnet-sdk-3.1 using just the plain Fedora repositories should get you everything you need.

Note that the other packages are in /usr/lib64/dotnet/shared/

So that's the Fedora package. It installs to /usr/lib64/dotnet.

Download the corresponding sdk-versions archive from https://aka.ms/dotnet-download as suggested by the error, extract the archive and find a folder sdk alongside shared

That installs the bits built by Microsoft next to the bits built by Fedora. The two things are built differently. They may use different (native) compiler settings. They may be using slightly different verisons of runtime packages. This is something that no one really tests and might blow up at any moment.

I would suggest using either the Microsoft packages for .NET Core, or the Fedora packages for .NET Core. Mixing them is probably not a safe thing to do.

@TobiasNils
Copy link

Good point, thanks for that. I had been following this guide. Installed the microsoft repo and then effectively with installing dotnet-sdk-3.1 I got "everything" but the sdk (also, no templates).

I just setup a new toolbox and went right to installing dotnet-sdk-3.1 and everything works :)
Thanks again!

@mairaw mairaw added area-tutorials Issues related to getting started tutorials needs-more-info Not enough information has been provided. Please share more detail as requested. labels Apr 23, 2020
@mairaw
Copy link
Contributor

mairaw commented Apr 23, 2020

@MrPaul3 can you please paste the output of dotnet --info? I'm wondering if you just installed the runtime but not the SDK.

@TobiasNils
Copy link

TobiasNils commented Apr 23, 2020

I just setup a new toolbox and went right to installing dotnet-sdk-3.1 and everything works :)
Thanks again!

EDIT: I don't know if this is the right place anymore, but in the toolbox container, dotnet run throws this error:

/usr/lib64/dotnet/sdk/3.1.103/NuGet.targets(123,5): error : '32 (Container Image)' is not a valid version string. (Parameter 'value') [/home/nils/WorkSpace/myApp/myApp.csproj]

In the normal fedora shell, after installing from the fedora repositories, the whole tutorial works.

@dagood
Copy link
Member

dagood commented Apr 23, 2020

@TobiasNils you might be hitting #3909. MSBuild passes all env vars in as MSBuild properties, and NuGet doesn't take kindly to a version prop being set.

@omajid
Copy link
Member

omajid commented Apr 23, 2020

We have hit this in Fedora before too: https://pagure.io/dotnet-sig/dotnet-3-0/issue/9. Please feel free to describe how reading in all env vars (including VERSION) and initializing msbuild properties with them is a bad idea at dotnet/msbuild#2713

@TobiasNils
Copy link

It was indeed the VERSION=32 (Container Image) env var set in toolbox, where I had installed the the microsoft repo. Deleting the toolbox and setting up a new one did not clean this up.
unset VERSION inside the (new) toolbox did.
Thanks so much!

omajid added a commit to omajid/dotnet-docs that referenced this issue Apr 24, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooing comments are all specfic to the
  Microsoft repository. I have removed them.
omajid added a commit to omajid/dotnet-docs that referenced this issue Apr 24, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooing comments are all specfic to the
  Microsoft repository. I have removed them.

Fixes: 18038
omajid added a commit to omajid/dotnet-docs that referenced this issue Apr 24, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora 32. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooting comments are all specific to the
  Microsoft repository. I have removed them.

Fixes: 18038
omajid added a commit to omajid/dotnet-docs that referenced this issue Apr 28, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora 32. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooting comments are all specific to the
  Microsoft repository. I have removed them.

Fixes: 18038
omajid added a commit to omajid/dotnet-docs that referenced this issue Apr 28, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora 32. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooting comments are all specific to the
  Microsoft repository. I have removed them.

Fixes: 18038
@zdavidlnx
Copy link

zdavidlnx commented Apr 29, 2020

Same problem here, just after update to Fedora 32.
With Fedora 30/31 I installed MS packages and all works perfect, after upgrade to F32 stop working.
dotnet --info output is:

_It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download

Host (useful for support):
Version: 3.1.3
Commit: 4a9f85e9f8

.NET Core SDKs installed:
No SDKs were found.

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download_

To Solve this, I uninstall all dotnet packages already installed. Then i disable all Microsoft dotnet repos (installed following Net Core web page instructions), then install package dotnet-sdk-3.1.x86_64 from Fedora 32.
Now it works.

dotnet --info ouput it's now:

**SDK de .NET Core (reflejando cualquier global.json):
Version: 3.1.103
Commit: 6f74c4a1dd

Entorno de tiempo de ejecución:
OS Name: fedora
OS Version: 32
OS Platform: Linux
RID: fedora.32-x64
Base Path: /usr/lib64/dotnet/sdk/3.1.103/

Host (useful for support):
Version: 3.1.3
Commit: 4a9f85e9f8

.NET Core SDKs installed:
3.1.103 [/usr/lib64/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.3 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download**

My only doubt is if Fedora will maintain this packages update with future updates or new versions.

Anyway good work , Fedora

@omajid
Copy link
Member

omajid commented Apr 29, 2020

My only doubt is if Fedora will maintain this packages update with future updates or new versions.

Speaking as a fedora maintainer: I am sure we will. We do this for other compilers and runtimes like Clang, GCC, OpenJDK, Python and Ruby. I don't see why .NET Core will be an exception.

Anyway good work , Fedora

Thanks, but this wouldn't been possible without the help of all the amazing dotnet maintainers/developers on github here, especially the https://github.com/dotnet/source-build/ folks.

@zdavidlnx
Copy link

My only doubt is if Fedora will maintain this packages update with future updates or new versions.

Speaking as a fedora maintainer: I am sure we will. We do this for other compilers and runtimes like Clang, GCC, OpenJDK, Python and Ruby. I don't see why .NET Core will be an exception.

Anyway good work , Fedora

Thanks, but this wouldn't been possible without the help of all the amazing dotnet maintainers/developers on github here, especially the https://github.com/dotnet/source-build/ folks.

Wonderfull to hear that!! And yes, thanks too to dotnet team.

Thraka pushed a commit to dotnet/docs that referenced this issue Apr 30, 2020
This is based off the existing instructions for Fedora 31, with a few
changes:

- .NET Core (3.1) packages are part of the default package repositories
  in Fedora 32. No extra repositories need to be enabled to be able to
  install .NET Core 3.1.

- Only 3.1 is available in the Fedora package repositories. So I added a
  comment suggesting users to install other SDK/Runtime versions
  manually. The other versions need to be a manual install because
  mixing dotnet packages from package repositories is a bad idea. For
  example, it might pull down sdk bits built by Microsoft but everything
  else built by Fedora. And that doesn't work:
  dotnet/core#4605

- The package manager troubleshooting comments are all specific to the
  Microsoft repository. I have removed them.

Fixes: 18038
@mairaw
Copy link
Contributor

mairaw commented May 14, 2020

The issue went to a different tangent it seems. I imagine that the Fedora issues are way different than that same error message on Windows.

I'd be inclined to close this issue since we never heard back from the original author of the thread.
@dagood do we still need a tracking issue for Fedora or does the docs issue cover this?

@dagood
Copy link
Member

dagood commented May 14, 2020

Agreed on both counts. The Fedora 32 issue is unrelated to the Windows problem in the original post, and without more info there isn't anything we can do there.

For the Fedora 32 problem, dotnet/docs#18347 has a link back to this thread as an example of a thing we should help with in the Microsoft Fedora 32 docs, and I don't see anything else in this thread that needs more tracking.

@dagood dagood closed this as completed May 14, 2020
@jensechu
Copy link

Just piping in that I am also running into this on Ubuntu 16.04.4 x64. I don't have a global env variable VERSION set.

/usr/share/dotnet/sdk/2.1.806/NuGet.targets(123,5): error : 'N/A' is not a valid version string. [/root/NadekoBot/src/NadekoBot/NadekoBot.csproj]

dotnet info:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.806
 Commit:    a8985a32df

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.806/

Host (useful for support):
  Version: 2.1.18
  Commit:  ba3b934aa4

.NET Core SDKs installed:
  2.1.806 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.18 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.18 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.18 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download```

@dagood
Copy link
Member

dagood commented May 14, 2020

@jensechu can you please get a binlog (http://aka.ms/binlog, so we can diagnose) and open a new issue? More info on that in #4491, which we unfortunately couldn't follow up on because we didn't get diagnostic info. It was similar: NuGet version issue, but unset version didn't help.

@jensechu
Copy link

jensechu commented May 14, 2020

@dagood Sure! I will do this when I wake up tomorrow, sorry. 😄 Thanks for your attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-tutorials Issues related to getting started tutorials needs-more-info Not enough information has been provided. Please share more detail as requested.
Projects
None yet
Development

No branches or pull requests

7 participants