SqlClient: Could not load type 'SqlGuidCaster' from assembly Microsoft.Data.SqlClient
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
Error:
System.Reflection.ReflectionTypeLoadException: „Unable to load one or more of the requested types.
Could not load type 'SqlGuidCaster' from assembly 'Microsoft.Data.SqlClient, Version=5.0.0.0, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.”
Code:
public static IEnumerable<Assembly> GetAssembliesWithTypesImplementing<T>()
{
return AppDomain.CurrentDomain.GetAssemblies()
.SelectMany(assembly => assembly.GetTypes())
.Where(type => !type.IsAbstract && typeof(T).IsAssignableFrom(type))
.Select(type => type.Assembly)
.Distinct();
}
line:
assembly.GetTypes()
The error appeared after upgrading from .net 7 to .net 8 preview 1. I searched and I don’t have such Microsoft.Data.SqlClient package installed
Expected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 45 (26 by maintainers)
Commits related to this issue
- add a workaround for https://github.com/dotnet/SqlClient/issues/1930 — committed to adamsitnik/AspNetCore.Diagnostics.HealthChecks by adamsitnik 7 months ago
- Hotfix (temporary workaround): Could not load type 'SqlGuidCaster' Addresses https://github.com/dotnet/SqlClient/issues/1930 — committed to Atrejoe/Inky-Calendar-Server by Atrejoe 7 months ago
Hi there. Just came across this issue myself when upgrading a service to .net 8, the 5.2.0-preview fixes it as said here. Just wondering if there’s an idea of how far out a full 5.2.0 release will be for this? Many thanks! 🙂
I had the same issue here. After changing to GetExportedTypes() seems to fix the issue
This same issue is present in
System.Data.SqlClientas I reported here.Should we expect the fix for this issue to be backported from
Microsoft.Data.SqlClienttoSystem.Data.SqlClient?@dot-net-user12345 Remove the “EntityFramwork” package, it uses Sustem.Data.SqlClient
I’m experiencing this issue after migrating to Microsoft.Data.SqlClient.
Ok. that’s interesting. The problem isn’t in SqlClient it’s to do without how object layouts are computed in the Jit. It looks like a class that’s laid out safely in 7 is now not safe in 8. Since 8 is still in very early preview this isn’t a pressing problem but i’ll see if i can find the people who might know what to do.
Same here, the issue is solved in the latest version of the NuGet package Microsoft.Data.SqlClient -> 5.2.0-preview.4.23342.2. I hope the final release will be out soon.
I had the samme issue. Upgrading to the preview 3 version of 5.2.0 works. For now this i blocking me from upgrading to .NET 8 as I’m not too happy about releasing a preview version to a production environment.
@Wraith2 is there an ETA of the next preview or even better the release of 5.2.0? The last preview was almost half a year ago so I was thinking that the release should be close or?
This should be fixed in all the latest preview builds. Can you try one of those please.
System.Data.SqlClient is deprecated and hasn’t been released with the framework for several versions. Unless there is a security issue or a other high importance change that is required it is unlikely to get any backported changes. Combine that with the fact that the type which causes the problem is internal and you’re using private reflection to find it and I think any change to it is very unlikely.
You should migrate to Microsoft.Data.SqlClient.
Seems to be working on me @odesuk , trying to upgrade our .net6 to .net8
FROM: assembly.GetTypes() TO: assembly.GetExportedTypes()
Notes: GetExportedTypes() - This method returns only the public types that are visible outside the assembly.
GetTypes() - This method returns all types defined in the assembly, regardless of their access modifiers (public, private, internal, etc.).
My worries;
@roji Just a heads up. This may have an impact on EF8 if EF8 wants to take a dependency on MDS 5.1. We need to figure out a way to ensure MDS 5.1 remains compatible with .NET 8.
@David-Engel @MichalPetryka this is a result of the runtime optimization in https://github.com/dotnet/runtime/pull/72549 which came from a suggestion on my new apis proposal https://github.com/dotnet/runtime/issues/51836#issuecomment-1189555912
We’ve got a situation where the runtime was previously using
struct SqlGuid{ byte[] _value; }and that has changed tostruct SqlGuid{ Guid? _value; }. overlaying a struct with ref types in the same position was unsafe and icky but supported. In NET8 this changes to trying to overlay a value type and a ref type which is entirely illegal and causes the type loader to abort the assembly load.I’m not sure of a good way to fix this. We can’t detect the right pattern to use at runtime because we cannot have the old pattern in the assembly, the type loader will reject it. If we choose to fix this only for net8 then we must have a day 1 build of SqlClient available to users when net8 launches or we prevent early adopters from using EFCore and NET8 which is a very poor PR look for this library.
@Wraith2 @lcheunglci I was able to reproduce the problem, here is the repo: https://github.com/Alerinos/SQLError Error:
Even if you aren’t using it directly you must have a transitive reference to Microsoft.Data.SqlClient (probably through EFCore) in order to have it present in the assembly list. So can you provide the minimal reproduction that can be debugged which exhibits this problem?