In AnyCPU, using x86.dll

[patrick]

Hello.

In AnyCPU, ADD Reference x86.dll => both AnyCPU platform compile c#source And x86.dll platform compile c# source
But Error.

--There are condition that AnyCPU cannot be changed to x86.
and x86 cannot be changed AnyCPU.

I must do In AnyCPU, ADD Reference x86.dll

Please help me

 

[jmcilhinney]

Your application needs to be the same bitness as your library in order to use it. If your library is 32-bit then your application needs to be 32-bit. If you target Any CPU but do not check the Prefer 32-bit box then the application will only be 32-bit when run on 32-bit Windows. You need to check that box in order for the application to be 32-bit on 64-bit Windows. It will still be 64-bit if the platform doesn't support 32-bit but then the library would obviously be useless anyway.

 

[patrick]

Your application needs to be the same bitness as your library in order to use it. If your library is 32-bit then your application needs to be 32-bit. If you target Any CPU but do not check the Prefer 32-bit box then the application will only be 32-bit when run on 32-bit Windows. You need to check that box in order for the application to be 32-bit on 64-bit Windows. It will still be 64-bit if the platform doesn't support 32-bit but then the library would obviously be useless anyway.

Error :
System.BadImageFormatException: 'Could not load file or assembly 'MyLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Reference assemblies should not be loaded for execution.


(There are condition that AnyCPU cannot be changed to x86. and x86 cannot be changed AnyCPU)
I cannot add a reference to ML.NET (x86) in the AnyCPU source code.

 

[jmcilhinney]

I tested before posting and it worked for me so I'm not sure what's different with your projects/assemblies. Exactly what library are you trying to reference? Have you checked the box I mentioned?

 

[patrick]

I tested before posting and it worked for me so I'm not sure what's different with your projects/assemblies. Exactly what library are you trying to reference? Have you checked the box I mentioned?

PC : intel Core i7
My PC : Windows10 64bit OS
VS : VisualStudio2019
Source : C# Source < Platform : AnyCPU > ( This does not change Platform : AnyCPU to Platform : x86. only AnyCPU )
dll : C# Source < Platform : x86 > This is a DLL developed using ML.NET (Microsoft.ML currently supports 'x64' and 'x86' processor architectures. Please ensure your application is targeting 'x64' or 'x86')


The goal is to add a reference to Platform:x86 DLL in source Platform:AnyCPU.

Error :
System.BadImageFormatException: 'Could not load file or assembly 'DLL', Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Reference assemblies should not be loaded for execution.

 

[Skydiver]

Did you check the checkbox mentioned above: "Prefer 32-bit"?

Why do you insist on the main app being AnyCPU if you are forced to run x86 anyway due to the dependencies that you have? This is another time to you need to ask your client/customer again: "Why do you have this specific requirement? What do you think that you are gaining?"

 

[patrick]

I tested before posting and it worked for me so I'm not sure what's different with your projects/assemblies. Exactly what library are you trying to reference? Have you checked the box I mentioned?

It's inactive,
How do you activate it?

 

[Skydiver]

What kind of project did you select from the project templates?

 

[patrick]

What kind of project did you select from the project templates?

Application type : class library

 

[Skydiver]

The preferred 32 bit is only available for executables, not libraries. This is because a library cannot dictate what bitness the executable that is loading it needs to be after the executable has already started.

 

[jmcilhinney]

This is a perfect example of why you need to provide a FULL and CLEAR explanation in the first place. If you don't, we have to guess or assume and we can get that wrong and waste everyone's time. I assumed that you were creating an application project that was referencing a library. I would think that my language in post #2 would make that clear, given how often I used the word "application". If you had specified that it was a library project referencing a library in the first place, we could have avoided wasting a day and a half on this.

 

[jmcilhinney]

If you are creating a library that has to reference another library that is x86 then your library cannot run in a 64-bit process anyway, so why would you need to target Any CPU? Make your library x86 and have it reference the existing x86 library, then the advice that I've already provided will apply to any other application projects that reference your library. If you can't make your library x86 then you're out of luck so we're done here.

 

[Skydiver]

So far, nobody has made a general purpose thunking layer that let's x64 CLR code call x86 CLR code. Not it's impossible, but rather I think there has been no serious demand for it.

Back in the Win95 days, the OS had a 32-bit to 16-bit thunking layer to let the code that was compiled for 32-bit still be able to talk to the 16-bit components that were brought over from the 16-bit Windows 3.x OS. When the 64-bit Windows versions came along, there is an OS level 32-bit to 64-bit thunking layer that exists, but that is only for the OS APIs that need such access. That list of APIs needed to be known at build time.

 

[patrick]

So far, nobody has made a general purpose thunking layer that let's x64 CLR code call x86 CLR code. Not it's impossible, but rather I think there has been no serious demand for it.

Back in the Win95 days, the OS had a 32-bit to 16-bit thunking layer to let the code that was compiled for 32-bit still be able to talk to the 16-bit components that were brought over from the 16-bit Windows 3.x OS. When the 64-bit Windows versions came along, there is an OS level 32-bit to 64-bit thunking layer that exists, but that is only for the OS APIs that need such access. That list of APIs needed to be known at build time.

I compiled and built for x86. Like the picture below

If you open the ClassLibrary1.csproj file in notepad above image, you will see the image below.

Question--1) In notepad, <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <-=== Why is it marked as AnyCPU?
As you can see in the picture above, I compiled and built it for x86 Platform.

Question--2)
Successful exe compiled and built with x86 Platform,,,,
Can't I use it on a PC with < PC : intel i7-64bit, PC OS: Windows10-64bit> ?

 

[Skydiver]

This doesn't mean what you think it means:

<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>

Notice the Condition attribute. This attribute will only make the section active if the condition is true. So that line is saying that if the build is initiated with the Platform property equal to '' (e.g. empty string or not set), then fall back to setting the Platform property to AnyCPU.

This can sometimes happen when people run MSBuild.exe from the command line and use the .CSPROJ file directly. As far as I know, if you run devenv.exe or use the .SLN file from the command line, then the Platform property is always selected to a valid value (unless you do some major hacking on the .SLN file or do some acrobatics with adding and removing build targets using the Visual Studio UI.)

A the dirty little secret is that Visual Studio in GUI mode just sort of uses MSBuild.exe to build. It actually hosts its own build engine that more or less parallels the build engine used by MSBuild.exe. (If you run devenv.exe to build, it eventually falls back to using the same build engine used by MSBuild.exe.) Anyway, the theory is that the .CSPROJ reflects a consistent set of settings that both the GUI as well as MSBuild will use to build your project.

As for your second question, any x86 Windows binary should run on a x64 Windows. (This is why for several years, Microsoft Office had both 32-bit and 64-bit versions available on their release CDs and DVDs, but the default was to install the x86 even though the target OS was x64 bit. You had to explicitly install the x64 on the 64 bit Windows. MS had to deal with less support calls back then when 64-bit Windows was not as popular. Nowadays, I believe that it detects the target OS and selects the corresponding version of Office (unless overridden by a group policy to still force 32-bit).) Unfortunately, your screenshots for your second question just show black rectangle with some light colored splotches so we can't see what error you are getting or what behavior you are seeing.