Bug 951 - The 'MinimumOSVersion' inside Info.plist does not include the device version
Summary: The 'MinimumOSVersion' inside Info.plist does not include the device version
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: 2.8 Beta 2
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Alan McGovern
URL:
Depends on:
Blocks:
 
Reported: 2011-09-21 03:51 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2011-09-25 18:14 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Rolf Bjarne Kvinge [MSFT] 2011-09-21 03:51:30 UTC
Create a new project from the "MonoTouch Single View Application - Universal" template.
Change debugging target to iPhone|Debug.
Run

Upload now fails due to:
Installation failed: The 'MinimumOSVersion' inside Info.plist does not include the device version (error: 0xe800007e)

This is with iOS 5 beta 7.

I can fix it by setting the Deployment Target in Info.plist (but it should be set by default).
Comment 1 Mikayla Hutchinson [MSFT] 2011-09-21 07:13:28 UTC
When a MinimumOSVersion isn't set in the project's Info.plist, the build should set the value in the compiled/merged plist to the SDK version used to compile.
Comment 2 Alan McGovern 2011-09-21 12:29:26 UTC
So this message is a tad confusing. What it means is that the minimum OS version you selected in MonoDevelop is higher than the OS version you're trying to deploy to. Essentially you've specified iOS 5.0 minimum but your device is running iOS 4.x. The reason why it worked when you manually specified the minimum version is because you selected one which your device was capable of running.

How should this be solved? Do we want MD to default to iOS 5.0 as the minimum or is there a better way of figuring out the real minimum?
Comment 3 Mikayla Hutchinson [MSFT] 2011-09-21 13:08:26 UTC
The minimum OS can only really be set correctly by the developer, or perhaps by some Cecil-based flow analysis and API version checking. This is the feature that allows your app to run on older OSes than the one matching the SDK you used, if you're sure that you're not using newer APIs or have guarded such uses behind runtime version checks.

If the developer doesn't manually set the MinOS, we use the SDK version. If the SDK version wasn't set explicitly (I'd recommend against setting it anyway), then we use the latest SDK version available. So basically, this means that the default situation is that the MinOS will match the latest SDK.

I'm of two minds about this. I like the current solution because it means that the user has to make a deliberate decision to target an older OS, and won't accidentally release an app that claims to run on older OSes that they intended.

But I can see how you could argue it the other way, and that the MD build chain should use some really old iOS version if the MinOS isn't set, or that we should bake the current version into the project when creating it.

Whatever we do, we certainly need to fix the error message, something like:
"The device OS version is older than the version for which your app was built. If you're sure your app will run on that OS version, you can set an older Deployment Target in the application settings"
Comment 4 Alan McGovern 2011-09-21 14:55:11 UTC
I dislike the idea of magically generating values for user visible properties and inserting them into the merged plist. It's completely opaque to the user so it'd be hard for them to figure out how and where some values are appearing from. For example if OSMinimumVersion isn't being set by the user, it'd be nice for it to show up as 5.0 in grey so they know that's what's going to be used.

What do you think of having two modes for the PList editor textboxes/dropdowns etc. Mode 1 is when there is no user set value or the user set value is empty. In this mode the value which would normally be autogenerated would be displayed in the textbox/dropdown but in grey. Mode 2 is when the user specifies a value. In this case the text would display in black, as it does now.

That might make it a bit more obvious that auto-generated values are going to be used and also show the user what value will be autogenerated. We should only do this for values which are visible in the basic PList editor. Users who switch to the advanced tab would be on their own.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2011-09-21 17:19:07 UTC
I think that just fixing the error message would be enough.
Comment 6 Alan McGovern 2011-09-22 05:22:03 UTC
That's the perfect short term solution and I'm going to (try to) do that. But long term it would be nice if the user can tell what values are going to be used when they don't specify one themselves.
Comment 7 Mikayla Hutchinson [MSFT] 2011-09-22 05:24:16 UTC
Alan, that applies to more than just that one widget.
Comment 8 Alan McGovern 2011-09-22 13:08:39 UTC
Fixed in git. The error message now reads:

The minimum supported version of iOS is set to {0}, which the device does not support. Either update the device to iOS {0} or newer, or set the Deployment Target in your project settings to a version your device supports.
Comment 9 Mikayla Hutchinson [MSFT] 2011-09-25 18:14:07 UTC
*** Bug 1040 has been marked as a duplicate of this bug. ***