Xamarin-macios: [Feature Request] Side by Side SDK Support

Created on 22 May 2019  ·  7Comments  ·  Source: xamarin/xamarin-macios

Over time we've had a number of requests for "side by side" support in the IDE.

Example: https://developercommunity.visualstudio.com/content/problem/314863/xamarinios-on-the-should-support-sxs-installations.html

There are a number of open questions on what that would entail:

  • Do we have a global Current pointer (like we do now) or somehow projects know which version to use
  • Would we need some xcode-select style tool to manipulate it
  • How does this interact with msbuild and assembly resolution, etc.

This issue is a meta issue to track interest. Creating this issue does not imply that this is being worked on actively or will happen in the future.

enhancement iOS macOS

Most helpful comment

_Edited copy/paste from my bits on a similar issue (December 5th, 2018)_ https://dev.azure.com/devdiv/DevDiv/_workitems/edit/712815

The biggest impact of SxS support for XI (and XM) is not in the SDK themselves. IOW the SDK can already exists side-by-side (it's been the case since we moved out of /Developer/ circa our unified/64bits support).

The main reasons it does not work (as expected) are:

mono / msbuild

On the mac we have a single system mono that points back to the (XI/XM) SDK targets. It can't point to many (just one) - unless we have separate mono as well. That could be a good thing anyway, since each version of the SDK is tested against a specific mono - but it's another pandora box with its share of surprises.

My understanding is that moving to SDK projects might help (and that should be on the roadmap soon but it might not be enough). Maybe .NET 5 will help/force us...

UI vs disk space

We can allow side-by-side installations (not removing old versions when installing new ones) but this will fill the disk space very quickly (limited SSD).

There needs to be a way, in both IDE, to manage/remove SDK versions and, ideally, something that won't conflict between VS(Win) and VS4Mac.

Xcode

You can have several Xcode installed side-by-side - but some stuff is updated globally (e.g. device support, command line tools...). That should not be a huge problem, just a limit to how old we can support SxS installs.

This will however cause scripting issues (like having more than a single mono) since build script that "shells out" might not be using the Xcode they were intended to run from. E.g. the "default/system" Xcode might not have the tool/option a build script needs, causing errors that won't be reproducible on another computer.

All 7 comments

_Edited copy/paste from my bits on a similar issue (December 5th, 2018)_ https://dev.azure.com/devdiv/DevDiv/_workitems/edit/712815

The biggest impact of SxS support for XI (and XM) is not in the SDK themselves. IOW the SDK can already exists side-by-side (it's been the case since we moved out of /Developer/ circa our unified/64bits support).

The main reasons it does not work (as expected) are:

mono / msbuild

On the mac we have a single system mono that points back to the (XI/XM) SDK targets. It can't point to many (just one) - unless we have separate mono as well. That could be a good thing anyway, since each version of the SDK is tested against a specific mono - but it's another pandora box with its share of surprises.

My understanding is that moving to SDK projects might help (and that should be on the roadmap soon but it might not be enough). Maybe .NET 5 will help/force us...

UI vs disk space

We can allow side-by-side installations (not removing old versions when installing new ones) but this will fill the disk space very quickly (limited SSD).

There needs to be a way, in both IDE, to manage/remove SDK versions and, ideally, something that won't conflict between VS(Win) and VS4Mac.

Xcode

You can have several Xcode installed side-by-side - but some stuff is updated globally (e.g. device support, command line tools...). That should not be a huge problem, just a limit to how old we can support SxS installs.

This will however cause scripting issues (like having more than a single mono) since build script that "shells out" might not be using the Xcode they were intended to run from. E.g. the "default/system" Xcode might not have the tool/option a build script needs, causing errors that won't be reproducible on another computer.

Thanks @spouliot for the details. If it were this easy to do, it would have already be done ;)

It's mostly a matter of making the switch between versions easier (as it can already be done with CI). For instance, a short term adjustment would be to cache the installers that VS pulls when switching between a VS4Win Preview and stable.

I suspect this may be solved with the .NET 5 work, but am not 100% certain.

I suspect this may be solved with the .NET 5 work, but am not 100% certain.

Yes, it will be solved with .NET 5.

  • Do we have a global Current pointer (like we do now) or somehow projects know which version to use

Projects will be able to specify the exact version to use, there will be no global/system version (however, there will be a default version depending on which .NET version is installed).

We can allow side-by-side installations (not removing old versions when installing new ones) but this will fill the disk space very quickly (limited SSD).

The .NET 5 way seems to be to fill up your disk, nothing seems to be uninstalled ever.

The .NET 5 way seems to be to fill up your disk, nothing seems to be uninstalled ever.

That's not an option of course.

It won't be easy to decide, when an old version can be removed. Especially when multiple Windows machines with different VS versions are paired to the same Mac.
You could remember when which version was used and then delete those which have not been used in e.g. a month (with a setting for the elapsed time).

The .NET 5 way seems to be to fill up your disk, nothing seems to be uninstalled ever.

That's not an option of course.

It won't be easy to decide, when an old version can be removed. Especially when multiple Windows machines with different VS versions are paired to the same Mac.
You could remember when which version was used and then delete those which have not been used in e.g. a month (with a setting for the elapsed time).

My point here really is that this is not a problem for us (the Xamarin.iOS team) to solve, it's a problem that should be solved generally for all of .NET 5 (afaik work is in progress on it).

_Edited Copy/Paste from a related issue (June 17, 2020)_
https://developercommunity.visualstudio.com/content/problem/1117465/why-downgrade-xamarin-ios-sdk.html

Feedback:
When selecting an bit older project there VS wants to install the older SDK … changing back to the newer Project will cost a lot of time to reinstall that SDK again. why is it removed?? this cost me so much time!

“The Xamarin.iOS SDK version ‘13.20.1.18’ that is installed on the Mac is not compatible with this version of Visual Studio. Would you like us to install Xamarin.iOS ‘13.18.2.1’ for you? This will overwrite any other existing Xamarin.iOS installation on your Mac.”

Was this page helpful?
0 / 5 - 0 ratings