17

I have a .NET Standard 2.0 project in my solution and I am using the IConfiguration interface. When I write the name VS suggest that I reference Microsoft.Extensions.Configuration.Abstractions.dll. If I do it is added under the reference node. However I can also add it as a NuGet package. Both ways seems to work. I assume that the reference VS suggests is added via the .NET Standard SDK that is referenced in the project.

Which is the recommended way to add that reference? What are the advantages and the disadvantages of each approach?

Stilgar
  • 22,354
  • 14
  • 64
  • 101
  • Im not giving answer on this because Im not sure, but I think that nuget will add reference to your project automatically, and I would prefer nuget since it allow to update package if there are new versions of it in nuget repo. – tym32167 Sep 20 '17 at 11:05
  • Where do you get the dll reference from? it should be a nuget package used in the .net standard project.. – Martin Ullrich Sep 20 '17 at 11:07
  • Also not going to give a direct answer but there are a few things such as 1. Nuget does solution wide reference restore 2. Adding via nuget adds the same dll as add reference 3. Easier to update / restore to specific version 4. During Continues Integration / Build Servers it pulls directly from nuget 5. If using a custom nuget feed you can isntall/update/restore from your own feed – Inept Adept Sep 20 '17 at 11:07
  • @MartinUllrich the reference comes from some folder like this Program Files\dotnet\sdk\NuGetFallbackFolder It uses the old Reference format in the project file rather than the package reference. – Stilgar Sep 20 '17 at 12:19
  • 1
    @MartynWeber my initial thought was to use the dll reference and in this way reduce the amount of dependencies and complexity of the build process. On the other hand now that I have looked at the way the project file references the package it may be simpler to reference as NuGet package. – Stilgar Sep 20 '17 at 12:20
  • @Stilgar I was of the same thinking, but one of the larger projects I have undertaken at my current position is to package alot of our current projects as nuget packages and with our CI system it was easier to set solution level references If I could of written a well defined answer like MartinUllrich I would of posted it as an answer but a few to many beers clouded my ability to write coherently :D – Inept Adept Sep 21 '17 at 11:16

1 Answers1

10

Referencing a DLL directly from a NuGet package that was downloaded manually, or is installed in a known location, can speed up the restore and build process but has a few dangers.

There are a number of things that a NuGet package can do when referenced that a DLL file cannot. If you want to reference a DLL from a package, make sure that the package does not do one of the following / account for the following possibilities:

  • Additional NuGet packages can be pulled in as dependencies. If you upgrade the DLL from a newer package, you need to check if dependencies have changed and update the project accordingly.
  • NuGet packages can provide different reference and implementation assemblies - e.g. a NuGet package may give an "API surface" dll in its ref/ folder and then contain different implementation assemblies for .NET Framework .NET Core, Xamarin and more in its lib/. folder. You have to be careful to select the correct DLL file to reference for the project type - a .NET Standard library may need to reference a ref-assembly (e.g. ref/netstandard1.4/foo.dll during compile time and a .NET Framework application that uses this library needs to reference the assembly from e.g. lib/net452/foo.dll.
  • NuGet packages may contain additional runtime-specifics and/or target framework specific content that is added to the build-output. This can be native libraries (.dll on windows, .so on linux etc. - from a runtime/ subfolder) or any content file. Getting this right without NuGet is tricky, since the .nuspec file can also define build actions for content files.
  • Build logic can be included in NuGet packages that set certain properties or execute targets during the build that is necessary for the product to be used correctly. This is impossible to do manually without editing the .csproj file in the right way.

If the NuGet package does not use any of the above (which you need to check manually), you are generally safe to reference the DLL instead. However, updating the DLL and its dependencies is a lot of work and easier to do with NuGet.

Additionally, you mentioned that you reference directly from the nuget fallback folder from the .NET Core tooling. This folder is not guaranteed to contain specific versions of the DLL in other installations (depending on the SDK versions installed) and may even be installed in a different location on different machines, rendering your project file unusable for other people working on it (as well as building on non-windows machines).

Joel Verhagen
  • 5,110
  • 4
  • 38
  • 47
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Thanks, it seems like referencing the NuGet package itself is the clear way to go. I would have done this to begin with but VS suggested this fix (referencing the dll directly) so I wondered if I am doing it wrong if the tooling prompts me to do otherwise. – Stilgar Sep 20 '17 at 14:57
  • Can we add a Precompiled view in a Nuget package and refer to that Precompiled view in the installed application. – Dhanil Dinesan Jul 02 '21 at 16:11