We Keep Coding

ASP.NET Core 6 Error: InvalidOperationException: A descriptor for '/Pages/Error.cshtml' was not found

I am new to ASP.NET Core 6 Web Applications. I am encountering a problem when I run my web application for first time.
I receive this error:
InvalidOperationException: A descriptor for '/Pages/Error.cshtml' was not found.
I need help to solve this issue.

There is a GitHub issue related to this error message, although the specifics of that particular case will be different. In it, contributor #pranavkm offers the following guidance:
The app references a 6.0 runtime and a 3.1 version of Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation (transitively via https://www.nuget.org/packages/Volo.Abp.AspNetCore.Mvc/1.1.2). We recently made a behavior change to Mvc which requires a compatible (6.0 versioned) runtime compilation when that feature is used. Adding a package reference to the 6.0 version gets you past that issue.
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="6.0.0-preview.2.21101.10" />
Mixing package versions (using 3.x or 5.x versioned package with the 6.0 runtime) isn't necessarily always going to work. We anticipate users to update their packages as part of the migration. I can run this by more people in the dev team, but it's unlikely that we will do any additional work here.
Now, obviously, you probably aren't using Volo.Abp—and, by extension, may not be using Razor Runtime Compilation. As a result, the source of your specific error is likely different. But the cause of your error should be the same: One of your dependencies maintains a reference to a legacy 3.x or 5.x package with incompatible code.
By evaluating your stack trace, you should be able to identify the specific culprit—and, hopefully, the developer has included an updated version of their package by now.
If it's due to a downstream dependency, as in the above example, you will need to drill down in the dependency graph on NuGet to find the offending package that relies on the 3.x or 5.x runtime. If that's the case, hopefully there is a newer compatible version, and then you can establish an explicit dependency to the upgraded version via NuGet.
If there isn't a newer compatible version of the offending package, you'll need to contact the vendor, and/or wait for them to release an update for .NET 6.

My solution was to change the target framework from net6 to net5, because it seems like the VS2019 probably unable to run the net6.0 application.

I had the same error and, after a package version wild goose chase, realised the page in question was excluded from my project:
This was fine until I moved over to VS 2022 for the .net 6 upgrade, and when I deleted the excluded files everything worked fine.
So I suppose that it was an issue with VS 2022 - unless someone can explain to me why it is legitimate for VS2022 to try to serve a page that is excluded from the project (when VS 2019 did not).

error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild

I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?

https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.

Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao

I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.

I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE

I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)

Azure Function Adding Reference to Sharepoint.dll Failing

I am getting an error when I attempt to add a reference to the Microsoft.Sharepoint.dll into my Azure function class. It keeps giving me the following error:
Package Sharepoint 15.0.0 is not compatible with net462 (.NetFramework, Version=v4.6.2). Package Sharepoint 15.0.0 supports microsoftsharepoint (Microsoft.SharePoint,version=v0.0).
Also the Microsoft.Sharepoint.Client.Runtime has a similar issue.
Given this I have followed other advice to switch the targeting framework to 4 and 4.5 but all of these seem to fail similarly. What is the supported framework for this and how can I add it into an azure function. Also I am dealing with an on-prem instance of sharepoint so I cannot connect via the online apis.

The Microsoft.Sharepoint.dll have no dependencies so, it it no matter with framework. I test in my site and could install it correctly.
You could try to use the Package Manager console in Visual Studio to install instead of the Manager Packages tool for the project.
And if you use Manage Nuget Packages, delete Nuget's cache from the packages' manager configuration.

How do I install System.Drawing.Common in a project that uses '.NETFramework,Version=v4.5.2'?

I am trying to write some unit tests in C# in a '.NETFramework,Version=v4.5.2' application but all tests give the next error:
'System.IO.FileNotFoundException : Could not load file or assembly
'System.Drawing.Common, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file
specified.'
When I try to install System.Drawing.Common I get the next error from the NuGet package:
Could not install package 'System.Drawing.Common 4.5.1'. You are trying to install this package into a project that targets
'.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more
information, contact the package author.
I cannot change the application version or the framework (.NET Core 2.1) and any other trick I found online did not work (or generated more errors).
Help?

in NuGet put this line :
Install-Package System.Drawing.Common -Version 4.5.2
in .NET CLI put :
dotnet add package System.Drawing.Common --version 4.5.2
in Paket CLI put :
paket add System.Drawing.Common --version 4.5.2

Had the same problem. I have cloned solution https://github.com/barnhill/barcodelib . It has two projects: library project targets .Net Standard 2.0 and refers to System.Drawings.Common. Example project depends on library and has reference to System.Drawings.Common. Example project was not compiling due to same error.
My solution was just to remove reference to System.Drawings.Common in nuget packages and readd it (rclick on Example project > Manage nuget packages > Browse Installed, remove the System.Drawings.Common package, and then add it back), unload project and then reload it again
Helped for me.

I managed to solve it by restarting Visual Studio, changing the framework to 4.6.1 (which I could not do before) and adding the reference.
OP's solution migrated from the question to an answer.

you could try to use one of the libs described in here instead https://devblogs.microsoft.com/dotnet/net-core-image-processing/
you could try to use https://www.nuget.org/packages/CoreCompat.System.Drawing/ as well and maybe try to change your app framework to .net standard 2.0?

This is kind of bizarre but it worked dramatically so I'm going to mention it. I built a small vs 2017 ent console project that was supposed to read an oracle database. When I started to run it I got the System.Drawing.Common error mentioned above. It seemed stupid because I wasn't really doing anything having to do with Drawing at all. In Manage Nuget Packages I deleted the Oracle.ManagedDataAccess driver and added the Oracle.ManagedDataAccess.Core and the System.Drawing.Common error went away and I was able to read my oracle database. So I'm suggesting that with NuGet you may be picking up some things you really don't need and if you have any choice for your NuGet packages, try different ones. This also may be some foible with how my organization managed nuget for Visual Studio 2017 enterprise.

Can we deploy a C# 7 web app to Azure using Kudu?

Since Visual Studio 2017 is released and we can use the new C# 7 features I expected this will work when deploying on Azure Web apps.
Unfortunately we're seeing compile errors when using continuous deployment (kudu git deploy) so it seems Azure doesn't support the new toolchain yet.
Is there anything we can do to get this to work now (besides publishing the assemblies directly)?

since we don't yet have msbuild15 in Azure.
if you want to use c#7 features with continuous integration, you may need some workaround
for dotnet core web solution, you can build it in Azure out of the box. (it uses its own dotnet msbuild.dll) [repository sample]
for asp.net web solution, you need to add Microsoft.Net.Compilers 2.0+ nuget package to the project where the new language feature is applied. For example, if a class library in the solution is using the new syntax, you need to add nuget package to that lib project. (the new c# compiler is thus imported if you refer this nuget package) [repository sample]
finally for mixed solution (dotnet core web app + .NET framework class lib), you need to run nuget restore for the .NET framework lib project independently since dotnet restore is not backwards compatible, it cannot retore project from the old build system. I did this by hacking my deploy.cmd [repository sample]
these workarounds either try to
imitate msbuild15 (case1: dotnet msbuild.dll, case2: compiler as a nuget package)
or imitate nuget4.0 (case 3: run both dotnet restore and nuget3.5 restore)
we are in the process of building these tools for Azure, they should be out soon. you can stay updated on github

Adding the Microsoft.Net.Compilers NuGet package fixes the issue.

As pointed out by #joshuanapoli in a comment to the accepted answer Scenario #2 works only with Microsoft.Net.Compilers v2.4.0 and below.
Took me a couple of hours to notice and figure it out.