You can get Windows cloud VMs to use as dev environments. We're basically back to the dumb terminal days, lol.
For your Macs, you can also try using Parallels with Windows ARM, which might be less laggy than emulating x86 in a VM. Many apps will then go through Microsoft's own x86 emulation layer inside Windows ARM. Sometimes that's faster? Worth a shot.
But nothing beats developing and testing on real Windows hardware. Doesn't that company have those machines already? You can run them as RDP servers (better than VNC) and just connect to them remotely.
And for your Linux machines, you can just dual boot into real Windows. They're still x86, aren't they?
Edit: Oh, and have you already tried WINE? That virtualizes system calls instead of emulating them. If it works, it should be much faster.
Thanks for this! I considered doing Windows cloud VMs, but just seemed like a hassle.
I'll try out Windows ARM with Parallels.
In this case we didn't acquire their hardware.
Yeah dual booting was the solution I was hoping to avoid, mostly because it's inconvenient to transfer information between the two systems on one machine, but it seems that's the most viable solution.
I looked at WINE, but read that specifically Visual Studio doesn't work very well on it.
You're using Visual Studio, not VSCode, right? It looked like Microsoft had at one point experimented with a hosted dev space for it under the name "Visual Studio Online": https://news.ycombinator.com/item?id=21442088 or https://devblogs.microsoft.com/visualstudio/announcing-visua..., but somehow it became merged/confused with Github Codespaces, which only supports VScode and not the regular Visual Studio. Their messaging is really confusing and all the old links just redirect to the unrelated Codespaces now :( Maybe you can reach out to @lostintangent to ask what happened?
IMHO doing something like that would make the developer experience less painful than every developer having to manage their own Parallels, Windows install, filesystem, networking, credentials, etc. all before they even touch the actual code. If you set up the hosted dev boxes beforehand, each dev should just be able to click a button and jump right into coding, from whatever their existing laptop is, without needing to alter their local stack.
Otherwise, if the Windows stack is something they only occasionally touch (vs their regular work in the Mac/Linux worlds), I think it's very likely that each individual dev's local VMs will quickly get out of sync with each other's and with whatever the "master" source of truth is. Sure, you can containerize it and share the containers instead, but at that point you're basically recreating Microsoft Dev Boxes... and without any real x86 hardware, to boot =/
I guess if you really want to do this self-hosted and stream it locally, you can get an high-powered Windows machine (probably a cheap server or a high-end gaming/workstation desktop with lots of RAM and CPUs will suffice), install Windows server stuff on it and use it to host RDS: https://learn.microsoft.com/en-us/windows-server/remote/remo...
One way or another, I guess the choice is between "buy licenses and have each individual dev configure their own work env" or "buy a server or a cloud subscription and let them manage the envs and stream to the devs".
Yeah Visual Studio, not Visual Studio Code. The main issue is the new code is built using an old .NET framework that isn't supported by the C# plugins on Visual Studio Code.
I think you have some good points, especially when it comes to supporting other devs. The hosted dev boxes make sense, assuming it's not laggy / slow to develop on. Will explore the Azure Microsoft Dev Box option and see how it feels.
You can get Windows cloud VMs to use as dev environments. We're basically back to the dumb terminal days, lol.
For your Macs, you can also try using Parallels with Windows ARM, which might be less laggy than emulating x86 in a VM. Many apps will then go through Microsoft's own x86 emulation layer inside Windows ARM. Sometimes that's faster? Worth a shot.
But nothing beats developing and testing on real Windows hardware. Doesn't that company have those machines already? You can run them as RDP servers (better than VNC) and just connect to them remotely.
And for your Linux machines, you can just dual boot into real Windows. They're still x86, aren't they?
Edit: Oh, and have you already tried WINE? That virtualizes system calls instead of emulating them. If it works, it should be much faster.
Thanks for this! I considered doing Windows cloud VMs, but just seemed like a hassle.
I'll try out Windows ARM with Parallels.
In this case we didn't acquire their hardware.
Yeah dual booting was the solution I was hoping to avoid, mostly because it's inconvenient to transfer information between the two systems on one machine, but it seems that's the most viable solution.
I looked at WINE, but read that specifically Visual Studio doesn't work very well on it.
You're using Visual Studio, not VSCode, right? It looked like Microsoft had at one point experimented with a hosted dev space for it under the name "Visual Studio Online": https://news.ycombinator.com/item?id=21442088 or https://devblogs.microsoft.com/visualstudio/announcing-visua..., but somehow it became merged/confused with Github Codespaces, which only supports VScode and not the regular Visual Studio. Their messaging is really confusing and all the old links just redirect to the unrelated Codespaces now :( Maybe you can reach out to @lostintangent to ask what happened?
I think the closest thing now is an Azure Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box. It should be simpler to manage & roll out than raw VMs (i.e., it's a hosted dev space preconfigured by IT, not a whole VM that each dev has to individually manage). Their product page is really vague, but here's a video that shows it working: https://youtu.be/kyeuSpR74W4?si=qK5IavNIPNIxi-Bp&t=310
IMHO doing something like that would make the developer experience less painful than every developer having to manage their own Parallels, Windows install, filesystem, networking, credentials, etc. all before they even touch the actual code. If you set up the hosted dev boxes beforehand, each dev should just be able to click a button and jump right into coding, from whatever their existing laptop is, without needing to alter their local stack.
Otherwise, if the Windows stack is something they only occasionally touch (vs their regular work in the Mac/Linux worlds), I think it's very likely that each individual dev's local VMs will quickly get out of sync with each other's and with whatever the "master" source of truth is. Sure, you can containerize it and share the containers instead, but at that point you're basically recreating Microsoft Dev Boxes... and without any real x86 hardware, to boot =/
I guess if you really want to do this self-hosted and stream it locally, you can get an high-powered Windows machine (probably a cheap server or a high-end gaming/workstation desktop with lots of RAM and CPUs will suffice), install Windows server stuff on it and use it to host RDS: https://learn.microsoft.com/en-us/windows-server/remote/remo...
One way or another, I guess the choice is between "buy licenses and have each individual dev configure their own work env" or "buy a server or a cloud subscription and let them manage the envs and stream to the devs".
Yeah Visual Studio, not Visual Studio Code. The main issue is the new code is built using an old .NET framework that isn't supported by the C# plugins on Visual Studio Code.
I think you have some good points, especially when it comes to supporting other devs. The hosted dev boxes make sense, assuming it's not laggy / slow to develop on. Will explore the Azure Microsoft Dev Box option and see how it feels.