4

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

ahsteele
  • 26,243
  • 28
  • 134
  • 248
Matt Morgan
  • 360
  • 3
  • 9

1 Answers1

4

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.

Tseng
  • 61,549
  • 15
  • 193
  • 205
  • It seems odd that the Core template using Core targets AnyCPU and Core template using .NET Framework targets x86. – Matt Morgan Apr 25 '17 at 12:19
  • Until I changed my project to AnyCPU and removed the runtime identifier I wasn't able to use Ninject. Which doesn't support Core, but I should be able to load it and use it, if I'm building against .NET 4.6.2 right? Removed this: `win7-x86` Added this: ` AnyCPU ` – Matt Morgan Apr 25 '17 at 12:29
  • In case anyone every looks at this... Doing the above (switching to AnyCPU and not specifying the runtime identifier) broke Kestrel. I got my project to run by switching to WebListener as described here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/weblistener – Matt Morgan Apr 25 '17 at 14:48
  • Something like that was to be expected, as like I said, Kestrel has a native component (libuv) and it needs to know which architecture version to load when you start it (and nuget / build manager to know which one to place in the bin/Release and bin/Debug folders). That's why `win7-x86` is mandatory for net45 (or when you do multitarget and net4xx is one of the targets) – Tseng Apr 25 '17 at 14:50