Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
MonoTouch really should define a symbol by default for conditional compilation in xplat apps. in fact, we really should have a better set. i propose:
XAMARIN_MOBILE - to be defined in both MT and M4A, and evetually, projects for WP that include the xam.mo lib and additional .net dlls
XAMARIN_IOS - to be defined in MT projects
XAMARIN_ANDROID - to be defined in M4A projects
The trick is that this needs to be done by the IDE, since none of our tools actually owns setting those values.
So we will need to make this change to MonoDevelop's iOS and Android addins, as well as the VS integration support.
We would likely use the __FOO__ syntax, which has traditionally been used as the compiler-vendor defines to avoid clashing with user defines.
Mono for Android defines a set of constants: __ANDROID__ and __ANDROID_X__ where 1 <= X <= $(TargetFrameworkVersion)'s API level, e.g. if you target Android v1.6, you'll have __ANDROID_1__, __ANDROID_2__, __ANDROID_3__, and __ANDROID_4__ defined.
This is done via MSBuild; see Novell.MonoDroid.Common.targets:
> <Target Name="_AddAndroidDefines">
> <!-- Convert Android version (v2.2) to API Level (8) -->
> <GetApiLevelFromFramework TargetFrameworkVersion="$(TargetFrameworkVersion)">
> <Output TaskParameter="AndroidApiLevel" PropertyName="AndroidApiLevel" />
> <!-- Get the defined constants for this API Level -->
> <GetAndroidDefineConstants AndroidApiLevel="$(AndroidApiLevel)">
> <Output TaskParameter="AndroidDefineConstants" PropertyName="AndroidDefineConstants" />
> <CreateProperty Value="$(DefineConstants);$(AndroidDefineConstants)">
> <Output TaskParameter="Value" PropertyName="DefineConstants" />
This is hooked up via <BuildDependsOn/>:
> <PropertyGroup Condition="'$(AndroidApplication)' == '' Or !($(AndroidApplication))">
Like miguel, I'd prefer using (sticking with) the __FOO__ prefix, as it's being automatically provided. I'm not sure that "XAMARIN" needs to be in the name; would __IOS__ may be sufficient for iOS builds?
For backward compatibility, Mono for Android needs to provide the existing __ANDROID__ symbols (e.g. several monodroid-samples project use them). We could also provide a parallel set of __XAMARIN_ANDROID__ defines, but that might be getting "crazy."
As for XAMARIN_MOBILE, in "projects for WP that include the xam.mo lib and additional .net dlls," I'm not sure how that would work. The only way Android is able to add constants is because Android apps have:
> <Import Project="$(MSBuildExtensionsPath)\Novell\Novell.MonoDroid.CSharp.targets" />
i.e. "we control the horizontal and the vertical."
"Normal" .NET projects will instead be importing Microsoft.CSharp.targets, which won't have the necessary "magic" to add a __XAMARIN_MOBILE__ define. We could provide a "Xamarin Mobile Library" project template which imports a Xamarin.Mobile.CSharp.targets file (which could do the necessary magic), but then it would no longer be a "normal" .NET library project. I'm not quite sure how to square this circle.
Yes, let us stick with what we have __ANDROID__, there is no need to add a vendor name to the define.
Agreed that we cant do much about apps that merely reference Xamarin.Mobile, that is a user-issue, just like adding a reference to Xamarin.Mobile would be.
=> MonoDevelop, since that's where the managed compilation happens.
I didn't mean that it would be specific to apps that were adding a ref to Xamarin.Mobile. i meant one common symbol for the xamarin mobile profile. otherwise, we'd have to do if android or if ios or if whatever.
I've updated the IPhoneProjectBuildExtensions to add __MOBILE__ and __iOS__ to the defines passed to the compiler at compile time.
*** Bug 5054 has been marked as a duplicate of this bug. ***
For consistency, monodroid/9bba7f7d adds __MOBILE__ to Xamarin.Android projects. This should be available in Xamarin.Android 4.8.
We have verified this issue with the latest builds:
And now under the option C#, Android is appearing for the Android templates and iOS is appearing for the iOS templates.
Moreover, for the iOS templates a mobile icon is appearing on the thumbnail of the template, and for android templates the green colour android logo is appearing on the thumbnail of the template.
PJ as per the comment #10 it seems that for Android templates also, the mobile icon should appear on the thumbnail of the template, in order to maintain consistency in Android and iOS and this change would be available in Xamarin.Android 4.8 build, so we will check once we will get the build for the same.
As of now leaving this bug as it is, please let us know if you have any suggestions.
I think there is some confusion about verifying this. This is not about templates. It's about the __MOBILE__ and __IOS__ defines being passed to the compiler. You can verify this by checking that this code is executed successfully in an iOS project:
Console.WriteLine ("__MOBILE__ is defined");
Console.WriteLine ("__IOS__ is defined");
and that this code is executed in an android project:
Console.WriteLine ("__MOBILE__ is defined");
Console.WriteLine ("__ANDROID__ is defined");