The "Microsoft.AspNetCore.Razor.Tasks.DiscoverDefaultScopedCssItems" task could not be loaded #4360
Comments
filipw
changed the title
|
Is there any file that I can try to modify to get around this issue? Thanks, |
|
Hello? |
|
I tried install from: sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm Issue was still present. |
|
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? |
|
@NTaylorMullen @ryanbrandenburg do you have any ideas what might be causing this? Also, this doesn't seem like an OmniSharp issue to me |
|
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? |
|
Ok, I see now that on the Ubuntu 20.04 LTS dotnet-sdk-5.0 package installation it installed: However, my CentOS 8 only has the following file installed: So it appears that in RHEL/CentOS 8 the following file(s) are missing: ls -la tasks/net46/ |
|
@SteveSandersonMS Given this is in relation to the CSS isolation bits, do you have insight here? |
|
The following resolved the error for me on CentOS 8: 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 How can this be resolved? |
|
@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. |
|
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:
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
.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 |
|
I tried @Kampfmoehre solution above and it worked. The one that fixes it is pointing to The one I was previously pointing to was |
|
@ 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: |
|
I'm facing the same issue, but I'm using Arch Linux, updated to the latest version of .NET 5 today. My output for The following .NET-related packages are installed: Building from command-line runs just fine, leading me to believe this is a problem with Omnisharp itself. This file: 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 Then everything worked just dandy. If anybody wants the files: They can probably be downloaded from somewhere else, but this worked for me. |
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. |
|
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.
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 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: This assigns a higher priority to the Microsoft package repository. Any future 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.
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. |
|
Hello
Thank you so much for the email. I wanted to share a bit more detail
about what I am experiencing. When I launch VSCode in my project
folder, which is a dotnet core project, I see:
And when I click on show, I see:
Failed to load project file '/home/sansari/vscodeprojs/aspnetcorewithau
th/aspnetcorewithauth/aspnetcorewithauth.csproj'.
/home/sansari/vscodeprojs/aspnetcorewithauth/aspnetcorewithauth/aspnetc
orewithauth.csproj
/usr/share/dotnet/sdk/5.0.201/Sdks/Microsoft.NET.Sdk/targets/Microsoft.
NET.Sdk.FrameworkReferenceResolution.targets(326,5): Error: The "Resolv
eTargetingPackAssets" task failed unexpectedly.
System.IO.FileNotFoundException: Could not find file "/usr/share/dotnet
/packs/Microsoft.NETCore.App.Ref/5.0.0/data/FrameworkList.xml"
File name: '/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/5.0.0/dat
a/FrameworkList.xml'
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode
mode, System.IO.FileAccess access, System.IO.FileShare share, System.I
nt32 bufferSize, System.Boolean anonymous, System.IO.FileOptions option
s) [0x0019e] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode
mode, System.IO.FileAccess access, System.IO.FileShare share, System.I
nt32 bufferSize) [0x00000] in <9f0df102fe6e4cfea29d2e46f585d8a5>:0
at (wrapper remoting-invoke-with-
check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.F
ileAccess,System.IO.FileShare,int)
at System.Xml.XmlDownloadManager.GetStream (System.Uri uri, System.Ne
t.ICredentials credentials, System.Net.IWebProxy proxy, System.Net.Cach
e.RequestCachePolicy cachePolicy) [0x00018] in <ffe1f7bdb820468982fbee9
2905c6f3b>:0
at System.Xml.XmlUrlResolver.GetEntity (System.Uri absoluteUri, Syste
m.String role, System.Type ofObjectToReturn) [0x00032] in <ffe1f7bdb820
468982fbee92905c6f3b>:0
at System.Xml.XmlTextReaderImpl.FinishInitUriString () [0x0004c] in <
ffe1f7bdb820468982fbee92905c6f3b>:0
at System.Xml.XmlTextReaderImpl..ctor (System.String uriStr, System.X
ml.XmlReaderSettings settings, System.Xml.XmlParserContext context, Sys
tem.Xml.XmlResolver uriResolver) [0x000c7] in <ffe1f7bdb820468982fbee92
905c6f3b>:0
at System.Xml.XmlReaderSettings.CreateReader (System.String inputUri,
System.Xml.XmlParserContext inputContext) [0x0003b] in <ffe1f7bdb82046
8982fbee92905c6f3b>:0
at System.Xml.XmlReader.Create (System.String inputUri, System.Xml.Xm
lReaderSettings settings, System.Xml.XmlParserContext inputContext) [0x
0000a] in <ffe1f7bdb820468982fbee92905c6f3b>:0
at System.Xml.XmlReader.Create (System.String inputUri, System.Xml.Xm
lReaderSettings settings) [0x00000] in <ffe1f7bdb820468982fbee92905c6f3
b>:0
at System.Xml.Linq.XDocument.Load (System.String uri, System.Xml.Linq
.LoadOptions options) [0x00007] in <9660d2fb40cf46f9864b20fa11035396>:0
at System.Xml.Linq.XDocument.Load (System.String uri) [0x00000] in <9
660d2fb40cf46f9864b20fa11035396>:0
at Microsoft.NET.Build.Tasks.ResolveTargetingPackAssets.AddReferences
FromFrameworkList (System.String frameworkListPath, System.String targe
tingPackRoot, System.String targetingPackDllFolder, Microsoft.Build.Fra
mework.ITaskItem targetingPack, System.Collections.Generic.List`1[T] re
ferenceItems) [0x00000] in <523dde8e2c404b6d82060d6c531ca472>:0
at Microsoft.NET.Build.Tasks.ResolveTargetingPackAssets.ExecuteCore (
) [0x0025a] in <523dde8e2c404b6d82060d6c531ca472>:0
at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x0002e] in <523dde
8e2c404b6d82060d6c531ca472>:0
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.
ITaskExecutionHost.Execute () [0x00029] in <f7274894ce154696afba1f0ffcd
06434>:0
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask (Micro
soft.Build.BackEnd.ITaskExecutionHost taskExecutionHost, Microsoft.Buil
d.BackEnd.Logging.TaskLoggingContext taskLoggingContext, Microsoft.Buil
d.BackEnd.TaskHost taskHost, Microsoft.Build.BackEnd.ItemBucket bucket,
Microsoft.Build.BackEnd.TaskExecutionMode howToExecuteTask) [0x002fc]
in <f7274894ce154696afba1f0ffcd06434>:0
[fail]: OmniSharp.MSBuild.ProjectManager
Attempted to update project that is not loaded: /home/sansari/v
scodeprojs/aspnetcorewithauth/aspnetcorewithauth/aspnetcorewithauth.csp
roj
I will review the content you provided, and greatly appreciate it. If
you have any other advice, please do let me know. This project was
working fine before I applied the latest update. I did see dotnet in
the list, but the gui window did not have a way to select the updates.
Here are the dotnet libraries I am aware of on my system as of now:
***@***.*** aspnetcorewithauth]$ dotnet --list-sdks
3.1.407 [/usr/share/dotnet/sdk]
5.0.201 [/usr/share/dotnet/sdk]
***@***.*** aspnetcorewithauth]$ dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.13
[/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.13
[/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4
[/usr/share/dotnet/shared/Microsoft.NETCore.App]
I just removed all of them with "sudo dnf remove dotnet*" and, issued:
"sudo dnf install dotnet-sdk-5.0.x86_64 dotnet-sdk-3.1.x86_64 --repo
packages-microsoft-com-prod", then I issued the command you provided
below. I do not seem to get the error any more. I am going to do an
update later and see if things will continue to work for me.
Regards-
Shahin
…On Thu, 2021-03-18 at 11:54 -0700, Omair Majid wrote:
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.
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.
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I just validated, and my project seems to be working. I also updated my
packages, and everythting seems to be running smoothly.
Thanks
…On Thu, 2021-03-18 at 11:54 -0700, Omair Majid wrote:
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.
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.
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Had the same issue on Fedora 33 as long as dotnet incompatibilities due to fedora/microsoft package differences. Solved it with:
After that mvc project rebuilding and C# for Visual Studio Code/OmniSharp v1.23.9 worked smoothly. |
|
For a Blazor WASM project (SDK @ v5.0.104) on Fedora 34, @mausworks your solution worked. Thanks a bunch! |
|
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. Finally I managed to make it all work again by installing the missing dependency ( 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. |
|
This does not work for me. Using Fedora 34. This is what I did:
Output of the install command is here: https://gist.github.com/m-ghaoui/8445541ce93fb68fcec60293abffe30a When I try to do something like It says the SDK is not installed: Looking up the command: 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. |
Between steps 3 and 4, can you run More details and options are documented as "Solution 3" at https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-mixup#solutions |
... does not seem to help (?) |
|
Maybe I can help with the logs produced by Omnisharp: I tried this solution but sadly `dotnet --info Host (useful for support): .NET SDKs installed: .NET runtimes installed: To install additional .NET runtimes or SDKs: EDIT: |
You're a total boss! Thank you so much! |
|
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 |
|
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 |
Thanks for raising this. I followed your steps and I see the same problem on my end. It looks like Microsoft's .NET 5 runtime has broken dependencies ( I think the problem will not happen if you install |
|
@mausworks solution works perfectly. My sdk version: dotnet core 5.0.204 |
|
@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. |
Hahah, worked!! Thank you! |
|
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: |
|
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? |
|
@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.
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 |
|
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. |
|
Completely forgot about this. |
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
The text was updated successfully, but these errors were encountered: