Closed novabe closed 6 years ago
We generally compile for AnyCPU (with an exception for Microsoft.Orleans.ServiceFabric.dll, which is x64). and the code should be runnable on either x86 or x64. Can't you instead set your grain interfaces/classes project as AnyCPU?
We generally compile for AnyCPU
I only checked ClientGenerator.exe and found it was AnyCPU, and didn't investigate further so I'm not sure why it had a problem with x86.
Can't you instead set your grain interfaces/classes project as AnyCPU?
Unfortunately in this case no, because that project has a VC++ dependency and as far as I know it's not really possible to make an AnyCPU VC++ DLL. Alternatively, x64 does work. But I still think it doesn't feel right that it would work with AnyCPU and x64, but not x86. I might be wrong.
I assume the reproduction steps successfully demonstrated the issue.
Thank for the additional details. I was able to reproduce the issue, and looks like what's happening is pretty simple. ClientGenerator.exe
being AnyCPU, on an x64 OS it starts as an x64 process, and because of that it fails to load the x86 binary later.
After I rebuilt ClientGenerator.exe
privately as x86, and manually replaced with it the one in packages\Microsoft.Orleans.OrleansCodeGenerator.Build.1.4.1\tools of my test project, it worked. So everything seems to work if ClientGenerator.exe
starts as an x86 process. Hence, I expect it work out of the box on an x86 OS.
So the immediate workaround for you I think is to use a private x86 build of ClientGenerator.exe
, just like I did. I don't know if there's an app.config setting to force an AnyCPU exe to start as x86 instead of crating a private x86 build.
A potential question here is if we need to build ClientGenerator.exe
as x86 instead of AnyCPU.I'm personally skeptical of that because this could cause issues with loading x64 dependencies, and x64 is the mainstream.
If we want it to always work with both x86 and x64 (not sure how important that is to this project), I'm going to propose this solution:
Store both x86 and x64 builds of ClientGenerator, and call the correct one based on the current project's platform. I think this can be done with changes only to the Microsoft.Orleans.OrleansCodeGenerator.Build.targets file (and format of ClientGenerator.exe).
Store both x86 and x64 builds of ClientGenerator, and call the correct one based on the current project's platform. I think this can be done with changes only to the Microsoft.Orleans.OrleansCodeGenerator.Build.targets file (and format of ClientGenerator.exe).
This sounds like a sensible solution. The only additional twist I'd add to it is that it's better to have the x86 version of ClientGenerator.exe
under a different name, e.g. ClientGeneratorx86.exe
, to minimize the potential confusion and build time implications. If you are willing to prepare a PR, we'll gladly review and take it.
I recently needed to compile for x86 and ran into the exact problem. In case anyone else comes across this thread with this problem, a simple resolution for getting the x86 ClientGenerator.exe is to add this to the Pre-Build script of your project
if $(PlatformName) == x86 ( "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7 Tools\CorFlags.exe" "$(SolutionDir)\packages\Microsoft.Orleans.OrleansCodeGenerator.Build.1.5.3\tools\ClientGenerator.exe" /32BITREQ+
Since ClientGenerator.exe is compiled for AnyCPU this will force it to run as 32 bit and the this will allow you to compile using x86. You can put the flags back to normal by running
if $(PlatformName) == x86 ( "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7 Tools\CorFlags.exe" "$(SolutionDir)\packages\Microsoft.Orleans.OrleansCodeGenerator.Build.1.5.3\tools\ClientGenerator.exe" /32BITREQ-
If you want more information on CorFlags, visit https://docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool
After compiling for x86 I ran into the issue at #2795 . The suggested solution there took care of the issue.
@versex Thanks for the workaround tip!
Build error is: The command ""c:\Projects\orleanstest\packages\Microsoft.Orleans.OrleansCodeGenerator.Build.1.4.0\build..\tools\ClientGenerator.exe" "@obj\Release\orleanstest.codegen.args.txt"" exited with code 3.
Build output is:
To recreate this bug, simply create a new project, add the latest Microsoft.Orleans.OrleansCodeGenerator.Build nuget package, change the project's platform target to x86, and build.