32-bit binaries don't work

[fahadash]

Regardless of what app type (Console, MVC Web, etc), you compile a 32-bit binary and it crashes.

I have tried the following steps in Windows 7, 10, VS2015 CE and VS2017 CE.

I have Windows 10, Visual Studio 2017. .NET Core App (any kind) will certifiably crash. Here is what you have to do: Start VS2017, Start a new .NET Core Console App, change the build settings to compile x86, hit play button. That's right! no code change, just the wizard generated "hello world" crashes immediately upon start. It has been going on since .NET Core 1.0, I thought they fixed it in 1.1; I have been searching internet for so long and exhausted possibilities I would love to get this fixed because I have a use case to run x86.

It has been going on since 1.0, and the latest one still crashes. Any solutions folks?

[Petermarcu]

@nguerrera you had some context on this. Can you share any info.

@fahadash do you need the image to be marked as 32-bit or can you just run it with the 32-bit dotnet.exe which will cause it to be jitted as 32-bit?

[fahadash]

I need image to be 32 bit. I am referencing a com interop 32 bit assembly.

[Wraith2]

I've just hit the same problem. I need a 32 bit image for interop as well.
The problem is that visual studio is using the 64 bit version of dotnet.exe to try and debug which results in a BadImageFormatException. I've verified that I have both x86 and x64 builds installed and that invoking the 32 bit dotnet exe with the project output does work so the compilation if fine but visual studio isn't attempting to resolve the correct debugging executable correctly when changing build platform targets.

I just experimented. Visual studio is using the path environment variable to locate dotnet.exe so the temporary fix seems to be to ensure that 32 is higher in the search order than 64. However I think this is really something the programming environment should handle not the user externally.

[nguerrera]

By default, VS (and dotnet run) will just use the dotnet.exe that comes first on your PATH to run the application. So, one (very inconvenient, ugly) approach is to make sure c:\Program Files (x86)\dotnet comes before c:\Program Files\dotnet on PATH before launching VS. But since that's global, it will give you the opposite problem: failure to run x64 apps.

Better option: you can override the default `$(RunCommand)~ to redirect to the more appropriate dotnet:

1. Add a file named Directory.Build.targets in a folder that is common to all of your projects, e.g. the root of your repo. See https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build

2. Give it the following content:

<Project>
  <PropertyGroup 
      Condition="'$(OS)' == 'Windows_NT' and
                 '$(PlatformTarget)' == 'x86' and
                 '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
                 '$(SelfContained)' != 'true'"
                  >
    <RunCommand>$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>
  </PropertyGroup>
</Project>

This says: if I'm evaluating the project on Windows and I'm targeting x86 with a framework-dependent .NET Core app, use dotnet from Program Files(x86).

As a cheap fix. we could consider putting this directly in the SDK as the new default. I have some more elaborate thoughts on how to make the experience switching between x86 and x64 to account for scenarios other than just F5 and where dotnet 32-bit/64-bit are in locations other the Program Files defaults. I plan to write those ideas up soon, but hopefully above is enough to keep folks unblocked...

[adamsitnik]

@nguerrera thanks for help!

[Wraith2]

I think that's the wrong link, did you mean MSBuild .Targets Files? Using that I've added a specific x64 override as well do no matter your environment variable order it'll pick the right version for the platform if you specify the platform. AnyCPU will use the default.

  <PropertyGroup 
      Condition="'$(OS)' == 'Windows_NT' and
                 '$(PlatformTarget)' == 'x86' and
                 '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
                 '$(SelfContained)' != 'true'"
                  >
    <RunCommand>$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>
  </PropertyGroup>

  <PropertyGroup
    Condition="'$(OS)' == 'Windows_NT' and
                 '$(PlatformTarget)' == 'x64' and
                 '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
                 '$(SelfContained)' != 'true'"
                  >
    <RunCommand>$(ProgramW6432)\dotnet\dotnet</RunCommand>
  </PropertyGroup>
</Project>

[nguerrera]

Both links have info about Directory.Build.targets/props

[nguerrera]

Glad that worked for you. Having the symmetric case for x64 handled is goodness. Thanks for sharing that improvement.

[nguerrera]

You can simplify handling both x86 and x64 by using a single property group and moving the PlatformTarget condition to the RunCommand:

<Project>
  <PropertyGroup 
      Condition="'$(OS)' == 'Windows_NT' and
                 '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
                 '$(SelfContained)' != 'true'"
                  >
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>
    <RunCommand Condition="'$(PlatformTarget)' == 'x64'">$(ProgramW6432)\dotnet\dotnet</RunCommand>
  </PropertyGroup>
</Project>

[nguerrera]

Closing this as a duplicate of https://github.com/dotnet/cli/issues/7532