xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/msbuild/Xamarin.Shared/Xamarin.Shared.props

349 строки
26 KiB
Plaintext
Исходник Обычный вид История

[msbuild] Add a Xamarin.Shared.props. (#8711) It's empty for now, but soon enough it will start getting shared Xamarin.iOS/Xamarin.Mac code.
2020-06-02 15:26:25 +03:00
<!--
***********************************************************************************************
Xamarin.Shared.props
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
This file imports the version- and platform-specific targets for the project importing
this file. This file also defines targets to produce an error if the specified targets
file does not exist, but the project is built anyway (command-line or IDE build).
Copyright (C) 2020 Microsoft. All rights reserved.
***********************************************************************************************
-->
<!-- This is shared between Xamarin.iOS and Xamarin.Mac -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets"
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets')"/>
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
<PropertyGroup Condition="'$(_PlatformName)' == ''">
<_PlatformName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.iOS'">iOS</_PlatformName>
Add a Xamarin.MacCatalyst target framework identifier.
2020-11-17 11:30:08 +03:00
<_PlatformName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.MacCatalyst'">iOS</_PlatformName>
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
<_PlatformName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.TVOS'">tvOS</_PlatformName>
<_PlatformName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.WatchOS'">watchOS</_PlatformName>
[msbuild] Use '_PlatformName' == 'MacCatalyst' instead of '_IsMacCatalyst'. (#10636) In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so reflect this in the build logic by setting _PlatformName to 'MacCatalyst'. This makes the build logic a lot simpler for .NET.
2021-02-12 23:49:49 +03:00
<_PlatformName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.MacCatalyst'">MacCatalyst</_PlatformName>
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
<_PlatformName Condition="'$(_PlatformName)' == ''">macOS</_PlatformName> <!-- detecting Xamarin.Mac is a bit more complicated, so just fall back to macOS if none of the others match -->
Add a Xamarin.MacCatalyst target framework identifier.
2020-11-17 11:30:08 +03:00
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
</PropertyGroup>
[msbuild] Unify XamarinMacFrameworkRoot and MonoTouchSdkRoot into _XamarinSdkRoot. (#8995)
2020-07-07 16:45:42 +03:00
<PropertyGroup>
<!-- _XamarinSdkRoot
[msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. (#11433) * [dotnet] Ship the buildinfo file. * [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. We do this by setting the _XamarinSdkRoot variable in our .NET logic, which our existing shared build logic reads, passes to the DetectSdkLocations task, and then sets our override environment variable (MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that existing code (which honors the override variable) continues to work as-is. Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
2021-05-05 04:36:48 +03:00
Xamarin.Mac: Defaults to XamarinMacFrameworkRoot, otherwise use XAMMAC_FRAMEWORK_PATH, otherwise /Library/Frameworks/Xamarin.Mac.framework/Versions/Current
[msbuild] Unify XamarinMacFrameworkRoot and MonoTouchSdkRoot into _XamarinSdkRoot. (#8995)
2020-07-07 16:45:42 +03:00
Xamarin.iOS: Defaults to MonoTouchSdkRoot, otherwise use MD_MTOUCH_SDK_ROOT, otherwise /Library/Frameworks/Xamarin.iOS.framework/Versions/Current
-->
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' == 'macOS' ">$(XamarinMacFrameworkRoot)</_XamarinSdkRoot>
[msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. (#11433) * [dotnet] Ship the buildinfo file. * [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. We do this by setting the _XamarinSdkRoot variable in our .NET logic, which our existing shared build logic reads, passes to the DetectSdkLocations task, and then sets our override environment variable (MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that existing code (which honors the override variable) continues to work as-is. Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
2021-05-05 04:36:48 +03:00
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' == 'macOS' ">$(XAMMAC_FRAMEWORK_PATH)</_XamarinSdkRoot>
[msbuild] Unify XamarinMacFrameworkRoot and MonoTouchSdkRoot into _XamarinSdkRoot. (#8995)
2020-07-07 16:45:42 +03:00
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' == 'macOS' ">/Library/Frameworks/Xamarin.Mac.framework/Versions/Current</_XamarinSdkRoot>
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' != 'macOS' ">$(MonoTouchSdkRoot)</_XamarinSdkRoot>
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' != 'macOS' ">$(MD_MTOUCH_SDK_ROOT)</_XamarinSdkRoot>
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == '' And '$(_PlatformName)' != 'macOS' ">/Library/Frameworks/Xamarin.iOS.framework/Versions/Current</_XamarinSdkRoot>
</PropertyGroup>
[msbuild] Unify _RequireCodeSigning and EnableCodeSigning into _RequireCodeSigning. (#8743)
2020-06-04 16:17:32 +03:00
<PropertyGroup>
<!--
We don't want to use the Platform variable for conditional logic.
Switching to a new property allows us to potentially switch from
device to simulator builds dynamically based on the user's
selection when starting the project. This allows us to eventually
even (optionally) switch back to AnyCPU platform in the IDE,
therefore fixing a key pain point in managing solution
configurations.
[msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. (#8797) * [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. * [msbuild] Use $(ComputedPlatform) instead of $(_Platform). They're identical, and this avoids using $(_Platform) before it's defined.
2020-06-09 15:28:36 +03:00
Additionally, we cannot use $(Platform) in conditions on props,
because VS interprets them as valid platforms for the current
project and makes them available for solution configurations,
which fails miserably for iOS class library projects. By using
another property name, we "opt out" of this "smart" behavior
[msbuild] Unify _RequireCodeSigning and EnableCodeSigning into _RequireCodeSigning. (#8743)
2020-06-04 16:17:32 +03:00
-->
<ComputedPlatform Condition="'$(ComputedPlatform)' == ''">$(Platform)</ComputedPlatform>
[tests] Add unit tests for building Mac Catalyst for ARM64. (#10768) * [dotnet] Use the expected case for ARM64. We use case-sensitive comparisons somewhere else, so make sure to use the same casing for the architecture as other platforms do. * [tests] Add tests to verify that Mac Catalyst builds successfully for ARM64. * [msbuild] Fix platform name in condition. * [msbuild] Pass -isysroot when building Mac Catalyst apps as well. Ohterwise clang will use the SDK from the command line tools, which may have nothing to do with the SDK we want to build with.
2021-03-04 19:44:55 +03:00
<ComputedPlatform Condition="'$(_PlatformName)' != 'macOS' And '$(_PlatformName)' != 'MacCatalyst' And '$(ComputedPlatform)' == 'AnyCPU'">iPhone</ComputedPlatform>
[msbuild] Unify _RequireCodeSigning and EnableCodeSigning into _RequireCodeSigning. (#8743)
2020-06-04 16:17:32 +03:00
</PropertyGroup>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
<Choose>
<!-- If TargetFrameworkIdentifier is 'Xamarin.Mac', then we're in Modern mode -->
<When Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.Mac'">
<PropertyGroup>
<TargetFrameworkName>Modern</TargetFrameworkName>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<_XamarinBclPath>$(_XamarinSdkRoot)/lib/mono/Xamarin.Mac/</_XamarinBclPath>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
</PropertyGroup>
</When>
<!-- If TargetFrameworkIdentifier is not 'Xamarin.Mac', but we're still a macOS app and UseXamMacFullFramework is true, then we're in Full mode -->
<When Condition="'$(TargetFrameworkIdentifier)' != 'Xamarin.Mac' And '$(_PlatformName)' == 'macOS' And '$(UseXamMacFullFramework)' == 'true'">
<PropertyGroup>
<TargetFrameworkName>Full</TargetFrameworkName>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<_XamarinBclPath>$(_XamarinSdkRoot)/lib/mono/4.5/</_XamarinBclPath>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
</PropertyGroup>
</When>
<!-- If the two other conditions don't match, but we're still a macOS app, then we're in System mode -->
<When Condition="'$(_PlatformName)' == 'macOS'">
<PropertyGroup>
<TargetFrameworkName>System</TargetFrameworkName>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<_XamarinBclPath>$(_XamarinSdkRoot)/lib/mono/4.5/</_XamarinBclPath>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
</PropertyGroup>
</When>
</Choose>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<PropertyGroup Condition="'$(_XamarinBclPath)' == ''">
[msbuild] Use '_PlatformName' == 'MacCatalyst' instead of '_IsMacCatalyst'. (#10636) In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so reflect this in the build logic by setting _PlatformName to 'MacCatalyst'. This makes the build logic a lot simpler for .NET.
2021-02-12 23:49:49 +03:00
<_XamarinBclPath Condition="'$(_PlatformName)' == 'MacCatalyst'">$(_XamarinSdkRoot)/lib/mono/Xamarin.MacCatalyst/</_XamarinBclPath>
<_XamarinBclPath Condition="'$(_PlatformName)' == 'iOS'">$(_XamarinSdkRoot)/lib/mono/Xamarin.iOS/</_XamarinBclPath>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<_XamarinBclPath Condition="'$(_PlatformName)' == 'tvOS'">$(_XamarinSdkRoot)/lib/mono/Xamarin.TVOS/</_XamarinBclPath>
<_XamarinBclPath Condition="'$(_PlatformName)' == 'watchOS'">$(_XamarinSdkRoot)/lib/mono/Xamarin.WatchOS/</_XamarinBclPath>
</PropertyGroup>
<PropertyGroup>
[msbuild] Use '_PlatformName' == 'MacCatalyst' instead of '_IsMacCatalyst'. (#10636) In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so reflect this in the build logic by setting _PlatformName to 'MacCatalyst'. This makes the build logic a lot simpler for .NET.
2021-02-12 23:49:49 +03:00
<_XamarinPlatformAssemblyName Condition="'$(_PlatformName)' == 'MacCatalyst'">Xamarin.MacCatalyst.dll</_XamarinPlatformAssemblyName>
<_XamarinPlatformAssemblyName Condition="'$(_PlatformName)' == 'iOS'">Xamarin.iOS.dll</_XamarinPlatformAssemblyName>
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<_XamarinPlatformAssemblyName Condition="'$(_PlatformName)' == 'tvOS'">Xamarin.TVOS.dll</_XamarinPlatformAssemblyName>
<_XamarinPlatformAssemblyName Condition="'$(_PlatformName)' == 'watchOS'">Xamarin.WatchOS.dll</_XamarinPlatformAssemblyName>
<_XamarinPlatformAssemblyName Condition="'$(_PlatformName)' == 'macOS'">Xamarin.Mac.dll</_XamarinPlatformAssemblyName>
<_XamarinPlatformAssemblyPath>$(_XamarinBclPath)$(_XamarinPlatformAssemblyName)</_XamarinPlatformAssemblyPath>
</PropertyGroup>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
<!-- Sometimes we've used different variable names for the same thing for Xamarin.iOS and Xamarin.Mac projects. Here we try to unify those variables -->
<PropertyGroup>
<!-- ResourcePrefix -->
<MonoMacResourcePrefix Condition="'$(_PlatformName)' == 'macOS' And '$(MonoMacResourcePrefix)' == ''">Resources</MonoMacResourcePrefix>
<XamMacResourcePrefix Condition="'$(_PlatformName)' == 'macOS' And '$(XamMacResourcePrefix)' == ''">$(MonoMacResourcePrefix)</XamMacResourcePrefix>
<XamMacResourcePrefix Condition="'$(_PlatformName)' == 'macOS' And '$(XamMacResourcePrefix)' == ''">Resources</XamMacResourcePrefix>
<IPhoneResourcePrefix Condition="'$(_PlatformName)' != 'macOS' And '$(IPhoneResourcePrefix)' == ''">Resources</IPhoneResourcePrefix>
<_ResourcePrefix Condition="'$(_PlatformName)' == 'macOS'">$(XamMacResourcePrefix)</_ResourcePrefix>
<_ResourcePrefix Condition="'$(_PlatformName)' != 'macOS'">$(IPhoneResourcePrefix)</_ResourcePrefix>
[msbuild] Unify MtouchSdkVersion and MacOSXSdkVersion into _SdkVersion. (#8734)
2020-06-03 20:24:36 +03:00
<!-- SdkVersion -->
<_SdkVersion Condition="'$(_PlatformName)' == 'macOS'">$(MacOSXSdkVersion)</_SdkVersion>
<_SdkVersion Condition="'$(_PlatformName)' != 'macOS'">$(MtouchSdkVersion)</_SdkVersion>
[msbuild] Unify _RequireCodeSigning and EnableCodeSigning into _RequireCodeSigning. (#8743)
2020-06-04 16:17:32 +03:00
<!-- RequireCodeSigning -->
<!-- iOS/watchOS/tvOS is simple: device builds require code signing, simulator builds do not. This is a big lie, for some simulator builds need to be signed, but the _DetectCodeSigning task handles those cases. -->
<_RequireCodeSigning Condition="'$(_PlatformName)' != 'macOS' And '$(_RequireCodeSigning)' == ''">false</_RequireCodeSigning> <!-- Xamarin.iOS builds are not signed by default -->
<_RequireCodeSigning Condition="'$(_PlatformName)' != 'macOS' And '$(ComputedPlatform)' == 'iPhone'">true</_RequireCodeSigning> <!-- except that device builds must be signed -->
<!-- macOS is a bit more complicated:
* 'EnableCodeSigning' specifies whether the app is signed or not, and this defaults to false if it's not set.
* Extensions are special, because they must be signed. However, due to historical reasons, extension projects will have set EnableCodeSigning=false. So we do the following:
* If we're an extension, and code signing is disabled: enable code signing, set the code signing key (_CodeSigningKey) to '-', and pass this value to the _DetectCodeSigning task.
-->
<_RequireCodeSigning Condition="'$(_PlatformName)' == 'macOS' And '$(_RequireCodeSigning)' == ''">$(EnableCodeSigning)</_RequireCodeSigning> <!-- Xamarin.Mac projects use the 'EnableCodeSigning' variable to enable code signing -->
<_RequireCodeSigning Condition="'$(_PlatformName)' == 'macOS' And '$(_RequireCodeSigning)' == ''">false</_RequireCodeSigning> <!-- Xamarin.Mac projects: disable by default -->
<_CodeSigningKey Condition="'$(_PlatformName)' == 'macOS' And '$(IsAppExtension)' == 'true' And '$(_CodeSigningKey)' == '' And '$(_RequireCodeSigning)' == 'false'">-</_CodeSigningKey> <!-- Set _CodeSigningKey to '-' if we're an extension where code signing is not requested -->
<_RequireCodeSigning Condition="'$(_PlatformName)' == 'macOS' And '$(IsAppExtension)' == 'true'">true</_RequireCodeSigning> <!-- But extensions must be signed, so make sure they are -->
[msbuild] Unify CodesignKey and CodeSigningKey into _SpecifiedCodesignKey. (#8758)
2020-06-05 18:07:25 +03:00
<!-- SpecifiedCodeSigningKey -->
[msbuild] Accept both 'CodeSigningKey' and 'CodesignKey' as synonyms. This makes it easier to use the same csproj for multiple platforms for customers.
2021-07-16 19:22:02 +03:00
<!-- Xamarin.Mac projects use 'CodeSigningKey', and Xamarin.iOS projects use 'CodesignKey'. -->
<!-- Here we accept both, and we'll recommend using 'CodesignKey' for all platforms going forward -->
<_SpecifiedCodesignKey Condition="'$(_SpecifiedCodesignKey)' == ''">$(CodeSigningKey)</_SpecifiedCodesignKey>
<_SpecifiedCodesignKey Condition="'$(_SpecifiedCodesignKey)' == ''">$(CodesignKey)</_SpecifiedCodesignKey>
[msbuild] Move the logic to create .pkg files from Mac-specific target files to shared target files. Because we need it for Mac Catalyst as well.
2021-07-22 22:38:56 +03:00
<!-- If we should create a .pkg or not (only relevant for macOS / Mac Catalyst) -->
<!-- The equivalent property for the other platforms is 'BuildIpa' -->
<CreatePackage Condition="'$(CreatePackage)' == ''">false</CreatePackage>
[msbuild] Move the EnablePackageSigning variable to shared code. So that it's set for both macOS and Mac Catalyst.
2021-07-16 19:22:02 +03:00
<!-- If the .pkg should be signed or not. Applicable to macOS and Mac Catalyst. Defaults to false. -->
<EnablePackageSigning Condition="'$(EnablePackageSigning)' == ''">false</EnablePackageSigning>
[dotnet] Rework how we compute the TargetArchitectures property. Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the TargetArchitectures property from either the RuntimeIdentifier or the RuntimeIdentifiers properties. Also make sure this target is executed before _ComputeTargetArchitectures. This is required so that we have a correct TargetArchitectures value for multi-rid builds when compiling the app manifest (Info.plist).
2021-06-23 17:53:45 +03:00
</PropertyGroup>
[msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. (#8797) * [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. * [msbuild] Use $(ComputedPlatform) instead of $(_Platform). They're identical, and this avoids using $(_Platform) before it's defined.
2020-06-09 15:28:36 +03:00
[dotnet] Rework how we compute the TargetArchitectures property. Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the TargetArchitectures property from either the RuntimeIdentifier or the RuntimeIdentifiers properties. Also make sure this target is executed before _ComputeTargetArchitectures. This is required so that we have a correct TargetArchitectures value for multi-rid builds when compiling the app manifest (Info.plist).
2021-06-23 17:53:45 +03:00
<PropertyGroup Condition="'$(UsingAppleNETSdk)' != 'true'">
[msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. (#8797) * [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. * [msbuild] Use $(ComputedPlatform) instead of $(_Platform). They're identical, and this avoids using $(_Platform) before it's defined.
2020-06-09 15:28:36 +03:00
<!-- TargetArchitectures -->
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' == 'macOS'">$(XamMacArch)</TargetArchitectures>
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' != 'macOS'">$(MtouchArch)</TargetArchitectures>
<!-- The default architecture for Xamarin.Mac is x86_64 -->
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' == 'macOS'">x86_64</TargetArchitectures>
<!-- There should always be an MtouchArch value in newer projects, but for older projects default to old values -->
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' != 'macOS' And '$(ComputedPlatform)' == 'iPhoneSimulator'">i386</TargetArchitectures>
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' != 'macOS' And '$(ComputedPlatform)' == 'iPhone' And '$(TargetFrameworkIdentifier)' == 'Xamarin.WatchOS'">ARMv7k</TargetArchitectures>
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' != 'macOS' And '$(ComputedPlatform)' == 'iPhone' And '$(TargetFrameworkIdentifier)' == 'Xamarin.TVOS'">ARM64</TargetArchitectures>
<TargetArchitectures Condition="'$(TargetArchitectures)' == '' And '$(_PlatformName)' != 'macOS' And '$(ComputedPlatform)' == 'iPhone'">ARMv7</TargetArchitectures>
[dotnet] Rework how we compute the TargetArchitectures property. Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the TargetArchitectures property from either the RuntimeIdentifier or the RuntimeIdentifiers properties. Also make sure this target is executed before _ComputeTargetArchitectures. This is required so that we have a correct TargetArchitectures value for multi-rid builds when compiling the app manifest (Info.plist).
2021-06-23 17:53:45 +03:00
</PropertyGroup>
[msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. (#8797) * [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures. * [msbuild] Use $(ComputedPlatform) instead of $(_Platform). They're identical, and this avoids using $(_Platform) before it's defined.
2020-06-09 15:28:36 +03:00
[dotnet] Rework how we compute the TargetArchitectures property. Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the TargetArchitectures property from either the RuntimeIdentifier or the RuntimeIdentifiers properties. Also make sure this target is executed before _ComputeTargetArchitectures. This is required so that we have a correct TargetArchitectures value for multi-rid builds when compiling the app manifest (Info.plist).
2021-06-23 17:53:45 +03:00
<PropertyGroup>
[msbuild] Unify the ArchiveOnBuild property
2021-07-16 19:22:02 +03:00
<ArchiveOnBuild Condition="'$(ArchiveOnBuild)' == ''">false</ArchiveOnBuild>
[msbuild] Unify the IsAppExtension property
2021-07-16 19:22:02 +03:00
<IsAppExtension Condition="'$(IsAppExtension)' == ''">false</IsAppExtension>
[msbuild] Merge the EnableSGenConc properties. We use two different properties for the same thing: MtouchEnableSGenConc and EnableSGenConc. Going forward, we're sticking with just EnableSGenConc, but we'll keep accepting MtouchEnableSGenConc if it's set.
2021-07-16 19:22:02 +03:00
<!-- Xamarin.iOS projects use MtouchEnableSGenConc, and Xamarin.Mac projects use EnableSGenConc -->
<!-- Going forward we're sticking with EnableSGenConc, but we'll accept MtouchEnableSGenConc if it's set -->
<!-- If both are set, EnableSGenConc takes precedence -->
<EnableSGenConc Condition="'$(EnableSGenConc)' == ''">$(MtouchEnableSGenConc)</EnableSGenConc>
<EnableSGenConc Condition="'$(EnableSGenConc)' == ''">false</EnableSGenConc>
[msbuild] Unify the _CanOutputAppBundle property.
2021-07-16 19:22:02 +03:00
<_CanOutputAppBundle>false</_CanOutputAppBundle>
<_CanOutputAppBundle Condition="'$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true' Or '$(IsWatchApp)' == 'true'">true</_CanOutputAppBundle>
[msbuild] Unify the Archive task between iOS and Mac. (#12200) The iOS version and the Mac version were slightly different in that they were adding different things to the archive, but both seemed to be resilient to those files not existing, so I just merged both implementations to try to add everything to the archive.
2021-07-26 10:19:01 +03:00
<!-- We can archive: -->
<!-- macOS and Mac Catalyst: executable projects which aren't app extensions -->
<!-- iOS, tvOS and watchOS: executable projects built for device which aren't app extensions nor watch apps -->
<_CanArchive>false</_CanArchive>
<_CanArchive Condition="('$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst') And '$(OutputType)' == 'Exe' And '$(IsAppExtension)' == 'false'">true</_CanArchive>
<_CanArchive Condition="('$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS') And '$(OutputType)' == 'Exe' And '$(ComputedPlatform)' == 'iPhone' And '$(IsAppExtension)' == 'false' And '$(IsWatchApp)' == 'false'">true</_CanArchive>
[msbuild] Unify MtouchDebug and MmpDebug into _Debug. (#8832) * [msbuild] Unify MtouchDebug and MmpDebug into _Debug. * [msbuild] Use _BundlerDebug instead of _Debug. _Debug is too generic, and more likely to clash with someone else.
2020-06-15 10:17:17 +03:00
<!-- Debug -->
[macos] Add correct support for producing/archiving `dSYM` (#10409) TL&DR: This PR 1. Removes the creation of the `.dSYM` based on `Debug Information` [1] 2. Adds dSYM support to XM msbuild (now shared with XI implementation) 3. Archive the `.dSYM` directories (plural) properly, e.g. ``` msbuild -p:Configuration=Release -p:ArchiveOnBuild=true ``` Why ? The long story... Historically `.dSYM` for Xamarin.Mac have not been very useful, largely because (most of) the code is JITed so not much is known before runtime. So they were simply not generated during the builds... However AOT options were added to Xamarin.Mac, making them potentially more useful. Also symbols from `libmono` and other native libraries / frameworks can prove useful when diagnosing application crashes. Unsurprisingly developers looking to get symbols eventually found _a way_ [1] to get a `.dSYM` for their applications - but it was not quite correct because: * setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had); * it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks. * the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution. [1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log Additional fixes * Use `Directory.Move` instead of running the `mv` command While the result is identical there is a cost to spawn several `mv` processes. Doing it in parallel (might have) helped but that setup also comes at a cost. `Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while the existing code took 17 ms to do the same. * Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 16:42:24 +03:00
<!-- Xamarin.Mac: use MmpDebug -->
[dotnet] Make the linker always process debug symbols, and remove debugging support if we're building a release build. (#9594) Unfortunately due to when things happen in the .NET build logic, we need to define the DebuggerSupport property (which determines whether the app should include debugging support or not) before importing the .NET build files. Since we want to use the _BundlerDebug property (a.k.a. MtouchDebug/MmpDebug) to determine if the app should include debugging support, we must figure out the value of the _BundlerDebug property before we can define the DebuggerSupport property. This turned out complicated, because we're currently defining _BundlerDebug in our old-style MSBuild logic, which is imported after we import the .NET build logic. The end result is that we can either shuffle around a lot of MSBuild code, or copy a few lines to set the _BundlerDebug property. Neither option makes me very happy, but copying a few lines of code seemed the better option, so that's what I did. Fixes these linkall test failures in Release mode: LinkAll.Attributes.AttributeTest [FAIL] DebugAssemblyAttributes : DebuggableAttribute Expected: False But was: True at LinkAll.Attributes.AttributeTest.DebugAssemblyAttributes() [FAIL] DebugConstructorAttributes : No debug attribute in release mode Expected: 0 But was: 2 at LinkAll.Attributes.AttributeTest.DebugConstructorAttributes() [FAIL] DebugPropertyAttributes : DebuggerBrowsable Expected: False But was: True at LinkAll.Attributes.AttributeTest.DebugPropertyAttributes() [FAIL] DebugTypeAttributes : no debug attribute in release mode Expected: 0 But was: 5 at LinkAll.Attributes.AttributeTest.DebugTypeAttributes() [FAIL] DebuggerTypeProxy_24203 : proxy Expected: null But was: <System.Collections.Generic.IDictionaryDebugView`2[K,V]> at LinkAll.Attributes.AttributeTest.DebuggerTypeProxy_24203()
2020-09-08 15:55:34 +03:00
<_BundlerDebug Condition="'$(_BundlerDebug)' == '' And '$(_PlatformName)' == 'macOS'">$(MmpDebug)</_BundlerDebug>
[msbuild] Unify MtouchDebug and MmpDebug into _Debug. (#8832) * [msbuild] Unify MtouchDebug and MmpDebug into _Debug. * [msbuild] Use _BundlerDebug instead of _Debug. _Debug is too generic, and more likely to clash with someone else.
2020-06-15 10:17:17 +03:00
<!-- Xamarin.iOS: Use MtouchDebug -->
[dotnet] Make the linker always process debug symbols, and remove debugging support if we're building a release build. (#9594) Unfortunately due to when things happen in the .NET build logic, we need to define the DebuggerSupport property (which determines whether the app should include debugging support or not) before importing the .NET build files. Since we want to use the _BundlerDebug property (a.k.a. MtouchDebug/MmpDebug) to determine if the app should include debugging support, we must figure out the value of the _BundlerDebug property before we can define the DebuggerSupport property. This turned out complicated, because we're currently defining _BundlerDebug in our old-style MSBuild logic, which is imported after we import the .NET build logic. The end result is that we can either shuffle around a lot of MSBuild code, or copy a few lines to set the _BundlerDebug property. Neither option makes me very happy, but copying a few lines of code seemed the better option, so that's what I did. Fixes these linkall test failures in Release mode: LinkAll.Attributes.AttributeTest [FAIL] DebugAssemblyAttributes : DebuggableAttribute Expected: False But was: True at LinkAll.Attributes.AttributeTest.DebugAssemblyAttributes() [FAIL] DebugConstructorAttributes : No debug attribute in release mode Expected: 0 But was: 2 at LinkAll.Attributes.AttributeTest.DebugConstructorAttributes() [FAIL] DebugPropertyAttributes : DebuggerBrowsable Expected: False But was: True at LinkAll.Attributes.AttributeTest.DebugPropertyAttributes() [FAIL] DebugTypeAttributes : no debug attribute in release mode Expected: 0 But was: 5 at LinkAll.Attributes.AttributeTest.DebugTypeAttributes() [FAIL] DebuggerTypeProxy_24203 : proxy Expected: null But was: <System.Collections.Generic.IDictionaryDebugView`2[K,V]> at LinkAll.Attributes.AttributeTest.DebuggerTypeProxy_24203()
2020-09-08 15:55:34 +03:00
<_BundlerDebug Condition="'$(_BundlerDebug)' == '' And '$(_PlatformName)' != 'macOS'">$(MtouchDebug)</_BundlerDebug>
[msbuild] Default 'BundlerDebug' to 'true' if no other option is set and we're building for a 'Debug' configuration. (#9247) It's somewhat of a breaking change, since previously Xamarin.Mac would default to 'false' if no value was set. It should be exceedingly rare though, since it's set in all the template projects. It makes the behavior a bit more intuitive for .NET projects, since then the values might not be set because of the simplified project files.
2020-07-31 16:21:02 +03:00
<!-- Otherwise the default is true if we're building a Debug configuration -->
<_BundlerDebug Condition="'$(_BundlerDebug)' == '' And '$(Configuration)' == 'Debug'">true</_BundlerDebug>
<!-- As a last resort, the default is false for all platforms -->
[msbuild] Unify MtouchDebug and MmpDebug into _Debug. (#8832) * [msbuild] Unify MtouchDebug and MmpDebug into _Debug. * [msbuild] Use _BundlerDebug instead of _Debug. _Debug is too generic, and more likely to clash with someone else.
2020-06-15 10:17:17 +03:00
<_BundlerDebug Condition="'$(_BundlerDebug)' == ''">false</_BundlerDebug>
[msbuild] Share the DeviceSpecificIntermediateOutputPath property. (#8854) * [msbuild] Share the DeviceSpecificIntermediateOutputPath property. We don't technically need this value for Xamarin.Mac, but many of the targets that can be shared need to use this for Xamarin.iOS, so set this value for Xamarin.Mac as well. It will always be the default IntermediateOutputPath for Xamarin.Mac, while for Xamarin.iOS it might be changed in _ComputeTargetArchitectures. * [msbuild] Remove usage in Xamarin.Mac of a variable that was always empty in the past.
2020-06-16 18:39:47 +03:00
[msbuild] Make the ParseExtraMtouchArgs task platform-agnostic, and share it between Xamarin.iOS and Xamarin.Mac. (#9061) * Change the parsing code slightly, to make it easier to parse other arguments (coming soon). * Add the parsing task to Xamarin.Mac projects, and use it there as well. The parsed result isn't used yet, but it will be soon. * Unify a few related MSBuild properties (MtouchNoSymbolStrip and MtouchNoDSymUtil).
2020-07-13 15:56:34 +03:00
<!-- Extra arguments -->
<_BundlerArguments Condition="'$(_PlatformName)' == 'macOS'">$(MonoBundlingExtraArgs)</_BundlerArguments>
<_BundlerArguments Condition="'$(_PlatformName)' != 'macOS'">$(MtouchExtraArgs)</_BundlerArguments>
<!-- NoSymbolStrip -->
[macos] Add correct support for producing/archiving `dSYM` (#10409) TL&DR: This PR 1. Removes the creation of the `.dSYM` based on `Debug Information` [1] 2. Adds dSYM support to XM msbuild (now shared with XI implementation) 3. Archive the `.dSYM` directories (plural) properly, e.g. ``` msbuild -p:Configuration=Release -p:ArchiveOnBuild=true ``` Why ? The long story... Historically `.dSYM` for Xamarin.Mac have not been very useful, largely because (most of) the code is JITed so not much is known before runtime. So they were simply not generated during the builds... However AOT options were added to Xamarin.Mac, making them potentially more useful. Also symbols from `libmono` and other native libraries / frameworks can prove useful when diagnosing application crashes. Unsurprisingly developers looking to get symbols eventually found _a way_ [1] to get a `.dSYM` for their applications - but it was not quite correct because: * setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had); * it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks. * the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution. [1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log Additional fixes * Use `Directory.Move` instead of running the `mv` command While the result is identical there is a cost to spawn several `mv` processes. Doing it in parallel (might have) helped but that setup also comes at a cost. `Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while the existing code took 17 ms to do the same. * Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 16:42:24 +03:00
<!-- Xamarin.Mac never had an equivalent for MtouchNoSymbolStrip and was never stripped -> true -->
<!-- default to 'false' -->
[msbuild] Make the ParseExtraMtouchArgs task platform-agnostic, and share it between Xamarin.iOS and Xamarin.Mac. (#9061) * Change the parsing code slightly, to make it easier to parse other arguments (coming soon). * Add the parsing task to Xamarin.Mac projects, and use it there as well. The parsed result isn't used yet, but it will be soon. * Unify a few related MSBuild properties (MtouchNoSymbolStrip and MtouchNoDSymUtil).
2020-07-13 15:56:34 +03:00
<_NoSymbolStrip Condition="'$(_PlatformName)' != 'macOS'">$(MtouchNoSymbolStrip)</_NoSymbolStrip>
[macos] Add correct support for producing/archiving `dSYM` (#10409) TL&DR: This PR 1. Removes the creation of the `.dSYM` based on `Debug Information` [1] 2. Adds dSYM support to XM msbuild (now shared with XI implementation) 3. Archive the `.dSYM` directories (plural) properly, e.g. ``` msbuild -p:Configuration=Release -p:ArchiveOnBuild=true ``` Why ? The long story... Historically `.dSYM` for Xamarin.Mac have not been very useful, largely because (most of) the code is JITed so not much is known before runtime. So they were simply not generated during the builds... However AOT options were added to Xamarin.Mac, making them potentially more useful. Also symbols from `libmono` and other native libraries / frameworks can prove useful when diagnosing application crashes. Unsurprisingly developers looking to get symbols eventually found _a way_ [1] to get a `.dSYM` for their applications - but it was not quite correct because: * setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had); * it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks. * the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution. [1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log Additional fixes * Use `Directory.Move` instead of running the `mv` command While the result is identical there is a cost to spawn several `mv` processes. Doing it in parallel (might have) helped but that setup also comes at a cost. `Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while the existing code took 17 ms to do the same. * Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 16:42:24 +03:00
<_NoSymbolStrip Condition="'$(_PlatformName)' == 'macOS'">true</_NoSymbolStrip>
[msbuild] Make the ParseExtraMtouchArgs task platform-agnostic, and share it between Xamarin.iOS and Xamarin.Mac. (#9061) * Change the parsing code slightly, to make it easier to parse other arguments (coming soon). * Add the parsing task to Xamarin.Mac projects, and use it there as well. The parsed result isn't used yet, but it will be soon. * Unify a few related MSBuild properties (MtouchNoSymbolStrip and MtouchNoDSymUtil).
2020-07-13 15:56:34 +03:00
<_NoSymbolStrip Condition="'$(_NoSymbolStrip)' == ''">false</_NoSymbolStrip>
<!-- NoDSymUtil -->
[macos] Add correct support for producing/archiving `dSYM` (#10409) TL&DR: This PR 1. Removes the creation of the `.dSYM` based on `Debug Information` [1] 2. Adds dSYM support to XM msbuild (now shared with XI implementation) 3. Archive the `.dSYM` directories (plural) properly, e.g. ``` msbuild -p:Configuration=Release -p:ArchiveOnBuild=true ``` Why ? The long story... Historically `.dSYM` for Xamarin.Mac have not been very useful, largely because (most of) the code is JITed so not much is known before runtime. So they were simply not generated during the builds... However AOT options were added to Xamarin.Mac, making them potentially more useful. Also symbols from `libmono` and other native libraries / frameworks can prove useful when diagnosing application crashes. Unsurprisingly developers looking to get symbols eventually found _a way_ [1] to get a `.dSYM` for their applications - but it was not quite correct because: * setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had); * it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks. * the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution. [1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log Additional fixes * Use `Directory.Move` instead of running the `mv` command While the result is identical there is a cost to spawn several `mv` processes. Doing it in parallel (might have) helped but that setup also comes at a cost. `Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while the existing code took 17 ms to do the same. * Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 16:42:24 +03:00
<!-- Xamarin.Mac never had an equivalent for MtouchNoDSymUtil and never produced them -> now, produce them by default when archiving -->
[msbuild] Make the ParseExtraMtouchArgs task platform-agnostic, and share it between Xamarin.iOS and Xamarin.Mac. (#9061) * Change the parsing code slightly, to make it easier to parse other arguments (coming soon). * Add the parsing task to Xamarin.Mac projects, and use it there as well. The parsed result isn't used yet, but it will be soon. * Unify a few related MSBuild properties (MtouchNoSymbolStrip and MtouchNoDSymUtil).
2020-07-13 15:56:34 +03:00
<_NoDSymUtil Condition="'$(_PlatformName)' != 'macOS'">$(MtouchNoDSymUtil)</_NoDSymUtil>
[macos] Add correct support for producing/archiving `dSYM` (#10409) TL&DR: This PR 1. Removes the creation of the `.dSYM` based on `Debug Information` [1] 2. Adds dSYM support to XM msbuild (now shared with XI implementation) 3. Archive the `.dSYM` directories (plural) properly, e.g. ``` msbuild -p:Configuration=Release -p:ArchiveOnBuild=true ``` Why ? The long story... Historically `.dSYM` for Xamarin.Mac have not been very useful, largely because (most of) the code is JITed so not much is known before runtime. So they were simply not generated during the builds... However AOT options were added to Xamarin.Mac, making them potentially more useful. Also symbols from `libmono` and other native libraries / frameworks can prove useful when diagnosing application crashes. Unsurprisingly developers looking to get symbols eventually found _a way_ [1] to get a `.dSYM` for their applications - but it was not quite correct because: * setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had); * it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks. * the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution. [1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log Additional fixes * Use `Directory.Move` instead of running the `mv` command While the result is identical there is a cost to spawn several `mv` processes. Doing it in parallel (might have) helped but that setup also comes at a cost. `Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while the existing code took 17 ms to do the same. * Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 16:42:24 +03:00
<_NoDSymUtil Condition="'$(_PlatformName)' == 'macOS' And '$(ArchiveOnBuild)' != 'true'">true</_NoDSymUtil>
[msbuild] Make the ParseExtraMtouchArgs task platform-agnostic, and share it between Xamarin.iOS and Xamarin.Mac. (#9061) * Change the parsing code slightly, to make it easier to parse other arguments (coming soon). * Add the parsing task to Xamarin.Mac projects, and use it there as well. The parsed result isn't used yet, but it will be soon. * Unify a few related MSBuild properties (MtouchNoSymbolStrip and MtouchNoDSymUtil).
2020-07-13 15:56:34 +03:00
<_NoDSymUtil Condition="'$(_NoDSymUtil)' == ''">false</_NoDSymUtil>
[msbuild] Share the DeviceSpecificIntermediateOutputPath property. (#8854) * [msbuild] Share the DeviceSpecificIntermediateOutputPath property. We don't technically need this value for Xamarin.Mac, but many of the targets that can be shared need to use this for Xamarin.iOS, so set this value for Xamarin.Mac as well. It will always be the default IntermediateOutputPath for Xamarin.Mac, while for Xamarin.iOS it might be changed in _ComputeTargetArchitectures. * [msbuild] Remove usage in Xamarin.Mac of a variable that was always empty in the past.
2020-06-16 18:39:47 +03:00
<!-- DeviceSpecificIntermediateOutputPath -->
<!--
We don't need this value for Xamarin.Mac, but many of the targets
that can be shared need to use this for Xamarin.iOS, so set this
value for Xamarin.Mac as well. It will always be the default
IntermediateOutputPath for Xamarin.Mac, while for Xamarin.iOS it
might be changed in _ComputeTargetArchitectures.
-->
<DeviceSpecificIntermediateOutputPath>$(IntermediateOutputPath)</DeviceSpecificIntermediateOutputPath>
<!-- Make sure DeviceSpecificOutputPath is a relative path, we depend
on this elsewhere (we prepend the project's directory). When
using dotnet IntermediateOutputPath (and thus
DeviceSpecificIntermediateOutputPath) might be a full path, so
handle this by calculating the corresponding relative path for
DeviceSpecificOutputPath. -->
<DeviceSpecificOutputPath>$(OutputPath)</DeviceSpecificOutputPath>
[dotnet] Fix MSBuild syntax. (#10055) For some reason .NET 6 does not like spaces in certain places: MSB4259: Unexpected space at position "32" of condition [...] So just remove them.
2020-11-06 16:01:19 +03:00
<DeviceSpecificOutputPath Condition="$([System.IO.Path]::IsPathRooted('$(DeviceSpecificOutputPath)')) == 'true'">$([MSBuild]::MakeRelative ('$(MSBuildProjectDirectory)','$(OutputPath)'))</DeviceSpecificOutputPath>
[msbuild] Make sure DeviceSpecificOutputPath always has a trailing slash. Fixes #12158. (#12162) Fixes https://github.com/xamarin/xamarin-macios/issues/12158.
2021-07-26 09:58:13 +03:00
<!-- We assume elsewhere that DeviceSpecificOutputPath has a trailing slash, so make sure that's always the case -->
<DeviceSpecificOutputPath>$([MSBuild]::EnsureTrailingSlash('$(DeviceSpecificOutputPath)'))</DeviceSpecificOutputPath>
[msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties. (#8983) * [msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties. * [msbuild] Fix/unify more resource collection code. * Remove the _CollectBundleResources target for Xamarin.iOS binding projects, we now have a single one for all project types. * Add an IsBindingProject property to distinguish binding projects from other projects. * Use the IsBindingProject to only depend on the other _Compile<ResourceType> targets when we're not building a binding project (which seems to be the reason why the _CollectBundleResources target was duplicated between normal projects and binding projects for both Xamarin.iOS and Xamarin.Mac: the binding project version didn't have any dependencies).
2020-07-01 21:13:05 +03:00
<!-- OptimizePNGs:
default to false if a binding project (both XI and XM)
otherwise default to false if a Xamarin.Mac project
otherwise default to true for Xamarin.iOS
-->
<OptimizePNGs Condition="'$(IsBindingProject)' == 'true' And '$(OptimizePNGs)' == ''">false</OptimizePNGs>
<OptimizePNGs Condition="'$(_PlatformName)' == 'macOS' And '$(OptimizePNGs)' == ''">false</OptimizePNGs>
<OptimizePNGs Condition="'$(_PlatformName)' != 'macOS' And '$(OptimizePNGs)' == ''">true</OptimizePNGs>
<!-- OptimizePropertyLists:
default to false if a binding project (both XI and XM)
otherwise default to false if a Xamarin.Mac project
otherwise default to true for Xamarin.iOS
-->
<OptimizePropertyLists Condition="'$(IsBindingProject)' == 'true' And '$(OptimizePropertyLists)' == ''">false</OptimizePropertyLists>
<OptimizePropertyLists Condition="'$(_PlatformName)' == 'macOS' And '$(OptimizePropertyLists)' == ''">false</OptimizePropertyLists>
<OptimizePropertyLists Condition="'$(_PlatformName)' != 'macOS' And '$(OptimizePropertyLists)' == ''">true</OptimizePropertyLists>
[msbuild] Unify the logic to copy bundle resources to the app. (#8987) * For Xamarin.Mac, this means using the _ComputeBundleResourceOutputPaths and _CopyResourcesToBundle targets from Xamarin.iOS instead of the _CopyContentToBundle target (which is now unused and thus removed). * Adapt the Xamarin.iOS logic (now shared) to handle the fact that the resources shouldn't always go into the root appbundle directory (since they go into Contents/Resources/ for macOS apps), by using the '_AppResourcesPath' variable to specify just this. Once upon a time the Xamarin.iOS logic was identical to the Xamarin.Mac logic, but then we implemented support for asset packs (https://github.com/xamarin/maccore/commit/a98693f07e3f7675773e1f371392c05ff178d3d4) and the code diverged. This means that unifying the logic again is a step towards making asset packs work for Xamarin.Mac apps.
2020-07-03 12:00:36 +03:00
<!-- EnableOnDemandResources: default to true for Xamarin.iOS and false for Xamarin.Mac -->
<EnableOnDemandResources Condition="'$(_PlatformName)' == 'macOS' And '$(EnableOnDemandResources)' == ''">false</EnableOnDemandResources>
<EnableOnDemandResources Condition="'$(_PlatformName)' != 'macOS' And '$(EnableOnDemandResources)' == ''">true</EnableOnDemandResources>
[msbuild] Share the Pack/UnpackLibraryResources targets between Xamarin.iOS and Xamarin.Mac. (#9471) There were 2 differences that had to be reconciled: * The Xamarin.Mac version took 'IntermediateOutputPath' as the intermediate output path, while the Xamarin.iOS version used 'DeviceSpecificIntermediateOutputPath'. 'DeviceSpecificIntermediateOutputPath' is defined to be 'IntermediateOutputPath' for Xamarin.Mac, so make the shared version use 'DeviceSpecificIntermediateOutputPath', since that works in both cases. * The Xamarin.Mac version was writing the output of PackLibraryResources to the FileWrites item group. This was removed on purpose from the Xamarin.iOS version in e97d69b25cc2b85e89feb775169f46f467c66f7a, so it seemed best to leave it out in the shared version as well. Also re-use the _EmbeddedResourcePrefix variable to determine the resource prefix.
2020-08-25 11:42:33 +03:00
<!-- This is the prefix used for embedded resources, both for library projects and binding projects -->
<_EmbeddedResourcePrefix Condition="'$(_PlatformName)' == 'macOS'">xammac</_EmbeddedResourcePrefix>
<_EmbeddedResourcePrefix Condition="'$(_PlatformName)' != 'macOS'">monotouch</_EmbeddedResourcePrefix>
[msbuild] Put Info.plist in the Contents/ subdirectory in the app for catalyst apps.
2020-11-18 10:38:01 +03:00
[msbuild] Use '_PlatformName' == 'MacCatalyst' instead of '_IsMacCatalyst'. (#10636) In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so reflect this in the build logic by setting _PlatformName to 'MacCatalyst'. This makes the build logic a lot simpler for .NET.
2021-02-12 23:49:49 +03:00
<_AppBundleManifestRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents/</_AppBundleManifestRelativePath>
[msbuild] Unify the AppBundleExtension property definition (#10614)
2021-02-11 17:37:39 +03:00
<AppBundleExtension Condition="'$(AppBundleExtension)' == '' And '$(IsAppExtension)' == 'true' And '$(IsXpcService)' == 'true'">.xpc</AppBundleExtension>
<AppBundleExtension Condition="'$(AppBundleExtension)' == '' And '$(IsAppExtension)' == 'true'">.appex</AppBundleExtension>
<AppBundleExtension Condition="'$(AppBundleExtension)' == ''">.app</AppBundleExtension>
[msbuild] Accept 'UseInterpreter' as an alternative for 'MtouchInterpreter'. Fixes #11138. (#11252) Accept 'UseInterpreter' as an alternative for 'MtouchInterpreter', so that we support the same variable name between iOS and Android. Fixes https://github.com/xamarin/xamarin-macios/issues/11138.
2021-04-21 16:37:16 +03:00
<!-- Accept 'UseInterpreter' as an alternative for 'MtouchInterpreter', so that we have the same variable name as Android -->
<MtouchInterpreter Condition="'$(MtouchInterpreter)' == '' And '$(UseInterpreter)' == 'True'">all</MtouchInterpreter>
[msbuild] Unify XamMacResourcePrefix and IPhoneResourcePrefix into _ResourcePrefix. (#8726)
2020-06-02 17:41:44 +03:00
</PropertyGroup>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
<PropertyGroup Condition="'$(IsBindingProject)' == 'true'">
[msbuild] Compute variables for where the platform assembly is, and the platform assembly name. (#9304) This will be more useful later, because these variables will be used in more places in the .NET code.
2020-08-07 15:53:30 +03:00
<BaseLibDllPath Condition="'$(OS)' == 'Unix'">$(_XamarinPlatformAssemblyPath)</BaseLibDllPath>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
[msbuild] Unify XamarinMacFrameworkRoot and MonoTouchSdkRoot into _XamarinSdkRoot. (#8995)
2020-07-07 16:45:42 +03:00
<BTouchToolPath Condition="'$(OS)' == 'Unix' And '$(BTouchToolPath)' == ''">$(_XamarinSdkRoot)/bin/</BTouchToolPath>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
<BTouchToolPath Condition="'$(OS)' != 'Unix' And '$(_PlatformName)' != 'macOS' And '$(BTouchToolPath)' == ''">$(MSBuildExtensionsPath)\Xamarin\iOS\</BTouchToolPath>
<BTouchToolExe Condition="'$(OS)' == 'Unix' And '$(BTouchToolExe)' == ''">bgen</BTouchToolExe>
<BTouchToolExe Condition="'$(OS)' != 'Unix' And '$(BTouchToolExe)' == ''">bgen.exe</BTouchToolExe>
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
<GeneratedSourcesDir Condition="'$(GeneratedSourcesDir)' == ''">$(IntermediateOutputPath)$(_PlatformName)</GeneratedSourcesDir>
<GeneratedSourcesDir Condition="'$(GeneratedSourcesDir)' != '' and !HasTrailingSlash ('$(GeneratedSourcesDir)')">$(GeneratedSourcesDir)\</GeneratedSourcesDir>
<_GeneratedSourcesFileList>$(GeneratedSourcesDir)sources.list</_GeneratedSourcesFileList>
<ProcessEnums Condition="'$(ProcessEnums)' == ''">false</ProcessEnums>
<!-- The generated binding code is unsafe, so make sure to allow unsafe code when compiling the C# code -->
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<!-- Build bindings with the latest (stable) version of C#
We require C# 8 for nullability support. However we allow custom
code to be included inside binding projects and we should not
support anything (stable) that the C# compiler (installed
separately) allow, so `latest` it is.
-->
<LangVersion>latest</LangVersion>
[msbuild] Share a few binding variables: BaseLibDllPath, BTouchToolPath and BTouchToolExe. (#8988) Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper scripts, since the wrapper scripts just call bgen with an additional --target-framework argument, which our BTouch task already does anyway, which means it's not necessary to call the wrapper scripts anymore. This also required: * Moving the code to detect which Xamarin.Mac profile we're building for into Xamarin.Shared.props, since the binding variable logic need to know which Xamarin.Mac profile we're building for. * Setting IsBindingProject property earlier in the build process, to make sure it's set before importing Xamarin.Shared.props.
2020-07-03 12:01:01 +03:00
</PropertyGroup>
[msbuild] Share the _ComputeTargetFrameworkMoniker target. (#8739)
2020-06-03 20:24:09 +03:00
<Target Name="_ComputeTargetFrameworkMoniker" Condition="'$(_ComputedTargetFrameworkMoniker)' == ''">
<PropertyGroup>
<!-- Get the TargetFrameworkMoniker and store it in our own variable so that it's overridable while only affecting the parts of the build that we care about.
This is overridability is a workaround while we wait for .NET 5 to be able to give us the TFM we're supposed to get during the build. -->
<_ComputedTargetFrameworkMoniker>$(TargetFrameworkMoniker)</_ComputedTargetFrameworkMoniker>
<!-- Detect the Mobile condition and set the computed Mobile TFM our tooling expects -->
<_ComputedTargetFrameworkMoniker Condition="'$(_PlatformName)' == 'macOS' And '$(_ComputedTargetFrameworkMoniker)' == 'Xamarin.Mac,Version=v2.0'">Xamarin.Mac,Version=v2.0,Profile=Mobile</_ComputedTargetFrameworkMoniker>
<!-- Detect the Full condition and set the computed TFM our tooling expects -->
<_ComputedTargetFrameworkMoniker Condition="'$(_PlatformName)' == 'macOS' And '$(UseXamMacFullFramework)' == 'true' And $([MSBuild]::ValueOrDefault('$(_ComputedTargetFrameworkMoniker),', '').StartsWith('.NETFramework,', StringComparison.OrdinalIgnoreCase))">Xamarin.Mac,Version=v4.5,Profile=Full</_ComputedTargetFrameworkMoniker>
<!-- Detect the System condition and set the computed TFM our tooling expects -->
<_ComputedTargetFrameworkMoniker Condition="'$(_PlatformName)' == 'macOS' And '$(UseXamMacFullFramework)' != 'true' And $([MSBuild]::ValueOrDefault('$(_ComputedTargetFrameworkMoniker),', '').StartsWith('.NETFramework,', StringComparison.OrdinalIgnoreCase))">Xamarin.Mac,Version=v4.5,Profile=System</_ComputedTargetFrameworkMoniker>
</PropertyGroup>
</Target>
[msbuild] Share the AllowedReferenceRelatedFileExtensions property override. (#9417)
2020-08-21 11:13:26 +03:00
<!-- When looking for related files to copy, look for Mono debugging files as well -->
<PropertyGroup>
<AllowedReferenceRelatedFileExtensions>
$(AllowedReferenceRelatedFileExtensions);
.dll.mdb;
.exe.mdb;
.pdb
</AllowedReferenceRelatedFileExtensions>
</PropertyGroup>
[msbuild] Share the IsMacEnabled and MtouchTargetsEnabled definitions between Xamarin.iOS and Xamarin.Mac. (#9439)
2020-08-21 16:01:30 +03:00
<!-- This is used to determine if VS is connected to mac. -->
<PropertyGroup>
[msbuild] Make the default value for IsMacEnabled property dependent upon the OS. (#9892) * [msbuild] Make the default value for IsMacEnabled property dependent upon the OS. Also make it overridable by only setting it if it's not already set. * Use $([MSBuild]::IsOSPlatform('windows')) instead of $(OS) The $(OS) value isn't standardized, so there's no sane check we can do against it.
2020-10-19 09:23:17 +03:00
<IsMacEnabled Condition="'$(IsMacEnabled)' == '' And !$([MSBuild]::IsOSPlatform('windows'))">true</IsMacEnabled>
<IsMacEnabled Condition="'$(IsMacEnabled)' == '' And $([MSBuild]::IsOSPlatform('windows'))">false</IsMacEnabled>
[msbuild] Share the IsMacEnabled and MtouchTargetsEnabled definitions between Xamarin.iOS and Xamarin.Mac. (#9439)
2020-08-21 16:01:30 +03:00
<MtouchTargetsEnabled Condition="'$(_PlatformName)' != 'macOS'">$(IsMacEnabled)</MtouchTargetsEnabled>
</PropertyGroup>
[msbuild] Set ResolveAssemblyConflicts once. (#9441) No need to set it in every file, when we have one file that rules them all.
2020-08-21 19:38:57 +03:00
<PropertyGroup>
<!-- Enable nuget package conflict resolution -->
<ResolveAssemblyConflicts>true</ResolveAssemblyConflicts>
</PropertyGroup>
[msbuild] Unify the code to define our platform-specific conditional compilation symbols. (#9524)
2020-08-27 18:47:31 +03:00
<PropertyGroup>
<_IsUnifiedDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__UNIFIED__($|;)'))</_IsUnifiedDefined>
<_IsMobileDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__MOBILE__($|;)'))</_IsMobileDefined>
<_IsIOSDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__IOS__($|;)'))</_IsIOSDefined>
<_IsTVOSDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__TVOS__($|;)'))</_IsTVOSDefined>
<_IsWatchOSDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__WATCHOS__($|;)'))</_IsWatchOSDefined>
<_IsMacOSDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__MACOS__($|;)'))</_IsMacOSDefined>
[msbuild] Define __MACCATALYST__ for Mac Catalyst apps. Mac Catalyst is a different target environment for iOS, which means that __IOS__ will also be defined.
2020-11-27 18:47:25 +03:00
<_IsMacCatalystDefined>$([System.Text.RegularExpressions.Regex]::IsMatch('$(DefineConstants.Trim())', '(^|;)__MACCATALYST__($|;)'))</_IsMacCatalystDefined>
[msbuild] Unify the code to define our platform-specific conditional compilation symbols. (#9524)
2020-08-27 18:47:31 +03:00
<DefineConstants Condition="!$(_IsUnifiedDefined)">__UNIFIED__;$(DefineConstants)</DefineConstants>
<DefineConstants Condition="!$(_IsMobileDefined) And '$(_PlatformName)' != 'macOS'">__MOBILE__;$(DefineConstants)</DefineConstants>
<DefineConstants Condition="!$(_IsIOSDefined) And '$(_PlatformName)' == 'iOS'">__IOS__;$(DefineConstants)</DefineConstants>
<DefineConstants Condition="!$(_IsTVOSDefined) And '$(_PlatformName)' == 'tvOS'">__TVOS__;$(DefineConstants)</DefineConstants>
<DefineConstants Condition="!$(_IsWatchOSDefined) And '$(_PlatformName)' == 'watchOS'">__WATCHOS__;$(DefineConstants)</DefineConstants>
<DefineConstants Condition="!$(_IsMacOSDefined) And '$(_PlatformName)' == 'macOS'">__MACOS__;$(DefineConstants)</DefineConstants>
[msbuild] Use '_PlatformName' == 'MacCatalyst' instead of '_IsMacCatalyst'. (#10636) In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so reflect this in the build logic by setting _PlatformName to 'MacCatalyst'. This makes the build logic a lot simpler for .NET.
2021-02-12 23:49:49 +03:00
<DefineConstants Condition="!$(_IsIOSDefined) And '$(_PlatformName)' == 'MacCatalyst'">__IOS__;$(DefineConstants)</DefineConstants> <!-- We define __IOS__ for MacCatalyst as well for now -->
<DefineConstants Condition="!$(_IsMacCatalystDefined) And '$(_PlatformName)' == 'MacCatalyst'">__MACCATALYST__;$(DefineConstants)</DefineConstants>
[msbuild] Unify the code to define our platform-specific conditional compilation symbols. (#9524)
2020-08-27 18:47:31 +03:00
</PropertyGroup>
[msbuild] Add a Xamarin.Shared.props. (#8711) It's empty for now, but soon enough it will start getting shared Xamarin.iOS/Xamarin.Mac code.
2020-06-02 15:26:25 +03:00
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets"
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets')"/>
</Project>