We Keep Coding

System.PlatformNotSupportedException when referencing System.Data.SqlClient ONLY when running as a docker image

I'm trying to run my azure function application as a docker image and when I do it throws me a System.PlatformNotSupportedException in Microsoft.Data.SqlClient.dll: 'Strings.PlatformNotSupported_DataSqlClient' exception any time I try to call my datalayer (no matter if its EF Core or Dapper that I use). I can run the application just fine when setting my API project as startup instead of the docker image.
There are very similar questions out there but none of them take into account that it is ONLY happening when I try to run it as a docker image or the fact that my target framework is netcoreapp3.1. I've already tried what the similar questions said. which is to add System.Data.SqlClient as a Nuget package which doesn't help no matter what version I make it.
I suspect I need to add something to the Dockerfile or something.
here is some additional information:
EDIT:
I am able to recreate the issue in a new project by simply creating an azure function, adding docker support, creating a simple data layer that performs a CRUD operation on a local database, then running the docker image and calling the endpoint that does the CRUD operation. Hope that helps.

The Microsoft.Data.SqlClient NuGet package includes a number of DLLs supporting different .NET targets and different runtime platforms. If you are getting a
PlatformNotSupported Exception
it ultimately means your application is not loading the appropriate DLL.
A different DLL for .NET Framework, .NET Core, .NET Standard, Windows, Linux, etc. The NuGet infrastructure will automatically reference and load the appropriate DLL based on your application's needs.
If your application loads a DLL from a NuGet package directly, it bypasses all this logic and probably loads the incorrect DLL.
The DLL in the NuGet package under lib/netstandard2.0/Microsoft.Data.SqlClient.dll is basically the fallback DLL for any unsupported target and simply throws the PlatformNotSupported exception for any call. This is a nicer exception than what you would otherwise get when running on a platform that does not have a DLL built for it. Ultimately, you want to use the NuGet package reference infrastructure or you would have to implement all this target framework and platform support logic yourself when determining which DLL to load.
Additionally, the NuGet package contains all the dependency information for the SqlClient library and facilitates the downloading and referencing of dependencies. If you reference and load an individual DLL manually, it is up to you to ensure all dependencies are also available to the SqlClient library.
Refer why do i get a platformnotsupported exception when my application hits a sqlclient method
You can update all your dependencies with latest versions. It may fix your problem. Please check the implemented target frameworks and platforms support the logic of your code.
Refer here Link 1 & Link 2

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).

Self-Contained, service asks for Runtime to be installed

Build:
.net core 3.1, asp.net core 3.1.3.
Deployment mode: Self-Contained
Target Runtime Win-x64
RedyToRun, single file.
User: win 10 x64, 1903, 18362.788
Its a simple ASP.NET Core 3.1.3 service that runs locally with users. It should not need to have .NET Core runtime installed (as far as I understand it).
It runs smoothly upon installation. User side, my test VMs and my own development environment.
Yet a handful of users have reported that "after not using it for a while" (say a week) they receive the message box saying "To run this application, you must install .net core. would you like to download it now?"
The weird part is: Even if runtime is installed, it keeps asking for it.
It's self-contained, not runtime dependent, this should not be needed.
Has anyone else had this issue or ideas?

It would seem that issue was that the files extracted into the temp directory was partially cleaned up by windows.. causing the application to crash and burn due to missing files.
Intersting issue that was solved in 3.1.4

SonarQube Not Analyzing .cs Files In .NET Standard 2.0 Project

I'm running SonarQube 7.9.1 on Windows 10 64-bit via the StartSonar.bat script. My backing database is SQL Server 2017, and my startup config is all default except the JDBC connection string and credentials for SQL Auth.
I started SonarQube and created a new project for my Selenium test harness solution, which contains some middleware assemblies targeting .NET Framework 4.5, a framework assembly targeting .NET Standard 2.0 that takes a dependency on the middleware, and some test assemblies targeting .NET Core 2.2 that take dependency on the Selenium framework and in some cases on a few of the .NET Framework 4.5 middleware assemblies as well.
When I run an analysis of my solution like so:
dotnet sonarscanner begin /k:"MyCompany.Selenium"; dotnet build; dotnet sonarscanner end
The middleware assemblies are all scanned so I can see the lines of code, bugs, vulnerabilities, code smells, etc as I'd expect but the actual framework code isn't analyzed at all:
My guess is that somewhere SonarQube is deciding on my behalf that the framework project is a "test" project and doesn't need code analysis, but the info I found at https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-msbuild/ for Detection of Test Projects indicates that project names ending in Test/Tests and MSTest projects are the only ones automatically flagged as such, and neither apply to my framework. Is there anything else I should be looking for?

Adding false in a propertygroup in .csproj in my project has worked for me. Thank you https://stackoverflow.com/users/5133088/jeroen-heier

Sharing a DLL between projects

Microsoft says it's platform neutral these days, so I'm trying to build on Mac and Linux only with VS Code and deploy to Azure. Why? It's mainly to prove that I can.
Our project has several parts which include a couple of different websites, a Web API, er API and a few other bits. On my Mac I've built a .Net Core Class Library with a load of objects in. Command line, dotnet build, DLL out, no problem.
I want to put that DLL on the Linux machine where the MVC website is being built - the objects forming the models part of that site hopefully. I cannot figure out how to get the website project to reference my DLL and use the objects.
I had assumed I copy it to the other machine, place it in the bin folder of the site being developed and reference it in the Dependencies section of the site's project.json. Nope. I saw a few articles that said .Net Core only works with NuGet and it had to be a package. Is that really true?
I've found and read (if not entirely understood) everything you could imagine on sharing between .net core and .net framework. This is a core-only project so not applicable. Frankly I'm lost, and something called .Net Standard has just rolled into my field of vision.

So instead of copying the DLL, use dotnet pack to build a nuget package on your Mac, and copy that to your Linux machine instead. Put it in a directory that you configure as a local nuget repository (no server or anything required) and you're away.
I agree it's not as straightforward as a reference to a DLL, but it's not too bad. Note that you'll need to version the package appropriately, so that the tool system can detect when it's changed.