5

I have a vs2015 solution containing an asp.net core project and have configured its project.json as follow :

{
  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "platform": "x86"
  },
  "runtimes": {
    "win10-x86": {}
  },
  "frameworks": {
    "net461": {}
  },
  "commands": {
    "web": "Microsoft.AspNet.Hosting --ASPNET_ENV production --server Microsoft.AspNet.Server.Kestrel --server.urls http://+:12345",
  }
  [...]
}

I am expecting the application to build and run with the platform specified in project.json ( FYI, I am running the app via vs2015 debugger on a win10/x64 box ). However, win7-x64 runtime is used instead. I can see a win7-x64 output directory and the prompt title launched indicates it too.

If I build and run directly via command line specifying the runtime, it works.

So my question is, what else do I need to configure to start the asp.net core app in x86 from vs2015 ?

DarkUrse
  • 2,084
  • 3
  • 25
  • 33

3 Answers3

6

Victor Hurdugaci's answer should be upvoted, this here just provides some more information in case you need it.

There seems to be a tooling issue at the moment when you have installed both the x86 and x64 .NET Core versions (More on this here: 32 bit not in good state and workarounds and the links).

Setting "buildOptions" to "platform": "x86" and "runtimes": to "win7-x86" in project.json is not working (the x64 directory can still get created during built depending on the PATH environment variable).

This will hopefully get fixed after they switch from project.json to .csproj (why they change it here: Changes to Project.json).

At the moment when you have installed both versions like this (.NET Framework Downloads):

enter image description here

You need to set the order in the path environment variable:

enter image description here

So that the one you want to use appears first and then (re-)start Visual Studio.

To check which dotnet is currently "active" run: dotnet --info in the console.

A.J.Bauer
  • 2,803
  • 1
  • 26
  • 35
  • Noting on "(this will be) fixed (when) switching from project.json to .csproj". I kind of hate it isn't already fixed with what we have now. Why isn't vs2015 making use of global.json > "sdk" > "architecture" for this purpose ? This flag seems to have be forgotten since dnx old times. It could have been a good (valid?) option to know what CLI the developer intends to run when hitting F5... And regarding .csproj choice, don't even get me started on that bad move :/ – DarkUrse Oct 13 '16 at 15:56
5

There are 2 options:

  1. (global) Uninstall the 64 bit .net SDK and install the 32 bit one. Restart VS afterwards.
  2. (local) Put a new .net SDK in a different folder and add from a console that path to your PATH. Then start VS from there. It will pick the first dotnet it finds on the PATH.
Victor Hurdugaci
  • 28,177
  • 5
  • 87
  • 103
  • 1
    That sounds .. extreme. As I said, I can build and run x86 version of my app from the command line specifying the rid ( So, I think I do have the appropriate runtime ). But curiously I have no control to choose from vs2015 GUI. – DarkUrse Sep 15 '16 at 07:40
  • Thanks Victor, you were correct after all. I was somehow expecting vs2015 to magically extrapolate from the project.json which version of the runtime I wanted to launch.. – DarkUrse Sep 15 '16 at 13:14
0

This is what worked for me :

An hour ago, visual studio 2015 team released a new update labeled "Microsoft Visual Studio 2015 Update 3 (KB3165756)"

After installation, everything works as expected.

A big thanks to MS and .net core / vs2015 teams for this extremely timely release :)

Addendum:

Installing the update isn't enough ( although I suspect it is part of the fix ). The additional steps to make this work you need to follow @VictorHurdugaci directives:

  1. Ensure you have installed the x86 version of the .net SDK

  2. And ensure PATH order of "C:\Program Files (x86)\dotnet\" before "C:\Program Files\dotnet\" the runtime which is not guaranteed when you install the new package ( I wanted to keep both x86 and x64 runtimes )

Thanks VictorHurdugaci, at the end of the day you were absolutely correct.

DarkUrse
  • 2,084
  • 3
  • 25
  • 33