Add ability to automatically choose correct architecture. (32, 64 bit)

[LtqxWYEG]

Problem Description

We have to have both versions installed. Two icons on desktop. Also it is uncertain with which version the context menu entry will open the file.

Proposal

Combine both and switch automatically to correct architecture needed for file.

Alternatives

Combine both versions into the same download file and let user start

Additional Context

Since it isn't already implemented, there must be a good reason to keep them separate, right? What is it?

[ElektroKill]

Hi,

To understand this problem let's first look at the 3 dnSpyEx distributions:
The netframework distribution contains both an x64 and x86 binary with the majority of the .dll files shared between them. Both binaries run on .NET Framework 4.8 which is installed on Windows 10/11 by default and can be installed on anything Windows 7 or newer. This release is aimed at compatibility with older systems.

the net-win64 and net-win32 distributions contain a single binary for a single architecture. This is because these distributions bundle the full .NET 6.0 runtime with them meaning that it does not have to be installed on the target system. .NET 6 offers many advantages in terms of performance as it is the newer runtime. However, due to it being newer it also means that Microsoft is dropping support for older operating systems, this will especially be the case when the net distributions move to .NET 8 which released later this year. Due to the inclusion of the runtime, it is impossible to have the two architectures merged into one distribution. Creating a single .NET 6 distribution that contains both x64 and x86 binaries would require us to no longer include the runtime with the distributions and rely on the user installing it themselves (.NET 6 does not come preinstalled on pretty much any Windows version).

Why are two different architecture binaries necessary:
When debugging a process, the debugger needs to be running in the same bitness as the debuggee (same pointer size).
This means that there will forever be a need for a 32-bit dnSpy version (or well until 32-bit apps will be completely eradicated).

Implementing the automatic switching is not possible as in the case of the net distributions, it is not guaranteed if and where the other binary is located. The best that could be done is differentiating the right-click context menu items from the two versions instead of having one. Would such a change be something you would like?

Sorry for the wall-of-text response, if anything is unclear feel free to ask further questions!

[LtqxWYEG]

Hi :) Very interesting. Thank you for the explanation. Yeah, I think the context menu problem is worth fixing. That's how I mainly open the program; and, since it is so convenient, I think I'm not in the minority with this behaviour. Kind regards Edit: What about the double click? Can it somehow choose the rights bits?

[ElektroKill]

Yeah, I think the context menu problem is worth fixing. That's how I mainly open the program; and, since it is so convenient, I think I'm not in the minority with this behaviour.

Good to hear that, I will work on getting the x86 distribution context menu changed to Open with dnSpy (32-bit). The x64 binary will remain with the Open with dnSpy context menu option.

Edit: What about the double click? Can it somehow choose the rights bits?

Double click for .dll and others will always use the first available "handler" for the file (aka. the first context menu entry available in alphabetical order) to my knowledge. This means that after the proposed change to the 32-bit context menu option, double-clicking will always use the 64-bit version. Auto selection of the correct bitness binary is not possible due to the reason regarding the net distributions mentioned in my previous response.

[LtqxWYEG]

Could you not make a small third executable (apart from 32 and 64) that acts as a junction/determinator, that is included in both versions (and identical) - so that the handler can always find it even if both versions are installed - which then looks if the file is 32 or 64 bit and finds and finds out if you have the correct version installed? (In case you might have only 32bit, ie) Then everytime you start one version a registry key is created withe the path to the exec. and the junction app looks it up and loads the file in the correct one or throws error. (key created every start not only at the first, because you might start the program once in Downloads directory and then decide to keep and move it) Ah, sorry. Wrote too fast. Basically a headless launcher type thing in both archives that handles/determines the file stuffs. Alternatively, do actually put both versions together, dnspy_32.exe and dnspy_64.exe, have two folders in root for 32 and 64, dnspy_launcher.exe is handling file enumeration and loads respective dnspy exec. (Depends on how many users may only need one version. If too many, just add the launcher to both archives)