现在NuGet团队提供了几款全新工具。它与Microsoft的一些团队合作推出了新版本的NuGet客户端，以支持通用Windows平台(UWP)和新的可移植类库(PCL)。新的NuGet工具可通过“工具
扩展和更新
VisualStudio中的更新”获取，还可以从NuGet分布站点获取.
NuGet还发布了新版本的NuGet命令行工具，您可以从dist.nuget.org上的相同位置下载它。本文将回顾这些新功能和Windows开发者向Windows10项目添加NuGet支持需要遵循的进程。
Project.Json从ASP.NET5开始，NuGet引入了project.json文件支持，以便使用您会立即依赖的程序包的明确定义来描述项目依赖项。在ASP.NET5中，这是定义项目配置的唯一文件。但是借助NuGet3.1，您可以在通用Windows项目和现代PCL（面向DNX、UWP和Microsoft.NETFramework4.6）中使用此文件来定义程序包引用。这种方法的好处就是VisualStudio中的“管理程序包”对话框将基于您所开发的项目类型，适当维护您的packages.config或project.json文件。
这一转变从packages.config模型开始，还允许您“重启”项目中的引用，并使用NuGet的新的可传递依赖项功能。开发者和程序包作者向NuGet团队报告，当他们将程序包添加到项目时，他们的packages.config文件会与其依赖程序包中的依赖项混淆。
例如，NHibernate是依赖于Iesi.Collections程序包的程序包。在packages.config中有两个引用：NHibernate和Iesi.Collections。在更新NHibernate时，会遇到一个问题“我是否也要更新Iesi.Collections？”同样存在与此相反的问题。如果有适用于Iesi.Collections的更新，我是否需要更新NHibernate来支持Iesi.Collections中的新功能？开发者可能会陷入对程序包引用所带来的项目程序包依赖项进行管理的令人厌恶的循环。
NuGet的可传递依赖项功能简化了这一决定，通过程序包定义文件（nuspec文档）中语义版本的改进支持更新程序包引用。开发者指定了其程序包支持的依赖项版本范围。当NuGet安装客户端时，这些依赖项会对packages.config文件中的指定版本添加硬引用，这些引用的程序包看上去就像您添加到项目中的任何其他程序包引用。您可以在图1中看到这一问题的极好示例。
在我将这些内容添加到项目中时，我实际上只需要Microsoft.AspNet.Mvc、Microsoft.AspNet.Identity.EntityFramework、Newtonsoft.Json和Microsoft.Owin.Security.MicrosoftAccount。这四个程序包所引用的其他项目都只是干扰，现在我有特定版本的硬引用。通过可传递依赖项功能，不再需要其他这些程序包的版本。我只需管理我真正要在项目中使用的四个库。
NuGet客户端会在后台为您解决和管理其他这些程序包，并将这些引用保持在项目中正在使用的程序包所声明的依赖版本约束范围内。这会极大地简化项目引用体验。
常见的本地程序包缓存开发者通常有自己倾向使用的一些程序包和工具。在您明显已经在某个项目中拥有这些程序包和工具并想在另一个项目中使用时，为什么需要在单个工作站上多次下载并安装它们？通过project.json托管的项目，NuGet下载这些程序包的副本并将其存储在位于%userprofile%\.nuget\packages文件夹的全局程序包文件夹中。这会减少在工作站上使用磁盘空间。还能避免额外调用，这些调用从NuGet.org提取程序包来获取您已经拥有的项目。
Project.json和常见的本地程序包缓存支持可供包含NuGet3.0的ASP.NET5以及其他始于NuGet3.1的项目类型使用。
弃用的功能从NuGet3.1开始，在使用project.json时，弃用对执行install.ps1/-uninstall.ps1脚本和在/content程序包文件夹中传递元素的支持。使用这些元素安装程序包既不会执行install.ps1文件，也不会将内容复制到您的项目中。
但是，在仍使用packages.config文件的项目中，仍然支持执行当前行为。出现这一情况有几个原因：
随着可传递程序包还原，无法可靠地选取要卸载和安装的程序包。
在将内容复制到用户项目，且程序包进行了更新时，会存在您无法可靠运行的隐式卸载过程。
NuGet需要完全支持VisualStudio之外的开发。随着转向支持完全跨平台.NET开发体验，WindowsPowershell在其他环境中不可用。更多的开发者还致力于开发VisualStudio之外的.NET代码，他们需要支持。
其他程序包管理器提供了管理和传递内容的卓越体验。NuGet可以作为.NETFramework的程序包管理器良好地工作，因此，鼓励继续使用。
不再支持“任何”框架。您无法再将文件直接放置于版本的根和库文件夹中，并将它们传送给项目。声明您的文件所支持的框架是非常重要的，这样，NuGet才能了解解析这些引用的优先级顺序。
不再支持解决方案包。这些程序包不能修改任何指定项目的功能，通常用于提供跨项目重复使用的共享资源。借助新共享的程序包文件夹，这些资源可能已经位于另一个项目的磁盘上。
新目标框架NuGet新版本的另一方面是支持新开发框架以及跨操作系统和体系结构的改进的本机程序包支持。NuGet进一步探索了托管.NETFramework模型之外的环境，以支持更多的生态系统，使您可以将库部署到以前无法访问的环境。
目标框架名字对象(TFM)是一种简写形式，用于创建程序包来声明二进制支持的框架以及每个框架需要的依赖项。您将在使用此表示法的程序包库和ref文件夹中找到文件夹的名称。程序包的nuspec依赖项元素中还有一些元素，这些元素使用一个TFM值声明目标框架属性来指示NuGet客户端将相应的库传递给使用项目。
下列TFM仍可用，引入的新TFM如图所示。
所列出的带有等于(=)符号的项是NuGet支持的同义词。针对许多不同的框架有许多支持，但这可能会造成混淆。您是否需要为托管框架包中的微框架提供支持？您需要获得多少Silverlight支持？您需要回答这些问题，以便最符合使用者的需求。
您会发现表中没有支持PCL的显式调用。尽管NuGet支持这些框架的组合，但它希望您拥有适用于现代PCL的更加向前兼容的名字对象。这会在您构造程序包和定义支持框架时提供更多的灵活性。NuGet3.1引入了适用于现代PCL的dotnet目标名字对象。
Dotnet目标名字对象在NuGet的早期版本中，您可以指定带有PCL的框架，该框架作为后接加号符号的TFM缩写的集合。您可能会使用类似“portable-net45+win8+wpa81+wp8”作为文件夹名称的结尾。
这可能会造成混淆，给使用者带来不兼容的问题。为了使PCL和跨平台开发体验更加简单，NuGet引入了dotnet名字对象。
此名字对象不会直接与任何指定版本或框架功能绑定。这是一个间接的引用，告诉NuGet“如果它支持您拥有的框架和运行时功能的话，这是您应该使用的应用。”然后NuGet客户端研究该引用以确定其支持的功能和框架。这一进程会持续，直到NuGet客户端解析dotnet引用支持的确切功能。
然后，只有在引用匹配项目的功能和需求的情况下，客户端才会应用该引用。您可以通过.NETFramework4.5以及后续派生的Framework版本（包括XamarinAndroid和XamariniOS）来引用dotnet名字对象。
这并不意味着您只需构建PCL，并将其与声明的dotnet依赖项捆绑在一起，就完成操作了。如果您想要使用旧版本的VisualStudio和通过传统可移植类库构建的NuGet客户端来支持项目，则应创建一个引用，并将其放置于完整PCL目标框架名字对象中。
在将程序包安装到与dotnet名字对象（.NETFramework4.6、UWP或ASP.NET5）完全兼容的项目类型时，最后会搜寻dotnet名字对象。在尝试查找与项目的框架或不太具体的框架相匹配的引用后，将会引发上述操作。该层次结构如图3所示。
图3框架层次结构，检查其中是否存在对通用Windows平台项目的引用
如果您的项目是使用仅针对这些框架中的任一个框架的project.json的现代PCL，则会首先分析dotnet名字对象。后跟一个标准的PCL解决策略，如图4所示。
图4框架层次结构，检查其中是否存在对现代可移植类库项目的引用
NuGet命令行现在NuGet类似于命令的可执行文件nuget.exe可用于支持将程序包安装、更新和还原到包含packages.config文件或project.json文件的项目。pack命令可以继续使用磁盘上的nuspec文件和packages.config文件。它并没有更新为基于project.json文件生成nuspec文件。要解决此问题，您需要针对任何通过project.json程序包引用构造的新程序包内容构建您自己的nuspec文件。未来版本中将包含解决此问题的更新。
此版本的命令行可执行文件还支持NuGet.orgv3终结点。此nuget.org源的新版本提供更快的交互，同时也是更加可靠的服务。通过内置的冗余和内容传送网络可以帮助快速传递程序包。
如果您在升级NuGet扩展后安装了Windows10SDK/Windows10工具，则安装程序会将此扩展降级为版本3.1。您需要重新将其至少更新为3.1.1版本。在此“扩展和更新”对话框中显示的版本是3.1..。WindowsPowerShell控制台是3.1.1.0。
总结现已提供支持Windows10UWP应用程序开发和PCL项目的功能。这些更改是广泛使用程序包管理器和.NETFramework的第一步。Microsoft持续改进.NET开发体验，并专注于提供程序包管理器，以支持所有.NET开发者在任何平台上构建任何类型的项目。
JeffreyT.Fritz是就职于MicrosoftNuGet团队的高级项目经理。他喜欢长时间地在海滩上散步，并处理在云中缩放的Web应用程序。您可以通过jefritz
microsoft.治疗白癜风的中成药北京较好的白癜风医院