1

I'm working on a lib (MyLib) that targets .net standard 2.0 and .net core app 3.0. The Lib has a dependency (PrimaryDependency), which in turn has another dependency (OtherDependency), and OtherDependency uses the Microsoft.Windows.Compatibility package:

MyLib
  PrimaryDependency
     OtherDependency (.NET Std 2.0, using Microsoft.Windows.Compatibility Nuget package)

I wrote two test apps using MyLib. One built on the .net 4.72, one for .netcoreapp 3.1. The net472 test app does not need anything from Microsoft.Windows.Compatibility (all that stuff is in the .NET runtime). So, the output does contain Tester.exe, MyLib.dll, PrimaryDependency.dll and OtherDependency.dll and it works just fine.

The .netcore test app output contains Tester.exe, Tester.dll, MyLib.dll, PrimaryDependency.dll, OtherDependency.dll and a bunch of System.* and Microsoft.* dlls (the parts from Microsoft.Windows.Compatibility that is needed to run the app), and it works fine, too.

Now, if I compile (or publish) MyLib.dll, neither the netstandard2.0 output nor the netcoreapp3.0 output does contain the System.* and Microsoft.* dlls that are needed for MyLib.dll to operate on .net core.

As MyLib.dll is a plugin, the final consumer of this dll does not have the MyLib project as a reference, and hence, the System.* and Microsoft.* dependencies go missing. What can I do to ensure when I compile/publich MyLib, that it does contain all the necessary dependencies?

Stephan Steiner
  • 1,043
  • 1
  • 9
  • 22
  • Normally, this is handled via "transitive dependencies" - i.e {some app} => {your lib} => {other things}; it is when someone builds an actual app ({some app}) that the transitive dependencies are evaluated (using the TFM of the {some app}), and the *app* should get everything it needs, including {other things}. Does that make sense? Are you using package-references? – Marc Gravell Jan 23 '20 at 21:25
  • Yes, makes perfect sense. Bug since MyLib is a plugin dll, that mechanism doesn't take. In the meantime I found that I could add true , and the output contains all files when I do dotnet publish (interestingly enough it only works from the CLI.. the publish through VS does not contain the files). – Stephan Steiner Jan 23 '20 at 21:31
  • @MarcGravell: I'm revisiting this topic. Yes I'm using package-references. Is there a way to ensure my output contains what is needed and only what is needed? I accidentally forgot to publish the runtime folder and then upon loading that MyLib.dll the whole thing blew up because of a missing sni. And that's SQL server - MyLib.dll has nothing whatsoever to do with Sql so there's a dependency that's redundant (and there are probably a lot of others given that I only need directoryservices from the compatiblity lib) – Stephan Steiner Mar 02 '20 at 21:12
  • if it blew up at runtime, then something *was* trying to use it, so from any tree-shaking perspective: it *was* required; the stack-trace would tell you by what exactly – Marc Gravell Mar 03 '20 at 07:17
  • actually, it's a plugin system, and it bombed when trying to instantiate the plugin. But I have my sincere doubts that SqlClient would be used if you're not doing anything on any SQL server. Note that I published using to true.. so it's not really shaking the tree so to speak unless I completely missunderstand what that flag does. – Stephan Steiner Mar 03 '20 at 18:10

0 Answers0