32-bit COM Assembly Doesn't Work With x86/AnyCPU Target Platform in Visual Studio 2022

Ashish Vora 1

I have a web app which has list of projects, all under single solution. Many of them refers the COM DLLs which is 3rd-party provided. Project X1 refers 32-bit COM DLL and its target platform set as AnyCPU, whereas the start-up project's target platform is x86. All projects targets .Net Framework v4.8.04084.

This combination is working very much fine with Visual Studio 2015 v14.0.25420.01 Update 3.

----------

Migration from VS2015 to VS2022

Opening the same solution in Visual Studio 2022 v17.1.0, it opens all projects including some errors for project X1, see below.

However, the build is successful for all projects including project X1. When try to run it, it throws System.BadImageFormatException for a 32-bit DLL referred in project X1. Find attached file containing the detailed error information.

Same problem if I change the target platform of start-up project to AnyCPU.

I have verified the component installation, visual studio versions and many more things, nothings seems to be causing this.

Is this because Visual Studio is x64 ? Even if it is, there should not be such backword compatibility issues after migration.

Can we have solution for this ? This is really a blocker for people like me migrating older projects to latest VS2022 needs to attended.

----------

Edit:

Opening the same solution in Visual Studio 2019 v16.11.5 works well without any changes.

David Lowndes 4,711 Reputation points

2022-03-04T09:18:16.68+00:00

Your startup project should presumably be x86 to match the DLL it uses. Switch back to that, what error do you get then?
Ashish Vora 1 Reputation point

2022-03-04T09:57:11.227+00:00

As a part of migration from VS2015 to VS2022, no changes have been made. The target for start-up project is set to x86 only, it throws the same error attached above, and the same output even if I change it to AnyCPU.
RLWA32 40,471 Reputation points

2022-03-04T10:06:33.143+00:00

Project X1 refers 32-bit COM DLL and its target platform set as AnyCPU

Change project X1 from AnyCPU to x86.
David Lowndes 4,711 Reputation points

2022-03-04T10:15:59.617+00:00

For the error you get, you appear to have a 64-32 bit mismatch somewhere in the components you build/use.
As you appear to have a fixed 32-bit dependency, ensure you build everything as x86.
Ashish Vora 1 Reputation point

2022-03-07T05:33:25.767+00:00

Thanks @David Lowndes , Yes, that could be one of the option. But I'm still unclear about why the same solution works in Visual Studio 2015 but for Visual Studio 2022, we need to make changes. As I mentioned above, it would be difficult to make such changes unless they are the part of known issues/changes in Visual Studio 2022.
Ashish Vora 1 Reputation point

2022-03-07T05:44:50.553+00:00

Thanks @RLWA32 , changing the target platform would be difficult for the stage of the project right now. This could be again one of the option but not sure why we need to make these changes as this works fine with VS2015.

If there are specific changes in VS2022 that lead to such issues, I think it would be in better to convince stakeholders of doing these changes.
David Lowndes 4,711 Reputation points

2022-03-07T10:39:26.86+00:00

Possibly due to the prefer 32-bit option?
Ashish Vora 1 Reputation point

2022-03-07T12:33:15.09+00:00

Prefer-32-Bit option is also not set.
David Lowndes 4,711 Reputation points

2022-03-07T12:36:12.97+00:00

Then set it.
RLWA32 40,471 Reputation points

2022-03-07T13:53:50.52+00:00

The Prefer-32 bit option is irrelevant for a class library. In VS2019, it is disabled in a class library project properties.

So if it is available to be set then the assumption would be that it is a project property for the start-up project. If that is the case then the start-up project was NOT x86, but was AnyCPU!

Now I'm not sure exactly what we've been talking about.
Albert Kallal 4,651 Reputation points

2022-04-09T03:05:57.533+00:00

Keep in mind that in 2015 days, any CPU while debugging or running would launch by default as x32. Remember, if you choose "any", then what command line you use (x32, or x64) will in fact determine what bit size you get. However, for a VERY long time, choosing "any" cpu and running FROM (and I stress the word FROM) VS means that now any CPU runs as x64 bits, where as previous versions (previous to 2019), you wound up with a x32 bit in-process.

Now, I find my x32 COM objects tend to break, since now, when you hit f5 to run + launch your app, you now get a x64 bit version running - and this occurs if you use ANY cpu. As noted, previous to 2019 (don't know which version), you always would get a x32 bit running version, even when you choose any cpu.

so, one reason for different behaviors? ANY cpu will now run + debug as x64 bits. What this suggests now?

If you want to test or run as x86, then set the project to x86. If you want x64, then set the project to x64.

So, referenced .net assemblies can be "any" CPU and they WILL take on the bit size of the main program that consumes those .dll's and assemblies.

However, WITH com objects? that is some what different, since COM objects are NEVER "any", but are registered on windows to be a x32 com object, or a x64 com object. However, if you choose ANY cpu, then you can register both bit sizes from that single .dll. You do TWO regams (run regasm32, and/or regasm64 to register which com object you want - or both)..

1 answer

Albert Kallal 4,651 Reputation points

2022-03-16T19:46:00.773+00:00

As a FYI?
The default for VS, I think up to 2017 was "any cpu" would run as x32 bits.

Now, in 2019 (or later), "any cpu" will result in your project running as x64 bits.

So, you have to FORCE the project to run as x86.

If you don't have a x86 setting, then click on configuration manger in above and add x86.
(you can use the x64 template during that prompting process).

So, what has changed?
Any CPU now defaults to x64 compared to previous versions of VS defaulted to x32 when using "any cpu". So, now, and these days, you have to set and "force" the issue.

Note that if you accidently, (or on purpose referenced some of the other assembles, and re-compiled them, that I would check those other projects - set to x86, and re-compile (rebuild all).

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Please sign in to rate this answer.

0 comments No comments
Sign in to comment