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

The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded #4360

Open
michaelbarkdoll opened this issue Jan 22, 2021 · 37 comments

Comments

@michaelbarkdoll
Copy link

Hi, just updated dotnet to 5.0.102 and now the follow error occurs loading this extension:
fail: OmniSharp.MSBuild.ProjectLoader
The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded from the assembly /usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/../../tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll. Invalid Image Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Any help fixing the issue is appreciated.

OmniSharp log

Starting OmniSharp server at 1/22/2021, 12:05:48 PM
Target: /home/cisadmin/sample-dotnet-projec1/test

OmniSharp server started.
Path: /home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/run
PID: 64366

Starting OmniSharp on centos 8.0 (x64)
info: OmniSharp.Services.DotNetCliService
DotNetPath set to dotnet
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 1 MSBuild instance(s)
1: StandAlone 16.8.0 - "/home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild/Current/Bin"
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
MSBUILD_EXE_PATH environment variable set to '/home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild/Current/Bin/MSBuild.exe'
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Registered MSBuild instance: StandAlone 16.8.0 - "/home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild/Current/Bin"
CscToolExe = csc.exe
MSBuildToolsPath = /home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild/Current/Bin
CscToolPath = /home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild/Current/Bin/Roslyn
BypassFrameworkInstallChecks = true
MSBuildExtensionsPath = /home/cisadmin/.vscode/extensions/ms-dotnettools.csharp-1.23.8/.omnisharp/1.37.5/omnisharp/.msbuild
info: OmniSharp.Cake.CakeProjectSystem
Detecting Cake files in '/home/cisadmin/sample-dotnet-projec1/test'.
info: OmniSharp.Cake.CakeProjectSystem
Could not find any Cake files
info: OmniSharp.MSBuild.ProjectSystem
No solution files found in '/home/cisadmin/sample-dotnet-projec1/test'
info: OmniSharp.MSBuild.ProjectManager
Queue project update for '/home/cisadmin/sample-dotnet-projec1/test/test.csproj'
info: OmniSharp.Script.ScriptProjectSystem
Detecting CSX files in '/home/cisadmin/sample-dotnet-projec1/test'.
info: OmniSharp.Script.ScriptProjectSystem
Could not find any CSX files
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.Completion.CompletionOptionsProvider, Order: 0
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.RenameWorkspaceOptionsProvider, Order: 100
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.ImplementTypeWorkspaceOptionsProvider, Order: 110
info: OmniSharp.WorkspaceInitializer
Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.BlockStructureWorkspaceOptionsProvider, Order: 140
info: OmniSharp.WorkspaceInitializer
Configuration finished.
info: OmniSharp.MSBuild.ProjectManager
Loading project: /home/cisadmin/sample-dotnet-projec1/test/test.csproj
info: OmniSharp.Stdio.Host
Omnisharp server running using Stdio at location '/home/cisadmin/sample-dotnet-projec1/test' on host 64206.
fail: OmniSharp.MSBuild.ProjectLoader
The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded from the assembly /usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/../../tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll. Invalid Image Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
[warn]: OmniSharp.MSBuild.ProjectManager
Failed to load project file '/home/cisadmin/sample-dotnet-projec1/test/test.csproj'.
/home/cisadmin/sample-dotnet-projec1/test/test.csproj
/usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.ScopedCss.targets(118,3): Error: The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded from the assembly /usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/../../tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll. Invalid Image Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Attempted to update project that is not loaded: /home/cisadmin/sample-dotnet-projec1/test/test.csproj

Steps to reproduce

dotnet new webapi -n test
code .

Expected behavior

C# extension would load

Actual behavior

C# extension fails to load

VS Code version:
1.52.1

C# Extension version:
1.23.8

Please paste the output from your clipboard$ dotnet --info
.NET SDK (reflecting any global.json):
Version: 5.0.102
Commit: 71365b4d42

Runtime Environment:
OS Name: centos
OS Version: 8
OS Platform: Linux
RID: centos.8-x64
Base Path: /usr/lib64/dotnet/sdk/5.0.102/

Host (useful for support):
Version: 5.0.2
Commit: cb5f173b96

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

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

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

@filipw filipw added the Razor label Jan 24, 2021
@filipw filipw changed the title [fail]: OmniSharp.MSBuild.ProjectLoader The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded Jan 24, 2021
@michaelbarkdoll
Copy link
Author

Is there any file that I can try to modify to get around this issue? Thanks,

@michaelbarkdoll
Copy link
Author

Hello?

@michaelbarkdoll
Copy link
Author

I tried install from:

sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm
yum install dotnet-sdk-5.0

Issue was still present.

@michaelbarkdoll
Copy link
Author

Tried v1.23.9-beta2 this morning. Error exists there as well. Where do I find instructions on compiling the source code into .vsix to diagnosis this further?

@filipw
Copy link
Contributor

filipw commented Jan 28, 2021

@NTaylorMullen @ryanbrandenburg do you have any ideas what might be causing this? Also, this doesn't seem like an OmniSharp issue to me

@michaelbarkdoll
Copy link
Author

michaelbarkdoll commented Jan 28, 2021

I'm thinking the issue is with the actual dotnet-sdk installation since once it was upgraded the issue started to occur. I tried to isolate the issue a bit further by installing a new development environment on Ubuntu 20.04 LTS and setup a "Remote - SSH" to it from RHEL 8. I was able to install the C# extension on the remote visual code ssh connection without the same error. Who maintains the dotnet-sdk-5.0 rpm package RHEL or Microsoft? Should I open a issue about this inside the larger dotnet/sdk projec or is it a VS Code issue?

@michaelbarkdoll
Copy link
Author

Ok, I see now that on the Ubuntu 20.04 LTS dotnet-sdk-5.0 package installation it installed:
/usr/share/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll
/usr/share/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/tasks/net5.0/Microsoft.NET.Sdk.Razor.Tasks.dll

However, my CentOS 8 only has the following file installed:
/usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/tasks/net5.0/Microsoft.NET.Sdk.Razor.Tasks.dll

So it appears that in RHEL/CentOS 8 the following file(s) are missing:
/usr/lib64/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk.Razor/tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll

ls -la tasks/net46/
-rw-r--r-- 1 root root 77192 Dec 14 20:17 Microsoft.NET.Sdk.Razor.Tasks.dll
-rw-r--r-- 1 root root 189832 Dec 14 20:17 System.Collections.Immutable.dll
-rw-r--r-- 1 root root 464776 Dec 14 20:17 System.Reflection.Metadata.dll

@NTaylorMullen
Copy link
Contributor

@SteveSandersonMS Given this is in relation to the CSS isolation bits, do you have insight here?

@michaelbarkdoll
Copy link
Author

The following resolved the error for me on CentOS 8:
sudo yum remove dotnet-sdk

sudo yum install dotnet-sdk-5.0-5.0.101-1 aspnetcore-runtime-5.0-5.0.1-1 aspnetcore-targeting-pack-5.0-5.0.0-1 dotnet-apphost-pack-5.0-5.0.1-1 dotnet-host-5.0.1-1 dotnet-hostfxr-5.0-5.0.1-1 dotnet-runtime-5.0-5.0.1-1 dotnet-targeting-pack-5.0-5.0.0-1

Appears some things moved around on the reinstall in terms of file location for the Microsoft.NET.Sdk.Razor.Tasks.dll:

/usr/share/dotnet/sdk/5.0.101/Sdks/Microsoft.NET.Sdk.Razor/tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll
/usr/share/dotnet/sdk/5.0.101/Sdks/Microsoft.NET.Sdk.Razor/tasks/net5.0/Microsoft.NET.Sdk.Razor.Tasks.dll

How can this be resolved?

@SteveSandersonMS
Copy link
Member

@NTaylorMullen Looks like an issue in the SDK packaging, if it can be fixed by moving assembly files around. It seems like the CSS isolation task just happens to be the first thing it's trying to load.

@Kampfmoehre
Copy link

Kampfmoehre commented Feb 15, 2021

I had a problem with dotnet/sdk#15863 and completely removed all dotnet packages, disabled the MS prod repo and installad dotnet-sdk-3.1 and dotnet-sdk-5.0 again. With dotnet 5.0.102 I now have the same problem loading a Blazor Server project. Is there anything I can install/change to make this work again until this is fixed?

Edit: I am running Fedora 33

Edit 2: I resolved the problem by again removing all packages and install the SDKs again - this time using the microsoft prod repo:

  • sudo dnf remove dotnet*
  • sudo dnf install dotnet-sdk-5.0.x86_64 dotnet-sdk-3.1.x86_64 --repo packages-microsoft-com-prod

I am using Fedora 33 and the sdk is provided by Fedora Update Repo too. It seems one SDK was installed via updates and one via ms prod repo and this is causing many problems. After removing all dotnet packages and install the SDKs again now Omnisharp seems to work without any error messages.

dotnet --info output:

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:    9effbc8ad5

Runtime Environment:
 OS Name:     fedora
 OS Version:  33
 OS Platform: Linux
 RID:         fedora.33-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.103/

Host (useful for support):
  Version: 5.0.3
  Commit:  eae88cc11b

.NET SDKs installed:
  3.1.406 [/usr/share/dotnet/sdk]
  5.0.103 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

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

@germ13
Copy link

germ13 commented Mar 2, 2021

I tried @Kampfmoehre solution above and it worked.
It seems there are two different microsoft repos for dotnetcore that one can install from in Fedora:

The one that fixes it is pointing to baseurl=https://packages.microsoft.com/fedora/33/prod/

The one I was previously pointing to was baseurl=https://packages.microsoft.com/rhel/7/prod/

@bitflame
Copy link

bitflame commented Mar 4, 2021

@ Kampfmoehre Just had to say thank you. Your solution worked for me. I am using Fedora 33 also, and I also had to install compat-openssl10 package. That one I had to get from the default repository so:
sudo dnf install compat-openssl10
is the command that worked for me.

@mausworks
Copy link

mausworks commented Mar 17, 2021

I'm facing the same issue, but I'm using Arch Linux, updated to the latest version of .NET 5 today. My output for dotnet --info is very similar to that of @Kampfmoehre

.NET SDK (reflecting any global.json):
 Version:   5.0.104
 Commit:    ca6b6acadb

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.104/

Host (useful for support):
  Version: 5.0.4
  Commit:  269e323b5f

.NET SDKs installed:
  3.1.112 [/usr/share/dotnet/sdk]
  5.0.104 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

The following .NET-related packages are installed:

aspnet-runtime              5.0.4.sdk104-1
aspnet-runtime-3.1          3.1.12.sdk112-3
aspnet-targeting-pack       5.0.4.sdk104-1
aspnet-targeting-pack-3.1   3.1.12.sdk112-3
dotnet-host                 5.0.4.sdk104-1
dotnet-runtime              5.0.4.sdk104-1
dotnet-runtime-3.1          3.1.12.sdk112-3
dotnet-sdk                  5.0.4.sdk104-1
dotnet-sdk-3.1              3.1.12.sdk112-3
dotnet-targeting-pack       5.0.4.sdk104-1
dotnet-targeting-pack-3.1   3.1.12.sdk112-3

Building from command-line runs just fine, leading me to believe this is a problem with Omnisharp itself.

This file:

/usr/share/dotnet/sdk/5.0.104/Sdks/Microsoft.NET.Sdk.Razor/tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll

Is indeed missing. This seems to be fixed in a later release of the SDK (5.0.201 for example).

EDIT: I fixed it by having my colleague send over his net46 folder from Microsoft.NET.Sdk.Razor/tasks, he's running the 5.0.201 SDK, but it still seems to work just fine. I simply unzipped it in:

/usr/share/dotnet/sdk/5.0.104/Sdks/Microsoft.NET.Sdk.Razor/tasks

Then everything worked just dandy. If anybody wants the files:

net46.zip

They can probably be downloaded from somewhere else, but this worked for me.

@bitflame
Copy link

I am using Fedora 33 and the sdk is provided by Fedora Update Repo too. It seems one SDK was installed via updates and one via ms prod repo and this is causing many problems. After removing all dotnet packages and install the SDKs again now Omnisharp seems to work without any error messages.

Do you find that every time you update Fedora the problem resurfaces? I know I need to learn how to selectively update my system. I wonder if we can report this to the Fedora packages, and asked to be fixed.

@omajid
Copy link
Member

omajid commented Mar 18, 2021

Hi, I am one of the developers involved in building .NET from source (source-build) as well as one of the maintainers packaging .NET in Fedora.

Do you find that every time you update Fedora the problem resurfaces? I know I need to learn how to selectively update my system.

I am not surprised. When two package repositories provide packages with same names, the one with the higher version gets installed. And it's hard to be sure what happens if they are at the same version. So it's possible you get a .NET SDK from the Microsoft package repository and a .NET host from the Fedora package repository. Mixing them doesn't work.

If you know you always want to use the Microsoft packages (or always want to use the Fedora packages) you can make use of repo priorities. Basically, you can give a package repository a higher priority and dnf/yum will always pick the package from there if multiple repositories provide it.

For example, if you always want to use the packages from the Microsoft repository, you can use this command once you have installed the Microsoft package repository:

sudo dnf config-manager --save --setopt="*microsoft-*.priority=50"

This assigns a higher priority to the Microsoft package repository. Any future yum/dnf commands will prefer to use packages from there once you run this command.

I wrote up more detail about it here: dotnet/runtime#47500 (comment)

Obviously, we would love it if the packages provided by Fedora worked out of the box for you and you didn't need extra packages from elsewhere, but this sort of workaround might save you some hassle while we fix the underlying issues.

I wonder if we can report this to the Fedora packages, and asked to be fixed.

Sure, please feel free to file bugs and report any issues you run into!

FWIW, we are tracking the issue here as well as dotnet/source-build#2006.

@bitflame
Copy link

bitflame commented Mar 18, 2021 via email

@bitflame
Copy link

bitflame commented Mar 18, 2021 via email

@ChristosMylonas
Copy link

Had the same issue on Fedora 33 as long as dotnet incompatibilities due to fedora/microsoft package differences.

Solved it with:

  • sudo dnf remove dotnet* remove all prior versions
  • sudo dnf clean all to clean up all package cache
  • sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc to reimport keys (optional)
  • sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/33/prod.repo to get ms repository
  • sudo dnf config-manager --save --setopt="*microsoft-*.priority=50" to raise ms package priority
  • sudo dnf install dotnet-sdk-5.0.x86_64 to install
  • DOTNET_ROOT=/usr/share/dotnet to set env (otherwise get libhostfxr.so missing errors).

After that mvc project rebuilding and C# for Visual Studio Code/OmniSharp v1.23.9 worked smoothly.

NET SDK (reflecting any global.json):
 Version:   5.0.202
 Commit:    db7cc87d51

Runtime Environment:
 OS Name:     fedora
 OS Version:  33
 OS Platform: Linux
 RID:         fedora.33-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.202/

Host (useful for support):
  Version: 5.0.5
  Commit:  2f740adc14

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

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

@deleepa
Copy link

deleepa commented Apr 17, 2021

For a Blazor WASM project (SDK @ v5.0.104) on Fedora 34, @mausworks your solution worked. Thanks a bunch!

@Kampfmoehre
Copy link

Just for info, I upgraded to Fedora 34 and the problems start once again. Omnisharp was not working and was throwing errors again.

I tried some things like updating the microsoft repo to 34 but that does not seem to contain dotnet-sdk-5.0 yet. Meanwhile the packages from the old microsoft 33 repo were no longer able to install (I removed them unfortunately) because they depend on a package that is not (yet) available for Fedora 34.
So I tried install dotnet only from Fedora repo which works kind of (at least at the command line) but Omnisharp is throwing errors again and is not working at all.

Finally I managed to make it all work again by installing the missing dependency (compat-openssl10). To make this work I copied the first block from /etc/yum.repos.d/fedora.repo to a new file /etc/yum.repos.d/fedora33.repo and replaced $releasevar with 33. At the end it looks like this:

[fedora33]
name=Fedora 33 - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-33&arch=$basearch
enabled=1
countme=1
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$basearch
skip_if_unavailable=False
exclude=dotnet-targeting-pack-3.1 netstandard-targeting-pack-2.1
priority=250

Don't forget to change the name in the block (I appended 33) else dnf will complain about two repo configs with the same name. I also set the priority to some high value (default is 99) so packages are not installed from it when they occur somewhere else (dnf priority is kind of reversed and looks at the lowest value first).

Now I was able to install the compact-openssl10 and also dotnet-sdk-5.0 from microsoft repo and now everything is working without complains again.

Once the tool becomes available in Fedora 34 I will delete the extra config and when dotnet-sdk-5.0 is available in https://packages.microsoft.com/fedora/34/prod/ I will update the microsoft repo.

@m-ghaoui
Copy link

m-ghaoui commented Jun 19, 2021

This does not work for me. Using Fedora 34.

This is what I did:

  1. sudo dnf remove dotnet*
  2. sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/34/prod.repo <-- Note I changed it to 34
  3. sudo dnf config-manager --save --setopt="*microsoft-*.priority=50"
  4. sudo dnf install dotnet-sdk-5.0.x86_64 dotnet-sdk-3.1.x86_64

Output of the install command is here: https://gist.github.com/m-ghaoui/8445541ce93fb68fcec60293abffe30a

When I try to do something like dotnet new

$ dotnet new
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application 'new' does not exist.
  * You intended to execute a .NET SDK command:
      It was not possible to find any installed .NET SDKs.
      Install a .NET SDK from:
        https://aka.ms/dotnet-download

It says the SDK is not installed:

$ dotnet --info

Host (useful for support):
  Version: 5.0.7
  Commit:  556582d964

.NET SDKs installed:
  No SDKs were found.

.NET runtimes installed:
  Microsoft.NETCore.App 3.1.16 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.7 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

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

Looking up the command:

$which dotnet
/usr/bin/dotnet
$ ls -sla /usr/bin/dotnet
4 lrwxrwxrwx. 1 root root 30 Jun 10 22:01 /usr/bin/dotnet -> ../..//usr/lib64/dotnet/dotnet

Am I using the correct executable?

I tried again but with the Fedora 33 repos. No dice.

@PCC17
Copy link

PCC17 commented Jun 19, 2021

This does not work for me. Using Fedora 34.

This is what I did:

  1. sudo dnf remove dotnet*
  2. sudo wget -O /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/34/prod.repo <-- Note I changed it to 34
  3. sudo dnf config-manager --save --setopt="*microsoft-*.priority=50"
  4. sudo dnf install dotnet-sdk-5.0.x86_64 dotnet-sdk-3.1.x86_64

Output of the install command is here: https://gist.github.com/m-ghaoui/8445541ce93fb68fcec60293abffe30a

When I try to do something like dotnet new

$ dotnet new
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
  * You intended to execute a .NET program:
      The application 'new' does not exist.
  * You intended to execute a .NET SDK command:
      It was not possible to find any installed .NET SDKs.
      Install a .NET SDK from:
        https://aka.ms/dotnet-download

It says the SDK is not installed:

$ dotnet --info

Host (useful for support):
  Version: 5.0.7
  Commit:  556582d964

.NET SDKs installed:
  No SDKs were found.

.NET runtimes installed:
  Microsoft.NETCore.App 3.1.16 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.7 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

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

Looking up the command:

$which dotnet
/usr/bin/dotnet
$ ls -sla /usr/bin/dotnet
4 lrwxrwxrwx. 1 root root 30 Jun 10 22:01 /usr/bin/dotnet -> ../..//usr/lib64/dotnet/dotnet

Am I using the correct executable?

I tried again but with the Fedora 33 repos. No dice.

You're doing nothing wrong im struggling with the same problem.
I hope someone will resolve this issue asap because it really slows down my development process

@omajid
Copy link
Member

omajid commented Jun 19, 2021

@m-ghaoui

This does not work for me. Using Fedora 34.

Between steps 3 and 4, can you run

sudo dnf remove 'dotnet*' 'aspnet*' 'netstandard*'

More details and options are documented as "Solution 3" at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-mixup#solutions

@m-ghaoui
Copy link

m-ghaoui commented Jun 19, 2021

@omajid

sudo dnf remove 'dotnet*' 'aspnet*' 'netstandard*'
$sudo dnf remove 'dotnet*' 'aspnet*' 'netstandard*'
No match for argument: dotnet*
No match for argument: aspnet*
No match for argument: netstandard*
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!

... does not seem to help (?)

@PCC17
Copy link

PCC17 commented Jun 20, 2021

Maybe I can help with the logs produced by Omnisharp:
The reason for my error is the following:
[fail]: OmniSharp.MSBuild.ProjectLoader The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded from the assembly /usr/lib64/dotnet/sdk/5.0.204/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/../../tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll. Invalid Image Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask

I tried this solution but sadly dotnet --info does not show any installed SDKs as @m-ghaoui has already reported.

`dotnet --info

Host (useful for support):
Version: 5.0.7
Commit: 556582d964

.NET SDKs installed:
No SDKs were found.

.NET runtimes installed:
Microsoft.NETCore.App 3.1.16 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.7 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

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

EDIT:
This solved my issue.
Although I had copy it into this folder: /usr/lib64/dotnet/sdk/5.0.204/Sdks/Microsoft.NET.Sdk.Razor/tasks

@n1ghtmare
Copy link

I'm facing the same issue, but I'm using Arch Linux, updated to the latest version of .NET 5 today. My output for dotnet --info is very similar to that of @Kampfmoehre

.NET SDK (reflecting any global.json):
 Version:   5.0.104
 Commit:    ca6b6acadb

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.104/

Host (useful for support):
  Version: 5.0.4
  Commit:  269e323b5f

.NET SDKs installed:
  3.1.112 [/usr/share/dotnet/sdk]
  5.0.104 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

The following .NET-related packages are installed:

aspnet-runtime              5.0.4.sdk104-1
aspnet-runtime-3.1          3.1.12.sdk112-3
aspnet-targeting-pack       5.0.4.sdk104-1
aspnet-targeting-pack-3.1   3.1.12.sdk112-3
dotnet-host                 5.0.4.sdk104-1
dotnet-runtime              5.0.4.sdk104-1
dotnet-runtime-3.1          3.1.12.sdk112-3
dotnet-sdk                  5.0.4.sdk104-1
dotnet-sdk-3.1              3.1.12.sdk112-3
dotnet-targeting-pack       5.0.4.sdk104-1
dotnet-targeting-pack-3.1   3.1.12.sdk112-3

Building from command-line runs just fine, leading me to believe this is a problem with Omnisharp itself.

This file:

/usr/share/dotnet/sdk/5.0.104/Sdks/Microsoft.NET.Sdk.Razor/tasks/net46/Microsoft.NET.Sdk.Razor.Tasks.dll

Is indeed missing. This seems to be fixed in a later release of the SDK (5.0.201 for example).

EDIT: I fixed it by having my colleague send over his net46 folder from Microsoft.NET.Sdk.Razor/tasks, he's running the 5.0.201 SDK, but it still seems to work just fine. I simply unzipped it in:

/usr/share/dotnet/sdk/5.0.104/Sdks/Microsoft.NET.Sdk.Razor/tasks

Then everything worked just dandy. If anybody wants the files:

net46.zip

They can probably be downloaded from somewhere else, but this worked for me.

You're a total boss! Thank you so much!

@JoeRobich
Copy link
Member

Another option for those on Arch is to install the dotnet-sdk-bin package instead of the dotnet-sdk package. see https://github.com/OmniSharp/omnisharp-vscode/wiki/Configuring-Arch-Linux-for-Razor-development

@omajid
Copy link
Member

omajid commented Jun 22, 2021

There's a fix in source-build now, so distributions like Arch, Fedora and RHEL should be getting a fix in the next .NET 5 release (probably next month): dotnet/source-build#2178

@omajid
Copy link
Member

omajid commented Jun 22, 2021

@m-ghaoui

This does not work for me. Using Fedora 34.

Thanks for raising this. I followed your steps and I see the same problem on my end. dnf install dotnet-runtime-5.0 gives a hint:

Last metadata expiration check: 0:07:12 ago on Tue Jun 22 21:00:06 2021.
Dependencies resolved.

 Problem: package dotnet-runtime-5.0-5.0.7-1.x86_64 requires dotnet-runtime-deps-5.0 >= 5.0.7, but none of the providers can be installed
  - cannot install the best candidate for the job
  - nothing provides compat-openssl10 needed by dotnet-runtime-deps-5.0-5.0.7-1.x86_64
======================================================================================================================
 Package                          Architecture    Version                  Repository                            Size
======================================================================================================================
Installing:
 dotnet-runtime-5.0               x86_64          5.0.7-1.fc34             updates                               26 M
Installing dependencies:
 dotnet-host                      x86_64          5.0.7-1.fc34             updates                              104 k
 dotnet-hostfxr-5.0               x86_64          5.0.7-1.fc34             updates                              152 k
 libicu                           x86_64          67.1-6.fc34              fedora                               9.7 M
 libunwind                        x86_64          1.4.0-5.fc34             fedora                                65 k
 lttng-ust                        x86_64          2.12.0-4.fc34            fedora                               289 k
 numactl-libs                     x86_64          2.0.14-3.fc34            fedora                                30 k
 userspace-rcu                    x86_64          0.12.1-3.fc34            fedora                               105 k
Skipping packages with broken dependencies:
 dotnet-runtime-5.0               x86_64          5.0.7-1                  packages-microsoft-com-prod           29 M
 dotnet-runtime-deps-5.0          x86_64          5.0.7-1                  packages-microsoft-com-prod          2.8 k

It looks like Microsoft's .NET 5 runtime has broken dependencies (compat-openss10 was EOL'ed before Fedora 34). And that makes dnf install some packages from the Microsoft repo and some from the Fedora repo, leading to the issues described at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-mixup.

I think the problem will not happen if you install compat-openssl10 on Fedora 33 and then use the same steps you did here.

@shabbyk
Copy link

shabbyk commented Jul 24, 2021

@mausworks solution works perfectly.

My sdk version: dotnet core 5.0.204
OS: Frdora 34, kernel 5.12.17-300.fc34.x86_64

@omajid
Copy link
Member

omajid commented Jul 30, 2021

@crummel fixed this via dotnet/source-build#2178 (thanks, @crummel!) and it is included in the latest release https://github.com/dotnet/source-build/releases/tag/v5.0.205-SDK.

This was built and released as an update for CentOS 8, Fedora 33 and later, and RHEL 8 a few days ago.

Is anyone still seeing this issue? If not, I think this issue can be closed now.

@sametoz
Copy link

sametoz commented Aug 8, 2021

Then everything worked just dandy. If anybody wants the files:

net46.zip

They can probably be downloaded from somewhere else, but this worked for me.

Hahah, worked!! Thank you!

@m-ghaoui
Copy link

Hi,

I just reinstalled Fedora 34 and installed the latest dotnet SDK and VS Code, and everything seems to be working fine for me.

For completeness sake, here is my dotnet info:

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.205
 Commit:    64a0cf25eb

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

Host (useful for support):
  Version: 5.0.8
  Commit:  35964c9215

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

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

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

@crummel
Copy link

crummel commented Oct 19, 2021

According to dotnet/announcements#190, net46 support has been dropped from the official runtime build. Source-build's patch is now a workaround that is not guaranteed to continue to work. Has there been any progress on updating Omnisharp to use .NET Core TFMs?

@JoeRobich
Copy link
Member

@crummel OmniSharp does not have a requirement for net46 specifically, the target files that ship in the NET SDK reference Full Framework versions of the assemblies when running on Full Framework MSBuild. It just happened in the scenarios above that the SDK was shipping net46 Full Framework assemblies for these scenarios. I would assume they have migrated to a newer TFMs.

Has there been any progress on updating Omnisharp to use .NET Core TFMs?

OmniSharp-Roslyn does have a branch where it has moved the language server to run on NET 5. We would need resourcing and a desire to break some Full Framework scenarios to get this build stable and to move the extension to run on top of it.

cc: @pavelhorak, @vzarytovskii

@Meligy
Copy link

Meligy commented Nov 14, 2021

Sounds like on a Mac for example this would be a problem when you have the setting:

"omnisharp.useGlobalMono": "never"

Which otherwise sounds like a good option to avoid machine-specific issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests