217

Closed

Allow specifying the folder where packages are installed

description

NuGet currently places packages in the solution folder. If you have many solutions in the repo that all use NuGet it leads to a lot of duplicate binary files in the repo. this slows down checkouts and can cause cluttering in the repo. Companies may also have existing policies for binary libraries in place.

If NuGet had the ability to configure the local path for packages these problems could be worked around. Such configuration could be placed in the exsisting packages.config file and perhaps in the global vssettings that are typically shared between team members anyway.

[global settings could then be copied to the local solution settings to make sure they are checked into version control]

Somewhat related to: http://nupack.codeplex.com/workitem/260
As that bug also discusses solution level settings, but different settings.

Note that this will not affect NuGet.Core but will be a feature of the VS integration.

file attachments

Closed Sep 20, 2012 at 7:24 PM by deepakverma
This is now in 2.1 release. 2.1 release notes would have more details on how to use it.

comments

justinc wrote Oct 9, 2010 at 12:59 PM

I voted for this but only if it can be done not at the expense of simplicity. Like maybe it goes to packages folder first but if there is an .nuconfig file where the packages folder would have been but with a different path in the config it will go somewhere else. I'm not really hoping to get extra popups or anything.

leebrandt wrote Oct 10, 2010 at 4:17 AM

Looks to be a duplicate of WorkItem 215

prabirshrestha wrote Oct 10, 2010 at 1:51 PM

.nuconfig file name might be a bit problem to windows users as windows explorer doesn't allow to create a file with only extension. though this could be solved by createing a file called nuconfig.txt then rename it to .nuconfig using dos/cmd.

rename nuconfig.txt .nuconfig
or if using bash
mv nuconfig.txt .nuconfig

just a bit much of work to win users. might be somewhat like nupack.config or something better.

aL3891 wrote Oct 11, 2010 at 11:46 AM

i didnt mean that is was to be called only ".nuconfig", i meant something like "packages.nuconfig" or something similar.
sorry for beeing unclear

aL3891 wrote Oct 11, 2010 at 11:47 AM

The discussion that lead to this workitem can be found here btw:
http://nupack.codeplex.com/Thread/View.aspx?ThreadId=229959

AnglicanGeek wrote Oct 11, 2010 at 6:32 PM

I closed 217 as a duplicated of this work item.

dcjulian29 wrote Oct 11, 2010 at 8:28 PM

The idea behind 217 was similar but not a duplicate IMHO as this talks more about shared locations/source repositories and solution/project settings. However, I can add my comments here just as easily...

I prefer to keep my third-party libraries in my /lib directory as opposed to /packages directory. I also prefer to keep my libraries with the project that they are used in even though this can cause duplication within a source control repository since I don't always update the libraries I use across every project in the repository. I propose a simple setting in a "nupack.config" file which would have global settings as to folder location to store packages downloaded via nupack.

Haacked wrote Oct 12, 2010 at 9:20 PM

Currently punting this to vNext. Definitely want to do this, need to define a spec for it.

Haacked wrote Nov 4, 2010 at 11:35 PM

Due to massive votes and feedback, we're reconsidering this one.

We don't have time to do the full out implementation for v1, but we can perhaps provide a "hidden feature" where a special nuget.config xml file in the same location as your .sln file will allow specifying the package directory. In the first implementation, there's no tooling support for setting this, so it's a completely manual process.

This file would only have one setting: <packagesDirectory />
This would be a relative path to the solution file. We don't support absolute paths.

<configuration>
<packagesDirectory>lib/packages</packagesDirectory>
</configuration>

dfowler wrote Nov 5, 2010 at 4:17 AM

We'll support both absolute and relative paths, but repository is still per solution, that means when you uninstall the last package from a particular solution, it will removed from this repository.

prabirshrestha wrote Nov 5, 2010 at 8:01 AM

i prefer lib to packages.
but can we add one more extra character and change it to "libs" - the plural form.

bxyoung wrote Nov 10, 2010 at 7:01 PM

@dfowler - I'm glad that you'll be supporting absolute and relative paths but the per solution part confuses me.

We have a couple applications here that have multiple solutions but share projects.

sln 1 - proj a : proj b : proj c
sln 2 - proj b : proj c : proj x
sln 3 - proj b : proj c : proj z

If Project B could have it's nuGet packages installed to C:\ProjectX\<lib>\<packageName>\dlls - then all 3 solutions could call from this repository. Then if packageY is updated from any of the solutions it would update the local repository and all 3 solutions would still be able to build without going to each solution and requesting a new update and all the code is happy.

Haacked wrote Nov 10, 2010 at 10:56 PM

@bxyong are all three of your solutions in the same directory? As in, are the three different .sln files in the same folder?

dfowler wrote Nov 11, 2010 at 8:46 AM

We've gone back and forth on this and have finally come up with a solution that will solve world hunger and fix everyone's problems :).

dfowler wrote Nov 15, 2010 at 12:37 AM

Fixed in CS b31f5bcee0a5 - 13c3faa59011

bradleylandis wrote Nov 19, 2010 at 6:56 AM

So was the solution described by Phil (concerning the nuget.config file) the one that was implemented? I updated to latest version and gave this a shot, but couldn't get it to work. I am having trouble finding it in the documentation.

dfowler wrote Nov 19, 2010 at 3:22 PM

There's no docs for this feature as yet. Add a nuget.config file next to the solution with this:
<settings>
<repositoryPath>{some path here}</repositoryPath>
</settings>

bradleylandis wrote Nov 20, 2010 at 3:35 AM

I apoligize for my ignorance in advance, but I am still having problems. I noticed that this was checked in after the 0.2 CTP build so I am trying to install a later build. I am using Visual Web Developer Express. So I grabbed the latest build and double click on the vsix file and I get "This extension is not installable on any current products". I then went and grabbed the 0.2 CTP build from the build server and clicked on the vsix and I get the same thing. But I can install that build from the Extension Manager inside of Visual Web Developer Express. Is there a special procedure for installing from a vsix file with Visual Web Developer Express?

AnglicanGeek wrote Dec 5, 2010 at 5:06 AM

Moving back to triage so we can move it to vNext and spend some more time on the design.

Haacked wrote Dec 6, 2010 at 9:23 PM

We need to spec this out more.

dmarsh wrote Dec 10, 2010 at 6:44 PM

The omission of this feature from V1 completely prevents our, and I'm sure many others, ability to adopt NuGet within our shop. I think you guys might be overthinking the feature too much if it's that complicated to get in. Just needs to allow specifying another folder where downloaded packages will be stored and then shops like ours can just point to that as a reference folder for projects manually. Sure it could be fanicer, but no more than what I described is necessary for V1.

Just upset that this is the top voted feature, it was being worked on and then it gets pulled right before you announce the RC for V1.

AnglicanGeek wrote Dec 10, 2010 at 7:11 PM

dmarsh, I'd like to understand what is blocking your adoption, as it helps me to test it and be a good customer advocate within the team. Do you plan to keep only NuGet packages in the custom folder, or also manually manipulated libraries? Are you planning to share it in some global location to share across solutions? Or is it purely a cosmetic, naming issue -- that you don't like "packages". We decided not to support the feature for this release because the first two still have potential problems we didn't have time to work through. We do know this is an important feature, and we do pay attention to the votes.

dmarsh wrote Dec 10, 2010 at 8:35 PM

AnglicanGeek, thanks for your interest.

Specifically, the biggest problem I think we have is that we don't believe plopping binaries and other related package "droppings" into every source control tree we're working in is a good practice. Sure there are benefis for simpler projects or devs doing demos and the existing model works great for them, but for those of us that manage large scale projects with source control and build servers it would be more beneficial to just point to the reference path of already downloaded packages. So, we would like the ability to download the packages to the build server at a common location and then just ensure that our automated team builds point there as a reference path. Similarly the developer, who may work on several different projects all using Ninject.MVC3, would be able to setup to download packages to a single directory on his local dev box and then know to reference from there for his local builds.

I'm gonna fork and see if I can add the feature myself, but I don't really have that much to dedicate to this. :(

Thanks again for listening.

Haacked wrote Dec 10, 2010 at 10:45 PM

@dmarsh. WE've actually partially implemented this feature in 1.0, but we left it undocumented and unsupported because we found some tricky design issues we need to work through. I don't recall exactly what they are. If you look at the source though, you may be able to figure out how to enable this.

In the meanwhile, I hope to write a spec soon describing the behavior so people can try it out.

serialseb wrote Dec 14, 2010 at 11:52 AM

See what I think about this at

patearl wrote Dec 14, 2010 at 10:35 PM

Being an ISV, we have many (like 50) solutions that share a set of common libraries, which in turn have dependencies on third party libraries. Even within a single project there can be different .sln files due to the number of .csproj files involved. Some combination of relative paths and per-solution settings would be greatly appreciated. Looking forward to the support of this scenario.

mmezzacca wrote Feb 11, 2011 at 1:52 PM

@Haacked Any update or timeline on this?

Haacked wrote Feb 11, 2011 at 3:37 PM

No, we've found some potential issues with it so we're not going to document it until we address it.

zam6ak wrote Feb 15, 2011 at 2:51 PM

Any updates on this?
Is the undocumented solution mentioned below working?

I would also prefer "Libraries" instead of "packages" but if the XML configuration @Haacked mentioned works this would be even better (one can decide which folder to use relative to solution file)

Also, there should be a way to allow project to override solution dependencies so if your solution has 10 project and they all use Commons.Logging 2.x but 1 project uses 1.x you can override it for that project

Good stuff - keep at it!

vitor_canova wrote Feb 22, 2011 at 7:59 PM

We have a issue here. Imagine we create a solution App1 with a console application called App1 and a class library called BLL. After that we add a nuget package in both (Entity Framework for example). Another day we create a new solution App2 with a console application called App2. We add the BLL to this solution. We add the same package in both (BLL already had). In the end we will have App1 with the packages of App1 and BLL and App2 with the packages of App2 but with the BLL points to the packages of App1. We imagine in the source control something like that: App1, App2, BLL. It will be very good if we could have the packages near that.

vitor_canova wrote Feb 25, 2011 at 1:40 PM

The "hack" introduced by Haacked and after "documented" by dfowler works great for us. Right now we can download all the packages from our SVN repository and add references to it with NuGet without need to have the packages in all solutions.

Thank's guys, you are doing a very good work here.

Haacked wrote Feb 25, 2011 at 4:01 PM

Glad it's working for you. But want to give you fair warning. Until we include it as a full feature, it's not supported and future versions of NuGet could break you.

vitor_canova wrote Feb 25, 2011 at 6:55 PM

Don't worry. We know about this. Actually we use Nuget only for internal packages. If it break us in a future version it isn't a great problem. We can change manually without problem.

Thank's for your concern ;)

vitor_canova wrote Feb 28, 2011 at 7:40 PM

I celebrate too soon. It does't work for me with Team Foundation Server. I tried many times.

tathamoddie wrote Apr 29, 2011 at 1:10 AM

I wish I could vote this down. It's just resistence to change.

Quoting from further up: "I prefer to keep my third-party libraries in my /lib directory as opposed to /packages directory. I also prefer to keep my libraries with the project that they are used in even though .."

People are just looking for knobs and dials for the sake of something to tweak because they feel like it. To all of them: move on and solve some issues that actually matter.

mlangsworth wrote Jun 20, 2011 at 12:18 AM

@tathamoddie I don't see how being so aggressive, emotive and above all presumptuous, is constructive. Thankfully not all MVPs are like you.

For us, the problem results from a nuget reference being project-based, not solution-based. You see I cannot use nuget and at the same time have all projects in my solution pick up references from a single source of truth (ie a single directory). Instead, if I understand correctly, because I have to add a nuget reference to each, and I also have to update each separately if I need to? If that's the case, this is the deal-breaker we're talking about.

So if you could specify a nuget package directory, and you updated the reference in just one project reference, all projects would of course pick up that updated package.

Haacked wrote Jun 20, 2011 at 2:27 PM

@mlangsworth That's not how NuGet works. The references are solution based. Every project within a solution references the assembly from the same place, the packages directory. In NuGet 1.4, we support updating a project within all projects at the same time.

monoman wrote Jun 20, 2011 at 7:20 PM

Yes this could be useful, but less with 1.4, nevertheless we adopted the inverse: we have an "internal source" that is kept in version control and all solutions have a copy of our customization of the NugetPowerTools msbuild targets files, that update from this "internal source" which is also the top source on the Package Manager dialogs too. As we have most of our projects still targetting the 2.0 framework we also put in that "source" some custom packages with older versions of open-source libs like nHibernate 1.2, that we need.

ahsteele wrote Sep 1, 2011 at 3:22 PM

@monoman are you saying this is no longer worth doing because of features added in version 1.4? What feature specifically?

psBrian wrote Sep 8, 2011 at 3:17 PM

Seconding the request to explain how 1.5 fixes this. It seems to still be broken. If I have a shared project Shared.csproj that is referenced in two solutions: foo.sln and bar.sln, every time I update foo I break bar's references and vice versa. That's a pretty big problem for any company that has non-trivial solutions.

danthman wrote Sep 15, 2011 at 12:31 AM

After reading through all this, I'm really not clear on where things stand right now. It doesn't seem like the changes in v1.4 have anything to do with this topic. In my particular case, I have some external shared libraries that I wrote that are not in my solution folder. I also have third-party libraries that are used by (1) the projects in my solution and (2) my external shared libraries. I would like my external shared libraries to have their own dedicated "packages" folder. The way it works now, when I use NuGet to add a package to one of my external shared libraries, it goes into the packages folder of whatever solution I happen to be working on at the time. To me, this is unexpected behavior because the shared library's project folder is not inside the solution folder. I don't care what the name of the folder is (although it's always nice to be able to customize such things), but I do care that I can't choose to have the "packages" folder either at the solution or the project level. This could be handled with a pair of radio buttons: ( ) Install this package in [Solution Folder]/packages or ( ) Install this package in [Project Folder]/packages.

dineshdhamija wrote Sep 21, 2011 at 6:09 PM

+1

nabog wrote Oct 6, 2011 at 2:54 PM

I would really like to do away with the "package" folders and the config files altogether. Any configuration should be specifiable via Tools >> Options >> Package Manager.

I navigate down my folder structure hundreds of times over the course of a month, and would rather not have it cluttered up.

The packages.config that's been added to the ASP.net project is truly a terrible idea. That has nothing to do with code.

Haacked wrote Oct 6, 2011 at 6:24 PM

@nabog where would you propose we store that information so that when the next person gets latest, their project is in the same state as yours? For example, if you go to Tools | Options and change the folder, that setting only applies to your Visual Studio instance. On another person's computer, it'll be a different folder unless you ensure that every person on every project you work on uses the same folder.

nabog wrote Oct 7, 2011 at 8:49 AM

@Haacked, I see what you mean: tools options are user specific so that won't work. What I was trying to say is that Nuget could be more tightly integrated with Visual Studio, so that the internals are hidden from the users. Perhaps the package configuration could be added to the solution file (<filename>.sln)? Clearly in order for the solution to build it must have access to all the downloaded binaries, so this seems consistent.

Haacked wrote Oct 7, 2011 at 7:00 PM

Except that NuGet doesn't depend on Visual Studio. For example, we have NuGet running as a web page as part of ASP.NET Web Pages. Web Matrix has a NuGet feature. Folks are building systems on top of NuGet such as this deployment system named Octopus: http://www.paulstovell.com/octopus/intro

If we made the .sln file contain all the NuGet systems, we effectively cut off this entire rich ecosystem of products building on top of NuGet.

healyje wrote Oct 21, 2011 at 6:43 PM

Gotta go with supporting this one. Really want control over the package repository that would extend across all users. The nuget.config is good for the moment...

Minnow wrote Oct 26, 2011 at 9:26 PM

There is a question on stackoverflow like this issue. I thought it would be good post a link to it here. Some might also want to see my answer to it, as I use the nuget.config feature documented here to answer the question.
http://stackoverflow.com/questions/6277925/nu-get-issue-with-project-level-dependences-for-projects-referenced-by-multipl

I wanted to solve this problem because I myself had the problem, so I actually use my answer (it's not just theory).

WayneBrantley wrote Jan 3, 2012 at 2:46 PM

With the new NuGet Package Restore workflow, you no longer check in the dependencies, so this would be a non-issue, right? (Unless you are trying to save a few kb of disk space)

brugidou wrote Jan 27, 2012 at 8:49 AM

What about having a system-wide repository defined by some env variable %NUGET_REPO% that is defined when you install nuget (via the VS extension or via nuget.exe) ?
This in combination with the restore feature will do.

peter172sp wrote Apr 23, 2012 at 3:49 PM

I'm on a very large project with 27 solutions and 583 projects. This is too big to put into one solution so there are shared projects that are in multiple solutions. We are working on packaging up many of the shared projects into NuGet, but still in the end there will be some shared projects that we prefer to be part of the main build. We are also using NuGet Package Restore.

I've identified one solution as being the primary solution for each of the shared projects. This is where it should get its packages and this is where changes, like adding NuGet references, should occur. Now if I build my solutions in a certain order I can make sure the packages get restored to the right place prior to re-building a shared project in some other solution. (see http://nuget.codeplex.com/workitem/2003 for a workaround that makes the build order less critical)

Here is where it gets really messy. I open a solution that contains shared projects (not the primary solution). I then do the update-package command. Now the shared projects contain a mixture of assembly references. Some point to the primary solution packages folder, some point to the package folder in the current solution. Now there is no order in which I can build solutions that will guarantee that the packages get restored to the expected locations. Package restore only restores packages to the current solution, not to the locations pointed to by the projects (even my workaround mentioned above assumes each project only uses one packages folder). If I had carefully done the update command in the same order that I built solutions this might avoid the problem, but I can't enforce this with all 100 developers on the project. It would be very easy for a developer to inadvertantly introduce this problem, and difficult for the developer to fix the problem. This actually happened to me and it took a full day to clean it up.

The fix is to use the "hidden feature" to specify the repositorypath in nuget.config in combination with the workaround described in http://nuget.codeplex.com/workitem/1990.

It seems to me that fixing issue 1990, so that Package Restore uses the repositoryPath from nuget.config, would then resolve this issue (providing you document the hidden feature).

Am I missing anything?

davebo wrote Apr 27, 2012 at 3:54 PM

If the NuGet.targets file is modified to not override a previously set PackagesDir, then the .user files could be used to set the location of the PackageDir.
i.e.
instead of: <PackagesDir Condition="'$(OS)' == 'Windows_NT'">
use : <PackagesDir Condition="'$(PackagesDir)' == '' And '$(OS)' == 'Windows_NT'">

.user file would then contain (for example)
<PropertyGroup>
<PackagesDir>C:\NuGet_Packages</PackagesDir>
</PropertyGroup>

In addition to the ability to override PackagesDir via the .user file, I think it would be useful to be able to set it globally in %APPDATA%\NuGet\NuGet.Config . I'm not sure if that's feasible, though.

cordifed wrote Jun 8, 2012 at 9:16 AM

Doesn't Package Restore eliminate this problem?

ecsousa wrote Jun 13, 2012 at 12:29 PM

Hello,

I have modified Nuget.targets in order to read the the repositoryPath form nuget.config so it will restore packages to same directory it was configured to download the first time.

I think this could help this issue: use the modified version of Nuget.targets, and configure a repositoryPath in nuget.config in every solution.

pranavkm wrote Jul 11, 2012 at 3:17 PM

@cordifed Not necessarily. If you have projects shared between solutions, you would need this.

TysonStolarski wrote Jul 20, 2012 at 12:26 AM

Copied from this thread: http://nuget.codeplex.com/discussions/261930

"Isn't a simple solution to this problem allowing the packages.config file in each project to specify an optional <installPath> element? If it is present, it will install all the packages referenced by that project into the specified path (relative to that packages.config file). If it isn't present, it falls back to the solution level install path.

This does mean you may end up with multiple projects containing multiple copies of the same dependencies (if you specify a local '.\packages\' folder for each project) but with Package Restore that doesn't matter as they shouldn't be committed anyway. And if you still did want a single shared 'lib' or 'packages' folder, you could still specify that with relative paths from the project directory. And because each path is relative to the project that specifies it, it works globally, regardless of how many solutions in various locations reference these projects."

pranavkm wrote Jul 31, 2012 at 2:11 PM

Fixed in changeset ceae8687f38a

firefox_xb9r wrote Aug 8, 2012 at 1:40 AM

This is great, exactly what I'm being required to do. I don't really care where my external packages end up as a developer BUT our configuration management team is very picky.

So I've taken the nuget.targes file and substituted it but no matter what I do I can't make Nuget change the packages file location. This is my last chance to get builds working with nuget before we are all forced to link each external connection by hand and install the packages from .zip files into an Externals folder.

Given my solutions file structure;

c:/src/branch/Solutions/MySolutions/.nuget/nuget.config
c:/src/branch/Solutions/MySolutions/.nuget/nuget.targets
and
c:/src/branch/Solutions/MySolutions/solution1.sln
c:/src/branch/Solutions/MySolutions/solution2.sln
c:/src/branch/Solutions/MySolutions/solution3.sln
c:/src/branch/Solutions/MySolutions/solution4.sln
...

and packages need to be installed in;
c:/src/branch/External/MySolutions/packages

What do I do to achieve this objective?

ferventcoder wrote Aug 8, 2012 at 4:45 PM

This doesn't work until nuget 2.1 is released. Until then see the dirty hack: http://nuget.org/packages/NuGetPackageFolderOverride

dnaumov wrote Feb 13 at 7:59 AM

It's still doesn't work. Don't know how you check it, but if Visual Studio Package Manager still adds new references to .csproj and writes hints to assembly as relative path from 'packages' how is it supposed to work with different repository location?

http://stackoverflow.com/questions/4092759/is-it-possible-to-change-the-location-of-packages-for-nuget/14849686#14849686

nikolawannabe wrote Mar 22 at 2:09 AM

I can confirm that this does not work. I set it up as specified in the documentation. When I install a package from the Package Manager Console, it installs to the packages folder still (even though I deleted the packages folder). If I build the application, it does download the packages to the location I have configured, but all the references are still pointing to the packages folder, and now I have packages in both places.

mahara wrote Mar 22 at 5:14 AM

@nikolawannabe How do your configuration look like?

linnestjerna wrote Mar 22 at 9:55 AM

My package manager has stopped respecting the nuget.config file that I have placed in the same folder as my solution, the config file used to work fine. 
<?xml version="1.0" encoding="utf-8"?>
<settings>
  <repositoryPath>..\Lib</repositoryPath>
</settings>
I have tried to alter the nuget config in my .nuget folder with the following:
<configuration>
  <config>
    <add key="repositoryPath" value="C:\thePathToMyPackagesFolder" />
  </config>
</configuration>
but this does not seem to work. I seem to me that the configuration of nugets package repo is broken.

mahara wrote Mar 22 at 12:12 PM

@linnestjerna This is my working NuGet.config file looks like (that I put in the root folder of my project source code):
<?xml version="1.0" encoding="utf-8"?>

<configuration>
  <config>
    <add key="repositoryPath"
         value="..\lib\NuGet\packages" />
  </config>
</configuration>
Perhaps, you're missing the xml definition tag in your NuGet.config file.

linnestjerna wrote Mar 22 at 3:04 PM

@mahara I omitted it during my post, but I 've double checked and I do have the xml tag in my file :)

linnestjerna wrote Mar 22 at 3:20 PM

@mahara sorry didn't see your post, tried taht but no. it does not work for me.

this is my folder structure
Lib\
 |
+----CommonLib.1.0.0.0
 |
Source\
 | 
+----- Product A
 |             +Project One
 |             +Project Two
 |
+----- Product B
 |             +Project Three
 |             +Project Four
 |
+-----  ProductSharedProjects
 |             +Project Five
 |
 Product A.sln
 Prpduct B.sln
And my package manager keeps installin in Source\packages no matter what I do. And as I posted yerlier it has worked.

my work around is to manuelly edit each proj file after I install and I have modified the nuget.targets to find my lib path.

my nuget Version is 2.2.40207.9053

mahara wrote Mar 22 at 3:49 PM

@linnestjerna Hmm... it's still weird to me it didn't work out for you.
My NuGet version is 2.2.40116.9051; not sure why you have a slightly different minor version.

My project structure is similar like that: lib, src, etc., except that I put the solution files inside the source folder.
Also, where do you put your NuGet.config file? For me, I put it in inside the source folder as well.

After that, all installed packages are put inside lib\NuGet\packages folder. Even when I install Fody extension, it's put inside lib\NuGet\Tools folder; not sure how it would figure it out automatically. But the thing is that it works for me, just as expected.

Could it be a new bug in the latest NuGet version you installed?

nikolawannabe wrote Mar 27 at 9:31 PM

@mahara My config is a standard Nuget.Config, it is located at the root of my TFS branch and contains the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositorypath" value="3rdParty\Nuget\" />
  </config>
</configuration>

Sign in to add a comment