VS 2017 .NET 4.6.2新的ASP.NET核心Web应用程序（.NET Framework）默认为x86平台

Question

Why?

Web Application (.NET Framework) and Core Web Application (.NET Core) both target AnyCPU platform.

Is this a bug or is there some value in doing this?

I'm on Windows 10 x64 and have installed the 4/18/2017 VS 2017 update.

Microsoft Visual Studio Enterprise 2017 Version 15.1 (26403.7) Release VisualStudio.15.Release/15.1.0+26403.7 Microsoft .NET Framework Version 4.6.01586

Answer 1

I suppose it's for compatibility reasons. The x86 is likely to refer to your <RuntimeIdentifier> in csproj.

<PropertyGroup Condition="'$(TargetFramework)' == 'net462'">
  <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
</PropertyGroup>

One of the reason it's required is for pulling Nuget dependencies and ASP.NET core relies on some native/non-managed libraries (=libraries not written in C#/CLR, but native ones in C/C++), like libuv (see NuGet ) which is an async socket library used by ASP.NET Core.

If it would default to x64 then this kind of applications couldn't be restored/run on x86 Operation Systems, so the only sane setting is x86 so far.

For .NET CLR/IL Code, the architecture (x64 or x86) doesn't really matter, but for these external dependencies it does. That's also why you get errors when you covert project.json projects which did target net45 and netstandard1.x to csproj, you need to add the above xml code to your csproj, to give NuGet a hint which type of architecture it should restore.

You can safely change that to <RuntimeIdentifier>win7-x64</RuntimeIdentifier> , if you and none of your coworkers develop the project on an x86 OS. For a list of valid RIDs (RuntimeIdentifiers), see the ASP.NET Core documentation . Though of course, for .NET Framework you are limited to the win* RIDs.

It should be nothing to worry about and you can leave it at the default. Usually it won't matter, as most libraries are are shipped with both x64 and x86 inside the NuGet package. But there could be some libraries which only run on one or either.