Going Native With Coding
Going Native With Coding
If asked for the applications I need to do my work, I would always start with Visual Studio (and Visual Studio Code, of course). If an artist needs paints and a canvas, I need Visual Studio to do my work. Basically, unlike most other packages, it is irreplaceable. For me, I need to run my ASP.NET code on a Microsoft IIS server and compile it on my Mac.
At the core of this is a magical little framework called .NET. But, what about Intel and ARM? Well, that’s where it gets a bit messy.
As you should know, Apple decided to move away from Intel x86/x64 and onto ARM architecture. It was a radical move like the one they did when they moved from IBM processors to Intel and had to rebuild their complete operating system. To give you a hint of the change, the Intel processor uses a little endian data format, and the IBM processor used the big endian data format. This meant that the data was processed and store in a completely different way.
But, it worked, and saved Apple — and who were struggling that the time to compete against the PC and Microsoft Windows. It was a genius move and allowed them to focus their work on their user interface, as the hardware underneath was basically just a PC. And, so for Apple, they jumped again, as they wanted a processor that could run cool and scale onto all their devices. And there was only one solution … the ARM architecture.
But, there was no way that Apple could recompile all their software to run natively under ARM. And while Adobe had the resources to recompile their software under ARM, many other pieces of software would stay linked to Intel x86. Apple’s solution is Rosetta 2 and which dynamically translates x86 code onto the ARM processor. This, of course, run slower than native code, as the two processors are different, and the cross-compiler is having to translate from one machine code command into another. But, for most users, the drop in performance is not noticeable, and almost all the application run without a glitch. When you get down to debugging things, though, you do see a few little problems, but the system does seem to struggle a bit when its memory is pushed to the limit. But the difference of performance between the Mac and Windows machines is significant. Given the reliability of the Macbook (apart from some patchy machines), it is the device of choice for many developers.
So, I am a heavy coder, and I have millions of lines of code and push out many updates each day. One of my main sites is https://asecuritysite.com, but I also created https://www.brightredbooks.net/subjects/. I thus need a stable development environment, and, over the past few years, I have stuck with Visual Studio 2019, and all hasbeen fine, but I do get the spinning beach ball, especially when the memory starts to fill up.
And, so, today, this popped up:
It promised a native build for Visual Studio:
Unfortunately, I have not had a great experience in updating Microsoft software, so it was a bit risky for me, as it often ends up with hours and days on StackOverflow finding the little glitch in the install. And, so, I fired up the install, and it started:
But, as I expected, it gave a typical Microsoft critical error message that stopped the whole solution from building:
Error MSB4019: The imported project "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/xbuild/Microsoft/VisualStudio/v17.0/WebApplications/Microsoft.WebApplication.targets" was not found.
I nearly gave up there, but headed off to StackOverflow, and found that it is a bug in Mono (the .NET version that runs on Mac OS). For some reason, it was missing a file, so I just copy the Microsoft.WebApplication.targets from the v16.0 folder into v17.0:
% cd /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/xbuild/Microsoft/VisualStudio/v16.0/WebApplications
% sudo mkdir ../../v17.0/WebApplications
% sudo cp Microsoft.WebApplication.targets ../../v17.0/WebApplications
But, I then found that it was highlighting every keyword with an error within the MVC Web framework. While it compiled okay, every line of my code had an error (and I have millions of lines of code!). I then noticed that the Microsoft.MVC.Web component had a little cross beside it, so opened up the trustworthy Nuget tool, and sourced the latest AspNet.WebPages component:
Overall, I didn’t want to reinstall any other of my components, as this would have set me of a long and time-costly road (and would probably break my stable Visual Studio 2019 setup). But, it worked wonderfully, and where all the errors were gone, and I had a new development environment:
If fact, my Mac had conveniently added both VS 2019 and VS 2022, so I could go back to my old version at any time:
I edited by code, and recompiled, and waited. And all was good:
So, for my code, I’m going native and hope to never see the spinning beach ball again. Here’s to that wonderful ARM architecture, and opening up its power. Well, back to work.