32 bit not in good state and workarounds

[kili0fi]

I am building 32 bit versions of everything in Asp.Net Core, because i have some legacy COM modules to support. 32 bit support is not well implemented, and has bugs. The solution consists of clean Asp.Net Core app with project.json, and from a .net module wrapping COM as .csproj.

• Even when configuring the solution completely to x86, the ASp.Net project builds to net452/Win7-x64 folder, even when project.json BuildOptions has "platform": "x86".
• File Libuv.dll is wrong, and i need manually to replace it from x86 nuget package. If not replaced, host.Run(); fails.
• Publishing does not work for 32 bit config. I use manual command:
  dotnet publish "%CurrentPath%" --framework net452 --runtime win-x86 --output "%TargetPath%" --configuration Debug --build-base-path "%CurrentPath%\artifacts\bin\MyProject"
  I need to allow the publishing to build it, publish, and afterwards copy correct Libuv.dll.

[guardrex]

IIRC you'll need to install 32 bit/x86 dotnet cli on your machine. Cross-compiling bitness to 32 from 64 is a known non-working scenario right now. See: aspnet/IISIntegration#214, https://github.com/dotnet/cli/issues/2922, and https://github.com/dotnet/cli/issues/2881.

[kili0fi]

32/64 bit should be just another project option. I do have x64 projects too. How do we do mixture of projects then?

[muratg]

@kili0fi You can install both 32bit and 64bit dotnet SDKs on your machine, side-by-side.

[kili0fi]

Tested, They can be installed side-by-side, but either one dominates depending on system PATH. So mixture of projects is possible, but it is really clumsy. This can be only temporary state. Either they should cross-compile or delegate to each other.

Installing x86 version fixes many things.

• Output directory changed from -x64 to Win7-x86, as it should.
• It now installs correct 32-bit libuv.dll.

But leaves room for improvement: None of these are showstoppers.

• The aforementioned support for mixture of projects.
• 32bit SDK is well hidden artifact. I suggest "Which version(s) i should install?" page.
• Publishing from Visual studio still fails, because it searches exe from wrong "Win" directory instead of "Win7-x86":
  C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets(149,5): Error : Could not find a part of the path 'D:\project\artifacts\bin\project\project\bin\Debug\net452\win\project.exe'.
  Running the publishing manually and enabling compilation fixes it.

[muratg]

cc @piotrpMSFT

[guardrex]

Dup of https://github.com/dotnet/cli/issues/2343

Related Issues:
https://github.com/dotnet/cli/issues/3387
https://github.com/dotnet/cli/issues/2922
https://github.com/dotnet/cli/issues/2881
https://github.com/dotnet/cli/issues/2428

[MatLeger]

Where can the 32 bit SDK be found? As @kili0fi mentioned it appears to be a well hidden artifact.

[kili0fi]

whispers quietly @MatLeger , go to www.asp.net. then download page, then Other Downloads, link is under the big white bar below "Docker".

[kili0fi]

One more finding: I have in my solution a windows dll as csproj. After installing the x86 SKD, the main project, which is project.json, can't find the dll. I had to change in the csproj the output path of e.g. debug, x86 configuration, output path from bin\x86\Debug\ to bin\Debug\ .

Although project.json is nice and clean, i am not so fond of it, if it is TOO simplistic, and can't be tweaked to actually work. We have solutions consisting of tens of modules. Their builds must work.

[kili0fi]

@guardrex , i see this issue might have fitted better into cli section. Bear with me while i am learning the ropes. Before this open-source stuff i just kicked closest MS arse. Above is my last finding before vacation. Feel free to close this issue if it's a duplicate.

[guardrex]

@kili0fi They'll cross-reference fine this way. The original issue is well known. Right now, they have it at the 1.0.0-prevew3 milestone (14% complete). If you can find a workaround, that seems like a good idea given where preview3 is at.

[jamesqo]

I also seem to be experiencing this issue; dotnet publish -c Release with a win10-x86 RID in the project.json says that it's not compatible with any of the target runtimes (all 64-bit).

[john-luke-laue]

@kili0fi I'm also trying to build my .NET Core Web Application using the x86 version of the SDK, but I can't seem to point dotnet to use the x86 version. I installed the x86 SDK from here, and it's sitting in C:\Program Files (x86)\dotnet

When I open my project in Visual Studio 2015, I get the error:
The project is configured to use .NET Core SDK version 1.0.0-preview2-003131 which is not installed or cannot be found under the path C:\Program Files\dotnet. These components are required to build and run this project. Download the version of .NET Core SDK specified in global.json or update the SDK version in global.json to the version that is installed.

Here is my global.json:

"sdk": {
    "version": "1.0.0-preview2-003121",
    "architecture": "x86"
  }

Any ideas about how to fix this?

[kili0fi]

@john-luke-laue , i suggest you look at your system PATH. Studio can't select which SDK it uses. Move the (x86) directory before the 64-bit version. If studio finds the 64-bit version first, it delegates to it, and it in turn fails to make correct x86 build.

If you give in command prompt command
dotnet --info
the last line should be
RID: win81-x86
when it finds the x86 version. If it says
RID: win81-x64
then the 64-bit version is first in path.

[Alxandr]

Is this still the case?

[ms0713]

@Alxandr Exactly how to achieve this ? "Move the (x86) directory before the 64-bit version". What I did was, removed dotnet folder from C:\Program Files(x86)\dotnet. But then my VS solution was not able to pick up dotnet from C:\Program Files\dotnet. Can you help?

[muratg]

@ms0713, @kili0fi is talking about the order in the PATH environment variable.

[Eilon]

Closing this issue because it isn't clear to me if there is an issue remaining. If you feel there's still an issue, please re-open this issue or log a new issue with complete details of the problem. Thanks!