Win10 ARM version ?

[pplanch]

Is your feature request related to a problem? Please describe. I am developing Excel VBA projects for use on both Windows and Mac machines. Since the introduction of the M1 Macs, the only possibility to run Windows on a VM on my Mac is through the ARM version (from the Insider program). It appears the RibbonX installer I downloaded requires an x64 architecture ...

Describe the solution you'd like Is it possible to get a version out that supports Win10 ARM as well ?

Describe alternatives you've considered I am new to RibbonX and don't know if any alternatives exist for ARM-based Office 365 on Win10. If there are, I'd be happy to explore those ...

Additional context I'm happy to contribute in translation support (I am native Dutch speaker, and fairly fluent in German and French), please let me know if this is of interest to you.

[fernandreu]

Hi @pplanch, support for Win10 ARM64 is something I could definitely add, although there might be a few issues for that to work:

1. Tool support: dotnet should support ARM64 without issues. It seems getting a Visual Studio installed might be a bit more problematic but it isn't really needed if you can build it via dotnet. The installer tool I use, Inno Setup, has also added support for Windows 10 ARM64 recently
2. Library support: after a quick search, I found out that WPF ARM64 support is coming with .NET 6 (to be released in November this year): https://github.com/dotnet/wpf/issues/4117. I'm not so sure about the other libraries that this repo uses though. There might be some effort needed in rebuilding some of these libraries to target ARM64 as well. In the worst case, there might be some issue preventing you from doing that
3. Build system support: this is the part I'm less sure about. I use Azure Pipelines to do the automated builds, but I haven't seen any mention of a Microsoft-hosted Windows ARM agent after a quick search. This would make sense if only Insider builds are available so far. I suspect they will be added to Azure Pipelines eventually

So, long story short: there isn't much I can do right now (especially given I don't own a newer Mac myself), but I am reasonably confident I could add Win10 ARM64 support in the future.

In the meantime, perhaps there is something you could try on your Windows VM:

• Download and install the latest .NET 6 SDK preview from here
• Clone this repo (or download a ZIP and extract it somewhere)
• Go to the file src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj and, at around line 14, change <TargetFrameworks>net461;net5.0-windows</TargetFrameworks> to <TargetFrameworks>net6.0-windows</TargetFrameworks>,
• Run the following in a command prompt: dotnet build path\to\src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj

If you are lucky, the command will run without flagging any errors (just warnings), and an executable will be created in src\OfficeRibbonXEditor\bin\Debug\net6.0-windows for you to try. More realistically, this will throw some errors that may or may not be easy to resolve. If you show me those errors here, I will try to help.

Regarding the translation support, this is always welcome! There is a German translation already, but nothing yet in terms of Dutch or French. Let me know if you need more guidelines than what I wrote in the readme or what was commented in previous issues (#139 #154 #163).

[pplanch]

@fernandreu, first of all , thanks for your fast and extensive response, highly appreciated.

Not sure if my direct reply through e-mail is the right “protocol” (I am unfamiliar still with Github, I basically just created the account yesterday to be able to send you my question).

I may also need some more details on your suggested trial on the Windows VM (what do you mean by “Clone this repo” ? I am not a “systems” experienced user, so may need some help.

This morning, I found the release announcement in my mailbox from Parallels Desktop of their upgrade to version 17. It still only supports Win10 ARM Insider Builds on an M1 (so no x64), but hopefully it is a little more stable and less delicate than version 16. I’ll be spending some time today first on installing the upgrade and recreating my 4 VM’s on Win10 with Office 365 (I have it in 4 languages to be able to test UI aspects of e.g. Excel VBA projects in different languages and to be able to support users in those 4 languages).

After that’s done I will give your suggestion with .NET 6 SDK preview a try.

As soon as I have some time later today I’ll dive into your readme for the translations and will provide you with feedback.

Already big thanks for the work you’re doing … I hope to benefit from it soon :-)

Philip

On 9 Aug 2021, at 23:09, Fernando Andreu @.***> wrote:

Hi @pplanch https://github.com/pplanch, support for Win10 ARM64 is something I could definitely add, although there might be a few issues for that to work:

Tool support: dotnet should support ARM64 without issues. It seems getting via Visual Studio installed might be a bit more problematic but it isn't really needed if you can build it via dotnet. The installer tool I use, Inno Setup, has also added support for Windows 10 ARM64 recently Library support: after a quick search, I found out that WPF ARM64 support is coming with .NET 6 (to be released in November this year): dotnet/wpf#4117 https://github.com/dotnet/wpf/issues/4117. I'm not so sure about the other libraries that this repo uses though. There might be some effort needed in rebuilding some of these libraries to target ARM64 as well. In the worst case, there might be some issue preventing you from doing that Build system support: this is the part I'm less sure about. I use Azure Pipelines to do the automated builds, but I haven't seen any mention of a Microsoft-hosted Windows ARM agent after a quick search. This would make sense if only Insider builds are available so far. I suspect they will be added to Azure Pipelines eventually So, long story short: there isn't much I can do right now (especially given I don't own a newer Mac myself), but I am reasonably confident I could add Win10 ARM64 support in the future.

In the meantime, perhaps there is something you could try on your Windows VM:

Download and install the latest .NET 6 SDK preview from here https://dotnet.microsoft.com/download/dotnet/6.0 Clone this repo (or download a ZIP and extract it somewhere) Go to the file src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj <x-msg://1/blob/master/src/OfficeRibbonXEditor/OfficeRibbonXEditor.csproj> and, at around line 14, change net461;net5.0-windows to net6.0-windows, Run the following in a command prompt: dotnet build path\to\src\OfficeRibbonXEditor\OfficeRibbonXEditor.csproj If you are lucky, the command will run without flagging any errors (just warnings), and an executable will be created in src\OfficeRibbonXEditor\bin\Debug\net6.0-windows for you to try. More realistically, this will throw some errors that may or may not be easy to resolve. If you show me those errors here, I will try to help.

Regarding the translation support, this is always welcome! There is a German translation already, but nothing yet in terms of Dutch or French. Let me know if you need more guidelines than what I wrote in the readme <x-msg://1/blob/master/README.md#do-you-want-to-see-the-tool-in-your-language> or what was commented in previous issues (#139 https://github.com/fernandreu/office-ribbonx-editor/issues/139 #154 https://github.com/fernandreu/office-ribbonx-editor/issues/154 #163 https://github.com/fernandreu/office-ribbonx-editor/issues/163).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fernandreu/office-ribbonx-editor/issues/174#issuecomment-895550866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVEN4RGOTQPWNMT5F52TL5TT4A7XRANCNFSM5BZ2OP5Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/fernandreu/office-ribbonx-editor/issues/174#issuecomment-895550866", "url": "https://github.com/fernandreu/office-ribbonx-editor/issues/174#issuecomment-895550866", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[fernandreu]

Yeah, you can reply either via email or by going into the issue page on GitHub. Just be aware that, in both cases, anybody can see the full content. Just saying this in case you are not comfortable sharing details such as phone numbers in your email signature, in which case you can edit your last message from the GitHub page. The other thing to keep in mind is that I won't be able to see any attachment you might send via email (incl. pictures); that only works on the website.

"Clone" is one of the operations you can do when working with Git, which is the Version Control System for most software projects nowadays. Essentially, it's like downloading the repo in a local folder. But, to keep things simple, you can instead just go to the front page of this repo, click on "Code" -> "Download ZIP" and extract that somewhere, giving you the same result as git clone:

[rfn6]

@pplanch Did you get this to work?

[pplanch]

Fernando, thanks for the follow-up. Since our last conversation, Parallels issued an M1 desktop VM version that runs Win11 insider preview build (I believe Microsoft pulls support for Win10 on ARM themselves).

As for the RibbonS, I’ve been using the “old” Office Ribbon Editor app (version 4.4.1 I believe) on my Win11 VM and have been studying up a little bit on the basics of XML that I needed to get my own ribbon to work. It works, and it serves my purpose well enough for now. I’ll be interested to learn as soon as an ARM copy of the ribbonX comes out though …

[fernandreu]

Hi both, now that .NET 6 are is officially released, I am going to attempt to make an ARM64 version of the tool to work.

First of all, let me be clear: after starting to investigate this, I don't think the current builds will work on ARM64, so I wouldn't spend too much time testing them.

The reason is relatively simple. The tool's code editor is based on Scintilla, which is a native Windows component. This has in turn being wrapped by the C# libraries ScintillaNET / ScintillaNET.WPF. While the Scintilla project has added support for ARM64 recently, none of the C# libraries have been adapted to support this. For example, you can see there are x86 / x64 folders in here but no arm64 folder. So, assuming Windows on ARM64 doesn't provide some sort of native x86 / x64 dll emulation somehow, it won't work. If you still want to give it a go, you can try the .NET Binaries in here. You will need the .NET 6 runtime installed.

Therefore, my roadmap to add ARM64 support is:

1. Build a newer version of Scintilla which supports ARM64
2. Include the resulting x86, x64 and arm64 dlls in the ScintillaNET project, and update it to support ARM64
3. Update the ScintillaNET.WPF project to use that new version of ScintillaNET and to add ARM64 support
4. Update this tool to use that new version of ScintillaNET.WPF and to add ARM64 support

There might be some hiccups here and there. For example, newer versions of Scintilla might have introduced incompatibilities with the C# wrappers, which I'll have to investigate and fix. Or I might be unable to build Scintilla for ARM64 on my machine, which in theory it shouldn't be the case. But, overall, I am relatively confident I should eventually be able to produce an ARM64 build. That's because Notepad++, which also uses the same Scintilla component, now also supports ARM64.

[fernandreu]

Actually, this might have taken less time than I expected. Can you try one of those? https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1135&view=artifacts&pathAsName=false&type=publishedArtifacts

If it went well, any of those should work on ARM64:

• .NET Binaries
• .NET Installer
• Self-Contained .NET (arm64) Binaries
• Self-Contained .NET (arm64) Installer

Worth mentioning that, even if the app launches fine, I might have introduced some breaking changes when I updated the version of Scintilla (from 4.1.2 to 4.4.6) which might only manifest when attempting certain actions.

[pplanch]

Fernando, I'll have a look tomorrow. Today I'm in the process of setting up my new equipment (I replaced my "old" M1 Macbook Air - which with its 16 GB of "RAM" had some performance issues running Win11 VM simultaneously with other stuff - with a new 16 M1 Macbook Pro on an M1Max processor - which on 64 GB of "RAM" should be able to run all 4 Win11 VM's in the 4 languages simultaneously and which will save me a lot of time on manual updating of the insider preview builds).

I'll keep you posted ... looking forward to your work :-)

[rfn6]

Fernando – I just downloaded the new ARM installer you linked and RibbonX appears to load correctly. Will keep you posted if I notice any bugs or instability.

Thanks a lot!

[rfn6]

@fernandreu The application crashes when you click on "CustomerUI14.xml" on the side bar, so you cannot edit the XML.

[fernandreu]

That's bad... that's when the Scintilla editor gets created, so it seems the ARM64 build of that is not working. Does it instantly crash without any error message? If so, does Event Viewer show any error messages instead?

An example of what could appear (from another program):

[rfn6]

@fernandreu These are the errors I was getting

[rfn6]

Application: OfficeRibbonXEditor.exe CoreCLR Version: 6.0.21.52210 .NET Version: 6.0.0 Description: The process was terminated due to an unhandled exception. Exception Info: System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'ScintillaNET.WPF.ScintillaWPF' that matches the specified binding constraints threw an exception. ---> System.ComponentModel.Win32Exception (0x80004005): Could not load the Scintilla module at the path 'C:\Users\User\AppData\Local\Temp\ScintillaNET\4.2.0\arm64\SciLexer.dll'. ---> System.ComponentModel.Win32Exception (193): %1 is not a valid Win32 application. at ScintillaNET.Scintilla.get_CreateParams() at System.Windows.Forms.Control..ctor(Boolean autoInstallSyncContext) at System.Windows.Forms.Control..ctor() at ScintillaNET.Scintilla..ctor() at ScintillaNET.WPF.ScintillaWPF..ctor() at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions) --- End of inner exception stack trace --- at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri) at System.Windows.Markup.XamlReader.RewrapException(Exception e, Uri baseUri) at System.Windows.FrameworkTemplate.LoadTemplateXaml(XamlReader templateReader, XamlObjectWriter currentWriter) at System.Windows.FrameworkTemplate.LoadOptimizedTemplateContent(DependencyObject container, IComponentConnector componentConnector, IStyleConnector styleConnector, List1 affectedChildren, UncommonField1 templatedNonFeChildrenField) at System.Windows.FrameworkTemplate.LoadContent(DependencyObject container, List1 affectedChildren) at System.Windows.StyleHelper.ApplyTemplateContent(UncommonField1 dataField, DependencyObject container, FrameworkElementFactory templateRoot, Int32 lastChildIndex, HybridDictionary childIndexFromChildID, FrameworkTemplate frameworkTemplate) at System.Windows.FrameworkTemplate.ApplyTemplateContent(UncommonField`1 templateDataField, FrameworkElement container) at System.Windows.FrameworkElement.ApplyTemplate() at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Control.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint) at System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Grid.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Border.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV) at System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged) at System.Windows.Controls.Grid.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Control.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV) at System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged) at System.Windows.Controls.Grid.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.DockPanel.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint) at System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Decorator.MeasureOverride(Size constraint) at System.Windows.Documents.AdornerDecorator.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Grid.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Controls.Border.MeasureOverride(Size constraint) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.Window.MeasureOverrideHelper(Size constraint) at System.Windows.Window.MeasureOverride(Size availableSize) at System.Windows.FrameworkElement.MeasureCore(Size availableSize) at System.Windows.UIElement.Measure(Size availableSize) at System.Windows.ContextLayoutManager.UpdateLayout() at System.Windows.UIElement.UpdateLayout() at System.Windows.Interop.HwndSource.SetLayoutSize() at System.Windows.Interop.HwndSource.set_RootVisualInternal(Visual value) at System.Windows.Interop.HwndSource.set_RootVisual(Visual value) at System.Windows.Window.SetRootVisual() at System.Windows.Window.SetRootVisualAndUpdateSTC() at System.Windows.Window.SetupInitialState(Double requestedTop, Double requestedLeft, Double requestedWidth, Double requestedHeight) at System.Windows.Window.CreateSourceWindow(Boolean duringShow) at System.Windows.Window.CreateSourceWindowDuringShow() at System.Windows.Window.SafeCreateWindowDuringShow() at System.Windows.Window.ShowHelper(Object booleanBox) at System.Windows.Window.Show() at System.Windows.Window.ShowDialog() at OfficeRibbonXEditor.App.LaunchDialog(Window mainWindow, IContentDialogBase content, Boolean showDialog) in D:\a\1\s\src\OfficeRibbonXEditor\App.xaml.cs:line 174 at OfficeRibbonXEditor.App.OnUnhandledException(Object sender, DispatcherUnhandledExceptionEventArgs e) in D:\a\1\s\src\OfficeRibbonXEditor\App.xaml.cs:line 195 at System.Windows.Threading.Dispatcher.CatchException(Exception e) at System.Windows.Threading.Dispatcher.CatchExceptionStatic(Object source, Exception e) at System.Windows.Threading.ExceptionWrapper.CatchException(Object source, Exception e, Delegate catchHandler) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam) at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg) at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at System.Windows.Threading.Dispatcher.Run() at System.Windows.Application.RunDispatcher(Object ignore) at System.Windows.Application.RunInternal(Window window) at System.Windows.Application.Run() at OfficeRibbonXEditor.App.Main()

[fernandreu]

It seems the tool is identifying the process architecture as arm64 as I would expect, and yet the corresponding Scintilla dll cannot be loaded. In other words, the dll isn't really targeting arm64, or the tool isn't really running in arm64, or there's some other error with the dll.

Is the tool running under x86/x64 emulation somehow?

Does the crash occur with both the framework-dependent versions of the tool (i.e. .NET Binaries / .NET Installer and the self-contained ones?

[rfn6]

@fernandreu How do I install the .net binaries version?

[rfn6]

FYI - "Self-Contained .NET (x64) Installer" works via emulation, so I will use that for now. Performance isn't as good because I'm running an emulation within a virtual machine (Parallels), but it works so all good lol.

[fernandreu]

Glad there is at least a way to make it work for now!

None of the Binaries versions need to be installed. They are just a .zip file that you can extract in any folder, and run the executable from there. The .NET Binaries one in particular needs the dotnet runtime installed beforehand though: https://dotnet.microsoft.com/download/dotnet/6.0/runtime

So, was Self-Contained .NET (arm64) Installer the one you tried initially and crashed, or was it something else?

I am hopeful the non-emulated arm64 tool only needs a few tweaks to work too. I have done some adjustments to show both the process and the OS architectures in the About dialog, in case it helps figuring out what's going on (but, based on the event log, I would expect both to be arm64 for the version which is crashing anyway):

The builds matching that screenshot are available here: https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1146&view=artifacts&pathAsName=false&type=publishedArtifacts

I did a bit of artifact renaming too, to refer to each variant more easily. The Framework Dependent variants are what was previously called just .NET Binaries / .NET Installer.

[rfn6]

"Self-Contained - arm64 - Installer" still doesn't work unfortunately.

[pplanch]

Fernando, here's my observations (for what they're worth ... I'm far from an expert on these matters) :

Framework Dependent installer didn't work. After installing and opening the app, I was prompted to install .net (with a download link to the installer) which I did, then whenever clicking on the RibbonX desktop shortcut NOTHING would happen. So I uninstalled RibbonX Editor again.

The Self-contained installer seems to work. I have RibbonX Editor open now. However, when opening one of my files that has CustomUI12 in it, and double-clicking on the Custom UI item in the RibbonX Editor, it crashes.

I'm running a Win11 Pro Insider Preview VM on an M1Max 16" Macbook Pro.

Let me know if this is helpful or if you need more details or logs.

For the time being, I'm going to revert back to the Office Ribbon Editor 4.4.1.

[fernandreu]

Hi @pplanch, the framework-dependent installer not even launching is something new. Did the .NET download link let you choose which architecture to install (arm64 / x64)? I wonder if it installed the wrong one, but probably not. Also, can you check the event logs to see if there is anything regarding that? Start menu, type event viewer, go to Windows Logs -> Application, then search for any errors with the source set to Application Error or .NET Runtime.

The self-contained issue seems to be the same issue as for rfn6, so no need to check the logs for that one.

There are a few things I can try to make this work, but it's going to be a bit of trial and error. In a few days I'll see if I can install Windows on a Raspberry Pi (also ARM64) and start doing the the trials myself.

[fernandreu]

I got ARM64 installed on my RPi, and I think I've found the issue. The VC++ redistributable for ARM64 needs to be installed beforehand on the machine: https://aka.ms/vs/17/release/vc_redist.arm64.exe

I suspect the emulated x64 version worked because some other program installed the equivalent x64 redistributable, as it is a pretty common requirement. It's also a requirement on x64 Windows, but it's probably so common that it's unlikely you'd find the same issue there.

Hence, could you check the self-contained builds from here again after installing the redistributables from the link above? I think there might still be something wrong with the framework-dependent version, but now I should be able to fix it more easily.

I'll see if I can make it to be installed automatically when installing the tool. Otherwise I will just put a note in the releases page / readme.

The result:

[fernandreu]

It seems either ARM64 Windows insists on treating some executables as x64, or the framework-dependent build I did was truly just for x64. Technically you can still run that via dotnet OfficeRibbonXEditor.dll (the dll, not the .exe), but it seems simpler to create framework-dependent builds specific for each architecture.

Hence, all the arm64 versions in this build should hopefully work (again, installing the VC++ redistributable first): https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=1150&view=artifacts&pathAsName=false&type=publishedArtifacts

For the framework-dependent versions, the .NET runtime you'll need is the desktop one for arm64, available here.

[rfn6]

@fernandreu what is the latest version to download in order to test this? I saw you made a few changes today.

[fernandreu]

@rfn6 feel free to test it with any version which comes from #196 since my last post. Yesterday I only added a warning if a VC++ redistributable isn't detected which can launch your browser to download it automatically, but nothing in terms of the tool's functionality really. I'm also doing some unit test refactoring (again, not affecting the tool's functionality), but I will probably get all this merged soon.