K-Software kann ich nun nicht mehr empfehlen. Die Preise sind ernorm gestiegen und zusätzlich wird nicht über die Notwendigkeit eines USB-Tokens informiert.
Kennt jemand eine gute Alternative?
Hier eine aktuelle News zum Thema ARM, da es langsam wirklich relevant zu werden scheint:
https://www.heise.de/news/Microsoft-stellt-ARM-Surfaces-im-Mai-vor-9681859.html
Habe gerade diese Liste mit nativer Software entdeckt, die auf ARM Systemen nicht emuliert werden muss und daher effizienter läuft. Mein Projekt ist dort auch aufgelistet, freu:)
Mal schauen wie es weitergeht
So, seit ein paar Monaten bin ich umgestiegen auf ein älteres Macbook, jedoch schon mit M1 CPU, und bin total zufrieden. Windows 11 on ARM läuft wunderbar in Parallels (nach ein paar wenigen Feinjustierungen). Der Lüfter geht so gut wie nie an, das Gehäuse wird nicht heiß. So macht es Spaß, mit VIsual Studio zu arbeiten. Für meine Entwicklungsumgebung habe ich x86 nun beerdigt.
Kleine Ergänzung: Möchte man überprüfen, ob es sich bei einem MSI-Paket auch wirklich um natives Arm64 handelt, kann man das Kommandozeilentool "MsiInfo.exe" verwenden. Das Tool ist Teil der Windows SDK.
Beispielaufruf in PowerShell:
& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86\MsiInfo.exe" mysetup.msi
Es werden mehrere Eigenschaften in der Konsole ausgegeben. Relevant ist der Wert für Template(MSI CPU) aus der Eigenschaft mit der Nummer 7, z.B.
...
[ 7][/p] Template(MSI CPU,LangIDs) = Arm64;1033
...
Wer seine Installationspakete bereits mit WiX v3 erstellt kann mit relativ wenig Aufwand auch native Arm64 MSI-Pakete erstellen.
Voraussetzung ist ein bestehendes WiX-Setup Projekt in Visual Studio (ich verwende VS 2022) mit installierter WiX v3 Extension und installierten Build Tools.
Da es für die aktuelle Version 3.14 noch kein offizielles Release gibt, muss der Developer Build (v3.14.0.6526 oder höher) installiert werden. Dazu Visual Studio beenden, das WiX Toolset herunterladen und installieren.
In der Setup-Prokjektdatei "<Projekt>.wixproj" die Plattform-Konfiguration innerhalb "<Projects>" hinzufügen
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|ARM64' ">
<DefineConstants>Debug</DefineConstants>
<OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|ARM64' ">
<OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
In der ".wxs" Datei ist es nötig, den Wert für "InstallerVersion" abzuändern in 500 (vorher: 200). Für das Installationsverzeichnis kann analog zu x64 die Variable "ProgramFiles64Folder" verwendet werden.
Damit sollte der Buiild eines Arm64 MSI-Pakets möglich sein.
Danke für die Infos! Der Quellcode speziell bei den UI Abhängigkeiten (z.B. Magic - The User Interface Library for .NET - Article) ist schon uralt. Sorry, das hatte ich vergessen zu erwähnen. Ist ja dann klar dass meine Erfahrungen hier für die wenigsten relevant sein dürften.
Ich habe mein (WinForms-) Projekt nun teilweise unter .NET 7 zum Laufen gebracht. Das sind meine Erfahrungen soweit:
- Die Klasse "ContextMenu" ist nicht mehr verfügbar
- Referenz auf System.Web ist nicht mehr erlaubt
- Fast alle UI-Elemente sehen etwas anders aus (Größe, Position) bzw. werden in einem Fall (PropertyGrid) viel zu klein dargestellt
- Es gibt ein Problem bei der Verwendung der Klasse "MemoryMappedFiles", das ich mir noch näher anschauen muss
- Die Performancesteigerung (Programmstart und zur Laufzeit) bei Arm64 in meinem Fall ca. 10%
Die Performance hat mich etwas enttäuscht, da hatte ich mir mehr erhofft. Hoffentlich bringt die AOT Kompilierung noch was. So wie ich das verstanden habe werden aktuell jedoch nur Konsolenanwendungen unterstützt.
Weiterhin ist mir aufgefallen, dass der Build mit Target .NET Framework 4.8.1 unter x86 auch auf Windows Systemen läuft, die z.B. nur das .NET Framework 4.0 installiert haben. Das liegt wohl daran, dass ich keine Funktionen verwende, die es nur in höheren Versionen des .NET Frameworks gibt.
Ich denke nun, dass für eine deutliche Performance-Steigerung ein umfassendes Code Refactoring nötig ist.
Das hört sich alles sehr interessant an. Laut dem Tool "upgrade-assistant" müssen vor der Migration nach .Net 7 noch Anpassungen vorgenommen werden. Sieht aber alles machbar aus. Das werde ich mir für mein Freizeitprojekt auf jeden Fall mal anschauen.
Auch ein Vergleich von emulierter und nativer Software ist kaum sinnvoll.
Gerade da ARM einige Hardware Befehle per Software emulieren muss, kann hier ein deutlicher Performance Unterschied bemerkbar sein.
Dies liegt schon in der Natur der Sache.
Ja, das ist mir klar. Mir hat der Vergleich mit der emulierten Exe deutlich gezeigt, dass es Sinn macht, Software auch als Arm build anzubieten. Es hätte ja auch sein können, dass der Performance-Unterschied so gering ist, dass man keinen Unterschied merkt.
...und dass deine Aussage, dass Arm quasi im Alleingang die Welt rettet, vollkommener Humbug ist.
Was bist du denn für ein Spaßvogel? So einen Schwachsinn habe ich niemals behauptet