Calling class library I get the error system.data.sqlclient is not supported on this platform - asp.net-core

Here is the setup when I am getting this error:
Project "main" based on Core 3.1 and of type console application. Does not have a reference to System.Data.SqlClient and does not need one.
It calls project "process" also based on Core 3.1 of type class library. Does not have a reference to System.Data.SqlClient and does not need one.
"Process" calls project "service" based on Core 3.1 of type class library. This project needs System.Data.SqlClient and has a reference to a package "System.Data.SqlClient (4.5.1)".
When debugging "main", when it gets to "service", the first time it reference SqlConnection, it errors with message "system.data.sqlclient is not supported on this platform"
Why am I getting this error and how can I fix it.
Note: When I add a refernce to System.Data.SqlClient in project "main" - no error, but of course as "main" does not need System.Data.SqlClient, it should not have one.
When I test "service" using xUnit, no errors, it works OK
Thanks

According to the document:
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 when you don't think
you should be, it ultimately means your application is not loading the
appropriate DLL. There could be a number of reasons for this. The
NuGet package structure and infrastructure around referencing and
loading referenced NuGet packages includes logic that allows a package
to contain multiple DLLs which implement support for different .NET
and platform targets. Meaning 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.
I suggest you could try to use Microsoft.Data.SqlClient instead. More details about cheat sheet for porting from System.Data.SqlClient to Microsoft.Data.SqlClient, you could refer to this article.

Related

Migration .Net framework to .NET 6 - class library

During migration of our existing project targeting .NET framework 4.8 we encountered starnge error:
MC1000 Unknown build error, 'Could not find type 'System.Web.PreApplicationStartMethodAttribute' in assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\ref\net6.0\System.Web.dll'.'
error message image
Basically we have one big class library targeting net6.0-windows that has been used across multiple different smaller projects.
This class library is compileable as a stanalone porject with no errors, but as soon as we reference it in our WPF project, also targeting same net6.0-windows, we got this error.
Does anyone experiencing sme problem?
Any help appreciated...
Eventually I found that mixing of ASP.NET components together with WinForm or WPF is not allowed anymore. So solution was to split our library file into two separate DLL assemblies each targeting proper SDK.

System.Web.ApplicationServices in .NET Core 2

I'm building a Web API in .NET Core 2. I'm using some custom nuget packages to leverage their built in functionality. These custom packages were built against an older .NET version (4.6.1). The problem is some of these packages have references to the old System.Web dll. I'm getting this warning on some of the custom packages in the solution
package was restored using '.net framework version=v4.6.1 instead of using the proj target framework.
The app is also throwing this exception below when I call code in one of the custom packages
System.IO.FileNotFoundException: Could not load file or assembly System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral,The system cannot find the file specified
Is there any way around this other than re-writing the code in my web Api?
No. System.Web is completely incompatible with Core. While Microsoft opened up NuGet packages that target .NET Framework to be utilized in with .NET Core, it did so based only on .NET Standard 2.0 compatibility, and makes no assurances that the packages will function in part or whole. You'll actually get a warning during compile telling you as much. Also, while you can actually have something like an ASP.NET Core app actually target .NET Framework, again, compatibility of third-party components is not guaranteed, simply because they target the same framework.
Long and short, if there's any dependency on System.Web at all, you can't use it.

Unable to resolve assemblies that use Portable Class Libraries

I'm having a problem with assembly resolution on an end-user machine and I believe it's related to using Portable Class Libraries....
I have a .NET 4.0 application that was originally written in Visual Studio 2010. Recently we upgraded to Visual Studio 2012 and we've created a few projects that are Portable Class Libraries. I don't believe we need these features now, but we're also building a Windows 8 Store application that might benefit from these libraries.
When I compile my project, what exactly does the portable library feature do? I expect that it allows me to run it on different frameworks without modification or recompiling.
When I look at the library in reflector dotPeek it shows the Platform attribute as:
.NETPortable,Version=v4.0,Profile=Profile5
And the references seem 2.0-ish:
mscorlib, Version=2.0.5.0
System, Version=2.0.5.0
System.Runtime.Serialization, Version=2.0.5.0
When I run the application on this end-user's machine, I see an error in the log file:
Could not load file or assembly, 'System.Core, Version=2.0.5.0...'
Googling System.Core 2.0.5.0 seems to refer to SilverLight -- which appears to be one of the targeted frameworks.
This machine does not have Visual Studio installed, but has .NET 4.0 (4.0.3 update)
Is there something I should be doing differently to compile, something I should investigate in my dependencies or something I should be looking to install on the end-user machine? What does the 2.0.5.0 refer to?
For .NET 4, you need an update (KB2468871) for Portable Class Libraries to work. From the KB Article:
Feature 5
Changes to the support portable libraries. These changes include API
updates and binder modifications. This update enables the CLR to bind
successfully to portable libraries so that a single DLL can run on the
.NET Framework 4, on Silverlight, on Xbox, or on the Windows Phone.
This update adds public Silverlight APIs to the .NET Framework 4 in
the same location. The API signatures will remain consistent across
the platform. All modifications are 100 percent compatible and will
not break any existing code.
Also see the "Deploying A .NET Framework App" section of the MSDN Portable Class Library Documentation.
EDIT: Actually, if the machine has .NET 4.0.3 installed as you mention, that should be sufficient. Can you double-check to make sure that it is actually installed?

Serialized Assembly Won't Upload to Database

I have a CLR project that calls a simple HTTP web service. Its x64-targeted and I got it to serialize properly only after going through the steps outlined at the following link which talks about the changes required to have VS2010 point to the correct target architecture (x64) - the changes just required unloading and changing the .csproj file with a few extra lines to reference the correct version of sgen.exe: http://geekswithblogs.net/akraus1/archive/2011/12/10/148002.aspx
Now, I am able to build this project and its .XmlSerializers.dll by setting "Generate serialized assembly" to on. I wanna do this because my CLR project is going to get deployed on the database, and I don't want it to runtime serialize any objects since those DLLs are not referenced in my database and I don't want to give my CLR project permissions higher than EXTERNAL_ACCESS for security reasons because this will be used in a production environment where security is important, and also because my database is NOT trustworthy.
Long story short, I am following the guide at the following link to upload my serialized assembly into the database but I get an error: http://footheory.com/blogs/bennie/archive/2006/12/07/invoking-a-web-service-from-a-sqlclr-stored-procedure.aspx
The error is: CREATE ASSEMBLY for assembly '.XmlSerializers' failed because the assembly is built for an unsupported version of the Common Language Runtime.
Does anyone know how to correct this by forcing sgen.exe to serialize a CLR-supported version of the assembly? Viva the Stack.
SQL Server 2005/2008/2008R2 supports only .Net 2.0. You need to change your project to target this, see How to: Target a Specific .NET Framework Version or Profile. You do not need to specify x64 for the build target, SQLCLR assemblies should be Common target built.
That said, calling web services from SQLCLR is a really really really bad idea. Don't do it. Have an external process handle the HTTP calls.
I found that the problem was actually not the fact that I'm using .NET 3.5 as a target, but I was referencing the wrong version of the sgen.exe tool, which in this case I needed the x64 version of 6.0A (which translates to .NET 3.5) at this path: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\sgen.exe. Now I am able to build the correct version of the serialization assembly, upload it, and also use it.

Does referencing the JDK namespaces from within a .NET application require the Java runtime to be installed?

I'm in a VB.NET application. I have referenced some java.* namespaces in my file and am utilizing objects and methods from this namespace throughout the code. Presumably this is relying upon J# to compile.
Imports java.util
Imports java.util.zip
Imports java.io
Are these JDK namespaces fully contained in the .NET framework, or will my clients need to have Java installed when they go to run my application?
As a side note, I have not explicity referenced any external Java DLL's or anything. This is all pure .NET as far as my code is concerned.
Yes, they're within the J# DLLs, which I strongly suspect VB is referencing for you automatically. If you open your binaries up in Reflector, I'm sure you'll see a reference to vjslib.dll there.
There's no dependency on an actual JRE/JDK being installed.
Personally I would try to migrate away from them, however. If you need more compression options than System.IO.Compression it's worth looking at SharpZipLib. Microsoft no longer ships J# as a product, and the idea of trying to port all the Java 1.1.4 classes to .NET, including their quirks, has always made me nervous.
vjslib.dll doesn't even ship by default with either the framework or Visual Studio these days...