Package versions

Try adding ExcludeAssets to the package reference so it's not copied to /artifacts/build (which is the mount point for cfs/plugins in the local stack).

<PackageReference Include="Microsoft.Data.SqlClient" Version="7.0.2">
  <ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>

This isn't entirely different from the same challenge you'd have had pre-14. If your plugin depends on a different version from what's in Community, a binding redirect would have always been a risky move. The safest bet for packages already referenced by Community (full list, versions available in Administration > About) is to reference the version in Community and to not deploy it with your plugin. 

Try adding ExcludeAssets to the package reference so it's not copied to /artifacts/build (which is the mount point for cfs/plugins in the local stack).

<PackageReference Include="Microsoft.Data.SqlClient" Version="7.0.2">
  <ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>

This isn't entirely different from the same challenge you'd have had pre-14. If your plugin depends on a different version from what's in Community, a binding redirect would have always been a risky move. The safest bet for packages already referenced by Community (full list, versions available in Administration > About) is to reference the version in Community and to not deploy it with your plugin. 

And to be clear, if it had a reference to a DLL that wasn't visible to it in cfs/plugins, the site would have still loaded with a useful error message logged. But in this case, it was due to a completely different version of Microsoft.Data.SqlClient.dll being bundled. We already have another issue logged that expands exception logging for non-loadable custom plugins.

This is what I thought would be the case, there have been lots of instances of extensions and code that requires different versions of libraries, Newtonsoft being the most egregious offender.  So how are we going to handle the situation where a feature requires binding redirects, I suspect if you took a sample of the current cloud solutions web.configs you will find a large proportion will have them are not standard.  

Newtonsoft.Json is a good example, and is part of the reason JSON serialization is now a first class API  in the platform, requiring neither Newtonsoft.Json nor System.Text.Json.

For other cases, the recommendation would be to use what's included or something else entirely if it would otherwise require a newer version from what's included.

This was a massive problem in the previous versions, as the libraries were so far out of date, I hope that you will keep libraries up to date in this version, and we will find out if it's a problem as time progresses. Case in point I would say SQL client needs upgrading to version 7.

Agreed. Keeping platform dependencies as well as cloud architectural components up-to-date is key both for the cloud environment as well as .NET 10. As for SQL, I'm sure it will be updated to the recent 7.x, but it is still up to date as of versions available alongside the .NET 10 release.