search

NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

NuGet should not apply binding redirects for class library projects #9706

Open vsfeedback opened 4 years ago

vsfeedback commented 4 years ago

This issue has been moved from a ticket on Developer Community.

adding or updating nuget packages creates app.config files for dll projects.

dll projects dont need app.config files. These files cause needless source control churn, so I delete them before commit. I dont want to keep deleting these files. Please stop creating them when they arent needed.

Original Comments

Visual Studio Feedback System on 6/1/2020, 01:03 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Fernando Aguilar [MSFT] on 6/5/2020, 01:29 PM:

​Thanks for your feedback, Andrew.

I imagine NuGet is trying to add binding redirects to the projects, as documented here.

Are you using packages.config-styled NuGet references? If that’s the case, is it possible to migrate to PackageReference? That way, all binding redirects are managed by NuGet at build time, eliminating the need of binding redirects provided in config files.

Andrew Stanton on 6/6/2020, 02:37 AM:

(private comment, text removed)

Original Solutions

Nikolche Kolev [MSFT] solved on 6/19/2020, 05:25 PM, 0 votes:

Thank you for filling this issue. This behavior is by design.

In packages.config NuGet is in charge of managing the binding redirects. Whenever a package change happens, NuGet determines whether a binding redirect is needed. NuGet will only apply the binding redirects when they are deemed necessary.

A sample that I tried out.

  1. Create a .NET Framework Class Library (.NET Framework 4.7.2)
  2. Observe that there is no app.config
  3. Install the Newtonsoft.Json package, version 12.0.3.
  4. Observe that there is no app.config.
  5. Install NuGet.Protocol 5.6.0.
  6. Because NuGet.Protocol itself depends on Newtonsoft.Json 9.0.1, NuGet decides to add a binding redirect.

You can consider disabling the NuGet application of binding redirects altogether with a NuGet.Config setting, see https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#bindingredirects-section

#### Andrew Stanton on 6/20/2020, 06:20 PM:

@Nikolche Kolev [MSFT] - does step 6 include creating an app.config file for a project type that does not make use of this file?

This behavior creates work churn (have to remember to delete it from the project before checkin) and source control churn (someone forgot to delete it and checked it in) for projects.that cant even use this file. Having to also deal with all of the vspscc and vssscc related churn that nuget creates is already a pain. Adding app.configs just piles on. Reformatting our config files when they didn't need it also piles on (i even offered working code - without condition - to fix that reformatting).

I hope you understand why I dont think that the intention of the design is to make more work for users by junking up the project files, and why this truly seems like an unintended side effect. I'm asking (again) to please fix some of these unintended side effects that constantly nag in my daily work and steal my time and attention.

chucklu commented 4 years ago

@nkolev92 Any update?

nkolev92 commented 4 years ago

Hey @chucklu, it's not something we are immediately going to be working on. We'd open to taking a PR. https://github.com/NuGet/NuGet.Client/blob/dev/CONTRIBUTING.md

chucklu commented 4 years ago

@nkolev92 Another side effect is, it takes too much time to do the package upgrade. I have 70 projects in one solution, and it takes more than 7 minutes to upgrade a package, although only 10 projects reference the package. I wonder if lots of time was wasting to check the bindingRedirect on non-relevant projects.

Time Elapsed: 00:07:37.3796247

KalleOlaviNiemitalo commented 3 years ago

Several projects that I maintain on .NET Framework use a *.dll.config file as the configuration file of a non-default application domain in which the DLL is then loaded. Especially for automated testing (NUnit Console uses the config by default) but also for isolating different versions of assemblies within the same process. I think all of those projects are currently using PackageReference and explicitly enabling AutoGenerateBindingRedirects, though, so they would not be harmed if NuGet stopped creating App.config source files in DLL projects.

zivkan commented 3 years ago

The binding redirects being discussed here are only about projects using packages.config. NuGet does this at package install time, and it modifies the app.config or web.config file that is part of your source control.

For projects using PackageReference, NuGet doesn't generate binding redirects, hence only the csproj will be modified in your source control commits. The .NET SDK (and I mean this in the generic sense, not the .NET Core or .NET 5 SDK, so this happens for non-SDK style projects too) might generate binding redirects in the output folder. This is an MSBuild feature, not NuGet.