0

I’m developing a .NET 7 app on Windows 11, Arm64. Compiling for “any CPU”. When trying to run the app in X64 computers, I get an error saying “This app can’t run on your PC”. The computer has .NET 7 SDK and runtime installed.

If I compile the app using .NET Framework 4.8 on the Arm64 computer, it works properly on the x64 computer as well. What is the issue with .NET 7 here?

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
maxo
  • 97
  • 9
  • Do you move the compiled .exe from computer to computer? If so, it seems that the .NET Runtime for .NET Core 7 is missing (or cannot be found) on the target computer, while the normal .NET Framework 4.8 is. Using AnyCPU should allow such interoperability. – Alejandro Mar 08 '23 at 12:53
  • 1
    You've got the wrong .net host, the .exe file. It is an native .exe that takes care of locating the runtime, loading the CLR and just-in-time compiler and jitting your Main() entrypoint. Being native, it can only run on an Arm processor. You could arbitrarily copy the .exe file from another similar project that was built on an x64 machine and rename it. Or run the app with dotnet.exe. You only get true "AnyCPU" with dotnet.exe – Hans Passant Mar 08 '23 at 13:08
  • Thank you Hans. I was able to start the application from the cmd.exe using >dotnet . Why isn’t a universal app.exe being created when I compile? How can I create a universal exe? – maxo Mar 08 '23 at 13:56
  • 1
    Operating systems and processors are not universal. This mattered back in the legacy framework as well, but they were *really* clever at hiding the issue. It required patching the OS loader at runtime. The kind of trick that doesn't port to the Unixes. – Hans Passant Mar 08 '23 at 14:55
  • But obviously the application is executable on x64 using the dotnet.exe. So how do I create an exe on ARM that is executable directly on x64? – maxo Mar 08 '23 at 15:08
  • @maxo you can use [OS-specific TFM](https://learn.microsoft.com/en-us/dotnet/standard/frameworks#net-5-os-specific-tfms) to publish the app. – Guru Stron Mar 08 '23 at 15:38
  • @GuruStron, it's all on Windows, so I'm already targeting Windows Framework. The difference is that I'm developing on Arm64, and targeting x64. – maxo Mar 08 '23 at 20:55
  • @maxo you can use architecture specific TFM, for example - `win-x64` – Guru Stron Mar 08 '23 at 20:59
  • @GuruStron, thank you! That actually worked.. but it created an insane amount of DLLs in the release folder. I wonder why. – maxo Mar 08 '23 at 21:43

1 Answers1

1

You can try using dotnet to run your compiled dll or publish the app (via the UI or using dotnet publish) providing architecture specific runtime identifier (RID) for example - win-x64. Note the --self-contained parameter which by default is true when RID is specified and the project is an executable one:

--sc|--self-contained [true|false]

Publishes the .NET runtime with your application so the runtime doesn't need to be installed on the target machine. Default is true if a runtime identifier is specified and the project is an executable project (not a library project).

Which will lead to publishing all components of the app, including the .NET libraries and target runtime (see the corresponding docs). Set it to false to publish framework-dependent executable, for example:

dotnet publish -r win-x64 --self-contained false

Also you can consider using publish profile files.

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
  • Thank you, this was my solution. The self-contained flag also removed all redundant libraries. But good to know that the option exist. – maxo Mar 09 '23 at 07:40
  • @maxo was glad to help! Self-contained usually pairs well with single file option. – Guru Stron Mar 09 '23 at 07:42