Location of files

May 5, 2011 at 7:37 PM


When adding a package, all scripts are added to the scripts folder, styles to the content folder etc. If you want another location of the files, you will lose the ability to upgrade and remove packages using the tools. I think that the best would be to be able to override locations for specific file types in Nuget settings.

For example:
*.js             ~/scripts
*.css           ~/assets/styles
*.png|*.gif   ~/assets/images

If the package contains any files of these types, the settings should override the standard settings.

There could be some problems with this approach though. What if you need to have different locations for different projects? What if the package requires the scripts to be in certain folders?

The first problem could be solved by having a local nuget.config file, with settings for the current project. The file could be checked in to the source control, which would allow all team members to have the same locations as well.

The second problem would need the package creators to make those certain scripts to be "sealed", so they can´t be overridden.

Any thoughts?

Jul 12, 2011 at 10:42 PM

Reviving this discussion. There's several questions we need to resolve:

  1. Solution level setting? Project level? Machine Level? Or all three? My vote would be to start at solution level and require all projects to follow the convention specified in the solution.
  2. Where's it stored? Perhaps a nuget.config file alongside repositories.config?
  3. Do we have UI to specify these? We should definitely consider adding a settings dialog for it. But for now, I'd suggest we don't have any UI for the first iteration.

Proposed setting format:


<contentMapping default="~/assets">
  <map extension="js" target="~/assets/js" />
  <map extension="jpg, png, gif" target="~/images" />
  <map extension="css" target="~/assets/css" />



Jul 12, 2011 at 10:53 PM

One issue if the settings are not saved at solution/project level is that if developer A installs, dev B may not be able to correctly uninstall/update because they settings may not match. So I'd avoid machine level here.

One other issue is that the original statement that "When adding a package, all scripts are added to the scripts folder, styles to the content folder etc" is not correct. Instead, they are added to wherever the package author placed them in the package.

If we start placing them in different location, it raises some tough questions. Do we completely ignore whatever path the package had them in? If we're not careful, we could end up flattening script/foo.js and script/sub/bar.js (coming from the package Content folder) into ~/assets/js, and lose the hierarchy, which is clearly not 'correct'.

I suppose we could special case the Script folder from the package, and only special cases files that are in there (and similar for css & images). So if you have script/foo.js and blah/bar.js in the package, you'd end up with ~/assets/js/foo.js and ~/blah/bar.js in the project. But that's just weird isn't it?

So I have to say this feature worried me a bit in term of having clear semantic. 

Jul 13, 2011 at 2:51 PM

As a package creator, I want to structure my contents in a way that makes sense to me. At the same time, the packate consumer would like some consistency in how new code is added to their project.

Instead of mapping by file extension, we can create "virtual" folders that will map to physical folders on install.

For example, in the contents node, the package creator will include files like:


The consumer would then define where $scripts, $css, $images, etc. are located in their project, and NuGet will install the content files appropriately.

Since the package creator won't know where the files are physically located, they should only reference files relative to their package folder. This is why I showed image.jpg in the $css folder. If you reference an image in your stylesheet it will be relative to the css file.

Anyway, I think having these "virtual" folders will give the desired flexibility to both producers and consumers.

What do you think?

Jul 13, 2011 at 4:07 PM
Edited Jul 13, 2011 at 4:20 PM

Interesting idea! So you’d do something like the following:


 And by default (aka without any mappings), would we remove the $ and just place them as-is?





But if you do apply a mapping, we’d move the folder to wherever you placed it. For example:

Mapping: $css -> ~/assets/css

In which case we’d create the assets folder if it didn’t exist and you’d end up with:


In the root of your target project (notice we maintain the directory structure within a “special” folder.

I’d also suggest that we only support this for top-level folders in the content directory. For example, we don’t do anything with:



Jul 13, 2011 at 4:14 PM

Yes, exactly. I think it's a nice convention and simple to understand.

BTW: Your image doesn't show up.

Jul 13, 2011 at 4:19 PM

Argh! Damn CodePlex! :( I updated it manually.

Jul 13, 2011 at 7:51 PM

Yes, that sounds interesting and probably not too expensive to implement.

Aug 16, 2012 at 5:40 AM

...FRRRRRRIIIING! (that was the light-boom flash caused by the flux capacitors of the time machine moving forward by a year...)

I like Kiliman's idea (and Phil's implementation)... Can we request David to push this with his magical Microsoft powers? :) 

Sep 11, 2012 at 9:59 PM

I do like kiliman's idea, but it doesn't necessarily solve the use-case I'm looking for.

Basically, I'd like to have jQuery install to my root /Scripts directory, but all jQuery plugins install to /Scripts/jQueryExt.

So I'd need to have a way to distinguish jquery-1.8.1.min.js from jquery.cookie.js.

Obviously a regex (or even basic wildcard support) would take care of this, but I'm unsure of the best way to handle configuration.

Apr 11, 2013 at 5:13 PM
Is there any news on this issue? Is it somewhere on a roadmap?
Apr 11, 2013 at 5:16 PM
Edited Apr 11, 2013 at 5:16 PM
It is on the roadmap, but we have decided when to do it. You can vote it up here https://nuget.codeplex.com/workitem/1914