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

Is there any way to share code between UWP apps and WPF apps?

To be clear, I follow the MVVM pattern, and I want to structure my project such that I can share my model code between a UWP app and a standard WPF app. The code I want to share has no UI. I don't relish the thought of finding new tools to replace the ones that I've been using for years that take care of certain tasks like logging, connecting to a document oriented database, etc.
I attempted to start writing a UWP wrapper around some code I already have and reference the model project directly. Visual Studio refused to let that happen, showing me an error message that says "Unable to add a reference to project 'ACK.Model'". The same thing happened when I attempted to put the model in a Universal Library and reference it from a WPF app. I'm not trying to share WPF code. Just the model layer that has no reference to UI libraries.
This is a scary proposition, because it means that if I want to do anything substantial I have to choose to either jump 100% to UWP or stay 100% WPF. NewtonSoft.JSON might have a universal distribution (ASP.NET MVC), but what about ElasticSearch.NET, and other tools needed to make important apps?
I found where the "Portable Class Library" project type was hiding. PCLs will allow me to share my code across WPF and Universal apps as that was one of the options. This solves the simple case of the Model part of my code, but I (still) can't use some of the libraries I want. There are still a large number of libraries that I need that do not have PCL available.

About a year later, with the advent of Visual Studio 2017 there is a more complete solution. If you target your libraries to .Net Standard then the library is compatible with both .Net Core apps and the monolithic .Net targeted app. The support for standard .Net libraries and APIs is fairly complete, as is the support for modern C# language features.
The general advice now is this:
Target .Net Standard for all libraries
Target the appropriate platform for your actual application. (UWP or WPF).
NOTE: if your library has to interact with C libraries or applications, you have to take extra care to make sure you load the correct version.
It appears that there is a solution, but it has to be adopted by the whole tool chain you want to use. When Microsoft introduced Windows Store apps in Windows 8, they also introduced a Portable Class Library (PCL). The purpose of the PCL is to share code between different parts of your application.
When you create a PCL in Visual Studio 2015, you can specify the types of APIs you want it to be accessible from:
Universal Apps
Mono
.Net Core 5
.Net 4.6
This of course, limits the APIs available to you but most of the ones you want to use are OK as long as it's not UI related. There are other limitations as well:
Your project can only be edited in Visual Studio 2015 or greater
You don't have access to special directories from the Environment variable (i.e. user Documents directory, etc.)
You can't link to a library designed for only one of your target platforms (i.e. libgit2sharp, etc.)
There's no way to browse the API for this subset--MSDN needs to get on the stick. MSDN has updated much of the API documentation, but it's still difficult to figure out what applies to your PCL
However, you can link any library designed for a single target platform to your PCL. It's not ideal, but it's better than nothing.
The ASP.NET MVC stack has been ported to using PCLs, so you can use NewtonSoft.JSON directly as well as any other of those libraries used by that application. However, there are several libraries that have not been ported.
This arrangement forces you to think about how you want to integrate better. The .Net Core 5 seems to be stable, but support is in it's infancy. The current generation of Universal Apps as of VS 2015 update 1 uses .Net Core 5 directly.
There are several features from Nuget that are not currently supported even though work is under way:
MS Build extensions (major changes to MSBuild and the project.json structure)
Install/uninstall scripts (related to the removal of the concept of install)
Content (related to install/uninstall, but work is in progress on this)
Content transforms (related to lack of install/uninstall)
I wish I had a more complete answer. But this is as far as I got once I discovered the PCL and how it evolved for the current infrastructure.
I'm in the process of creating a game creation toolkit that incorporates version control right off the bat. I want to be able to deploy a game as a Windows 10 app, or as a standard WPF app, but due to the libraries I'm using to integrate version control I need to create the editor as a standard WPF app. I had to be a bit creative in building the shared code and importing the correct libraries.
First, my project hierarchy:
Project.Model (Portable Class Library)
Project.Model.Versioning (standard C# library)
Mvvm.Toolkit (Portable Class Library)
Editor (Standard WPF application)
I want the core PCL to be able to load a project and deserialize the JSON encoded objects. The PCL did have access to System.IO, but surprisingly it is not the same as the one defined in the standard C# library. Here's how I had to fix things:
After adding the package reference to NewtonSoft.JSON, I had to change the target framework in the packages.config file:
<package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />
All projects dependent on my Project.Model class had to install the `system.io.filesystem' package from nuget so that the System.IO.FileInfo etc. objects were the same.
While this is definitely not a panacea, it's also not a dead end. I'm sure there are more gotchas, but this will at least help with some of the problems.

a .NET Standard library could be used to share a Model-View-ViewModel architecture between a WPF project and a UWP project.
https://www.syncfusion.com/ebooks/xamarin-forms-succinctly/sharing-code-among-platforms
https://devblogs.microsoft.com/dotnet/announcing-uwp-support-for-net-standard-2-0/

Use MvvmCross with dot42

I'm currently trying some techniques for writing Android programs with C#. I found MvvmCross that is really nice for an old WPF programmer. Sadly, the free Xamarin version does not allow the use of MvvmCross, and licences are far too expensive for playing around.
Now i stumbles across dot42, but could not manage to load MvvmCross into a dot42 project via nuget. I get
Could not install package 'MvvmCross.PortableSupport 3.1.1'. You are trying to install this package into a project that targets 'Dot42,Version=v2.3.3', but the package does not contain any assembly references or content files that are compatible with that framework.
so I guess, Dot42 isn't supported by MvvmCross. Is it possible to use MvvmCross with dot42?

You won't currently be able to easily use nuget with dot42 - nuget hasn't yet added any extension for them.
Also, you won't be able to use MonoDroid-targetted assemblies for dot42 - those assemblies are built against Xamarin's runtime - not dot42.
However... if anyone wanted to get MvvmCross working against dot42, then I believe this should be possible - as dot42 supports quiet a good .Net functionality set, including PCLs. To do so would require editing the source code, cloning the MonoDroid projects and then changing the code that targets Xamarin/MonoDroid runtime objects to instead target the dot42 equivalents. I'd personally love to see this done, but haven't had time to work on it myself.

Using older .NET API in a Modern UI application for Windows 8?

I am currently trying to make use of DropNet to make a simple Modern UI application that will be able to access users' Dropbox accounts and upload files. However, DropNet apparently only supports .NET 3.5.
I've been trying to make the application utilize the .NET 3.5 runtime (rather than 4.5), but to no avail. I choose the appropriate .NET version like so:
Yet when I try to confirm the version, it shows a greyed out box like this:
This contrasts with non Modern UI apps, which show the appropriate version and give you the ability to change it.
When I try to obtain DropNet through NuGet, it throws up an error (as you'd probably expect):
Could not install package 'DropNet 1.9.3'. You are trying to install this package into a project that targets '.NETCore,Version=v4.5', but the package does not contain any assembly references that are compatible with that framework. For more information, contact the package author.
Is there any way to achieve what I'm trying to do?

You cannot make this work. A Store app project must target .NET 4.5, the only version of .NET that's compatible with the language projection that's needed to make .NET programs work on WinRT. In addition, the profile that permits WinRT programming (.NETCore as shown in the error message) is strictly limited and does not support references to .NET assemblies that target older versions of .NET.
I'm not aware of a 4.5 Store compatible wrapper for the DropBox api. You could possible take advantage of their generic REST api. Beware the general trouble you'll have making it work, and surely the reason that a 4.5 wrapper isn't available, Windows suspends a Store app when the user switches away from it. Which will interrupt a file transfer. A highly likely occurrence, the user won't have much patience with it.

Visual Studio 2012 How to debug "Unable to add reference to project x" error?

In Visual Studio 2012 in a blank new Class Library I am trying to add reference to an existing project in the solution, also a Class Library, MonoGame.Framework.Windows8 (https://github.com/mono/MonoGame), but get the error:
Unable to add reference to Project MonoGame.Framework.Windows8
I have built the existing library, MonoGame, successfully and made it a dependency of the new one. What could be the problem?
(It's extremely annoying the error message does not give a reason!)

Trying to add the built dll has a reference gave a more explicit error message which has solved the problem for me, it said:
“A reference to ‘x’ could not be added. The project targets ‘.NetFramework’ while the file reference targets ‘.NetCore’. This is not a supported scenario”
The MonoGame Class Library is a Class Library (Windows Store apps) type! (The bit in parenthesis is important! Presumably the difference is the Windows Store apps type use .Net Core which is not the same as .Net Framework).
So to get it working your project must be a Class Library (Windows Store apps) which is available under the Windows Store option in Add New Project.

I suspect the problem is to do with the 'Target Framework' in project options.
I don't know how MonoGame works for Windows 8 but when you're developing for Android the target framework options are the different versions of Android [e.g. Android 2.2 (Froyo)]. When you create a regular class library you have choices between the different versions of the .NET framework or Mono [e.g. Mono / .NET 4.0].
Unfortunately, these frameworks are not compatible with each other. You can't add a project reference for Android to a .NET framework class library and visa-versa.
The solution is to use a Portable Class Library. They are specifically designed to deal with this issue. The downside is that you will only have access to the subset of assemblies provided in the lowest denominator you choose to target.
You might also want to consider code sharing between projects using linked files. It can make maintenance a little trickier but gives you a little more control over code that should compile in both target frameworks but doesn't fit into the portable class library. Here's a related question:
Project reference vs. file links in Mono multi-target projects
The key to all of this once you understand what's going on here is how you structure your solution. With a little care you can have nearly all your code shared across different platforms.

I might be because of both projects are using different Framework versions and change the Framework versions in both Projects of properties section then your problem might solve.

Same question I guess here:
Visual Studio 11 metro apps unable to add reference?
The answer was:
What are you adding a reference to? Metro style apps can only add references to other Metro style class libraries or portable class libraries