12

If I have a "Any CPU" compiled .NET app, it will run in 64bit mode on a 64bit OS.

But if I, for whatever reason, wants to force this app to run in 32bit mode. (As if it were compiled using "x86"). Recompiling is not an option, so is this possible to config at run time ? With the .manifest file perhaps?

Magnus Johansson
  • 28,010
  • 19
  • 106
  • 164

2 Answers2

11

I believe you can do this with CorFlags.exe

Something like:
CorFlags yourassembly.exe /32BIT+

Note that if the assembly is strong named you will also have to use the /force option which breaks the strong naming, so you'll then have to resign the assembly.

Simon P Stevens
  • 27,303
  • 5
  • 81
  • 107
  • Well, that's is unfortunately not feasible. The app in question is strong named and distributed to end users (consumers), and re-signing is not really an option either. Too bad. – Magnus Johansson Jun 12 '09 at 12:38
  • 1
    You can set the CLR to skip strong name verification for a specified assembly. Using "sn.exe -Vr assemblyname" (-Vu to re-enable). Obviously this would have to be run on the customers machine. I wouldn't really recommend this though as disabling strong name verification basically punches a security hole in the CLR, any assembly could be copied over your app and would receive full trust automatically (See: http://msdn.microsoft.com/en-us/library/k5b5tt23.aspx). My recommendation is don't mess with this, find a way to do a re-compile, or don't do it. – Simon P Stevens Jun 12 '09 at 20:48
  • @Simon P.Stevens, I agree with you on all points. My hope were that it could be an entry in the manifest file that I could distribute. But that seems not the case. – Magnus Johansson Jun 19 '09 at 15:13
  • 1
    I think the corflags field is in the manifest file, but the manifest file makes up part of the signed assembly too, so changes to it break the signing. I suppose it might be possible to distribute a separate manifest file and somehow get your app to ignore the one embedded in it. Perhaps it's something you could try. See here: http://blogs.msdn.com/dsvc/archive/2008/06/28/x86-x64-ia64-any-cpu.aspx it mentions the actual fields in the manifest file. Let me know if you manage to get this working. I'd be quite interested in how you did it. – Simon P Stevens Jun 19 '09 at 17:47
1

I got a new solution!

Writing a custom .NET host is a better solution for this question. Because host is native applications, if you compile it as 32/64bit app, the assembly it loads will run on 32/64bit mode.

Don't need to worry about hosting because .NET build processes provide a default host to run .NET applications. In some specialized circumstances, though, it can be useful to explicitly host the .NET runtime.

So, you can prepare two host (C++ app), one build as 32bit app, the other is 64bit. And make a launch （exe or script) that invoke the host which mode you like. The host will load and run your assembly with the same mode as the host.

There is a tutoral about Hosting Core CLR: Write a custom .NET Core host to control the .NET runtime from your native code.

If your assembly is .net framework app, see Hosting the CLR the Right Way.

anchur
  • 39
  • 6
  • off topic, the question stated that >Recompiling is not an option – arslan2012 Sep 21 '20 at 03:49
  • 1
    @arslan2012 the assembly doesn't need to recompile, the host is an extra app that load and run the assembly. Your assembly just keep as it is. – anchur Sep 21 '20 at 04:08
  • Interesting. The question was posted over 11 years ago. A lot of water has passed under the bridges since then so I don't remember the exact scenario and if this was applicable at the time. – Magnus Johansson Sep 21 '20 at 08:04