0

The .Net Core Console Template in VS2019 adds the Microsoft.NETCore.App Metapackage as an 'SDK', which includes dependencies to .NetFramework libraries.

For example, why is System.ServiceProcess.dll (A .NetFramework Assembly)listed as a dependency instead of System.ServiceProcess.ServiceController.dll (the equivalent .NetCore assembly)?

Image of VS

To actually use the Types included in System.ServiceProcess.dll, you need to add a reference to System.ServiceProcess.ServiceController nuget package. I'm confused why the NetCore.App SDK would list a .NetFramework assembly as a dependency, especially considering accessing the types included in that assembly require an extra nuget package

FakeSaint
  • 492
  • 5
  • 8
  • Unfortunately, you forgot to use a tool like ILSpy to open `System.ServiceProcess.dll` from .NET Core and .NET Framework. Then clearly they are completely different. The .NET Core one only contains a few type forwarding definitions, and only with `System.ServiceProcess.ServiceController` referenced can take effect. Don't be confused by the names. – Lex Li Jun 30 '19 at 02:05
  • Actually I did! I'm confused why .net framework assemblies are being listed as an SDK dependency at all. What is their purpose? I think it has to do with the distinction between the "metapackage" that is the SDK and the actual nuget packages that are used by .net core. – FakeSaint Jun 30 '19 at 10:40
  • https://stackoverflow.com/questions/47365136/why-does-my-net-standard-nuget-package-trigger-so-many-dependencies – FakeSaint Jun 30 '19 at 10:43

1 Answers1

2

Those are not .NET Framework assemblies but rather compile-time reference assemblies that provide API surface compatibility (assembly / type identity) for using existing libraries or packages on .NET Core. Some of these will work cross-platform (like code depending on System.Object being defined in mscorlib.dll which has been added for compatibility in .NET Core 2.0) and some may not. The SDK just adds all the facade / reference assemblies to the compilation to help resolve references during compilation. They do not actually contain any code. Even some dll files you can find in the actual .NET Core runtime may only contain type forwards and not actual implementations.

Also see Compatibility shim used by .NET Standard 2.0 for information about the compatibility mechanisms.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217