In my projects folder root, I have a packages folder that is utilized by various web applications at C:/Projects/packages. All application references that point to this folder work fine.
However, with a new application, when I pulled the latest code, all references expect the packages folder to live at the solution level - C:/Projects/CompanyName/Apps/SolutionFolder/packages.
When I pull latest, this folder is not included (it's never checked in to subversion) so I have missing references when I first open a project up. However, when I try to build, it doesn't pull the latest for these packages and of course, doesn't compile. When I run Update-Package -reinstall, it will update the packages IN C:/Projects/packages, and it WILL NOT create the packages folder at the solution level.
I've confirmed that I have the packages.config in each project in the solution and that each project expects that the assemblies will be housed in the packages folder at that level. What's weird is that after I run the -reinstall, these hintpaths in the project files will actually point to the C:/Projects/packages folder and the assembly references will resolve...but only for 3rd party packages and NOT for our in-house built packages.
Does anyone know why this occurs? The solution has been to get a copy of the packages folder that a coworker is using and paste that into the solution folder but that doesn't solve the problem if it occurs again.
Per #MattWards link I checked the nuget.config file in appdata, which specified this C:/project.packages path. After removing this setting and building my solution, the packages folder was added to the solution level and everything worked.
Related
Trying to tidy up my file structure, I moved packages.config to a subfolder. Only to discover it was not being picked up by Nuget any more.
Is it possible to move the file or is it hard-coded into VS that it must be in the same directory as the project file?
Googling doesn't give me an obvious answer, I just get general information on packages.config's purpose.
Does packages.config have to be in the project folder?
You cannot move that packages.config file into any other sub folder except the project's root folder.
Also, I agree with thatguy.
Packages.config nuget management format allows packages.config file be in the root directory of the project and nuget and msbuild will be able to recognize this file and manage the nuget packages in your project. That's its mechanism.
So my suggestion is that you should move it back to the project's root directory. And so far, this is the only way to ensure that you successfully manage packages using packages.config.
Besides, if you still want your request to come true, I suggest you could suggest a feature request on our User Voice Forum(click suggest a feature). And The Team will consider your request carefully and I hope they will give you a satisfactory reply.
If used, packages.config is typically located in a project root. It's automatically created when the first NuGet operation is run, but can also be created manually before running any commands such as nuget restore.
This is from the packages.config reference. Although it states that the configuration file is typically located in the project root, there is no indication on any requirements for moving it. Therefore, it might be a limitation of the Visual Studio Nuget package manager that expects the packages.config file in the project root. I have never seen any official documentation or a working example of moving this file without breaking the package manager.
I'm using TFS for the first time and attempting a build. I'm getting the error:
This project references NuGet package(s) that are missing on this computer. use NuGet Package Restore to download them.
I realize that there are many similar posts on StackOverflow and I've searched through quite a few of them. What I've gathered is that the two boxes under Package Restore in Package Manager Settings should be checked (but that this is also irrelevant now because they're checked by default). I verified that mine were both checked anyway.
The next piece of advice I considered is deleting the /packages folder from the Source Control version of my application. There is no packages folder there OR in my local (pre migration to TFS) version of the application. Instead, there's a ../packages/ folder (up one level) from the application folder. It seems that, at some point, I've opted to store the packages for all of my applications in the same folder? If so, where is this setting and what do I need to change it to either in my local version or in Source Control Explorer?
Thanks!
Some dlls are used frequently in some projects in my company. So I already created one package which contain those dll files, let us just say a.dll, b.dll, c.ll and d.dll. Then I install this package via nuget to the project, all those four dll files will be added to the project. But I do not need all of them into each project, I may only need some of them. I try to delete the dll files which do not need. That`s all works fine.
Now my question is that all dll files will be re-added to the project after update that package. Obviously it is annoying to manually delete dll files after each update.
So is there a way for me to choose the dll files which I need to install when I install my package?
Thanks in advance.
So is there a way for me to choose the dll files which I need to install when I install my package?
As aware as I know you could not choose the dll files when you install your nuget package, at least now we can not do it.
According to the nuget official documents:
When we including multiple dll file in the lib folder, nuget will automatically add those dll file into the project as references. This is nuget default behavior. Besides, updating a package simply means installing an updated version, this is equivalent to a re-installed behavior. So all dll files will be re-added to the project include those deleted files.
Since there are only four dll files in your project, I suggest that you can pack each dll files into packages separately. In this case, you do not need to add all dll files into your project, just install what you needed. Besides, we do not need to update the package in order to update one of dll file.
Hope this helps.
My project on UAT is throwing an exception concerning a NuGet package that exists on my dev environment (that is, I found under my /packages folder), but does not seems to be part of my solution (that is, I launch NuGet Package Manager but I cannot find it under the list of Installed packages).
The code runs fine on dev, but crashes on UAT.
My question is: how do I figure out where this library is being used?
Some NuGet packages have trouble uninstalling completely, so there may still be leftover references in your project files (.csproj, .vbproj,...).
First, check for <Reference Include=".."> elements containing a <HintPath> pointing to the missing folder. you should remove them.
Then check for <Project Import="..." /> elements pointing to the missing folder. There may also be some conditions (for <Error> elements) checking if paths exists. Remove all of these.
Then delete your packages folder containing all the NuGet packages and re-open the solution in VS and restore the packages.
This can result in two outcomes:
It works and you successfully removed all "dangling" references to NuGet packages that are no longer in use.
You cannot compile because auf missing NuGet packages. In this case, install the NuGet packages again via the package management UI.
I have my project set to Allow NuGet to download missing packages as well as Automatically check for missing packages during build in Visual Studio. In my solution folder, there is a packages folder and it contains everything that I need for my project. However the references to them in the project are still broken.
I have tried removing the references and adding them with NuGet, but NuGet says the item is already in the project (it is in the packages folder) even though the reference is there and the project can't build. The only way that I can seem to get around it is to manually go into each of the packages in the packages folder and select every .dll.
Is there a better way to do this?
Open package manager console and type:
Update-Package -Reinstall
This should refresh all your references based on each project's packages.config file.