{"id":8835,"date":"2017-01-30T11:33:29","date_gmt":"2017-01-30T19:33:29","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/?p=8835"},"modified":"2021-09-30T10:26:38","modified_gmt":"2021-09-30T17:26:38","slug":"announcing-net-core-net-native-and-nuget-updates-in-vs-2017-rc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/announcing-net-core-net-native-and-nuget-updates-in-vs-2017-rc\/","title":{"rendered":"Announcing .NET Core, .NET Native and NuGet Updates in VS 2017 RC"},"content":{"rendered":"<p><strong>Updated (4\/2017):\u00a0<\/strong>See <a href=\"https:\/\/github.com\/dotnet\/core\/blob\/master\/release-notes\/README.md\"><strong>.NET Core Releases<\/strong><\/a> to learn about newer releases.<\/p>\n<p>We just\u00a0released updates to the .NET Core SDK, .NET Native Tools and NuGet, all of which are included in Visual Studio 2017 RC. You can also install the .NET Core SDK for command-line use, on Windows, Mac and Linux. Please check out the ASP.NET blog to learn more about <a href=\"https:\/\/blogs.msdn.microsoft.com\/webdev\/2017\/01\/27\/updates-to-web-tools-in-visual-studio-2017-rc\/\">Web Tools updates<\/a>\u00a0and the Visual Studio blog for the\u00a0<a href=\"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2017\/01\/27\/update-to-visual-studio-2017-release-candidate\/\">Visual Studio 2017 RC update<\/a>.<\/p>\n<ul>\n<li><a href=\"https:\/\/www.visualstudio.com\/vs\/visual-studio-2017-rc\">Install Visual Studio 2017 RC<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/dotnet\/core\/tree\/master\/release-notes\">Install .NET Core 1.0 SDK &#8211; RC3<\/a><\/li>\n<\/ul>\n<p>The following improvements are the .NET highlights of the release:<\/p>\n<ul>\n<li>.NET Core &#8211; The csproj project format has been simplified and project migration is much more reliable.<\/li>\n<li>.NET Native &#8211; Major performance increase for SIMD and other performance improvements.<\/li>\n<li>NuGet &#8211; .NET Framework, UWP, .NET Core and other .NET projects can now use PackageReference instead of packages.config for NuGet dependencies.<\/li>\n<\/ul>\n<p>Note: csproj projects created with <a href=\"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2016\/12\/12\/updating-visual-studio-2017-rc-net-core-tooling-improvements\/\">earlier releases of Visual Studio 2017<\/a> or on the command-line with the .NET Core SDK must be manually updated to load in the latest release. Please read the <a href=\"#updating-net-core-projects\">Updating .NET Core Projects section<\/a>, below, for more information.<\/p>\n<h2><a href=\"#net-core\" id=\"user-content-net-core\" class=\"anchor\"><\/a>.NET Core<\/h2>\n<p>The .NET Core tools have been significantly improved in this update, fixing bugs and usability issues. A major focus of this release has been simplifying the project file and improving project migration. We are no longer using the &#8220;preview&#8221; term, but &#8220;RC3&#8221; to match Visual Studio 2017 RC.<\/p>\n<p>The tools in the new SDK produce and operate on csproj projects. If you are using project.json projects, including with Visual Studio 2015, then please wait to install the new SDK until you are ready to move to csproj and MSBuild. If you are a Visual Studio user, you will get the SDK when you install Visual Studio 2017.\u00a0See\u00a0<a href=\"https:\/\/github.com\/aspnet\/Tooling\/blob\/master\/known-issues-vs2017.md\">Known issues for Web Tools, and ASP.NET and ASP.NET\/.NET Core in Visual Studio 2017<\/a>.<\/p>\n<h3><a href=\"#getting-the-release\" id=\"user-content-getting-the-release\" class=\"anchor\"><\/a>Getting the Release<\/h3>\n<p>This .NET Core SDK release is available in Visual Studio 2017 RC, as part of the <strong>.NET Core cross-platform development<\/strong> workload. It is also available in the <strong>ASP.NET Web<\/strong> workload and an optional component of the <strong>.NET Desktop<\/strong> workload. These workloads can be selected as part of the Visual Studio 2017 RC installation process. The ability to build and consume .NET Standard class libraries is available in the all of the above workloads and in the <strong>UWP<\/strong> workload.<\/p>\n<p>You can also install the .NET Core SDK release for command-line use on Windows, macOS and Linux by following the instructions at <a href=\"https:\/\/github.com\/dotnet\/core\/tree\/master\/release-notes\">.NET Core 1.0 &#8211; RC3 Download<\/a>.<\/p>\n<p>The release is also available as Docker images, in the <a href=\"https:\/\/hub.docker.com\/r\/microsoft\/dotnet\/\">dotnet repo<\/a>. The following images include the new SDK:<\/p>\n<ul>\n<li>1.0.3-sdk-msbuild-rc3<\/li>\n<li>1.0.3-sdk-msbuild-rc3-nanoserver<\/li>\n<li>1.1.0-sdk-msbuild-rc3<\/li>\n<li>1.1.0-sdk-msbuild-rc3-nanoserver<\/li>\n<\/ul>\n<p>The <a href=\"https:\/\/hub.docker.com\/r\/microsoft\/aspnetcore-build\/\">aspnetcore-build repo<\/a> has also been updated.<\/p>\n<h3><a href=\"#net-code-sdk-components\" id=\"user-content-net-code-sdk-components\" class=\"anchor\"><\/a>.NET Core SDK Components<\/h3>\n<p>This release contains the .NET Core Tools 1.0 RC3, the .NET Core 1.0.3 runtime and the .NET Core 1.1.0 runtime. No changes have been made to the .NET Core runtime in this release. .NET Core 1.0.3 and 1.1.0 were both released previously.<\/p>\n<p>The .NET Core SDK includes a set of .NET Core Tools and one of more runtimes. In previous SDK releases, there was only ever one runtime included. This change in approach was made to make it easier to acquire all supported runtimes as a single step. This experience helps when you are collaborating with developers who are using multipe runtimes. It also makes it easier to update multiple runtimes on your machine when fixes are released. The SDK naturally gets larger, but not as much as you might guess since there is only ever one set of tools in the package. It also enables us to improve the tools for everyone more easily.<\/p>\n<h3><a href=\"#smaller-project-file\" id=\"user-content-smaller-project-file\" class=\"anchor\"><\/a>Smaller Project file<\/h3>\n<p>The following example is the new, much shorter, default template for .NET Core apps. This is the final project format for .NET Core.<\/p>\n<div class=\"highlight highlight-text-xml\">\n<pre>&lt;<span class=\"pl-ent\">Project<\/span> <span class=\"pl-e\">Sdk<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>Microsoft.NET.Sdk<span class=\"pl-pds\">\"<\/span><\/span>&gt;\n  &lt;<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n    &lt;<span class=\"pl-ent\">OutputType<\/span>&gt;Exe&lt;\/<span class=\"pl-ent\">OutputType<\/span>&gt;\n    &lt;<span class=\"pl-ent\">TargetFramework<\/span>&gt;netcoreapp1.0&lt;\/<span class=\"pl-ent\">TargetFramework<\/span>&gt;\n  &lt;\/<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n&lt;\/<span class=\"pl-ent\">Project<\/span>&gt;<\/pre>\n<\/div>\n<p>You can change the <code>TargetFramework<\/code> value from <code>netcoreapp1.0<\/code> to <code>netcoreapp1.1<\/code> in order to target .NET Core 1.1. The example project above targets .NET Core 1.0.<\/p>\n<p>The following csproj elements\/attributes are no longer included in the project file.<\/p>\n<ul>\n<li><code>ToolsVersion<\/code> &#8211; no longer a required attribute.<\/li>\n<li><code>Compile Include<\/code> &#8211; the new default includes all files.<\/li>\n<li><code>EmbeddedResource Include<\/code> &#8211; the new default includes all resources.<\/li>\n<li><code>PackageReference<\/code> &#8211; is now implicit for <a href=\"http:\/\/www.nuget.org\/packages\/Microsoft.NETCore.App\/\">Microsoft.NETCore.App<\/a>, and <a href=\"http:\/\/www.nuget.org\/packages\/NETStandard.Library\/\">NETStandard.Library<\/a>. All other packages, including ASP.NET Core, still require PackageReference!<\/li>\n<li><code>PackageReference<\/code> for the <a href=\"http:\/\/www.nuget.org\/packages\/Microsoft.NET.Sdk\">Microsoft.NET.Sdk<\/a> package has been moved to a required top-level <code>Project<\/code> <code>Sdk<\/code> attribute.<\/li>\n<\/ul>\n<p>The default template for .NET Standard library projects is very similar:<\/p>\n<div class=\"highlight highlight-text-xml\">\n<pre>&lt;<span class=\"pl-ent\">Project<\/span> <span class=\"pl-e\">Sdk<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>Microsoft.NET.Sdk<span class=\"pl-pds\">\"<\/span><\/span>&gt;\n  &lt;<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n    &lt;<span class=\"pl-ent\">TargetFramework<\/span>&gt;netstandard1.4&lt;\/<span class=\"pl-ent\">TargetFramework<\/span>&gt;\n  &lt;\/<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n&lt;\/<span class=\"pl-ent\">Project<\/span>&gt;<\/pre>\n<\/div>\n<p>Just like with the .NET Core template above, you can target a different version of .NET Standard by changing the <code>TargetFramework<\/code> value. <a href=\"https:\/\/github.com\/dotnet\/standard\/blob\/master\/docs\/versions.md\">.NET Standard 1.4<\/a> was chosen as the default version since it is supported by the .NET Framework and .NET Core and is the highest version currently supported by .NET Native (for UWP apps).<\/p>\n<p>The default template for ASP.NET Core apps is only slightly larger and also does a good job of demonstrating what package references look like, for example with the <a href=\"http:\/\/www.nuget.org\/packages\/Microsoft.AspNetCore\/\">ASP.NET Core meta package<\/a>.<\/p>\n<div class=\"highlight highlight-text-xml\">\n<pre>&lt;<span class=\"pl-ent\">Project<\/span> <span class=\"pl-e\">Sdk<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>Microsoft.NET.Sdk.Web<span class=\"pl-pds\">\"<\/span><\/span>&gt;\n  &lt;<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n    &lt;<span class=\"pl-ent\">TargetFramework<\/span>&gt;netcoreapp1.0&lt;\/<span class=\"pl-ent\">TargetFramework<\/span>&gt;\n  &lt;\/<span class=\"pl-ent\">PropertyGroup<\/span>&gt;\n  &lt;<span class=\"pl-ent\">ItemGroup<\/span>&gt;\n    &lt;<span class=\"pl-ent\">Folder<\/span> <span class=\"pl-e\">Include<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>wwwroot<span class=\"pl-pds\">\"<\/span><\/span> \/&gt;\n  &lt;\/<span class=\"pl-ent\">ItemGroup<\/span>&gt;\n  &lt;<span class=\"pl-ent\">ItemGroup<\/span>&gt;\n    &lt;<span class=\"pl-ent\">PackageReference<\/span> <span class=\"pl-e\">Include<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>Microsoft.ApplicationInsights.AspNetCore<span class=\"pl-pds\">\"<\/span><\/span> <span class=\"pl-e\">Version<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>2.0.0-beta1<span class=\"pl-pds\">\"<\/span><\/span> \/&gt;\n    &lt;<span class=\"pl-ent\">PackageReference<\/span> <span class=\"pl-e\">Include<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>Microsoft.AspNetCore<span class=\"pl-pds\">\"<\/span><\/span> <span class=\"pl-e\">Version<\/span>=<span class=\"pl-s\"><span class=\"pl-pds\">\"<\/span>1.0.3<span class=\"pl-pds\">\"<\/span><\/span> \/&gt;\n  &lt;\/<span class=\"pl-ent\">ItemGroup<\/span>&gt;\n&lt;\/<span class=\"pl-ent\">Project<\/span>&gt;<\/pre>\n<\/div>\n<p><a id=\"updating-net-core-projects\"><\/a><\/p>\n<h3><a href=\"#updating-net-core-csproj-projects\" id=\"user-content-updating-net-core-csproj-projects\" class=\"anchor\"><\/a>Updating .NET Core csproj Projects<\/h3>\n<p>As described above, the .NET Core csproj project files are now shorter. This change moves multiple pieces of project data that were explicitly declared in earlier project files into default settings that are implicitly declared as part of the SDK. The existing explicitly declared data becomes a duplicate declaration of the same implicitly declared data, when loaded with the new tools, which generates MSBuild errors for <code>Compile<\/code> and <code>EmbeddedResource<\/code> elements and warnings for <code>PackageReference<\/code>.<\/p>\n<p>You need to remove the following data from your existing csproj files:<\/p>\n<ul>\n<li>Compile<\/li>\n<li>EmbeddedResource<\/li>\n<li>PackageReference Include=&#8221;Microsoft.NETCore.App&#8221; &#8230;<\/li>\n<li>PackageReference Include=&#8221;NETStandard.Library&#8221; &#8230;<\/li>\n<li>PackageReference Include=&#8221;Microsoft.NET.Sdk&#8221; &#8230;<\/li>\n<\/ul>\n<p>The SDK reference has moved to the root <code>Project<\/code> element, as you can see in the examples above. The SDK reference is required.<\/p>\n<p>For more information, see: <a href=\"https:\/\/github.com\/dotnet\/core\/blob\/master\/release-notes\/1.0\/sdk\/1.0-rc3-implicit-package-refs.md\">Implicit metapackage package reference in the .NET Core SDK<\/a> and <a href=\"https:\/\/github.com\/dotnet\/core\/blob\/master\/release-notes\/1.0\/sdk\/1.0-rc3-default-compile-items.md\">Default Compile Item Values in the the .NET Core SDK<\/a>.<\/p>\n<h3><a href=\"#projectjsonxproj---csproj-migration\" id=\"user-content-projectjsonxproj---csproj-migration\" class=\"anchor\"><\/a>Project.json\/xproj -&gt; csproj Migration<\/h3>\n<p>Major improvements have been made to project file migration (project.json\/xproj -&gt; csproj). The team fixed many <a href=\"https:\/\/github.com\/dotnet\/cli\/issues?q=is%3Aissue+milestone%3A1.0.0-preview5+label%3Amigration+is%3Aclosed\">project migration issues<\/a> to improve the migration experience.<\/p>\n<p>We recommend that you discard previously migrated csproj project files and do a fresh migration from project.json\/xproj so that you&#8217;ll get the new improvements. You won&#8217;t need to follow the manual csproj project file updates described in the section above.<\/p>\n<h3><a href=\"#net-core-cli\" id=\"user-content-net-core-cli\" class=\"anchor\"><\/a>.NET Core CLI<\/h3>\n<p>.NET Core CLI commands were added to make it easier to manage your projects from the command-line. Our goal is to ensure that you can make project changes manually, via CLI commands or via UI in Visual Studio.<\/p>\n<ul>\n<li><code>dotnet sln<\/code> &#8212; This command adds, removes and lists projects to\/from a solution. Usage: <code>dotnet sln [arguments] [options] [command]<\/code><\/li>\n<li><code>dotnet add reference<\/code> &#8212; This command adds a project reference to a project. It replaces <code>dotnet add p2p<\/code>. Usage: <code>dotnet add [PROJECT] reference [options] [args]<\/code><\/li>\n<li><code>dotnet add package<\/code> &#8212; This command adds\/removes\/updates packages in a project file. Usage: <code>dotnet add &lt;PROJECT&gt; package [options] [args]<\/code>.<\/li>\n<\/ul>\n<p>Note that these commands check for illegal states, as appropriate. For example, If you attempt to add a package that is not compatible with a given project, the command will (correctly) fail.<\/p>\n<h3><a href=\"#other-improvements\" id=\"user-content-other-improvements\" class=\"anchor\"><\/a>Other Improvements<\/h3>\n<p>Edit and continue now works for .NET Core projects.<\/p>\n<p>You can develop ASP.NET Core apps with Linux Docker images. See <a href=\"https:\/\/aka.ms\/DockerToolsTroubleshooting\">Docker Tools Troubleshooting<\/a> for additional information.<\/p>\n<p>You can now remote <a href=\"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/2017\/01\/26\/debugging-net-core-on-unix-over-ssh\/\">debug .NET Core apps running on Linux over SSH from Visual Studio<\/a>. See the process attach dialog, attaching to a .NET Core process on Linux!<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/attach-to-process.png\" alt=\"attach-to-process\" width=\"567\" height=\"403\" class=\"aligncenter wp-image-8845 size-full\" srcset=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/attach-to-process.png 567w, https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/attach-to-process-300x213.png 300w\" sizes=\"(max-width: 567px) 100vw, 567px\" \/><\/p>\n<h3><a href=\"#docs\" id=\"user-content-docs\" class=\"anchor\"><\/a>Docs<\/h3>\n<p>You may wonder where the docs are for the new tools. The <a href=\"https:\/\/docs.microsoft.com\/en-us\/dotnet\/articles\/core\/\">.NET Core Docs<\/a> site continues to document the project.json tools and experience.\u00a0We intend to have a complete set of docs in place for Visual Studio 2017 RTM.<\/p>\n<p>In the meantime, the docs are being updated to document the csproj\/msbuild tools and experience in the <a href=\"https:\/\/github.com\/dotnet\/docs\/tree\/csproj\">csproj branch of dotnet\/docs<\/a> and the <a href=\"https:\/\/github.com\/aspnet\/docs\/tree\/csproj\">csproj branch of aspnet\/docs<\/a>. \u00a0The docs are not ready for consumption, but feel free to follow progress or contribute. We are using GitHub projects to manage effort &#8211; see <a href=\"https:\/\/github.com\/dotnet\/docs\/projects\/5\">dotnet\/docs<\/a> and <a href=\"https:\/\/github.com\/aspnet\/Docs\/projects\/6\">aspnet\/docs<\/a>.<\/p>\n<h2>NuGet<\/h2>\n<p>.NET Core projects have adopted the new PackageReference syntax for csproj project files, as you can see in the ASP.NET Core template example above. The PackageReference syntax has now been enabled for other projects, including .NET Framework and UWP.<\/p>\n<p>When you create a new .NET Framework or UWP project, you will now be asked if you want to use the existing packages.config or the new PackageReference format, as you can see below.<\/p>\n<p><img decoding=\"async\" src=\"\" alt=\"nuget-format-dialog\" width=\"500\" height=\"241\" class=\"aligncenter wp-image-8855 size-mediumlarge\" \/><\/p>\n<p>You can set the default NuGet format type in the dialog above or in the NuGet settings dialog, as you can see below.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/nuget-format-default-dialog-1024x693-1.png\" alt=\"nuget-format-default-dialog\" width=\"879\" height=\"595\" class=\"aligncenter wp-image-8865 size-large\" \/><\/p>\n<p>PackageReference is the new NuGet format going forward. We recommend that you start using it for new projects. It is new in Visual Studio 2017 and is not supported in earlier Visual Studio versions.<\/p>\n<p>At present, there is no automated way to convert an existing project that uses packages.config to the new PackageReference format. We know that this is an important scenario that you would like to see integrated into Visual Studio and are working on enabling it. We expect to make this capability available after Visual Studio 2017 releases.<\/p>\n<h2><a href=\"#net-native\" id=\"user-content-net-native\" class=\"anchor\"><\/a>.NET Native<\/h2>\n<p>.NET Native 1.6 RC contains lots of great improvements, including addressing over 100 customer reported issues!<\/p>\n<h3><a href=\"#hardware-accelerated-systemnumericsvectors\" id=\"user-content-hardware-accelerated-systemnumericsvectors\" class=\"anchor\"><\/a>Hardware-accelerated System.Numerics.Vectors<\/h3>\n<p>We&#8217;ve updated .NET Native&#8217;s <a href=\"http:\/\/www.nuget.org\/packages\/System.Numerics.Vectors\">System.Numerics.Vectors<\/a> support to be hardware-accelerated on all .NET Native platforms (using 128-bit SSE2 on x64 and x86 and 128-bit NEON on ARM32)!<\/p>\n<p>Here&#8217;s a rendering of a Mandelbrot set with .NET Native 1.6:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/SIMD_1.6-1-1.gif\" alt=\"simd_1-6\" width=\"495\" height=\"300\" class=\"aligncenter size-full wp-image-8866\" \/><\/p>\n<p>Here&#8217;s the same rendering with .NET Native 1.4:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/SIMD_1.4.1.gif\" alt=\"simd_1-4\" width=\"495\" height=\"300\" class=\"aligncenter size-full wp-image-8875\" \/><\/p>\n<p>As you can see, .NET Native 1.6 takes just 1.9 seconds while .NET Native 1.4 takes 64 seconds to do the same work! The use of SIMD registers providers a major improvement in performance for System.Numerics.Vectors.<\/p>\n<h3><a href=\"#how-to-get-net-native-16-rc\" id=\"user-content-how-to-get-net-native-16-rc\" class=\"anchor\"><\/a>How to Get .NET Native 1.6 RC<\/h3>\n<p>.NET Native is now included within the <a href=\"http:\/\/www.nuget.org\/packages\/Microsoft.NETCore.UniversalWindowsPlatform\/\">Microsoft.NETCore.UniversalWindowsPlatform NuGet package<\/a>, starting with version 5.3.0. This means that you can select the version of .NET Native you want to use by selecting a specific version of the Microsoft.NETCore.UniversalWindowsPlatform package (starting with version 5.3.0). This capability is new with Visual Studio 2017. By using NuGet, we can ship .NET Native updates more easily and it&#8217;s easier for you to select the version you want to use, per project.<\/p>\n<p>Here are the steps:<\/p>\n<ol>\n<li>Right click on the project and select <strong>Manage NuGet Packages&#8230;<\/strong><\/li>\n<li>Select the <strong>Microsoft.NETCore.UniversalWindowsPlatform<\/strong> NuGet package.<\/li>\n<li>Change the version to <strong>5.3.0<\/strong>.<\/li>\n<li>Click the <strong>Update<\/strong> button.<\/li>\n<\/ol>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2017\/01\/vsNugetUpdate-1024x112-1.png\" alt=\"vsnugetupdate\" width=\"879\" height=\"96\" class=\"aligncenter wp-image-8885 size-large\" \/><\/p>\n<p>If you do not see version 5.3.0 listed, make sure that the Package Source is set to <strong>nuget.org<\/strong>.<\/p>\n<p>You can revert back to .NET Native 1.4 at any time by rolling back the Microsoft.NETCore.UniversalWindowsPlatform NuGet package from 5.3.0 to any earlier version such as 5.2.2 or 5.1.0. This can be done by following the same steps outlined above with the desired version.<\/p>\n<p>Visual Studio 2017 RC comes with .NET Native 1.4 by default. This is the same version that is included in Visual Studio 2015 Update 3, with the addition of a few fixes. .NET Native 1.6 is not supported in Visual Studio 2015.<\/p>\n<h3><a href=\"#publishing-apps-to-the-store\" id=\"user-content-publishing-apps-to-the-store\" class=\"anchor\"><\/a>Publishing apps to the store<\/h3>\n<p>You can publish apps to the Windows Store with .NET Native 1.6 RC, starting today.<\/p>\n<p><del><span>We are actively working to enable you to submit apps to the Windows Store using our new .NET Native bits. Stay tuned for updates!<\/span><\/del><\/p>\n<p>We will be actively listening for feedback and may make additional changes for the Visual Studio 2017 RTM. You will need to upgrade to a later version of the Microsoft.NETCore.UniversalWindowsPlatform package if there are additional updates at that time.<\/p>\n<h3><a href=\"#general-improvements\" id=\"user-content-general-improvements\" class=\"anchor\"><\/a>General Improvements<\/h3>\n<p>Here are some of the general improvements:<\/p>\n<ul>\n<li>You can now inspect static fields that contain the <code>ThreadStatic<\/code> attribute.<\/li>\n<li>We&#8217;ve began building the Shared Library package on x64 with profile-guided optimizations which reduces the package size and improves startup time for x64 native apps. This change brings x64 to parity with x86 and ARM32.<\/li>\n<li>We&#8217;ve integrated .NET Native garbage collector with Windows Runtime MemoryManager API to properly calculate memory load factor in UWP applications.<\/li>\n<li>We&#8217;ve reduced compile times for applications that contain large and\/or complex methods by ~25% in certain scenarios.<\/li>\n<li>Up to 400% performance improvement in reverse p\/invoke, and 135% performance improvement when accessing Windows Runtime objects in certain scenarios.<\/li>\n<li>We&#8217;ve made improvements to the reflection stack and metadata formats that resulted in up to 300% performance improvements in some customer scenarios.<\/li>\n<li>We&#8217;ve made improvements to delegate invocation that can reduce code size and give up to 7% faster performance.<\/li>\n<li>We&#8217;ve also made many other code quality improvements which improved startup times, better steady-state performance, less memory usage and smaller app size.<\/li>\n<\/ul>\n<p>Here are some of the more common customer reported issues that we fixed:<\/p>\n<ul>\n<li>We&#8217;ve resolved an issue that sometimes resulted in a 1300 error when submitting a package to the store after upgrading \/ cherry-picking .NET Core assembly packages.<\/li>\n<li>We&#8217;ve resolved an issue that caused a memory leak when interacting with certain Windows Runtime objects in a different process.<\/li>\n<li>We&#8217;ve significantly reduced global lock contention when accessing Windows Runtime objects from multiple threads<\/li>\n<li>We&#8217;ve resolved an issue that resulted in queries not executing properly in Entity Framework when enabling .NET Native. (<a href=\"https:\/\/github.com\/aspnet\/EntityFramework\/issues\/6381\">GitHub #6381<\/a>)<\/li>\n<li>We&#8217;ve resolved an issue with System.Linq.Expressions that resulted in unsupressable error messages. (<a href=\"https:\/\/github.com\/dotnet\/corefx\/issues\/5088\">GitHub #5088<\/a>)<\/li>\n<li>.NET Native will now show a warning if you have a native DLL in a different CPU architecture than the application being built. This is a common mistake that results in the application not being able to launch.<\/li>\n<\/ul>\n<h3><a href=\"#known-issues\" id=\"user-content-known-issues\" class=\"anchor\"><\/a>Known issues<\/h3>\n<p>.NET native does not currently support portable PDBs. When debugging managed components with portable PDBs in application compiled with .NET native, you may have trouble setting breakpoints, stepping in, and\/or inspecting variables of related types in those components. You can delete the files from the local package directory (usersuserName.nugetpackages) to workaround the warning. This change was also made in the servicing update for .NET Native 1.4 in the latest update to Visual Studio 2017 RC. Earlier versions of .NET native may incorrectly throw <code>OutOfMemoryException<\/code> and crash during build when consuming portable PDBs.<\/p>\n<h2><a href=\"#closing\" id=\"user-content-closing\" class=\"anchor\"><\/a>Closing<\/h2>\n<p>We announced our intention last summer to <a href=\"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2016\/05\/23\/changes-to-project-json\/\">bring more uniformity to .NET projects<\/a> and .NET development. Today&#8217;s releases are a major step forward on that plan. Our first focus has been the .NET project format and build tools, as described here. Later this year, we&#8217;ll focus more on available APIs. We intend to make .NET development simpler and easier and will stay focussed on that vision.<\/p>\n<p>Thanks for using Visual Studio 2017 RC, for trying out the new .NET features and for giving us feedback. We&#8217;ve made major improvements for .NET development across multiple application types. We hope that you like them. Tell us what you think!<\/p>\n<p>Please share feedback in the comments or send it directly to us via email:<\/p>\n<ul>\n<li><a href=\"mailto:dotnet@microsoft.com\">dotnet@microsoft.com<\/a> for .NET Core<\/li>\n<li><a href=\"mailto:dotnetnative@microsoft.com\">dotnetnative@microsoft.com<\/a> for .NET Native<\/li>\n<\/ul>\n<p>Thanks for Stacey Haffner, Joe Morris and Zlatko Knezevic for their contributions to this post.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Updated (4\/2017):\u00a0See .NET Core Releases to learn about newer releases. We just\u00a0released updates to the .NET Core SDK, .NET Native Tools and NuGet, all of which are included in Visual Studio 2017 RC. You can also install the .NET Core SDK for command-line use, on Windows, Mac and Linux. Please check out the ASP.NET blog [&hellip;]<\/p>\n","protected":false},"author":336,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[],"class_list":["post-8835","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"acf":[],"blog_post_summary":"<p>Updated (4\/2017):\u00a0See .NET Core Releases to learn about newer releases. We just\u00a0released updates to the .NET Core SDK, .NET Native Tools and NuGet, all of which are included in Visual Studio 2017 RC. You can also install the .NET Core SDK for command-line use, on Windows, Mac and Linux. Please check out the ASP.NET blog [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/8835","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/336"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=8835"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/8835\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=8835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=8835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=8835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}