CHAPTER 2 ■ CONSUMING AND MANAGING PACKAGES IN A SOLUTION
17
Once you filter the list of available NuGet packages based on the technology you are using and an additional keyword
that refines that search, the list of packages at your disposal will be easier to process. Note that while you have now searched
on technology, a search for things like Twitter or JSON parser will yield packages that provide a certain functionality.
Since nuget.org contains various packages of a variable quality, it is important to take some other clues into
account in choosing packages. It’s very similar to all app stores out there, where not every app you install has the same
quality baseline.
Luckily, every NuGet package comes with a number of details to inform your choice. If you look back at Figure 2-3,
the right-hand pane shows a variety of details about a package:
The package creator, which may influence whether you deem the NuGet package to be •
trustworthy.
The package ID, which will probably not influence your decision but is great to remember if •
you really like the package and want to reuse it in future projects.
The package version and last update date, which may give you an idea of how mature and how •
well-maintained the NuGet package is.
The number of downloads is a good indication of a package’s popularity. But don’t judge a •
package by its number of downloads alone; great-quality packages sometimes have only a
handful of downloads.
The Project Information hyperlink brings you to the NuGet package’s project information •
page, where you can learn a lot about a package.
The package description, dependencies, and release notes can also give a strong indication •
about whether the NuGet package will fit your needs.
The package license. Sometimes a specific open source license cannot be added to the project •
you are building or a package cannot be used in production because of conflicting license
terms. There are packages with many different licenses, and depending on your environment
and project, the license can be very important.
Be wise in your decisions, and always try out new packages in a sample application (not on your actual project)
if you are not familiar with them!
Note ■ As we will see in later chapters, NuGet packages can contain PowerShell code that runs under the same
privileges as your Visual Studio application. Package authors can do a lot of interesting things, such as adding PowerShell
cmdlets to the Package Manager Console within Visual Studio. However, a malicious PowerShell script could do much
damage, as there are no restrictions or validations on the PowerShell code being executed. While we don't want to scare
you, always be cautious about the packages you install and report anything you find harmful. You can always extract the
package archive or use NuGet Package Explorer to inspect the package contents.
If you do find a nefarious package, use the Report Abuse link on the package page. This will inform the NuGet Gallery
administrators and prompt them to investigate the package more closely.
If you know the value of one or more fields displayed in the NuGet package management dialog box or the
metadata fields within a package, you can narrow search results further. For example, if you want to search for
packages containing the word Glimpse in the ID, you can specify a search for id:Glimpse. Similarly, other package
metadata fields can be searched as well. Table 2-1 lists some example searches for attributes that can be searched
through. Do note that these searches will execute a Contains search, meaning that a search for id:Glimpse will
return Glimpse as well as Glimpse.WindowsAzure and so on.