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

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

[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Version information -->
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
<Import Project="Microsoft.$(_PlatformName).Sdk.Versions.props" />
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<!-- This contains the OS versions we support for target platform -->
<Import Project="Microsoft.$(_PlatformName).Sdk.SupportedTargetPlatforms.props" />
<Import Project="Xamarin.Shared.Sdk.TargetFrameworkInference.props" />
Imports the .user.env file if exists and the build is from VS (#17466) This will allow the latest runtime identifier values to be evaluated in time during the MSBuild property evaluation phase. Related and dependent of this PR: https://github.com/xamarin/XamarinVS/pull/13606
2023-02-08 11:37:39 +03:00
<!-- Imports the .user.env file if exists and the build is from VS -->
<Import Project="$(MSBuildProjectFullPath).user.env" Condition="Exists('$(MSBuildProjectFullPath).user.env') And '$(BuildingInsideVisualStudio)' == 'true'" />
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<PropertyGroup>
[msbuild] Rename $(_UsingXamarinSdk) to $(UsingAppleNETSdk) (#11270) The `$(_UsingXamarinSdk)` property has been renamed to help improve external usability. This change increases parity with the Android SDK, which currently defines `$(UsingAndroidNETSdk)` for internal and external use.
2021-04-22 04:32:33 +03:00
<!-- Set to true when using the Microsoft.<platform>.Sdk NuGet. This is used by pre-existing/shared targets to tweak behavior depending on build system -->
<UsingAppleNETSdk>true</UsingAppleNETSdk>
[net6] Fixes build issues from VS for Preview 7 (#12281) * [net6] Adds missing custom linker steps when building from Windows To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`. When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS. * [net6] Updates .NET SDK path for remote tasks execution This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist. * Adds missing spaces to TaskRunner.cs
2021-07-29 16:20:20 +03:00
<!-- This is the location of the Microsoft.<platform>.Sdk NuGet (/usr/local/share/dotnet/sdk/<version>/Sdks/Microsoft.[iOS/tvOS/watchOS/macOS].Sdk) on the platform the build is running from (Mac or Win) -->
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
<_XamarinSdkRootDirectory>$([MSBuild]::NormalizePath('$(MSBuildThisFileDirectory)', '..'))\</_XamarinSdkRootDirectory>
[net6] Fixes build issues from VS for Preview 7 (#12281) * [net6] Adds missing custom linker steps when building from Windows To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`. When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS. * [net6] Updates .NET SDK path for remote tasks execution This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist. * Adds missing spaces to TaskRunner.cs
2021-07-29 16:20:20 +03:00
<!-- This is the location of the Microsoft.<platform>.Sdk NuGet on macOS, this value will be overriden from Windows -->
<_XamarinSdkRootDirectoryOnMac>$(_XamarinSdkRootDirectory)</_XamarinSdkRootDirectoryOnMac>
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
<_XamarinTaskAssembly Condition="'$(_PlatformName)' != 'macOS'">$(_XamarinSdkRootDirectory)\tools\msbuild\iOS\Xamarin.iOS.Tasks.dll</_XamarinTaskAssembly>
<_XamarinTaskAssembly Condition="'$(_PlatformName)' == 'macOS'">$(_XamarinSdkRootDirectory)\tools\msbuild\macOS\Xamarin.Mac.Tasks.dll</_XamarinTaskAssembly>
[dotnet] suppress IL2026 linker warning (#11043) We started using `$(SuppressTrimAnalysisWarnings)` by default, because ILLink started emitting warnings by default in .NET 6 Preview 3. 7bf3e8d8 fixed *most* of these warnings except for `IL2026`: https://github.com/dotnet/sdk/blob/16aedd6e72bd2f8dea01918478fc1368bc017fe9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L52-L57 I get around 20 instances of this warning when building dotnet/maui. `IL2026` occurs because this logic is evaluated much earlier than the `PrepareForILLink` MSBuild target: https://github.com/dotnet/sdk/blob/16aedd6e72bd2f8dea01918478fc1368bc017fe9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L202 The MSBuild evaluation order right now is: * Sdk/Sdk.props * Microsoft.[platform].Sdk.props * Xamarin.Shared.Sdk.props * Microsoft.NET.ILLink.targets * Microsoft.[platform].Sdk.targets * Xamarin.Shared.Sdk.targets We need to set `$(SuppressTrimAnalysisWarnings)` earlier in `Xamarin.Shared.Sdk.props` to solve the issue here. On the Android side I got lucky, and it worked first try without thinking too much. We import a `*.DefaultProperties.targets` before `Microsoft.NET.ILLink.targets`, and that is why it worked.
2021-03-31 17:07:02 +03:00
<SuppressTrimAnalysisWarnings Condition=" '$(SuppressTrimAnalysisWarnings)' == '' ">true</SuppressTrimAnalysisWarnings>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<AfterMicrosoftNETSdkTargets>$(AfterMicrosoftNETSdkTargets);$(MSBuildThisFileDirectory)Microsoft.$(_PlatformName).Sdk.targets</AfterMicrosoftNETSdkTargets>
[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 is used by the existing MSBuild targets files -->
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == ''">$(_XamarinSdkRootDirectory)</_XamarinSdkRoot>
[dotnet] Fix _DetectSdkLocations from Windows (#11451) This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS. This should not change the original behavior when building from macOS.
2021-05-06 08:42:43 +03:00
<!-- _XamarinSdkRootOnMac this should be passed to tasks that need to access the Xamarin Sdk dir on the Mac, this value will be overriden from Windows -->
<_XamarinSdkRootOnMac>$(_XamarinSdkRoot)</_XamarinSdkRootOnMac>
[dotnet] Tell .NET to not generate files we don't need. Fixes #9687. (#11693) Tell .NET to not generate files we don't need: * Dependency file (*.deps.json). * Reference assemblies for executable projects. Fixes https://github.com/xamarin/xamarin-macios/issues/9687.
2021-05-31 19:06:42 +03:00
<!-- We don't need any dependency files -->
<GenerateDependencyFile Condition="'$(GenerateDependencyFile)' == ''">false</GenerateDependencyFile>
[dotnet] Make sure that MSBuild doesn't strip away our PublishFolderType metadata
2021-08-12 13:30:57 +03:00
<!-- MSBuild will discard the 'PublishFolderType' metadata on items unless we set these properties -->
<MSBuildDisableGetCopyToOutputDirectoryItemsOptimization>true</MSBuildDisableGetCopyToOutputDirectoryItemsOptimization>
<MSBuildDisableGetCopyToPublishDirectoryItemsOptimization>true</MSBuildDisableGetCopyToPublishDirectoryItemsOptimization>
[dotnet] Only validate the RuntimeIdentifier if we need/use it. Fixes #13482. (#14339) Fixes https://github.com/xamarin/xamarin-macios/issues/13482.
2022-03-09 10:22:52 +03:00
<!-- Do we need a RuntimeIdentifier? For apps and app extensions we do -->
<_RuntimeIdentifierIsRequired Condition="'$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true'">true</_RuntimeIdentifierIsRequired>
[dotnet] Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore. Fixes #16193. (#16306) Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore, because .NET gets it wrong when building from inside VS (Windows). When building using either VSMac or the command line (either from Windows or Mac), the `MSBuildRuntimeType` property is set to `Core`, and as a result, the default value for `GenerateSatelliteAssembliesForCore` is `true`: ```xml <GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore> ``` See: https://github.com/dotnet/sdk/blob/00100960bf06cb595daba647673cd0329be896f4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L41 This is the correct behavior. However, when building from inside Visual Studio (for Windows), the `MSBuildRuntimeType` property is set to `Full`, and thus `GenerateSatelliteAssembliesForCore` is not set to `true`, and we end up executing al.exe to generate satellite assemblies, which is wrong (al.exe complains that 'arm64' is an invalid platform). Fix this by always defaulting `GenerateSatelliteAssembliesForCore` to `true`, independent on where we're executing. Ref: https://github.com/dotnet/sdk/issues/28419. Fixes https://github.com/xamarin/xamarin-macios/issues/16193.
2022-10-10 22:41:36 +03:00
<!-- The logic to compute the default value for GenerateSatelliteAssembliesForCore is wrong when building inside Visual Studio (Windows), so make sure it defaults to the correct value -->
<!-- Ref: https://github.com/xamarin/xamarin-macios/issues/16193 -->
<!-- Ref: https://github.com/dotnet/sdk/issues/28419 -->
<GenerateSatelliteAssembliesForCore Condition="'$(GenerateSatelliteAssembliesForCore)' == ''">true</GenerateSatelliteAssembliesForCore>
[dotnet] Ensure any trimmer components are restored properly. (#17227) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM).
2023-01-16 10:21:09 +03:00
<!-- This will ensure any trimmer components are restored by the framework reference logic. As such it must happen before Microsoft.NET.Publish.targets is included.
Ref:
* https://github.com/dotnet/sdk/pull/29441
* https://github.com/dotnet/sdk/blob/c5a58bc6c3eb2b236b314e6d17a89a537459890c/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L20-L21
* https://github.com/dotnet/sdk/blob/c5a58bc6c3eb2b236b314e6d17a89a537459890c/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets#L102
-->
<_IsTrimmingEnabled>true</_IsTrimmingEnabled>
[dotnet] Enable generation of runtime configuration file (#17840) Set the GenerateRuntimeConfigurationFiles (GRCF) property to true to avoid warnings at build time + add test for change. Diving deeper into the fix... - This warning only occurs with .NET apps which is why GRCF is only updated in the dotnet directory and not msbuild (legacy) - After examining the binlog (see issue), it was found that the GRCF was contingent upon the HasRuntimeOutput property, which is only defined for executable projects. And in this case, the user's project output type is library thus both the RuntimeOutput and consequently GRCF properties were not enabled. - By setting the GRCF to true we can address the original warning of concern while ensuring the rest of the projects's behavior is not altered in mysterious ways (i.e. by touching the RuntimeOutput property or the project output type instead, these changes could have extraneous effects). Fixes #17543 --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2023-03-23 18:10:04 +03:00
<!-- The GRCF property is contingent upon the HasRuntimeOutput property, which is only defined for executable projects. So, explicitly define GRCF for extension projects to avoid warnings at build time. -->
<GenerateRuntimeConfigurationFiles Condition="'$(IsAppExtension)' == 'true'">true</GenerateRuntimeConfigurationFiles>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
</PropertyGroup>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
<!-- Set the default RuntimeIdentifier if not already specified. -->
[dotnet] Only validate the RuntimeIdentifier if we need/use it. Fixes #13482. (#14339) Fixes https://github.com/xamarin/xamarin-macios/issues/13482.
2022-03-09 10:22:52 +03:00
<PropertyGroup Condition="'$(_RuntimeIdentifierIsRequired)' == 'true' And '$(RuntimeIdentifier)' == '' And '$(RuntimeIdentifiers)' == '' ">
[dotnet] Make relase builds for desktop universal by default. Fixes #15620. (#15769)
2022-08-31 17:45:10 +03:00
<!-- The _<platform>RuntimeIdentifier values are set from the IDE -->
[dotnet] Adds platform specific RID options (#14643) This enables Visual Studio to set a specific `RuntimeIdentifier` for each platform when building all target frameworks in a MAUI project. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2022-04-06 10:39:33 +03:00
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'iOS'">$(_iOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'tvOS'">$(_tvOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'macOS'">$(_macOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'MacCatalyst'">$(_MacCatalystRuntimeIdentifier)</RuntimeIdentifier>
<_XamarinUsingDefaultRuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">true</_XamarinUsingDefaultRuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(_PlatformName)' == 'iOS'">iossimulator-x64</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(_PlatformName)' == 'tvOS'">tvossimulator-x64</RuntimeIdentifier>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
[dotnet] Make relase builds for desktop universal by default. Fixes #15620. (#15769)
2022-08-31 17:45:10 +03:00
<!-- For release desktop builds we default to universal apps in .NET 7+ -->
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' != 'Release' And '$(_PlatformName)' == 'macOS'">osx-x64</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' != 'Release' And '$(_PlatformName)' == 'MacCatalyst'">maccatalyst-x64</RuntimeIdentifier>
<RuntimeIdentifiers Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' == 'Release' And '$(_PlatformName)' == 'macOS'">osx-x64;osx-arm64</RuntimeIdentifiers>
<RuntimeIdentifiers Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' == 'Release' And '$(_PlatformName)' == 'MacCatalyst'">maccatalyst-x64;maccatalyst-arm64</RuntimeIdentifiers>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
[dotnet] Always set 'UseAppHost' and '_RuntimeIdentifierUsesAppHost' to 'false' in .NET. Otherwise .NET might want to include an app host in the app, which ends up with a build warning, because we don't use apphosts.
2021-12-17 01:15:09 +03:00
</PropertyGroup>
<!-- We're never using any app hosts -->
<PropertyGroup>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
<_RuntimeIdentifierUsesAppHost>false</_RuntimeIdentifierUsesAppHost>
<UseAppHost>false</UseAppHost>
</PropertyGroup>
[dotnet] Enable LLVM by default for release builds. Fixes #12147. (#12660) Fixes https://github.com/xamarin/xamarin-macios/issues/12147.
2021-09-08 19:04:39 +03:00
[net6][msbuild] Set SelfContained for AppExtensions sooner to fix publishing (#12703) This PR resolves a crash when running the linker on publishing iOS extensions. The crash would occur here in failing to resolve corelib. The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies. This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib. After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish. _ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true' Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target. This means we'd fail to set SelfContained until after the condition, and not run. This was verified by setting /p:SelfContained=true to true. I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
2021-09-20 17:40:41 +03:00
<!-- App extensions are self-contained, even though their OutputType=Library. This must be done here and not targets as it is checked before targets are invoked. -->
[dotnet] Make relase builds for desktop universal by default. Fixes #15620. (#15769)
2022-08-31 17:45:10 +03:00
<PropertyGroup Condition="'$(IsAppExtension)' == 'true' And '$(RuntimeIdentifier)' != ''">
[net6][msbuild] Set SelfContained for AppExtensions sooner to fix publishing (#12703) This PR resolves a crash when running the linker on publishing iOS extensions. The crash would occur here in failing to resolve corelib. The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies. This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib. After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish. _ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true' Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target. This means we'd fail to set SelfContained until after the condition, and not run. This was verified by setting /p:SelfContained=true to true. I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
2021-09-20 17:40:41 +03:00
<SelfContained>true</SelfContained>
</PropertyGroup>
[dotnet] Enable LLVM by default for release builds. Fixes #12147. (#12660) Fixes https://github.com/xamarin/xamarin-macios/issues/12147.
2021-09-08 19:04:39 +03:00
<!--
Enable LLVM by default for mobile release builds.
At this point we don't necessarily know yet whether we're building for device or simulator,
but the MtouchUseLlvm value is ignored when using the simulator, so it doesn't matter
if we set it in all cases.
-->
<PropertyGroup Condition="'$(MtouchUseLlvm)' == '' And '$(Configuration)' == 'Release' And ('$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS')">
<MtouchUseLlvm>true</MtouchUseLlvm>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
</PropertyGroup>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
</Project>