8

I have a question so that I can better understand NuGet packages, packages.config and the .csproj file.

It is my understanding that the setting in the NuGet Package Manager >> General for default package management format determines if your project uses packages.config or the .csproj file for resolving and restoring packages. In my project we have selected Packages.config.

No problem it compiles and runs. So I decided to test if it would run without the reference for a dll in the .csproj file, as it is my understanding it does not use or need this. This is an incorrect assumption as though the package is in the packages.config file, when I removed the reference in the .csproj file there was an error in my project and the project would not compile.

I also noticed that if the dll is not in the references in the Solution Explorer that it fails to compile as well I( I assume these are the .csproj references).

So I am not clear on the role of the .csproj file for a Packages.config Management format for NuGet packages and the references in Solution Explorer.

Darren
  • 1,352
  • 5
  • 19
  • 49
  • 1
    To be 100% clear: Are you talking about .NET Framework or .NET Standard/Core? – ProgrammingLlama Jul 27 '18 at 01:34
  • 8
    When you add a Nuget Package reference to the project, Packages.config is modified to show update the list of Nuget packages being used by the project and .csproj file is modified to add the path of the library belonging to the package. So if you manually modify the .csproj file and remove the DLL reference it will surly break because having entry in packages.config is different then having reference added to the .csproj file. The Nuget package my have multiple libraries targetting different .NET framework so when you add package .csproj file will have appropriate library referenced. – Chetan Jul 27 '18 at 01:34
  • @john It is .Net Framework – Darren Jul 27 '18 at 01:37
  • So my next question is why does Nuget when I restore packages not add an entry in references in .csproj file? Is that just a glitch that happens sometimes? – Darren Jul 27 '18 at 01:40
  • I just edited last comment to *not – Darren Jul 27 '18 at 01:41
  • @Chetan Ranpariya would you like to post your comment as an answer – Darren Jul 27 '18 at 02:59
  • 1
    just ran into this as well, super confusing. makes you appreciate npm – ihor.eth May 08 '23 at 19:36

2 Answers2

8

The difference is on how you manage your NuGet references.

Before VS2017 the information what NuGet packages to be used during assembly was stored in files packages.config.

Since VS2017 there is a new option called package references which stores this information in the project (.csproj) file.

https://devblogs.microsoft.com/nuget/migrate-packages-config-to-package-reference/

MerlinC
  • 96
  • 1
  • 3
7

Before VS2017 and .NET Core, NuGet was not deeply integrated into MSBuild so it needed a separate mechanism to list dependencies in a project: packages.config or project.json. Using Visual Studio solution explorer's References context menu, developer adds .csproj references to restored packages in a solution-wide folder managed by NuGet.

The reference added to the project file .csproj by Visual Studio looks like this:

<Reference Include="EntityFramework, Version=6.0.0.0"><HintPath>..\packages\EntityFramework.6.4.4\lib\net45\EntityFramework.dll</HintPath></Reference>

Starting with VS2017 and .NET Core, NuGet becomes a first class citizen in MSBuild. NuGet package dependencies are now listed as PackageReference in the SDK-style project file .csproj

A reference now looks like this:

<PackageReference Include="EntityFramework" Version="6.4.4" />

JuanG
  • 71
  • 2
  • 3
  • `developer manually integrates MSBuild` Can you add a code snippet example of this? – ryanwebjackson May 10 '22 at 19:31
  • 1
    @ryanwebjackson updated answer with sample snippets. There is no C# code involved here because MSBuild uses XML to describe a C# project. – JuanG Jul 08 '22 at 05:48