Let's say I have a nuget package in my Nexus repository called MyPackage.1.0.0. I also have a solution in Visual Studio that has MyPackage.1.0.0 installed. If I make a change to my nuget package in Nexus but I don't change the version number, what happens in Visual Studio? Will Visual Studio know that the installed package is outdated? Will it automatically download the new version next time the solution is built?
No, Visual Studio will not detect this and will not use the updated package. Also, if you are using package reference nuget package management format, the package once installed gets extracted to the global packages folder. If you now try to install this package in a completely different project, nuget first looks in this global packages folder and if it finds it which it will, it will use it and not go to package sources to retrieve it again.
You can clear the local nuget caches by calling
nuget locals all -clear
from the command line.
After that, all packages will be downloaded again. This may be acceptable during development (i.e. if you need to tweak your package until it works), but clearly is not an option if others are using the same version already.
Related
I have a problem updating the Nuget packages. I had to install my Visual Studio in a new environment and new is also Azure DevOps. Previously we had the TFS.
Meanwhile I have some packages on the Azure DevOps that I need for my Solution. In addition, packages from Nuget.org are still needed.
In my solution older versions of the Nuget packages are included. Some packages I can't update for some reasons.
Now I have a Nuget package that needs to be updated and here comes my problem. When I go to Tools --> Manage Nuget Package for Solutions... and click on Install, it brings me in the Preview Changes overview all packages that have an older version and wants to update all of them.
Where can I set it or what do I have to do, so that only the one package is updated, which I have selected? In my old environment it works normally.
Thanks.
Cheers
If you want to update one package for all the projects under the solution, you should right-click on the solution-->Manage Nuget Packages for Solution
This will update the package of all selected projects to one same version.
You could also right-click on the project-->Manage nuget packages to update the package one by one. It is definitely not as flexible as the above one .
As you know NuGet uses %LOCALAPPDATA%\NuGet\Cache location for caching. It first checks if requested packages is here then download if needed.
How can I properly disable this cache mechanism from Nuget and "Visual Studio 2013", and make sure they always download from sources?
Can I build Nuget Package Manager Extension from source, then install it to Visual Studio? Or Are there any registry configuration that disable it?
Thanks
You cannot disable NuGet from using a cache. The only thing you can do without changing the source code is to change the location of the cache directory using a NuGetCachePath environment variable.
So you are left with clearing the local cache manually or automatically before installing a NuGet package or modifying the source code for NuGet's Visual Studio extension.
The source code for NuGet 2.8.5 and older is available on CodePlex.
The source code for NuGet 3.0 is available on GitHub
There are some instructions available on how to setup the NuGet development environment to be able to build and run NuGet within Visual Studio.
Currently it's possible to do so in case you'd running Install NuGet packages task through CLI which is common practice.
You can order NuGet to not use it's cache at all by using -NoCache input parameter. Then it will behave as you described. See CLI reference of NuGet.exe
I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
I've got problem with version of dependency that I set manually.
Note: I use Automatic restore within Visual Studio.
When I set Version="1.3.12.5" for my dependency in packages.config I expect that restore will install package and it will be referenced in next build I trigger. But it is not true. Package is installed and placed in packages directory but build does not use this downloaded packages (as csproj is not changed automatically).
Do you know possible scenarios to workaround this problem?
I tried to use Proget Client Tools but it turned out that it is not possible to use local directory feed with this. I need local and remote feeds support also, so it is additional requirement.
So, paraphrasing my question is...
How to easily change referenced version of package without touching csproj? (which is hard to edit in visual studio) Editing version twice (one in packages.config, two in csproj) is also an overkill.
Remember Package Restore simply downloads the package to the packages folder. It does not update project references as NuGet expects that the package had previously been installed. It's simply downloading the missing package files.
Package Restore is not a replacement for Install-Package. You can specify a specific version when installing. This will add the project references properly.
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.