2

I have a VS extension, targetting .NET 4.6.1. I've refactored some of it into a .NET standard 2.0 dll, referenced by the extension. Where the extension depended on System.Data.SqlClient, the .NET standard dll depends on Microsoft.Data.SqlClient, added as a nuget package. The trouble is, at runtime, I get...

Could not load file or assembly 'Microsoft.Data.SqlClient, Version=1.11.20045.2, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5' or one of its dependencies

Following this question, I thought I'd look in the VSIX and sure enough, Microsoft.Data.SqlClient.dll is gloriously missing. I'm not very good with reference issues, but it seems this is totally out of my hands?

I really need this to work, and will happily screen-share or otherwise help anyone who can fix my problem. If you prefer to see the problem in situ, you can clone https://github.com/bbsimonbb/query-first.git then checkout the branch target-core-and-framework.

bbsimonbb
  • 20,571
  • 9
  • 59
  • 92

1 Answers1

1

Your problem might be caused by how NuGet dependencies are resolved. Your extension project "A" references a .NET Standard project "B" that in turn depends on a NuGet package "Microsoft.Data.SqlClient". Therefore, "A" has a transitive dependency on "Microsoft.Data.SqlClient" through "B". In other words, "A" needs "B", as well as the NuGet package to work.

As I can see from thelinked repository, your extension project uses the old-style format for .NET Framework projects, not the new SDK-style format like your .NET Standard library. When using the old project format, project "A" will only get assemblies of direct dependencies like "B" in its output folder, not indirect dependencies like the NuGet package. This is why the assemblies are not found. With the new SDK-style project and PackageReference, these transitive dependencies are respected. Hence, the package assemblies will be copied to your output folder or extension.

In order to make this work, you need to migrate your .NET Framework project to the new SDK-style format and use PackageReference for packages. It seems that this might be tricky for Visual Studio extensions, but it is possible and you can find more on it in this question. If this is not possible in your case, I guess you will have to resort to use plain old references to the assemblies that you require.

thatguy
  • 13,242
  • 6
  • 19
  • 33