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.
Related
I have been working maven projects since 2 two years.First of all, I import maven projects to eclipse then
thanks to my pom.xml some dependencies is installed and I see these dependencies on my maven dependencies folder on eclipe project explorer.It connected to my .M2 folder.
Right now , I import a .Net framework project (which is written with C#) in my visual studio program.The solution explorer (references section) show many dependencies(they gives error).Then I found these libraries then I created a folder which is called nugetPackages and I connected my nuget packages manager to that folder(tools/options/nuget package manager/package sources).I reopen my project and libraries on references section does not give any error.My question is where does that libraries names come from ? There are any file like that pom.xml.
I hope I can explain my situation.
Are the libraries (DLLs) that you want to reference in your project NuGet packages or just some framework libraries? If they are Nuget packages they should be described in packages.config file http://prntscr.com/1140xn0 for the classic .NET application (.net framework 4.5 for example) In a .Net Core applications the Nuget packages that are required are defined in the file .csproj file http://prntscr.com/11412iq. In both cases, you can download all required NuGet packages by right clicking on the .sln file and selecting Restore Nuget Packages http://prntscr.com/1140zsk This will automatically create the nugget folder and download all required Nuget packages. If you have manually added dlls you need to navigate to them and select them by right-clicking References - Add reference http://prntscr.com/114142x
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'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.
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).
I am building a new project in ASP.NET 5.
In my solution I have added a new Class Library (Package) project.
I right click on this project and choose for Manage Nuget packages to install PetaPoco.Core.
When I install everything seems fine except that the PetaPoco.cs file is not in my project.
In my references I se the PetaPoco version 5.1.171 installed.
Is this something different then a normal class library and do I need to use something else in order to use the installed PetaPoco class or is it a problem during the installation?
I have removed and reinstalled this but still the same.
Someone that can help me out?
/Michael
It looks like the PetaPoco.Core package isn't setup to be used in portable class libraries (PCLs).
Including content files in PCLs like the Models folder that PetaPoco.Core creates requires a different NuGet setup than a regular project. Documentation on this can be found on NuGet. I downloaded their package directly and can confirm that it is not setup in the way the linked resource describes.
It may be that the project requires features that are not available yet cross-platform, or they simply haven't had time to make changes to support PCLs, or some other reason that I am not aware of.
NuGet packages are usually installed as DLLs in the bin folder of your project, with the needed references also added automatically to the project. They usually don't include source files. You may find sources - if available - on the package/project website.
Visual Studio IntelliSense will pick up the DLLs and show what it can about the classes and methods inside, including comments and method signatures.
See here for a tutorial, including how to build your own NuGet packages.
EDIT: PetaPoco is the exception that does add a .cs file... see comment below.