Today’s crop of GUI (Graphical User Interface) tools are great, and most of us rely on them to get our work done every day. However, it is helpful to understand how and why things work “underneath the hood” and how to take advantage of what’s down there.
For example, we have two sets of developers who use different types of computers and we need to change the platform type within each of the projects (I know, this shouldn’t be the case, but that’s to tackle on another day). 
We could use Visual Studio or Rider to make the change each time, or we could open the individual .csproj files and make the edits. In this case, there are several in the solution, so either way it’s easy to miss one and break things for developers who are on the far side of the world.
Alternatively, you can take a few minutes and find a way to automate the changes such that they’re less likely to be missed or botched by a typo. In this case, I decided to dig out a decades-old tool, sed and build a set of scripts.
#!/bin/zsh if [[ $(uname -m) == 'x86_64' ]]; then # leave the csproj files alone else # makes changes appropriate to test engineers running OS X on M-Processor Macs sed -i.tmp 's/x64/arm64/I' CD/CD.csproj && rm CD/CD.csproj.tmp sed -i.tmp 's/x64/arm64/I' JT/JT.csproj && rm JT/JT.csproj.tmp sed -i.tmp 's/x64/arm64/I' MC/MC.csproj && rm MC/MC.csproj.tmp sed -i.tmp 's/x64/arm64/I' SE.Test/SE.Test.csproj && rm SE.Test/SE.Test.csproj.tmp
and
#!/bin/zsh # restores files to settings appropriate for test engineers running Windows on x86 PCs sed -i.tmp 's/arm64/x64/I' CD/CD.csproj && rm CD/CD.csproj.tmp sed -i.tmp 's/arm64/x64/I' JT/JT.csproj && rm JT/JT.csproj.tmp sed -i.tmp 's/arm64/x64/I' MC/MC.csproj && rm MC/MC.csproj.tmp sed -i.tmp 's/arm64/x64/I' SE.Test/SE.Test.csproj && rm SE.Test/SE.Test.csproj.tmp
I’ll let you go dig into the usage of sed, just realize that each of these scripts changes the values we need to change — and only those values — to set everyone up for success. OS X users need only run the first script to do our work, then the second one before we commit our code. Any other changes to the project files (adding NuGet packages, for example) remain in place.
This may or may not be the best solution (feel free to comment with thoughts/suggestions) to our situation, but it works well and is “good enough” for the other devs – and in fact another dev has already submitted a PR to have a GitHub action use these.