We are happy to announce an update to the NuGet client that comes bundled with Visual Studio 2017 version 15.3 RTW and .NET Core 2.0 SDK. This release introduces support for new scenarios such as .NET Core 2.0/.NET Standard 2.0, some new features, a series of bug fixes and performance improvements. You can see more details, known issues, and workarounds associated with this release in our release notes. Here are some links to get started with using the latest NuGet functionality:
- Visual Studio 2017 version 15.3
- .NET Core 2.0
- NuGet.exe
- Visual Studio 2015 – NuGet Package Manager update (v3.6.0)
TL;DR
Our major focus for this release was adding support for .NET Core 2.0. In addition, we made some other improvements:
- Support for new TFMs
- MSBuild integration of NuGet warnings and errors
- Support for Semantic Versioning 2.0.0
For Visual Studio 2015, you can now start using .NET Standard 2.0 packages by installing the latest NuGet client (v3.6.0) for Visual Studio 2015.
We are also happy to announce that we have integrated the NuGet.org facelift we had previously previewed back into the NuGet.org site and results in the following improvements available to all NuGet.org users:
Support for new TFMs
We have added support for the following TFMs – netcoreapp2.0 and netstandard2.0. We also enabled Tizen as a supported TFM that helps integration of Tizen .NET libraries with Xamarin Forms. The complete list of supported TFMs is reflected in this documentation.
MSBuild integration of NuGet warnings and errors
We have integrated NuGet warnings and errors with MSBuild so you can use existing MSBuild properties to suppress certain warnings or elevate them to errors. In addition, we have also improved warnings and errors to output relevant information and thereby making them more actionable. All NuGet warnings/errors now have a unique number associated with them as documented here.
Note: These improvements are only available to project systems that support expressing NuGet dependencies using PackageReference.
How does it work?
As an example, when you install a .NET Framework package (say RestSharp) into a .NET Core 2.0 project, you will see the following NU1701 warning:
Warning NU1701 Package 'RestSharp 105.2.3' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
If you are okay with the risk as stated by the warning and do not want to see it in future restores/builds, you can do one of the following:
Suppress the warning in the project on a PackageReference basis
To suppress the warning, you can go to the package properties window and add
NU1701 to the NoWarn property: 
This results in the following entry being created in the project file:
Suppress the warning at a project level
If you do not want to see the warning at all in the project irrespective of the package reference that introduces it, you can suppress it in the project’s build properties:
This results in the following entry being created in the project file:
Elevate a warning to an error
In case you want to elevate a specific warning to an error, you can do so by specifying the same in the Build properties:
This results in the following entry being created in the project file:
A word of caution!
If you have set your project’s build property to treat all warnings as errors, you may start to see your builds fail because of the NuGet warnings now being flagged as errors. You can choose to either fix these warnings and/or suppress them using one of the mechanisms specified above.
Support for Semantic Versioning 2.0.0
Semantic Versioning 2.0.0 specification has been out for a long time and we have gotten multiple requests to support it. We have been listening to your requests and feedback and are happy to announce SemVer 2.0.0 support for NuGet starting with our latest client releases including NuGet 4.3.0, Visual Studio 2017 version 15.3 and dotnet.exe 2.0.0. We are also making this support available for Visual Studio 2015 as a separate download.
A word of caution!
If your package version contains one of the following, they will not be visible from the older clients (NuGet clients before 4.3.0 or Visual Studio before 2017 version 15.3):
- The pre-release label is dot-separated, e.g. 1.0.0-alpha.1
- The version has build-metadata, e.g. 1.0.0+githash We recommend you consider this to be a beta-feature until a significant majority of our users are on these latest clients that understand Semantic Versioning 2.0.0. Read more on Semantic Versioning 2.0.0 NuGet support, here.
Update to the NuGet client in Visual Studio 2015
We wanted to ensure that developers using Visual Studio 2015 can use packages targeting .NET Standard 2.0, and have created an update to the NuGet client in Visual Studio 2015 that adds the following improvements:
-
Support for consuming .NET Standard 2.0 packages into the compatible projects
-
Support for Semantic Versioning 2.0.0 packages
-
Fix for UI hang bug as described in NuGet #4976
The facelift to NuGet.org site is live!
A month ago, we had announced a significant redesign of the NuGet.org site. We got a ton of great feedback, and for that, we are always grateful. We were able to address a majority of that feedback as listed below (See full list of issues here):
Condensed list for ‘Manage Packages’ #4431
We have improved the author’s view of packages they own to make it more manageable – sorted and compact:
Search results consistency with Visual Studio #3791, #4493
We have made the package ID to be the consistent identifier (header) for the packages that show up on NuGet.org or Visual Studio:
The NuGet.org package search has a new filter for prelease packages so that search results would be consistent with this existing functionality on Visual Studio:
In addition, we have made some improvements to package search results to fit more items by reducing the package ID font size and by removing the unnecessary separator line. We will continue to explore more ways to improve this page. In case you missed the improvements we made to NuGet.org, here is a quick summary of our previous blog post:
An accessible NuGet.org site
We are committed to making sure that NuGet.org is fully accessible to all users. We addressed many accessibility issues for this preview in accordance with Section 508 Laws and Web Content Accessibility Guidelines (WCAG 2.0 AA). If you find any accessibility issues, please let us know by filing an issue on GitHub. Some of the changes we’ve made include:
-
Updating tab order on all pages to ensure proper keyboard navigation
-
Setting ARIA attributes on elements to make sure screen-reader technologies work on the website
-
Ensuring all interactive elements have visual feedback for when they are focused by the keyboard
-
Setting text colors to properly contrast with backgrounds with a minimum ratio of 4.5:1
Prominent package details
During our discussions, we heard from you what information is important when determining the viability of a package. The importance of various aspects like freshness, download count, license type, access to a project site, and many more influenced the design of a more streamlined package details page.
We created sections to divide package details to make it easier to parse through all the information to get a better understanding of a package. All the vital information is placed at the top of the page to be seen first when navigating to the page. Additionally, the project site now displays as the full URL (if it is under a certain number of characters), publish date is more readable, and license type is made more prominent. Now that NuGet is supported by a variety of consoles, we wanted to support the many ways users can add packages to their projects. We’ve made it easier to copy the command to install a package and added a new tab for the command to install using the .NET CLI.
Streamlined account settings
We’ve made it easier for users to access their account settings, moving away from a centralized account page that combined unrelated settings together. Now, API keys and package management controls can be accessed from any page with the account dropdown. It’s much easier for authors to manage their packages.
We want to hear your feedback!
We want NuGet to meet the evolving needs of our community. In case you missed it, we recently published a post that describes some of the experiences we are working in the near future. Share your thoughts with us at feedback@nuget.org. You can also leave a comment below, and as always, if you run into any issues or have an idea, open an issue on GitHub: NuGet client issues, NuGet server issues
0 comments