CODEWITHSUNDEEP
.net-6.0.net-8.0side-by-sidedotnet-sdk
Simon Dowdeswell
Simon Dowdeswell

Reputation: 1081

dotnet 6 runtime error only when .net 8 sdk is installed on machine

I had a solution, working for over a year, with .net6.0 framework projects. The code runs fine but i can see that System.Data.SqlClient has security issues. So i have upgraded to .net8.0 on a feature branch. One of the .net8.0 issues was the following message for which the fix was to move to a different library and that was done on that branch.

Could not load type 'SqlGuidCaster' from assembly 'System.Data.SqlClient, Version=4.6.1.5, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.

However, now on the original .net6.0 branch this same message is suddenly appearing. It only goes away if i uninstall VS2022 and .net 8 (which not an acceptable solution)

I have a global.json at the sln root which specifies the sdk version that is installed on the machine (ive also tried the other rollForward options latestMinor and latestFeature):

  "sdk": {
    "version": "6.0.421",
    "rollForward": "disable"
  }

To me it appears that the installation of .net 8 sdk (8.0.204) has caused dotnet to always use something from the .net8.0 suite such that the .net8.0 issue is now reported for the .net6.0 project. How can I fix this for the .net6.0 projects branch (which runs tests in CI is in production and is working)?

PS: - I have it working, but it's sad - my findings are:

I have managed to totally uninstall .net8 and its sdk. It required me to go back to VisualStudio 17.2 which relies on .net 6, not 7 and 8 as newer versions do. It also required deleting .net8 remnants under %appdata% and my user directory. I have worked out that the .net SDKs do not work side-by-side - the newest one is used for a set of (shared) dlls and you can see them being loaded in the debug output window. This is usually backward compatible. However, it does not pan out well in some cases such as mine, above, with System.Data.SqlClient. If you thought dll hell was a thing of the past think again when it comes to the .net SDK.

Upvotes: 1

Views: 455

Answers (0)

Related Questions