Nuget Package Restore, upon editing Package.Config, in Text Editor? - c#

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).

Related

Nuget Pack not including new files

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?

When added to solution NuGet packages restore/install to multiple locations

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.

Nuget Package without Package.Config?

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.

What's the difference between a dll and nuget package?

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.

How to add a nuget package to the package.config the proper way?

For my C# project I am maintaining a packages.config which includes all the dependencies my project requires. Over the time I have been copy-pasting the entries manually using a regular text editor, checking in the version number I found on the NuGet website and so on. To restore the package upon a checkout, I use nuget -o nuget-packages install packages.config which worked good so far (I am using Xamarin Studio on non-windows systems, so no VS available).
I was just realizing that messing with the packages.config in a text editor couldn't be the intended way. I know from npm and bower that a npm install --save-dev <pkg-xy> will to the job and write the package version back to the config. Is there an equivalent of this in NuGet.exe?
From the command line this not supported. You will have to edit the packages.config file manually, or write a utility to do this work for you, or extend NuGet.exe with this feature.
There is no equivalent in NuGet to NPM's npm install -save
Currently the only way to have the packages.config file automatically updated when you want to install a new NuGet package to your project is to use an IDE, such as Visual Studio or Xamarin Studio, and actually install the package. Using NuGet.exe from the command line does not have an option to add/remove entries in to/from the packages.config file when installing a new package.
NuGet.exe does have an update command which will update the package to the latest version. Whilst this would update your packages.config file it also updates your project file by adding any assembly references that the NuGet package needs.
You really shouldn't be editing packages.config. Package Restore doesn't do what you think it does. It simply downloads any missing packages that are listed in packages.config.
You might think this is what you want, but Package Restore does NOT add references to your project. It also doesn't do any of the other things the package creator had intended like running an install.ps1 script.
When installing a package, NuGet handles all of this, so your project files have added references, content, etc. This and the packages.config file is what you would commit to source control. You can leave out the actual packages folder, so you don't have to commit large binary files.
When you open the solution and build, NuGet will see that the packages are missing and will download them as if you had checked them in. The actual "install" was already done (and committed). That is all that Package Restore does: no more, no less.
If you are using Xamarin Studio, you can install NuGet by following the instructions here:
https://github.com/mrward/monodevelop-nuget-addin

Categories