Alan's Blog

How to Build .NET Core 7 Applications to Run on macOS With Components from Installed Visual Studio Extension

.net core blazor macos install
install devexpress macos
reference dll .NET Core

These were some of my searches in trying to do something very unsupported, yet very needed: be able to build and run a .NET Core application on macOS that referenced controls from a paid Visual Studio extension. Specifically, I'm using DevExpress, however the process I've found should work for any1.

tl;dr

You're probably a busy developer so here you go:

  1. Install Parallels on macOS and create a Windows 11 ARM Virtual Machine
  2. In the VM, Install Visual Studio and Configure for .NET Core 7 Blazor/Web Development
  3. Install Component Library Extension
  4. Add project to a shared directory both Windows and macOS can access
  5. Open project in Visual Studio and build at least once2
  6. Open Windows Terminal and cd to the project directory
  7. Run dotnet publish -c Debug --runtime osx-arm64
  8. Leave the VM, open Terminal on macOS and cd to the macOS build location, the previous command in Windows should tell you where. Mine was at <project directory>\bin\Debug\net7.0\osx-arm64\publish\
  9. Make the application executable by running chmod +x AppName
  10. Code Sign the application by running codesign -s - ./AppName3
  11. Run your application with ./AppName

Why Would You Want to do This?

I daily drive an M1 MacBook Air. It's a fantastic machine and I've had it since April 2021. The battery lasts all day, I can run the latest fancy LLMs locally on it, and it's so incredibly fast. I am also the only Mac in the company, so with everyone else wanting to move toward a unified language and set of development technologies, I had to adapt.

Foolishly, I thought all I would need to do is install Windows 11 in a Parallels VM and everything should work there. Most things do, but domain accounts and SQL proved tricky, and because of quirks of Windows 11 ARM with domains and that Kerberos via macOS worked flawlessly, the easier path seemed to be running on macOS. The downside, is in the shared applications we work on, some of the components and controls are only available best supported as an installed extension for Visual Studio4.

What happened next was a two week survey of how .NET Core works in Visual Studio and via the command line interface (CLI) and exploring how package references, particularly those that were only distributed as DLLs without sources or were part of installed extensions were incorporated into projects. Thankfully now, the actual building of the application is almost identical now across all developers, but with this new knowledge everyone is free to use any other tools they wish to work how works best for them.

Benefits for Others

Through this I've also found easy ways to by in large avoid loading Visual Studio if it's too heavy for your liking and do day-to-day through the CLI. These aren't secrets per se, but the easiest path does seem to be the ability to start or load a project in Visual Studio to get it to do the templating, make sure extensions are working, then offload after the setup to command line so you can develop anywhere. Even if you're on Windows, you could use the same idea, minus the virtual machine and targeted runtime, to set up a project once in Visual Studio then code in anything you like and compile build via CLI. Using dotnet run also gives way better errors for different stages of development, though if you need the debugging and step-through ability Visual Studio offers, then you could for that moment load up Visual Studio and run through there.

And with that, it seems .NET Core for the majority of development time can be worked on in any tool on any system, so long as for builds you have a Windows VM hanging out. Not too shabby considering the Windows-centric history of everything involved!

Footnotes 🐾

  1. I mean how should I know, but probably? Assuming they are source unavailable, this is the only reliable way and I have to imagine given everything else I've seen where there's often just a single right way to do something, it's probably a true statement.↩

  2. I don't know if this is truly needed, but it does at least force Visual Studio to understand everything and sync up .NET Core with what Visual Studio knows about. It's what, 30 seconds one time?↩

  3. This requires Xcode and Xcode Command Line Tools which if you have Xcode installed can be acquired by running xcode-select –install↩

  4. I may have read incorrectly early on in my process. It seems for DevExpress you can get a NuGet Feed set of credentials for a trial. However, I do want my build environment to match that of my peers, and they all use the installable extension.↩

#.net core #blazor #c sharp #components #macos #visual studio