I upgraded a Windows on ARM PC to the latest Insider build and then installed Visual Studio 2022 17.3 Preview 2 on Arm. It was a stark reminder of the challenges this platform still faces.
Like most of you, I don’t use Windows on Arm regularly. But unlike most of you, I can if I want: I keep a Windows on Arm PC around specifically for testing purposes. And while the basics haven’t changed at all—I’m very much hoping that that next-generation NUVIA-based Qualcomm chipset family pays off—it’s still part of the job. I need to keep up on this stuff.
And to be fair to Microsoft, which is complicit if not mostly responsible for the failings of this niche Windows platform, there’s been a lot of movement on the Arm front in recent months. We’re starting to see more and more core Windows 11 experiences, from the Windows Store to Media Player to Notepad, upgraded to native Arm codebases. And Microsoft is really turning the corner for developers: in addition to the Project Volterra developer hardware, the software giant announced at Build 2022 that it was porting .NET/.NET Framework, Visual C++, and Visual Studio to Arm. Incredible.
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
And now it’s available in its first preview build. Naturally, I needed to try it.
The Windows on Arm PC I have is an HP EliteBook Folio. It’s a gorgeous 2-in-1 with a unique (well, semi-unique now that Surface Laptop Studio is a thing) form factor and possibly the single best keyboard I’ve ever used on a laptop. Unfortunately, it’s also running Windows 11 on Arm, which means that everything else about this PC is terrible. Despite its high-end (for Arm) specs—a Qualcomm Snapdragon 8cx Gen 2 processor and 16 GB of RAM—this thing runs slower than a Pentium Gold-based Surface Go. It’s terrible.
And I was reminded of that when I decided to install the Visual Studio preview. First, I had to—or, at least, did—upgrade to the latest Windows Insider Preview build, since this machine is on the preview (and in the Dev channel, which was stupid in retrospect). That process took all afternoon for reasons I can’t explain: after an hour or more, it rebooted, so I assumed it was installing the build. But when the desktop came back up, no build had been installed. So I had to start the process all over again.
We were out last night, so when we got home, I woke up the Folio and pressed the Restart button so the build could fully install. That happened overnight, of course, so when I got up in the morning, I made coffee and set about downloading and installing the Visual Studio Preview.
Here again, I have a hard time explaining why this took so long. But to put this in perspective, I routinely install the latest Visual Studio version on whatever Intel/AMD-based laptops I use, and the three-ish workloads I use require roughly 17 GB of downloading and the whole process takes about 30 minutes.
With the Folio, it took one hour and 17 minutes to download and install just 1.6 GB of stuff. This preview version of the product only supports three workloads—ASP.NET and web development, .NET desktop development, and Desktop development with C++—but because each is just a subset of what you get on x86/x64, the size is less than 1/10th as big. I did install all three.
With that monotony out of the way, I launched Visual Studio, which looks and appears to work just like its x64-based sibling. That makes sense.
But what I was really interested in was whether this thing could handle one of my .NETpad projects. I updated two of them, the Windows Forms version and the Windows Presentation Foundation (WPF) version, earlier this year. And since both should be covered by that .NET desktop development workload, they should theoretically work just fine on Arm.
I went with the WPF version since it’s my favorite. I was able to clone my GitHub repository normally, though I waited for all the background tasks to finish since Arm PCs are so slow to begin with.
And then, suspiciously and with some trepidation, I clicked the Build button.
Everything happened slowly: It is Arm, after all. But incredibly, the application started up and ran normally. .NETpad lives on Arm!
This is actually pretty impressive. I figured there would be something, some WPF component or whatever, that would trip this thing up. But it just worked.
In-app (Visual Studio) performance, predictably, is pretty slow. But to be fair, some actions are slow in the x64 versions of this product too. For example, the default view for XAML files splits between a XAML preview and XAML code, and that’s so slow normally that I turn off the preview pane. But on Arm, it was laughably slow. I think it took about 40 seconds to come up.
But whatever. That this works at all—that Microsoft went to this effort now, when Windows on Arm is barely on life support—is impressive. And it will certainly make it easier for developers to test their apps on Arm. The trick, of course, will be convincing anyone to do so.
So we’ll see what happens. But this is a neat little step forward. Shaky and slow to be sure. But a step forward.