-->
- The Isolated (clawscratchgames) Mac Os X
- The Isolated (clawscratchgames) Mac Os Catalina
- The Isolated (claw Scratch Games) Mac Os Sierra
This guide describes how to use Pair to Mac to connect Visual Studio 2019to a Mac build host. The same instructions apply to Visual Studio 2017.
Hello everyone, Ros newbie here, I am following the tutorial on Ros Wiki for installation of Ros Melodic for Mac OS X, and am encountering an issue when attempting to invoke catkinmakeisolated to. Enable remote login on the Mac. To set up the Mac build host, first enable remote login: On the Mac, open System Preferences and go to the Sharing pane. Check Remote Login in the Service list. Make sure that it is configured to allow access for All users, or that your Mac username or group is included in the list of allowed users. If prompted, configure the macOS firewall.
Overview
Building native iOS applications requires access to Apple's build tools,which only run on a Mac. Because of this, Visual Studio 2019 must connect toa network-accessible Mac to build Xamarin.iOS applications.
Visual Studio 2019's Pair to Mac feature discovers, connects to,authenticates with, and remembers Mac build hosts so that Windows-basediOS developers can work productively.
Pair to Mac enables the following development workflow:
Developers can write Xamarin.iOS code in Visual Studio 2019.
Visual Studio 2019 opens a network connection to a Mac build host anduses the build tools on that machine to compile and sign the iOS app.
There is no need to run a separate application on the Mac – VisualStudio 2019 invokes Mac builds securely over SSH.
Visual Studio 2019 is notified of changes as soon as they happen. Forexample, when an iOS device is plugged in to the Mac or becomes availableon the network, the iOS Toolbar updates instantly.
Multiple instances of Visual Studio 2019 can connect to the Macsimultaneously.
It's possible to use the Windows command-line to build iOS applications.
Note
Before following the instructions in this guide, complete the following steps:
- On a Windows machine, install Visual Studio 2019
- On a Mac, install Xcode and Visual Studio for Mac
- You must manually open Xcode after installing so that it can add any additional components.
If you would prefer not to install Visual Studio for Mac, Visual Studio 2019can automatically configure the Mac build host with Xamarin.iOS and Mono.You must still install and run Xcode.For more information, see Automatic Mac provisioning.
Enable remote login on the Mac
To set up the Mac build host, first enable remote login:
On the Mac, open System Preferences and go to the Sharing pane.
Check Remote Login in the Service Snowman stack mac os. list.
Make sure that it is configured to allow access for All users, orthat your Mac username or group is included in the list of allowedusers.
If prompted, configure the macOS firewall.
If you have set the macOS firewall to block incoming connections, youmay need to allow
mono-sgento receive incoming connections. An alertappears to prompt you if this is the case.If it is on the same network as the Windows machine, the Mac shouldnow be discoverable by Visual Studio 2019. If the Mac is still notdiscoverable, try manually adding a Mac or takea look at the troubleshooting guide.
Connect to the Mac from Visual Studio 2019
Now that remote login is enabled, connect Visual Studio 2019 to the Mac.
In Visual Studio 2019, open an existing iOS project or create a new oneby choosing File > New > Project and then selecting an iOS projecttemplate.
Open the Pair to Mac dialog.
Use the Pair to Mac button iOS toolbar:
Or, select Tools > iOS > Pair to Mac.
The Pair to Mac dialog displays a list of all previously-connectedand currently-available Mac build hosts:
Select a Mac in the list. Click Connect.
Enter your username and password.
The first time you connect to any particular Mac, you areprompted to enter your username and password for that machine:
Tip
When logging in, use your system username rather than full name.
Pair to Mac uses these credentials to create a new SSH connectionto the Mac. If it succeeds, a key is added to the authorized_keysfile on the Mac. Subsequent connections to the same Mac will loginautomatically.
Pair to Mac automatically configures the Mac. Date or die: the pilot episode mac os.
Starting with Visual Studio 2019 version15.6,Visual Studio 2019 installs or updates Mono and Xamarin.iOS on aconnected Mac build host as needed (note that Xcode must still beinstalled manually). See Automatic Macprovisioning for more details.
Look for the connection status icon.
When Visual Studio 2019 is connected to a Mac, that Mac's itemin the Pair to Mac dialog displays an icon indicating thatit is currently connected:
There can be only one connected Mac at a time.
Tip
Right-clicking any Mac in the Pair to Mac list brings up a contextmenu that allows you to Connect.., Forget this Mac, orDisconnect:
If you choose Forget this Mac, your credentials for the selectedMac will be forgotten. To reconnect to that Mac, you will need to re-enteryour username and password.
If you have successfully paired to a Mac build host, you are ready to buildXamarin.iOS apps in Visual Studio 2019. Take a look at theIntroduction to Xamarin.iOS for Visual Studioguide.
If you have not been able to pair a Mac, try manually adding aMac or take a look at the troubleshootingguide.
Manually add a Mac
If you do not see a particular Mac listed in the Pair to Mac dialog,add it manually:
Locate your Mac's IP address.
Open System Preferences > Sharing > Remote Login on your Mac:
Alternatively, use the command line. In Terminal, issue this command: The last demon mac os.
Depending on your network configuration, you may need to use aninterface name other than
en0. For example:en1,en2, etc.
In Visual Studio 2019's Pair to Mac dialog, select Add Mac..:
Enter the Mac's IP address and click Add:
Enter your username and password for the Mac:
Tip
When logging in, use your system username rather than full name.
Click Login to connect Visual Studio 2019 to the Mac over SSH and addit to the list of known machines.
Automatic Mac provisioning
Starting with Visual Studio 2019 version 15.6,Pair to Mac automatically provisions a Mac with software necessary forbuilding Xamarin.iOS applications: Mono, Xamarin.iOS (the softwareframework, not the Visual Studio for Mac IDE), and various Xcode-relatedtools (but not Xcode itself).
Important
- Pair to Mac cannot install Xcode; you must manually install it on theMac build host. It is required for Xamarin.iOS development.
- Automatic Mac provisioning requires that remote login isenabled on the Mac, and the Mac must be network-accessible to the Windowsmachine. See Enabling remote login on the Macfor more details.
- Automatic Mac provisioning requires 3GB of free space on the Mac to install Xamarin.iOS.
Pair to Mac performs necessary software installations/updates when VisualStudio 2019 is connecting to theMac.
Mono
Pair to Mac will check to make sure that Mono is installed. If it is notinstalled, Pair to Mac will download and install the latest stable versionof Mono on the Mac.
Progress is indicated by various prompts, as shown by the followingscreenshots (click to zoom):
| Mono | Install Check | Downloading | Installing |
|---|
Xamarin.iOS
Pair to Mac upgrades Xamarin.iOS on the Mac to match the versioninstalled on the Windows machine.
Important
Pair to Mac will not downgrade Xamarin.iOS on the Mac from alpha/betato stable. If you have Visual Studio for Mac installed, set yourrelease channel asfollows:
- If you use Visual Studio 2019, select the Stable updates channel inVisual Studio for Mac.
- If you use Visual Studio 2019 Preview, select the Alpha updateschannel in Visual Studio for Mac.
Progress is indicated by various prompts, as shown by the followingscreenshots (click to zoom):
| Xamarin.iOS | Install Check | Downloading | Installing |
|---|
Xcode tools and license
Pair to Mac will also check to determine whether Xcode has been installedand its license accepted. While Pair to Mac does not install Xcode, itdoes prompt for license acceptance, as shown in the following screenshots(click to zoom):
| Xcode | Install Check | License Acceptance |
|---|
Additionally, Pair to Mac will install or update various packagesdistributed with Xcode. For example:
- MobileDeviceDevelopment.pkg
- XcodeExtensionSupport.pkg
- MobileDevice.pkg
- XcodeSystemResources.pkg
The installation of these packages happens quickly and without a prompt.
Note
These tools are distinct from the Xcode Command Line Tools, whichas of macOS 10.9 areinstalled with Xcode.
Troubleshooting automatic Mac provisioning
If you encounter any trouble using automatic Mac provisioning, take a lookat the Visual Studio 2019 IDE logs, stored in%LOCALAPPDATA%XamarinLogs16.0. These logs may contain error messagesto help you better diagnose the failure or get support.
Build iOS apps from the Windows command-line
Pair to Mac supports building Xamarin.iOS applications from the commandline. For example:
The parameters passed to msbuild in the above example are:
ServerAddress– The IP address of the Mac build host.ServerUser– The username to use when logging in to the Mac build host.Use your system username rather than your full name.ServerPassword– The password to use when logging in to the Mac build host.
Note
Visual Studio 2019 stores msbuild in the following directory:C:Program Files (x86)Microsoft Visual Studio2019MSBuildCurrentBin
The first time Pair to Mac logs in to a particular Mac build host fromeither Visual Studio 2019 or the command-line, it sets up SSH keys. With thesekeys, future logins will not require a username or password. Newlycreated keys are stored in %LOCALAPPDATA%XamarinMonoTouch.
If the ServerPassword parameter is omitted from a command-line buildinvocation, Pair to Mac attempts to log in to the Mac build hostusing the saved SSH keys.
Summary
This article described how to use Pair to Mac to connect Visual Studio 2019 to aMac build host, enabling Visual Studio 2019 developers to build native iOSapplications with Xamarin.iOS.
Next steps
This is the second post in my ongoing series pondering the Intel Macs of the future. In part one, I considered the professional line. Today I've got something on my mind that's a bit harder to pin down: the xMac.
Long-time readers are probably already familiar with the concept of the xMac. As far as I know, the term 'xMac' was coined in the Mac Ach right here at Ars. I tried to find the exact post but, well, long-time readers also know what the forum search is like. The earliest post I could find that mentions the xMac was made by Jade on November 28, 2001, and it doesn't even explain the term. This leads me to believe that this post is not the origin of the xMac meme. Anyway, in a post made the next day, Jade adds this description: '$1000 xMac: gamer/burner/music machine.'
The Isolated (clawscratchgames) Mac Os X
The xMac saga continues on from there, across ninety-six pages of search results spanning almost four years. During that time, the xMac was tossed like leaf in the wind in the Mac Ach. The xMac is an iTunes device. It's a game machine. It's a sub-$1000 Mac. No, it's sub-$500. It's a floor wax, a dessert topping. The xMac is all things to all people!
The installation of these packages happens quickly and without a prompt.
Note
These tools are distinct from the Xcode Command Line Tools, whichas of macOS 10.9 areinstalled with Xcode.
Troubleshooting automatic Mac provisioning
If you encounter any trouble using automatic Mac provisioning, take a lookat the Visual Studio 2019 IDE logs, stored in%LOCALAPPDATA%XamarinLogs16.0. These logs may contain error messagesto help you better diagnose the failure or get support.
Build iOS apps from the Windows command-line
Pair to Mac supports building Xamarin.iOS applications from the commandline. For example:
The parameters passed to msbuild in the above example are:
ServerAddress– The IP address of the Mac build host.ServerUser– The username to use when logging in to the Mac build host.Use your system username rather than your full name.ServerPassword– The password to use when logging in to the Mac build host.
Note
Visual Studio 2019 stores msbuild in the following directory:C:Program Files (x86)Microsoft Visual Studio2019MSBuildCurrentBin
The first time Pair to Mac logs in to a particular Mac build host fromeither Visual Studio 2019 or the command-line, it sets up SSH keys. With thesekeys, future logins will not require a username or password. Newlycreated keys are stored in %LOCALAPPDATA%XamarinMonoTouch.
If the ServerPassword parameter is omitted from a command-line buildinvocation, Pair to Mac attempts to log in to the Mac build hostusing the saved SSH keys.
Summary
This article described how to use Pair to Mac to connect Visual Studio 2019 to aMac build host, enabling Visual Studio 2019 developers to build native iOSapplications with Xamarin.iOS.
Next steps
This is the second post in my ongoing series pondering the Intel Macs of the future. In part one, I considered the professional line. Today I've got something on my mind that's a bit harder to pin down: the xMac.
Long-time readers are probably already familiar with the concept of the xMac. As far as I know, the term 'xMac' was coined in the Mac Ach right here at Ars. I tried to find the exact post but, well, long-time readers also know what the forum search is like. The earliest post I could find that mentions the xMac was made by Jade on November 28, 2001, and it doesn't even explain the term. This leads me to believe that this post is not the origin of the xMac meme. Anyway, in a post made the next day, Jade adds this description: '$1000 xMac: gamer/burner/music machine.'
The Isolated (clawscratchgames) Mac Os X
The xMac saga continues on from there, across ninety-six pages of search results spanning almost four years. During that time, the xMac was tossed like leaf in the wind in the Mac Ach. The xMac is an iTunes device. It's a game machine. It's a sub-$1000 Mac. No, it's sub-$500. It's a floor wax, a dessert topping. The xMac is all things to all people!
Eventually, as will happen with any long-running forum topic, everyone pretty much forgot how the whole thing started. (Well, I did, anyway.) Discussion of the xMac continued, but each reader likely had a slightly different idea of what, exactly, that term meant.
Things finally came to a head with the run-up to the introduction of the Mac mini. A thread named Headless xMac confirmed! (Sub $500 Mac) chronicled the final days. But even then, there was debate about what would constitute vindication or defeat for proponents and opponents of the xMac idea—both its likelihood of becoming a reality and its intrinsic value as a product idea. In the end, it was generally accepted that the Mac mini was 'close enough' to being the fabled xMac, and the matter was (blessedly, most would agree) closed.
Well, I'm bringing it back. As far as I'm concerned, it never left. My own personal conception of the xMac does not match-up well with the Mac mini. I'd go so far as to say that my xMac vision is also a lot closer to the original concept of the xMac..except I've already established that I'm not sure exactly where or when the xMac idea originated, so never mind.
I do think that all of the variations on the xMac idea have one important thing in common. It seems like everyone can agree that the xMac is 'headless.' That is, it has no integrated display like the iMac or a laptop. A corollary that is also widely agreed upon is that the Power Mac, as it currently exists, is definitely not the xMac. That leaves the consensus description of the xMac as 'a headless Mac that is not the Power Mac.'
By that definition, the Mac mini fits the bill. Technically, the Power Mac G4 Cube also qualified. Despite the name, it was definitely not like the Power Mac (i.e., a full-sized tower). But the Cube is not my xMac either.
Here's what I want. Start with a choice of two possible CPUs: the very fastest single CPU Apple sells, and the second-fastest. In contemporary terms, these would both be dual core CPUs. The internal expansion buses should also be top-of-the-line, but with less capacity than the Power Mac. One high-speed slot for the graphics card and at least one other, slower slot for another card would be fine. RAM capacity should be roughly half that of the Power Mac. There should be room for two internal hard drives and a single optical drive.
AdvertisementExternal expansion should be similar to the Power Mac, but with fewer of the 'expensive' ports (e.g., FireWire 800) and more of the cheap ones (e.g., at least three USB ports). It should be wireless-capable, both long- and short-range. The short-range capability should be standard. (BlueTooth, in today's terms.)
Then there's the case. It should be much, much smaller than the Power Mac's full-sized tower. Think Shuttle-sized, but styled like a Mac. The Shuttles are nice, but they're shaped too much like shoe boxes for my taste. The xMac should be distinctive, like the mini. Maybe that means a pizza-box form factor, or maybe a skinny, upright mini-tower, I don't know. I trust that Ive can think of something.
There should be two pre-defined configurations. The first should use the 'second-fastest' CPU, a less capable optical drive, a single, medium-sized hard drive, and a mainstream video card. The second should use the fastest CPU, the best optical drive, a large hard drive, and a high-end video card. The build-to-order (BTO) options must span the entire range for each item that can be configured: CPU, RAM, hard drive(s), video card, optical drive, and wireless.
So far, this xMac sounds like a product between the Power Mac and the iMac, which is probably a good idea. There's a bit of a hole there in Apple's line-up. But there's One More Thing..
You know those build-to-order options I mentioned? When I said that they should 'span the entire range,' I meant the entire range. No, I'm not talking about the high-end. Think in the other direction. Think of the top item in a BTO pop-up menu. Now picture this:
Ladies and gentlemen, I give you the xMac. My xMac. The Mac that I want to buy. Reduced to one sentence, it's a completely configurable, headless Mac that trades expandability for reduced size and cost.
Now, granted, the hypothetical Apple web store BTO form shown above is less appealing because it's presented in terms of today's technology. Who cares if the CPU is optional if you can't easily buy one from a third party? But picture it a few years from now with a choice of Intel CPUs in that pop-up menu. Suddenly, buying a CPU-less Mac starts to actually make sense.
Well, it makes sense from the perspective of a tech-savvy customer, anyway. Unfortunately, when considered from virtually any other perspective, the idea is a loser. Although it pains me to admit it, I never expect the xMac as I've described it to become a reality. Why is it such a bad idea? Let me count the ways.
Nearly all of the consumer benefits of this xMac come at the expense of Apple's profit margins. Every dollar I can save by only buying exactly what I need, and nothing more, is a dollar that Apple loses. Worse, all this configurability vastly increases Apple's inventory management challenges, makes reporting more difficult, and increases labor costs. Pre-defined, pre-packaged products are much easier for Apple to deal with, and much more profitable as well. Given all of this, what's Apple's motivation to produce such a product?
What about those consumer benefits? Happy customers are good for Apple in the long run, right? True, but will the xMac actually make customers happy? The computer geeks are in the bag, but what about everyone else?
Pity the poor 'normal' customer given enough BTO configuration options to hang himself. All consumers want to feel like they're getting the best possible deal. To a computer geek, that means not being forced to buy anything unnecessary. But to everyone else, that same configurability has the opposite effect, causing worry and doubt. It's hard to know that you're getting the optimal combination of parts for your needs when you don't understand the effect each component has on overall system performance, and you don't know what a fair price is for each part.
AdvertisementThe Isolated (clawscratchgames) Mac Os Catalina
But hey, didn't I specify two pre-defined configurations for the xMac? Won't the novices just choose one of those instead? Sure, maybe some will. But that nagging feeling that someone, somewhere is getting a better deal than you is very powerful. Eventually, it becomes an open secret that the way to get the best deal on a Mac is to find a computer geek and have him tell you the exact configuration of xMac you should buy. I'm sorry, but we've been there, done that, and it stinks. Apple is supposed to be about simplicity, not hassles—even self-inflicted hassles.
The two points above reinforce each other. As the xMac slowly becomes the obvious sweet spot in the product line-up, it begins to cannibalize the sales of the higher-margin Power Macs, hurting Apple's bottom line even more. And as more people find themselves shopping for an xMac because they heard it's the best deal, the formerly simple Apple buying experience becomes annoying and complex for an increasing proportion of Apple's customers.
As inadequate as computer geeks may find Apple's current, inflexibly BTO system, it's just about perfect for most of Apple's customers. People want some choice in order to feel like they're in control—even if they don't exercise it and end up buying a box-stock product from an Apple Store anyway. For those that do choose to build-to-order, the limited choices Apple offers are mostly understandable even to novices. 'A bigger hard drive means you can store more stuff.' 'More memory means you can run more stuff at the same time.' One or two simple choices are enough. More, and the customer is overwhelmed. Fewer, and they feel too confined.
The Isolated (claw Scratch Games) Mac Os Sierra
Yes, it looks like my xMac will have to remain a fantasy. But I'd be happy with a compromise: a completely configurable headless Mac that trades expandability for reduced size and cost. Call it the Power Mac mini, make it cheaper and faster than at least one Power Mac model, and give the 'deluxe' version the fastest available single CPU. That'd still cannibalize some Power Mac sales, but it'd also present an opportunity to up-sell iMac and (especially) Mac mini customers. It could still be a net win.
Finally, let's not forget about the elephant in the room. 'If Apple didn't insist on restricting Mac OS X to run only on Apple hardware, this problem wouldn't exist in the first place!' Yes, that's true, but would an xMac by any other vendor be as sweet? Or make Apple as much money? Or dilute the brand by compromising the 'Apple experience'? And on and on—this is another topic entirely, and one I don't want to dive into right now. Suffice it to say that I have a hard time seeing a happy ending to the perennial 'Mac OS X on open hardware' scenario right now. But things change, so I'm keeping an open mind.
Anyway, back on topic. The Mac mini didn't close the book on the xMac for me, but the Power Mac mini might. I know this post was supposed to be about the Intel Macs of the future, but both my xMac idea and its compromised cousin, the Power Mac mini, are CPU-agnostic. Obviously, it's too late for either of them to arrive in the PowerPC era, so they're both Intel Mac ideas by default.
I'm sure would-be Mac builders everywhere would like every Mac to be as configurable as the xMac I've described. Sadly, I think even one such model is wishful thinking. The more interesting question is this: how many 'regular' Mac users out there would be interested in a Power Mac mini?
I've always been a Power Mac buyer, but I've never actually filled one of those monster towers to the brim. In isolated cases, I've maxed-out some kinds of expansion (cough—Power Mac G5 internal hard drives—cough). But I don't think I've ever used more than one expansion slot (not counting the graphics card), and I'm more than willing to sacrifice some of my eight RAM slots (six filled) for reduced system size and cost.
Yes, I'd love to have an xMac, but I'd gladly settle for a Power Mac mini. How about you?
