I'm using Visual Studio 2017, building a .Net framework (not core) v4.6.1 ASP.Net MVC project and when I added packages to my single project inside my solution the packages are seemingly restoring/installing to multiple different locations. I am installing packages from multiple feeds, some are internal to my company and others are public.
Some packages are located at my solution root and others seemingly are landing at %userprofile%.nuget\packages\
One package even installed and its hintpath was in a completely different location from the two of them. The package was installed there but I don't know why it didn't install to what I consider the solution's local package folder.
I'm not sure if these are the right questions to ask yet, but these are what I'm trying to answer for now:
For VS2017, .Net framework, ASP.Net MVC what is the default package install location?
How do I specify which feed a package comes from for CI/CD purposes?
Does NuGet look for packages already installed on my computer?
If yes, where does NuGet look for packages and where can I find its list of locations it looks for.
Thanks!
1.For VS2017, .Net framework, ASP.Net MVC what is the default package install location?
It depends on which package management method you using. If you are use package.config, the default package install location is solution root, if you are use PackageReference, the default package install location is %userprofile%.nuget\packages\. That is the reason why you added packages to single project inside the solution the packages are seemingly restoring/installing to multiple different locations. You can unload and edit your project, check the project file .csproj, you will find following:
<ItemGroup>
<PackageReference Include="xxxxx">
<Version>x.x.x</Version>
</PackageReference>
</ItemGroup>
To resolve this issue, you can accept the advice of Lex. If you want to unify, make the choice and change the files. You can uninstall those packages which using PackageReference(or package.config), then change the nuget settings(Tools->Options->NuGet Package Manager->General->Default package management format->Packages.config), then reinstall those packages, make sure they use a uniform form.
2.How do I specify which feed a package comes from for CI/CD purposes?
You can not do such things and you do not need to do things. As we know, when we install nuget packages from multiple feeds, all the packages are downloaded to the local host, Visual Studio will use those packages on the local, Nuget does not care which feed it comes from.
3.Does NuGet look for packages already installed on my computer?
4.If yes, where does NuGet look for packages and where can I find its list of locations it looks for.
Yes, you can use the command line nuget locals all -list to find its list of locations.
See Managing the global packages, cache, and temp folders for some more details.
Hope this helps.
Related
I've added new models and helpers to my project, but when I run nuget pack and install the package in my project I don't see the new items in the Assembly Explorer nor can I use them. Am I missing something during the build that wouldn't include new files added to the package?
I'm using visual studio 2017 and the nuget cli
At a guess, you didn't change the package version when you changed the code and packed again. NuGet is designed such that the package id/version produces an immutable package. This means it's valid to download a package, say Newtonsoft.Json 12.0.1 from nuget.org just once, and every time you use that package in any project on the same computer you can re-use the same download, rather than having to download it every time you restore/build the project.
This causes some people problems when they're trying to test their packages. One option is to take advantage of Semantic Versioning and use 1.0.1-preview.1, 1.0.1-preview.2, so every single build of the project has a unique version number. In addition, or instead, you could use a nuget.config to set the globalPackagesFolder to a different location that gets cleared every time you change the package. If you delete the "cache", it can't reuse the old contents. But this only works if you control the machines that use the package. Once you publish the package where anyone else can use the package, you will cause problems if you change the contents, which is why nuget.org doesn't allow deleting packages, only unlisting them.
However, another possible solution is to just not use packages and simply use project references. Some people have the misconception that if you have two packages, one depends on the other, that they need to use package references to make sure NuGet dependency information flows. That's not correct. If you pack with the MSBuild pack targets (highly recommended, and the default option for SDK style projects), NuGet will always convert project references into NuGet dependencies. nuget pack will convert project references into dependencies when the other project also has its own nuspec file. When you test your project with project references, you never have to worry about immutable packages. Just pack when it's ready, but it's not needed for testing.
Maybe you have a .nuspec file (at the same level than your .csproj) that you need to edit to include new files?
I encountered a solution (.Net Full framework) Where there are no package.config in the solution and Feeds coming from In house Nuget servers.
Where list of packages are maintained, if not in Package.Config?
Where is the list of packages are maintained, if not in Package.Config?
First, you should make sure you have that solution have already installed the nuget package, once you install a package, NuGet will add Package.Config file to your project to record the dependency in either your project file or a packages.config file.
If you confirm that your solution has a nuget package installed, but there is no Package.Config file, your nuget package should use another management method: PackageReference
Edit your project, you will find following PackageReference list:
<ItemGroup>
<PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
</ItemGroup>
See NuGet is now fully integrated into MSBuild for more details:
In the past, NuGet packages were managed in two different ways -
packages.config and project.json - each with their own sets of
advantages and limitations. With Visual Studio 2017 and .NET Core, we
have improved the NuGet package management experience by introducing
the PackageReference feature in MSBuild. PackageReference brings new
and improved capabilities such as deep MSBuild integration, improved
performance for everyday tasks such as install and restore,
multi-targeting and more.
The packages.config file could be somewhere else? In that case look in your msbuild project file (i.e. *.csproj, *.vbproj, *.vcxproj) and see where the references to that nuget assembly are coming from. Then look in that directory for the packages.config file. It might be more complicated than that, in which case, it's useful to do a global search for packages.config in your repo, to see where they reside (If they do exist at all).
This is a common practice: To have one project specify the nuget package, and all the other projects borrow it. As Jon said, this is really dependent on how the folks at your company and department set up your builds and dependencies.
When merging two projects, we're in need of Install-Package several 100 times. Doesn't Nuget support package restore, once Package.config is edited. The way it works like charm for Node JS package?
Once package.config is edited, why can't we fire Update-Package to
restore all packages?
Is it supported in the successor Dotnet CLI?
While packages.config tells NuGet which packages to download and extract (for which target framework), the process of installing package references may also modify the .csproj file. So if you update only one of these after a merge, you could find yourself trouble.
The successor of this mechanism is PackageReference (NuGet blog post), which replaces packages.config and only requires listing the referenced packages and versions (and even some additional MSBuild logic could be used by projects to manage shared versions / packages etc.). However, there is no migration tool available, so you'd need to uninstall all packages and add the package references you need. Some NuGet features also changes - for example the support fo content files (=> files copied into the project directory) was removed which may still be used by some projects (e.g. web projects assuming that jQuery or other JS libraries would be acquired in this way).
First of all, I apologize if this is a basic question. I tried looking this up, but for some reason, I got more confused. So, I decided to ask here. Is a dll file and a nuget package the same? Are they both just being referenced in the project?
When you add features to your project via a nuget package, you're just adding files to your project. It can be javascript files (like jQuery), DLLs that your project references (like Newtonsoft JSON), or a whole bunch of things (like Entity Framework or Owin/SignalR) -- anything really.
The advantage of using the nuget package system is that it tracks it all for you. It notifies you if your added packages received an update, it removes the files and unreferences them if you take the package off your project. It handles all of that for you, so you don't have to track the files that the nuget package added, place them in special folders, make sure they get copied in your builds, all that micromanaging stuff.
From the docs, https://www.nuget.org.
"What is NuGet? NuGet is the package manager for the Microsoft
development platform including .NET. The NuGet client tools provide
the ability to produce and consume packages. The NuGet Gallery is the
central package repository used by all package authors and consumers."
A package can contain one or more dlls in addition to other assets such as config files etc.
You can add libraries via reference into your project but you would not notice when they were updated.
NuGet is a Visual Studio extension that makes it easy to pull in not only libraries but components, and most importantly their configuration into your visual studio project. It will help you manage your packages installed on your project and it will notify you when the package has new version released.
Let's say I created my own DLL, I could add my own DLL by reference. However, it won't be available in NuGet until I package and publish it first to make it available at the NuGet Package Gallery.
I cannot install the NuGet package System.IdentityModel.Tokens.Jwt (.Net JWT Handler) into my project. If i try to install the package with NuGet, it will install into the root of the solution only (a .nuget folder is created in the root of the solution). I need to install the package in my project, not the solution.
Why would this happen? I tried passing in the project name to the Install-Package command in the Package Manager Console, and that looks like it installs correctly but no references are added to my project and the packages.config file is not updated.
My project is currently referencing .Net 4.5.1 and I have also tried with .Net 4.5.
The package I am trying to install is here:
System.IdentityModel.Tokens.Jwt
I'm having the same issue. I was trying to install the package as said in this article http://msdn.microsoft.com/en-us/library/dn205064(v=vs.110).aspx
So, I look into the package history and finally I installed the previous package
http://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt/3.0.0
It works fine for me.
With NuGet, you can now specify the directory the packages are installed in.
http://docs.nuget.org/docs/release-notes/nuget-2.1
Specify ‘packages’ Folder Location
In the past, NuGet has managed a solution’s packages from a known ‘packages’ folder found beneath the solution root directory. For development teams that have many different solutions which have NuGet packages installed, this can result in the same package being installed in many different places on the file system. NuGet 2.1 provides more granular control over the location of the packages folder via the ‘repositoryPath’ element in the NuGet.config file. Building on the previous example of hierarchical nuget.config support, assume that we wish to have all projects under C:\myteam\ share the same packages folder. To accomplish this, simply add the following entry to C:\myteam\nuget.config.
The package System.IdentityModel.Tokens.Jwt 3.0.1 has some problems: the file System.IdentityModel.Tokens.Jwt.dll and System.IdentityModel.Tokens.Jwt.Xml should be put in directory lib\net45, but they are put in the root directory instead. This causes NuGet to think the package is a solution level package, and will not install the package into a project.
This problem was fixed in System.IdentityModel.Tokens.Jwt 3.0.2