This project is read-only.


Feature Request: Drag packages.config to Properties folder


I'd like to be able to drag the packages.config file into my project's Properties folder, but currently when I do this I get an error in the Add Library Package Reference dialog.

It would be even better if packages.config was added to the Properties folder to begin with, but I wouldn't mind dragging it myself.

Related discussions:
Closed Jul 5, 2012 at 6:21 PM by
Closing as won't fix.
  • We wouldn’t ever want to put packages.config in the properties folder by default because Web sites don’t have a properties folder
  • Enabling the file to be anywhere in a project would mean adding potentially expensive logic to NuGet to find the file


Jaykul wrote Jul 25, 2012 at 3:03 AM

That doesn't seem like a rejection that was discussed by a team of people. Do you guys talk these things over?

Why can't you just put it in properties folder by default, and if there's no properties folder put it in the root. Obviously checking for the existence of a properties folder isn't "expensive" and would result in this file being hidden from the project listing in Visual Studio. Considering that you practically never want to edit the file by hand, it intuitively belongs in the Properties folder anyway.

pranavkm wrote Jul 25, 2012 at 4:14 PM

My concern for this is having to now do lookups per project via DTE - one to check if it's in the root to continue supporting extant projects and one to check if it's in the Properties folder - and looking up things via DTE isn't necessarily inexpensive.

Are there specific concerns about having the config file in the project root? We could perhaps look at making the node Invisible (the VS project system supports a Visible attribute I think), but is it really that annoying to see an extra file in your project?

davedev wrote Dec 13, 2012 at 3:48 AM

My concern for this is having to now do lookups per project via DTE
Why would you have to use the DTE at all? Do a recursive search in the project directory for the first file named Packages.config. Its exact location doesn't actually matter, right? It's not like there's any reason it MUST be in the root?

is it really that annoying to see an extra file in your project?
Yes, it's pretty annoying, clutter. Its content should either be embedded in the project file with the rest of the project-related properties and references (preferred), or it should be a file in the Properties folder, or at least it should be hidden in Solution Explorer (that would be a bit lame though).
Currently, packages.config is the only file in all of my projects that I'm not supposed to edit directly yet it's always visible. For me, it's simply a matter of organization. It's frustrating that I can control every aspect of my project's organization in Solution Explorer except one strange file that I can't edit and it must always be in the root of my project. Essentially, NuGet doesn't properly organize my projects' settings and it doesn't allow me to organize them myself. I find this to be too restrictive.

davedev wrote Dec 13, 2012 at 3:50 AM

Please consider re-opening this issue so that it can gather feedback at least.

rlim00 wrote Aug 28, 2013 at 9:12 PM

I would also like to chime in. I also find the sight of the packages.config in my solution explorer window very annoying. Putting it in the Properties folder would indeed alleviate this visual issue. If you have many projects in a solution, each using NuGet packages, the sum of these files can take up quite a bit of vertical space in the solution explorer.

GjhKaal wrote Feb 11, 2015 at 9:51 AM

The problem is not where to put the packages.config file, but what packages.config file to use if two different projects (with different platform definitions, e.g. CRL4.0 and CLR4.5) share the same code files. It is now impossible to use two different build configurations, with the same packages.config file, unless you want to add/remove all packages in case of a package update.

  • use conditional compilation symbols, so more than one platform is supported
  • create copies of the project files, in the same solution folder
  • change the target framework in each project file to match the desired target
Now try to add nuget files...

davedev wrote Feb 11, 2015 at 12:46 PM

@GjhKaal That's an entirely different issue. The problem stated here is exactly the problem that I want fixed. I never use the same project folder to represent two different projects, for a number of reasons.