I was having trouble with nuget Visual Studio 2017 and wanted to test if it was our proxy server or not. I downloaded nuget.exe and dropped it at the root of my C drive. I executed nuget.exe install Microsoft.AspNetCore and it asked for my proxy server username and password. I supplied it, and it proceeded to create dozens of directories in C:\ with that package and all of it's dependencies (can I get a DOH!) Problem is, there's no uninstall in nuget.exe. The package manager in VS isn't available unless you have a solution open, and the package manager console (powershell) won't uninstall unless you have a solution open. Can I just clobber all those directories and their contents? Or will that just make things different and somehow worse:
Can I just clobber all those directories and their contents? Or will that just make things different and somehow worse
Yes, you can (If you confirm that you no longer need these packages).
According to the document install command (NuGet CLI):
The install command does not modify a project file or packages.config;
in this way it's similar to restore in that it only adds packages to
disk but does not change a project's dependencies.
When you use nuget.exe install some packages, it just download those packages to the disk and not change anything in the project, this is similar to some files you downloaded from the internet.
So, if you do not need those packages any more, you can just delete them from the disk manually.
Besides, there is an option delete command (NuGet CLI), which can be used to deletes or unlists a package from a package source. The exact behavior depends on the source. For local folders, for instance, the package is deleted; for nuget.org the package is unlisted. But it only delete the file .nupkg and will keep the folders and other files of other packages, like lib folder. If you want remove the package completely, just delete those packages manually.
Hope this helps.
Related
Let's say I have a solution called MyFirstSolution and inside I have project with name MyFirstProject. Inside that project I'm installing nuget packages like Dapper, EntityFramework etc...
How things should work:
packages folder should be created into the folder MyFirstSolution and inside should be downloaded and installer all nuget packages referenced into the project.
The problem I'm having is that the packages folder is not created and the nuget packages are downloaded one level above the MyFirstSolution folder into some folder called XYZHelper.
When I download a solution from some repository nuget packages are restored to that same folder, not to the solution itself and references in csproj file says that they should be in solutionFolder\packages so all of my projects don't build.
If I copy the packages manually to the folder that they should be, it's all good but after every build a copy is made into that XYZHelper folder.
I don't have any postbuild events or anything like it configured into the projects. It is something with the visual studio I guess, but I can't figure out what.
How things should work: packages folder should be created into the
folder MyFirstSolution and inside should be downloaded and installer
all nuget packages referenced into the project.
Hi Stdfan, not sure about your VS version. But for VS2015 and earlier versions, the nuget packages are controlled by packages.config file. And things should work like what you mentioned.
But for VS2017 and VS2019, they have two methods to manage nuget: Packages.config and PackageReference. And for PackageReference format, the packages are stored in C:\Users\xxx\.nuget\packages. So if your vs version is VS2017 or VS2019, you can try if changing the format to PackageReference help resolve this issue.
The problem I'm having is that the packages folder is not created and
the nuget packages are downloaded one level above the MyFirstSolution
folder into some folder called XYZHelper.
Direction1:
Like zivkan suggested,I also think something affects the restore process.Normal for Packages.config format, the folders would be stored in packages folder. But according to
this document, we can customize nuget.config file to control nuget behavior. So please check locations where nuget.config exists,there might be some changes in the nuget.config for computer or some settings in nuget.config for users which causes this issue.(The nuget.config for user won't exist unless we create it there)
Direction2:
When I download a solution from some repository nuget packages are
restored to that same folder
As the restore process is invisible in build output, so there is possibility that the nuget restore works well, but something in build process move the content of packages folder into XYZhelper.
Check customize your build. Please check your directory structure for the Directory.build.xx file, it can affect your build process if it exists in any folder of the structure: C:\xxx\lancel\source\repos\
I don't have any postbuild events or anything like it configured into
the projects. It is something with the visual studio I guess, but I
can't figure out what.
This is not about VS normal settings. I think some custom file causes this issue(no matter nuget.config or directory.build.xxx), and please check if you've installed any third-party software or vs extension. Try close vs, delete the .vs, bin and obj folders and then run vs as safe mode.
Target folder of nuget packages can also be set using the envirenment variable NUGET_PACKAGES.
And you can do this in your existing project-file like this:
<Project Sdk="Microsoft.NET.Sdk">
...
<Target Name="NugetPublicfolder" BeforeTargets="PreBuildEvent">
<Exec Command="SET NUGET_PACKAGES=C:\MyProjectA\libraries\"/>
</Target>
...
</Project>
Now when you build/publish the project the libraries will be placed in C:\MyProjectA\libraries\
Actually the nuget packages are first downloaded to the socalled http-cache folder (%userprofile%\AppData\Local\NuGet\v3-cache), where it will be extacted from to the above folder (which is called the globalPackagesFolder folder)
The solution packages folder can be changed with a nuget.config (the setting name is called repositoryPath). So, check for nuget.config files that might be setting this value. You can get an exact list of nuget.config files used by a restore by downloading nuget.exe from nuget.org/downloads and running nuget restore MyFirstSolution.sln. Near the end of the output it will list every nuget.config file that was read.
When there is no config file that changes the solution packages folder (repository path), it always defaults to a subdirectory named packages in the same directory as the .sln file. The only way I know of to change this location for packages.config projects is with a nuget.config file, so I feel confident you should be able to solve it by finding the right config file.
I've tried with Nuget Update, Nuget restore, but they are actually not the same and here's why:
I've created a Nuget pkg only to distribute an executable file. When I install the Nuget the executable is added to my project so I can reference it and run it within my application.
Now, I don't want that every developer has to install the Nuget to have the executable in their project, but I just want the .exe to be added when the project is built. And of course, the reference to the package in the config file is present.
If I run Update-Package -Id -reinstall(using the Package Manager of VS) a folder with the .exe is added to the project root, but if I do nuget update or nuget restore (using the nuget CLI) it only re-add the .exe into the packages folder.
The reason why I need to run the nuget CLI is because I'm using TeamCity and I want to add the .exe when the automatic build runs.
I hope it makes sense.
How reproduce VS2017 Package Manager command “Update-Package -reinstall” with Nuget CLI
I am afraid you can NOT do such things with NuGet CLI. That because NuGet CLI does not modify a project file or packages.config. When we modify the project file, we need to do it by NuGet API in Visual Studio, but only package manager console can provide access to visual studio objects:
https://github.com/NuGet/Home/issues/1512
That is the reason why I said the easiest way is using the command line Update-Package -Id -reinstall in your previous thread. Then I also gave you another way to resolve this issue from the root cause, using .targets file to copy the executable file to the the project root, please check my update answer.
Of course, there is another simple idea to resolve this issue, just add a pre-build event in your project to copy the executable file to the the project root:
xcopy /Y "$(SolutionDir)packages\MyToolPackage.1.0.0\Tools\wkhtmltopdf.exe" "$(ProjectDir)"
Hope this helps.
While installing Nuget package like bootstap using visual studio 2017, for example, nuget manager installing the css files of bootstrap package in "~/Content/" directory while i prefer it to be located in "~/Content/css".
i know that i can move the files manually and to change the reference manually but then, i will need to do it again every time i am updating the package using visual studio nuget package manager.
i am wondering, if there is an option to tell every package where to install the relevant files so it will be remembered for later updates.
i am wondering, if there is an option to tell every package where to install the relevant files so it will be remembered for later updates.
I am afraid there is no such option to tell every package where to install the relevant files. According to the conventions for .nuspec file:
The convention for content is:
Think of the content folder as the root of the target application that ultimately consumes the package. To have the package add an image
in the application's /images folder, place it in the package's
content/images folder.
Just like Matt comment, "The location of the files is determined by the NuGet package itself", so there is no such option to tell every package where to install the relevant files.
I modified a solution and deleted one of the .csproj files and instead packaged the .dlls into a NuGet package. Then I added the package to the two other .csproj files that reference the .dlls. All was good - it builds locally, but I can't get it to build on the build server. When I look at the code gotten out of TFS for the build I see that the packages.config for both projects have the correct reference to the NuGet package, but when I open the solution in VS the references have little yellow exclamation marks next to them because they're broken references. The only way I can get it to build is to open the NuGet CMI and execute Uninstall-package package-name and the Install-Package package-name. Then the references are good. When I look in the packages.config of the main project it contains the correct reference to the Package. So I've given up on getting TFS to correctly grab the package, but since Install-Package and Uninstall-Package are CMI commands only I can't automate that (or can I)? Does anyone know if a way that I could automate that to happen after the source is pulled from TFS but before the build?
The yellow exclamation marks issue should be related to the reference path. When you download the source from TFS to another location, the system cannot find the references as the original reference path changed.
So, you need to reinstall the package, you can use the NuGet command line in the Package Manager Console:
Update-Package -reinstall
since Install-Package and Uninstall-Package are CMI commands only I can't automate that (or can I)? Does anyone know if a way that I could automate that to happen after the source is pulled from TFS but before the build?
The simple answer is you can not automate that. You can use the command Install-Package and Uninstall-Package to reinstall the packages to your project in the Package Manager Console, but it seems impossible to automate that. Please forgive me for the lengthy explanation below.
First, we need to know the different the operation Install packages between NuGet CLI and Package Manager, although NuGet CLI and Package Manager both support the operation Install packages.
The operation Install packages on NuGet CLI:
Obviously, NuGet will not reinstall the references when you using the Install-packages operation on the NuGet CLI, just download the package to the packages folder. See NuGet CLI reference：
The install command does not modify a project file or packages.config;
in this way it's similar to restore in that it only adds packages to
disk but does not change a project's dependencies.
Conversely, operation Install packages on Package Manager:
Installs a package and its dependencies into a project.
If you want to automate that, you have to do this operations via NuGet CLI. Since Install package on NuGet CLI will not modify the reference of project, so we could not automate the operation install package to update the reference of the project.
Besides, we also do not recommend you automate that. Once you have automate that, NuGet execute the uninstall/install operations every time before you build the project. We only need to do an uninstall/install the operation after get the project from TFS. Even we do not need to do this operation if the references of the project are not broken after NuGet restore. So according to the reference of the project to determine whether or not to use an command:
Update-Package -reinstall
in the Package Manager Console should be the best choice.
With NuGet, I added Json.NET (Newtonsoft.Json) to my code. As result of a mistake (adding code to CMS, ignoring DLLs, and checking out), my reference DLLs were deleted.
How do I restore ?
I followed all links in this SO question, but nothing brings back the DLLs.
If you still have the packages.config file you should be able to use nuget.exe to restore the packages in the packages folder. You can run nuget install followed by the path to your packages.config file.
nuget install packages.config
This will restore the packages to the packages folder but not modify your project.
If you do not have the packages.config file you could try running nuget install specifying the package id and the version instead.
If you have files in your packages folder you may want to remove those before running this command.