Develop Reference

Error with Microsoft.EntityFrameworkCore.Query.IParameterValues after update project to entity core 5

After update ef core to version 5, from 3.1. I get error:
System.Reflection.ReflectionTypeLoadException: 'Unable to load one or more of the requested types.
Could not load type 'Microsoft.EntityFrameworkCore.Query.IParameterValues' from assembly 'Microsoft.EntityFrameworkCore, Version=5.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.'
This error show up during using Automatic DI. Did Entity removed this extensions?
Thank you

this API no longer exists;
here it is in 3.1, but when you try for 5.0, it says:
The requested page is not available for Entity Framework Core 5.0. You have been redirected to the newest product version this page is available for.
So; the API is removed - that's allowed in a major, so: stop trying to configure/use it, I guess?

Error: "The module cannot be loaded because only single file assemblies are supported" in .NET Core

Despite having a several years background in .NET backend, I'm a newbie in cross-platforms, hence in .NET Core.
I'm struggling the below error during runtime of the component developed in .NET Core 3.1 framework which is a worker service (introduced in .NET Core 3.x).
Any ideas folks?
Important: This .netmodule file is already being utilized in our current backend in .NET environment bundled with another .dll assembly file(s). I know that most of the .NET 3rd party libraries are NOT compatible with .NET Core area. However, I'm not sure whether there's a hidden catch on the issue; since when I google'd the error message, I could not find any exact match.
System.IO.FileLoadException: Could not load file or assembly 'dcpssacs.netmodule'. The module cannot be loaded because only single file assemblies are supported. (0x8013101E)
File name: 'dcpssacs.netmodule'
at DDSMessageReceiver.Core.GenericSimplicityLayer.DefaultSettings(BaseModel& baseModel)
at DDSMessageReceiver.Worker.InitializeModules() in C:\Triodor_Workspace\T4CNext\DDSMessageReceiver\DDSMessageReceiver\Worker.cs:line 83
at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__139_1(Object state)
at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

"Wrong assembly binding redirects" when running BenchmarkDotNet

When running BenchmarkDotNet for a method in my project I get a few "Wrong assembly binding redirect" warning/error messages printed to screen. This got me a bit puzzled, as I thought assembly binding redirects is a .Net Framework concept, while my projects are .Net Core 3.0. Googling the warning/error message gave no result. Any tips to what these messages mean, and possibly how to fix the problem. I tried cleaning Nuget cache, restoring Nuget packages, cleaning and rebuilding the solution, but to no help.
// BeforeAnythingElse
// Benchmark Process Environment Information:
// Runtime=.NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
// GC=Concurrent Workstation
// Job: DefaultJob
OverheadJitting 1: 1 op, 308100.00 ns, 308.1000 us/op
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en-US, PublicKeyToken=cc7b13ffcd2ddd51.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en, PublicKeyToken=cc7b13ffcd2ddd51.

The short answer is that you can ignore this warning.
The long answer: for some reason VS sometimes generates invalid assembly binding redirects for Full .NET Framework projects that reference .NET Standard libraries. It was causing a lot of trouble to BenchmarkDotNet users in the past:
https://github.com/dotnet/BenchmarkDotNet/issues/895,
https://github.com/dotnet/BenchmarkDotNet/issues/667,
https://github.com/dotnet/BenchmarkDotNet/issues/896,
https://github.com/dotnet/BenchmarkDotNet/issues/942 .
I decided to implement an ugly workaround that searches for .dll file manually and loads it when .NET Framework fails to do so.
Of course, this applies only to Full .NET Framework. When I was porting BenchmarkDotNet to .NET Standard 2.0 I've forgotten that we don't need to do this for .NET Core. As the end result, you get this confusing warning.
I've sent a PR that fixes that: https://github.com/dotnet/BenchmarkDotNet/pull/1365 and this workaround will now be executed only for Full .NET Framework projects

ServiceStack error calling Request.GetRawBody();

I am attempting to get access to the underlying JSON object (request body) within a service call in service stack. The reason I wish to do this is to create a PATCH version of an existing service, which will only attempt to update fields that were in the JSON. Seems simple enough:
public object Patch(AddUpdateContactRequest request)
{
var json = this.Request.GetRawBody();
var keysToUpdate = JsonSerializer.DeserializeFromString<Dictionary<string, string>>(json);
return Put(request);
}
However, I get an exception from service stack when GetRawBody() is called (when service stack is calling in to .NET core):
Message: "Could not load type
'Microsoft.AspNetCore.Http.Internal.BufferingHelper' from assembly
'Microsoft.AspNetCore.Http, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60'."
Source: "ServiceStack"
StackTrace: " at ServiceStack.Host.NetCore.NetCoreRequest.GetRawBody() in
C:\BuildAgent\work\3481147c480f4a2f\src\ServiceStack\Host\NetCore\NetCoreRequest.cs:line
211"
TargetSite: {System.String GetRawBody()}
TypeName: "Microsoft.AspNetCore.Http.Internal.BufferingHelper"
It seems to be referencing version 3.0 of Microsoft.AspNetCore.Http, but this version does not have the namespace Microsoft.AspNetCore.Http.Internal.BufferingHelper. It looks like a version mismatch issue, but I cannot seem to make it work. I cannot see any dll version conflicts locally, I am implicitly referencing the latest version of .NET core and have the latest SDK/hosting package installed.

If this is .NET Core 3.0 this is due to a breaking change in .NET Core 3.0 which has been resolved in the latest v5.7.1 packages on MyGet.

.Net Core 3.0 invoking .Net Framework 4.8 program via Reflection

I have a .net Core 3.0 application attempting to invoke .Net Framework 4.8 via reflection. Our goal is to read encrypted AppSettings.config (xml) with ConfigurationManager, which is not possible in .Net Core. Unencrypted yes, but encrypted (CipherData), no.
My reflection code that accesses a static class & method goes like this:
Assembly assembly = Assembly.LoadFrom(exeFullName);
MethodInfo method = assembly.GetType(nameSpacenClass).GetMethod(methodName);
if (method != null)
{
object rtnVal = method.Invoke(null, new object[] { jsonParms });
return rtnVal;
}
else
return null;
The method.Invoke errorred out with this exception message:
FileNotFoundException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
So I wrote a proxy program in .Net Framework 4.8, and use the same code to access the code that reads encrypted config via reflection, and it works fine.
Then, I coded .net Core 3.0 to access that proxy via reflection, and it fails. The proxy .Net Framework 4.8 has no references whatsoever. It is barebone. Yet core still requires ConfigurationManager even though the proxy does not. The Config program has only one reference - to System.Configuration.
Core 3.0 => Encrypted App.config => Failed
Core 3.0 => ConfigProgram 4.8 => App.Config => Failed
ConfigProgram 4.8 => App.config => Works
Proxy 4.8 => ConfigProgram 4.8 => App.Config => Works
Core 3.0 => Proxy 4.8 => ConfigProgram 4.8 => App.Config => Failed
I guess the referenced System.Configuration is not required for Reflection invoke by 4.8 but is required even though trough a barebone stepping stone, by .Net Core 3.0. Could someone help me please?

When you load an assembly built for .NET Framework via reflection on .NET Core, it does not load any parts of .NET Framework - just your assembly ("user cod"). And some parts may or may not work. In your case it fails because the requested classes / assemblies of the code compiled for .NET Framework is not part of .NET Core.
This is the reason why only the cases where you start a .NET Framework application to begin with - thus booting up the .NET Framework Runtime - work for you.