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

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

Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<!--
***********************************************************************************************
Xamarin.Shared.targets
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) 2018 Microsoft. All rights reserved.
***********************************************************************************************
-->
<!-- This is shared between Xamarin.iOS and Xamarin.Mac -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
[msbuild] Add a GetMinimumOSVersion target that reads the app manifest and outputs the MinimumOSVersion. (#8858) This makes it possible for several other tasks to take the MinimumOSVersion as direct input, instead of the app manifest's path. Previously the app manifest (Info.plist) was loaded and parsed in each task, slightly differently in each place, and in addition there are differences between macOS and other platforms, which made it even worse. This code refactoring also made it possible to remove an error code which wasn't necessary anymore. This task also computes the default MinimumOSVersion if none is specified in the app manifest. There is one breaking change: a library project could previously specify an inexistent Info.plist, and it would build fine. This will now result in a "Error loading 'Info.plist': File not found" error. This is trivial to fix: just remove the Info.plist from the project file (or an alternative solution could be to condition the inclusion of the Info.plist in the project file on the existence of the Info.plist). New commits in xamarin/Xamarin.MacDev: * xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73) Diff: https://github.com/xamarin/Xamarin.MacDev/compare/45c5a680e20a209ac846a32e0f2f0f83e843ab76..a1bc6f39b3efe5d817c60d78eaff3f4c2de720ea
2020-06-16 18:40:04 +03:00
<PropertyGroup Condition="'$(_TaskAssemblyName)' == ''">
[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
<_TaskAssemblyName Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS' Or '$(_PlatformName)' == 'MacCatalyst'">$(MSBuildThisFileDirectory)..\iOS\Xamarin.iOS.Tasks.dll</_TaskAssemblyName>
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<_TaskAssemblyName Condition="'$(_PlatformName)' == 'macOS'">$(MSBuildThisFileDirectory)Xamarin.Mac.Tasks.dll</_TaskAssemblyName>
[msbuild] Add a GetMinimumOSVersion target that reads the app manifest and outputs the MinimumOSVersion. (#8858) This makes it possible for several other tasks to take the MinimumOSVersion as direct input, instead of the app manifest's path. Previously the app manifest (Info.plist) was loaded and parsed in each task, slightly differently in each place, and in addition there are differences between macOS and other platforms, which made it even worse. This code refactoring also made it possible to remove an error code which wasn't necessary anymore. This task also computes the default MinimumOSVersion if none is specified in the app manifest. There is one breaking change: a library project could previously specify an inexistent Info.plist, and it would build fine. This will now result in a "Error loading 'Info.plist': File not found" error. This is trivial to fix: just remove the Info.plist from the project file (or an alternative solution could be to condition the inclusion of the Info.plist in the project file on the existence of the Info.plist). New commits in xamarin/Xamarin.MacDev: * xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73) Diff: https://github.com/xamarin/Xamarin.MacDev/compare/45c5a680e20a209ac846a32e0f2f0f83e843ab76..a1bc6f39b3efe5d817c60d78eaff3f4c2de720ea
2020-06-16 18:40:04 +03:00
</PropertyGroup>
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<!-- Tasks that override built-in tasks to support remoting from VS/Windows -->
<UsingTask TaskName="Microsoft.Build.Tasks.Copy" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.Delete" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.Exec" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.MakeDir" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.Move" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.RemoveDir" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Microsoft.Build.Tasks.Touch" AssemblyFile="$(_TaskAssemblyName)" />
[dotnet] Initial support for .NET6 from Windows (#10590) These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI. For now this only enables builds for the iOS Simulator, physical devices are not yet supported. - Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows. - The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack. - On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project. ------------ * [msbuild] Adds support for executing Xamarin.iOS tasks from Windows * [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows * Added XMA Build Agent to Xamarin.MacDev.Tasks.sln * Fixes some MSBuild versioning problems * Makes the XMA Build agent load Xamarin.iOS tasks We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one. There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll. * Added Xamarin.iOS.Tasks.Windows project * Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj * Adds Messaging assemblies when ILRepacking Xamarin Tasks The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks * Adds a reference to Messaging.Core targets to the Agent's project * [msbuild] Adds Xamarin iOS Windows targets * [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer. * [dotnet] Creates iOS Windows pack Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS. * Fixes type in dotnet makefile * [dotnet] Fixes the iOS Windows pack generation - The windows pack should not include the Sdk and Targets folders - For now we'll just create an iOS pack - Fixes the path to the files to include on the Windows Sdk pack * Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Added reference to the core iOS SDK from the Windows iOS SDK Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version * Updated Messaging version * Override MessagingBuildClientAssemblyFile property and correctly imported props from targets * [dotnet] Make Windows pack using target files from the output dir We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source * [dotnet] Adds the Windows Sdk pack to the workload manifest * [msbuild] Fixes the Windows Sdk pack name * [dotnet] Merge Mqtt instead of Mqtt.Server We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks * Updated Messaging version * [dotnet] Several fixes for the Windows Sdk - Adds missing task CollectMonotouchReferences - Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA - Updates the msbuild/Makefile to include files from both the output dir and the source dir - Overrides the agents directory to look for them on the Windows pack * [dotnet] Fixes the XMA Build agent - The build agent is an app so it cannot target ns2.0 - The MSBuild dependencies should be copied into the agent zip file - Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed - Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack * Bumps Xamarin.Messaging to 1.2.102 * Adds net6-win branch to trigger builds * Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks * Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task * Fix unloaded Xamarin.Messaging.Build project * Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows Also added missing tasks and changes .After.targets * Updated Xamarin.Messaging version * Build agent - reference MSBuild assemblies from the framework Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS * [msbuild] Fixes _UpdateDynamicLibraryId target The tasks con this target need to be executed remotely (when building from Windows). * Updates resources * Bump Xamarin.Messaging Fixes problems when executing Exec task remotely * [dotnet] Overrides Publish targets to execute them remotely from Windows The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows. This is done in a Windows.After.targets file so it won't affect builds on macOS. * Added ILMerge to Xamarin.iOS.Tasks.Windows Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package * Bumps Messaging This new version of messaging fixes a problem when copying task inputs from Windows to the Mac * [dotnet] Fixes copying files to the Mac when building from Windows When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those. * [dotnet] Fixes how files are copied to the output dir - Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac - Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up. * Fixes typo on Xamarin.iOS.Common.After.targets * Bumps Xamarin.Messaging * [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type. This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project. * [msbuild] Fixes warnings when building from Windows * [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly. * [dotnet] Compute PublishTrimmed on a target We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows. * Bumps Messaging to 1.2.111 * [dotnet] Execute ILLink remotely when building from Windows - Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows. - This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task. * [dotnet] Fixes intput/output files creation for linker tasks - Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely - All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely - CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac - Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build. * [msbuild] Minor fixes after merging from main * [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack * [dotnet] Fixes dotnet Windows specific pack generation Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package. It also adds a variable to enable building this pack. * [dotnet] Adds iOS Windows specific pack to iOS only MSI There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI * [dotnet] Create a separate bundle for the iOS Windows MSI We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows. * Fixes spacing issues in Xamarin.iOS.Tasks.csproj * Bumps Touch.Unit back to 05db76 * Fixes formatting problems * [msbuild] Replaces error E0176 by E0186 Because there's a warning W0176 that will overlap with the error * [msbuild] Fixes CompileEntitlements task There were 2 problems: 1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac) 2- We should copy to the Mac the default entitlements file if no custom file was specified * Several fixes to cleanup the code to support iOS from Windows * Apply suggestions from code review Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Formatting fixes in Xamarin.Messaging.Build * Reverted formatting changes in CompileEntitlements.cs * More formatting fixes * Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> * Fixes order of MSBuild errors in the resource file * Add newly added localizable strings to canary test of translated strings. * Delete tests that ensure theres code only on the abstract tasks These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore. * [dotnet] Don't build the Windows SDK pack if not configured to do so. Co-authored-by: mag <mauro.agnoletti@gmail.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-02-12 09:43:17 +03:00
<UsingTask TaskName="Microsoft.Build.Tasks.WriteLinesToFile" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<!-- Xamarin.iOS-specific tasks. Some of these are duplicated with the Xamarin.Mac ones below, and should eventually be re-namespaced to be in Xamarin.MacDev -->
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CollectAssetPacks" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CollectITunesArtwork" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CollectITunesSourceFiles" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CompileAppManifest" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CompileITunesMetadata" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CompileSceneKitAssets" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CreateAssetPack" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CreateDebugConfiguration" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CreateDebugSettings" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CreateEmbeddedResources" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.DetectDebugNetworkConfiguration" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.DetectSdkLocations" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.DetectSigningIdentity" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.FindWatchOS2AppBundle" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.GetFiles" AssemblyFile="$(_TaskAssemblyName)" />
[dotnet] Add support for 'dotnet build -t:run'. (#9823) * Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into a separate NuGet (to avoid shipping the same mlaunch executable in three different packages), but that can be done at a later stage. * Add a GetMlaunchArguments task that computes the mlaunch arguments to install or launch an app in either the simulator or on device. * Implement the MSBuild logic to make the Run target (provided by .NET) launch mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done by setting the RunCommand and RunArguments properties (which the Run target uses) to the correct values. Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which I haven't figured out yet: A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'. Failed to run as a self-contained app. - The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework. - If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'. That's for a different pull request though. Ref: https://github.com/xamarin/net6-samples/issues/35.
2020-10-09 14:01:13 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.GetMlaunchArguments" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.MTouch" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.ParseDeviceSpecificBuildInformation" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.PrepareNativeReferences" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.ResolveNativeWatchApp" AssemblyFile="$(_TaskAssemblyName)" />
[dotnet] Revert changes that separate Messaging from Xamarin.iOS.Tasks to fix dotnet build (#10738) This reverts commit 9a27951a99866e9e278953a4468951fdda78f40a. The purpose of the original commit was to take out 4 tasks that were only executed from Windows to the Windows specific pack (and enabling more tasks that need to be executed remotely on that pack). To execute tasks remotely the build will initially run `SayHello` which connects to the Mac and shares the connection with all the tasks through IBuildEngine4[1]. When that connection object is retrieved on the tasks we need to cast it as a Messaging connection type, and this works from Visual Studio and msbuild because there's just one messaging assembly loaded. But it doesn't work on dotnet/msbuild, because there's a feature called ALC (AssemblyLoadContext) which will load each assembly task into it's own context[2], loading all its dependencies in that context. In this scenario sharing custom objects between tasks won't work because the original object type could be from a different context than the one retrieving it. This is described here: https://github.com/dotnet/msbuild/issues/5084. [1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4?view=msbuild-16-netcore [2] https://github.com/dotnet/msbuild/blob/master/documentation/specs/task-isolation-and-dependencies.md
2021-03-01 10:05:01 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.ResolveUniversalTypeIdentifiers" AssemblyFile="Xamarin.iOS.Tasks.dll" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.ValidateAppBundleTask" AssemblyFile="$(_TaskAssemblyName)" />
[dotnet] Revert changes that separate Messaging from Xamarin.iOS.Tasks to fix dotnet build (#10738) This reverts commit 9a27951a99866e9e278953a4468951fdda78f40a. The purpose of the original commit was to take out 4 tasks that were only executed from Windows to the Windows specific pack (and enabling more tasks that need to be executed remotely on that pack). To execute tasks remotely the build will initially run `SayHello` which connects to the Mac and shares the connection with all the tasks through IBuildEngine4[1]. When that connection object is retrieved on the tasks we need to cast it as a Messaging connection type, and this works from Visual Studio and msbuild because there's just one messaging assembly loaded. But it doesn't work on dotnet/msbuild, because there's a feature called ALC (AssemblyLoadContext) which will load each assembly task into it's own context[2], loading all its dependencies in that context. In this scenario sharing custom objects between tasks won't work because the original object type could be from a different context than the one retrieving it. This is described here: https://github.com/dotnet/msbuild/issues/5084. [1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4?view=msbuild-16-netcore [2] https://github.com/dotnet/msbuild/blob/master/documentation/specs/task-isolation-and-dependencies.md
2021-03-01 10:05:01 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.VerifyXcodeVersion" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.WriteAssetPackManifest" AssemblyFile="$(_TaskAssemblyName)" />
<!-- Xamarin.Mac-specific tasks. Some of these are duplicated with the Xamarin.iOS ones above, and should eventually be re-namespaced to be in Xamarin.MacDev -->
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.CompileAppManifest" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.CompileSceneKitAssets" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.CreateEmbeddedResources" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.DetectSdkLocations" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.DetectSigningIdentity" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.Mmp" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' == 'macOS'" TaskName="Xamarin.Mac.Tasks.PrepareNativeReferences" AssemblyFile="$(_TaskAssemblyName)" />
<!-- Tasks shared between Xamarin.iOS and Xamarin.Mac -->
[msbuild] Share the ACTool task implementation between iOS and macOS. (#12425)
2021-08-13 21:15:53 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ACTool" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the ALToolUpload and ALToolValidate task implementations between iOS and macOS. (#12852)
2021-09-28 18:38:51 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ALToolUpload" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.ALToolValidate" AssemblyFile="$(_TaskAssemblyName)" />
[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
<UsingTask TaskName="Xamarin.MacDev.Tasks.Archive" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ArTool" AssemblyFile="$(_TaskAssemblyName)" />
[dotnet] Implement AOT compilation for mobile platforms (#9962) * Add an AOTCompile task that runs the AOT compiler for a given set of input assemblies. This task will eventually be deprecated by an equivalent task provided by Mono, but this works for now. * Add an _AOTCompile target that takes care of running the AOT compiler and compile the result into object files.
2020-10-27 17:16:34 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.AOTCompile" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the BTouch task implementation between iOS and macOS. (#12873)
2021-10-04 09:18:47 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.BTouch" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.Codesign" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the CodesignVerify task implementation between iOS and macOS. (#12918)
2021-10-06 16:51:42 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CodesignVerify" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CollectBundleResources" AssemblyFile="$(_TaskAssemblyName)" />
[mac] Add user-framework support for Xamarin.Mac (#10144) * Move existing tests to iOS subdirectory and adjust reference paths
2020-11-26 16:47:41 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CollectFrameworks" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the CompileEntitlements task implementation between iOS and macOS. (#12946)
2021-10-07 09:17:50 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CompileEntitlements" AssemblyFile="$(_TaskAssemblyName)" />
[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
<UsingTask TaskName="Xamarin.MacDev.Tasks.ComputeBundleResourceOutputPaths" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CoreMLCompiler" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateAssetPackManifest" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the iOS and macOS versions of the CreateBindingResourcePackage task. (#12710) * Slightly less code. * More code sharing. * Brings remote windows support to this task for macOS projects if we ever want that.
2021-09-15 16:10:35 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateBindingResourcePackage" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateInstallerPackage" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreatePkgInfo" AssemblyFile="$(_TaskAssemblyName)" />
Xamarin.Mac native Apple Silicon targetting support (#10115) * Add support for Xamarin.Mac arm64 * Add compile product definition task Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures. * Don't reference dynamic objC_send on arm64 When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64. * Fix improper delete/move with already existing directories * Fix stret requirement for Xamarin.Mac in arm64. The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64. * Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app * Re-generalize some mmp registrar rules `Microsoft.macOS.registrar` was missed by the current rule set * Fix mmp tests * Set E7072 as not translated Tests were failing otherwise * Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same) * Fix style issues * Fix `ToLower` usage for invariant usage * Fix xtro-sharpie test
2021-03-18 04:48:02 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CompileProductDefinition" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.Ditto" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.DSymUtil" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the EmbedProvisionProfile and EmbedMobileProvision tasks between iOS and macOS. (#10322) These two tasks did essentially the same thing, so we can just merge them. I kept the "EmbedProvisionProfile" name, because that sounded like the most applicable to all platforms.
2021-01-11 16:34:19 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.EmbedProvisionProfile" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.FindItemWithLogicalName" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.GenerateBundleName" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share several cleaning targets between Xamarin.iOS and Xamarin.Mac. (#11898) The iOS version of the cleaning tasks were much more comprehensive, so those won out when there were any differences. This also required moving the GetDirectoriesTask to shared code.
2021-06-11 17:39:44 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.GetDirectories" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Delete any Mono crash dump files in the root app bundle before codesigning. Fixes #12320. (#12332) This is what happens: 1. Mono will write crash dumps in the current directory: https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/mono/mono/utils/mono-state.c#L302-L322 2. The current directory is by default the root of the app bundle. 3. If there are any files in the root of the app bundle for macOS or Mac Catalyst, 'codesign' will fail ("unsealed contents present in the bundle root"). This leads to the following sequence of events: 1. App developer builds & runs a Mac Catalyst app. 2. The app crashes for some reason. 3. Mono creates a crash dump (in the root directory of the app bundle). 4. The app developer changes something in the project and tries again. 5. The build fails, because 'codesign' fails. Avoid this by deleting any crash dump files from the root of the app bundle before signing the app.
2021-08-10 08:39:00 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.GetFileSystemEntries" AssemblyFile="$(_TaskAssemblyName)" />
[windows][msbuild] Fix the use of a windows path inside `_PrepareDebugSymbolGeneration` (#11870) Revert a small part of #10409 so the path evaluation always happens on the mac computer (even if the build is done from Windows) Also dded a comment to avoid repeating that mistake again Fixes https://github.com/xamarin/xamarin-macios/issues/11817 Move task so it also work for Xamarin.Mac (since this is now shared code)
2021-06-09 16:19:42 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.GetFullPath" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.GetPropertyListValue" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.IBTool" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the Metal[Lib] task implementations between iOS and macOS. (#12851)
2021-09-29 08:55:55 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.Metal" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.MetalLib" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the OptimizeImage and OptimizePropertyList tasks and targets between iOS and macOS. (#12819) This brings .png and .plist optimization to macOS (but no behavior is changed, because it's already disabled by default).
2021-09-24 17:26:28 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.OptimizeImage" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.OptimizePropertyList" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.PackLibraryResources" AssemblyFile="$(_TaskAssemblyName)" />
[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
<UsingTask TaskName="Xamarin.MacDev.Tasks.ParseBundlerArguments" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Move Xamarin.iOS' implementation of the PrepareResourceRules task to Xamarin.MacDev.Tasks. (#9318)
2020-08-07 15:54:38 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.PrepareResourceRules" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.PropertyListEditor" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ReadAppManifest" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ReadItemsFromFile" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ResolveNativeReferences" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the ScnTool task implementation between iOS and macOS. (#12850)
2021-09-28 18:31:53 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ScnTool" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.SmartCopy" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.SpotlightIndexer" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.SymbolStrip" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Share the TextureAtlas task implementation between iOS and macOS. (#12826)
2021-09-27 21:27:24 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.TextureAtlas" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.UnpackLibraryResources" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.WriteAppManifest" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify all the UsingTask statements. (#8998) Some of these have been duplicated across various targets files, and when adding a new task it's annoying to forget to add it somewhere. So just have them all in the same place, so that they're loaded in every file. There are still duplicates between the iOS and Mac tasks, but those will be unified in a later PR.
2020-07-07 16:52:06 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.WriteItemsToFile" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.Zip" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Add a GetMinimumOSVersion target that reads the app manifest and outputs the MinimumOSVersion. (#8858) This makes it possible for several other tasks to take the MinimumOSVersion as direct input, instead of the app manifest's path. Previously the app manifest (Info.plist) was loaded and parsed in each task, slightly differently in each place, and in addition there are differences between macOS and other platforms, which made it even worse. This code refactoring also made it possible to remove an error code which wasn't necessary anymore. This task also computes the default MinimumOSVersion if none is specified in the app manifest. There is one breaking change: a library project could previously specify an inexistent Info.plist, and it would build fine. This will now result in a "Error loading 'Info.plist': File not found" error. This is trivial to fix: just remove the Info.plist from the project file (or an alternative solution could be to condition the inclusion of the Info.plist in the project file on the existence of the Info.plist). New commits in xamarin/Xamarin.MacDev: * xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73) Diff: https://github.com/xamarin/Xamarin.MacDev/compare/45c5a680e20a209ac846a32e0f2f0f83e843ab76..a1bc6f39b3efe5d817c60d78eaff3f4c2de720ea
2020-06-16 18:40:04 +03:00
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets"
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets')"/>
[msbuild] Share the OptimizeImage and OptimizePropertyList tasks and targets between iOS and macOS. (#12819) This brings .png and .plist optimization to macOS (but no behavior is changed, because it's already disabled by default).
2021-09-24 17:26:28 +03:00
<ItemDefinitionGroup>
<_BundleResourceWithLogicalName>
<Optimize />
</_BundleResourceWithLogicalName>
</ItemDefinitionGroup>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<!--
@(NativeReference) are not safe to use as an Input to a task, as frameworks are a directory and will appears unbuilt every time.
So we split it into two camps as a prebuild step
-->
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
<Target Name="_ExpandNativeReferences" Condition="'$(DesignTimeBuild)' != 'true'" DependsOnTargets="_DetectSdkLocations;_ComputeTargetArchitectures">
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<ItemGroup>
[msbuild] Fix xcframework support when used directly as native references (#10219) instead _indirectly_ thru a binding project. It got broken when I fixed the msbuild tests (to avoid re-building needlessly the project). Test case: https://github.com/spouliot/xcframework Also don't resolve when building binding projects - since it's not useful (as we already package the whole .xcframework)
2020-12-10 20:45:58 +03:00
<_XCFrameworkNativeReference Include="@(NativeReference -> '%(Identity)/.')" Condition="'%(Extension)' == '.xcframework'" />
<_FrameworkNativeReference Include="@(NativeReference -> '%(Identity)/%(Filename)')" Condition="'%(Extension)' == '.framework'" />
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
<_FileNativeReference Include="@(NativeReference)" Condition="'%(Extension)' != '.framework' And '%(Extension)' != '.xcframework'" />
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</ItemGroup>
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
<ResolveNativeReferences
SessionId="$(BuildSessionId)"
[msbuild] Fix xcframework support when used directly as native references (#10219) instead _indirectly_ thru a binding project. It got broken when I fixed the msbuild tests (to avoid re-building needlessly the project). Test case: https://github.com/spouliot/xcframework Also don't resolve when building binding projects - since it's not useful (as we already package the whole .xcframework)
2020-12-10 20:45:58 +03:00
Condition="'$(IsMacEnabled)' == 'true' And '$(IsBindingProject)' != 'true'"
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
Architectures="$(TargetArchitectures)"
[msbuild/tools] Augment the CreateBindingResourcePackage to support creating a zipped binding resource package. (#12868) Augment the CreateBindingResourcePackage to support creating a zipped binding resource package (which is just a zipped version of the binding resource package). This can either be manually chosen by the new 'Compressed' property, or automatically detected (create a zipped version when there's a symlink in the binding resource package). The default is to not create a zipped version in legacy Xamarin, and automatically detect for .NET. The problem this is trying to solve is when creating a NuGet package - NuGet doesn't handle symlinks correctly and it's not possible to create a NuGet with symlinks. Instead we need to create a zipfile with all the binding resources. The default has been chosen so that we automatically create a zip file when it's required for .NET, while still maintaining old behavior with legacy Xamarin.
2021-10-01 09:40:01 +03:00
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
[msbuild] Fix xcframework support when used directly as native references (#10219) instead _indirectly_ thru a binding project. It got broken when I fixed the msbuild tests (to avoid re-building needlessly the project). Test case: https://github.com/spouliot/xcframework Also don't resolve when building binding projects - since it's not useful (as we already package the whole .xcframework)
2020-12-10 20:45:58 +03:00
NativeReferences="@(_XCFrameworkNativeReference);@(_FrameworkNativeReference)"
[msbuild] Add support for `.xcframework` (#10046) This is done early so we can resolve the inner framework, inside the xcframework, and let the existing framework support do most of the work. The resolving code has unit tests. Custom projects for "NoEmbedding" exists for all supported platforms and executed by xharness. A sample `xcframework` with tests projects is also available [here](https://github.com/spouliot/xcframework). The xcframework test case is based on Rolf's earlier/partial implementation. https://github.com/rolfbjarne/xamarin-macios/commit/xcframework Things to note: Do not rename a framework (like XTest) to use it in an xcframework (like XCTest). That will fail at codesign but won't give anything useful. You might think signing the framework (instead of the inner binary) would solve it. It does, as it codesign, but then the app crash at startup. At some point you realize some symbols are still using XTest (not XCTest) and then you can delete several other weird workarounds (like for `ld`) because all of it was cause by this never identified rename. dSYM support (and tests) to be done in a separate PR.
2020-11-30 21:44:03 +03:00
References="@(ReferencePath)"
SdkIsSimulator="$(_SdkIsSimulator)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
<Output TaskParameter="NativeFrameworks" ItemName="_FrameworkNativeReference" />
</ResolveNativeReferences>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</Target>
<PropertyGroup>
[dotnet] Add support for 'dotnet pack'. Fixes #12631. (#12900) Add support for 'dotnet pack', by: 1. Add a workaround for the fact that as soon as a project has a 'NativeReference' item, .NET's MSBuild logic wants to include a 'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks, because we don't create such a file, so we work around it by removing the file in question from the corresponding item groups. 2. Add any binding resource packages to the NuGet. 3. Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
2021-10-04 08:43:55 +03:00
<BindingResourcePath>$(OutputPath)$(AssemblyName).resources</BindingResourcePath>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</PropertyGroup>
[msbuild] Don't execute the entire _CreateBindingResourcePackage if 'NoBindingEmbedding!=true'. (#13374) This fixes an issue where we'd create the stamp file even if 'NoBindingEmbedding' wasn't set. Also remove SkipBindingResourcePackage property, it doesn't show up anywhere else in our code base, nor in the history, nor anywhere relevant in Google.
2021-11-19 10:53:01 +03:00
<Target Name="_CreateBindingResourcePackage"
Condition="'$(DesignTimeBuild)' != 'true' And '$(NoBindingEmbedding)' == 'true'"
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
DependsOnTargets="_ExpandNativeReferences"
Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279) * Bump VSMac to 8.1.0.2742 to fix msbuild issues This is required to get the support for the msbuild `ToolsVersion` change from `15.0` to `Current`. * [tests][msbuild] Fix Binding resources test with updated msbuild Test failure with updated msbuild and vsmac 8.1: ``` Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True) Binding project build did not create package? Expected: True But was: False at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0 at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&) at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0 ``` The test builds the project multiple times. Before the 3rd build, the project file's timestamp is updated and expects that the binding package will be rebuilt. But it is not, because the target `_CreateBindingResourcePackage` doesn't depend on that project file. So, add that to the target inputs. * [nuget] Use xibuild to run nuget Fix errors seen during `nuget restore` for tests: ``` Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" ```
2019-06-19 08:07:27 +03:00
Inputs="$(MSBuildAllProjects);$(MSBuildProjectFullPath);@(ObjcBindingApiDefinition);@(ObjcBindingCoreSource);@(ReferencePath);@(ObjcBindingNativeLibrary);@(_FrameworkNativeReference);@(_FileNativeReference)"
[msbuild/tools] Augment the CreateBindingResourcePackage to support creating a zipped binding resource package. (#12868) Augment the CreateBindingResourcePackage to support creating a zipped binding resource package (which is just a zipped version of the binding resource package). This can either be manually chosen by the new 'Compressed' property, or automatically detected (create a zipped version when there's a symlink in the binding resource package). The default is to not create a zipped version in legacy Xamarin, and automatically detect for .NET. The problem this is trying to solve is when creating a NuGet package - NuGet doesn't handle symlinks correctly and it's not possible to create a NuGet with symlinks. Instead we need to create a zipfile with all the binding resources. The default has been chosen so that we automatically create a zip file when it's required for .NET, while still maintaining old behavior with legacy Xamarin.
2021-10-01 09:40:01 +03:00
Outputs="$(BindingResourcePath).stamp">
<!-- CompressBindingResourcePackage specifies whether the package should be compressed (zipped) or not
true: compressed (we produce an Assembly.resources directory)
false: not compressed (we produce an Assembly.resources.zip file)
auto: compressed if there are any symlinks
The default is 'false' for legacy Xamarin projects (for compatibility) and 'auto' for .NET projects (NuGet doesn't handle symlinks properly, so this way it's not necessary to set this property to create NuGets that work)
-->
<PropertyGroup Condition="'$(CompressBindingResourcePackage)' == ''">
<CompressBindingResourcePackage Condition="'$(UsingAppleNETSdk)' == 'true'">auto</CompressBindingResourcePackage>
<CompressBindingResourcePackage Condition="'$(UsingAppleNETSdk)' != 'true'">false</CompressBindingResourcePackage>
</PropertyGroup>
[msbuild] Don't execute the entire _CreateBindingResourcePackage if 'NoBindingEmbedding!=true'. (#13374) This fixes an issue where we'd create the stamp file even if 'NoBindingEmbedding' wasn't set. Also remove SkipBindingResourcePackage property, it doesn't show up anywhere else in our code base, nor in the history, nor anywhere relevant in Google.
2021-11-19 10:53:01 +03:00
<CreateBindingResourcePackage Condition="'$(IsMacEnabled)' == 'true'"
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
SessionId="$(BuildSessionId)"
NativeReferences="@(NativeReference)"
[msbuild/tools] Augment the CreateBindingResourcePackage to support creating a zipped binding resource package. (#12868) Augment the CreateBindingResourcePackage to support creating a zipped binding resource package (which is just a zipped version of the binding resource package). This can either be manually chosen by the new 'Compressed' property, or automatically detected (create a zipped version when there's a symlink in the binding resource package). The default is to not create a zipped version in legacy Xamarin, and automatically detect for .NET. The problem this is trying to solve is when creating a NuGet package - NuGet doesn't handle symlinks correctly and it's not possible to create a NuGet with symlinks. Instead we need to create a zipfile with all the binding resources. The default has been chosen so that we automatically create a zip file when it's required for .NET, while still maintaining old behavior with legacy Xamarin.
2021-10-01 09:40:01 +03:00
BindingResourcePath="$(BindingResourcePath)"
Compress="$(CompressBindingResourcePackage)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</CreateBindingResourcePackage>
[msbuild/tools] Augment the CreateBindingResourcePackage to support creating a zipped binding resource package. (#12868) Augment the CreateBindingResourcePackage to support creating a zipped binding resource package (which is just a zipped version of the binding resource package). This can either be manually chosen by the new 'Compressed' property, or automatically detected (create a zipped version when there's a symlink in the binding resource package). The default is to not create a zipped version in legacy Xamarin, and automatically detect for .NET. The problem this is trying to solve is when creating a NuGet package - NuGet doesn't handle symlinks correctly and it's not possible to create a NuGet with symlinks. Instead we need to create a zipfile with all the binding resources. The default has been chosen so that we automatically create a zip file when it's required for .NET, while still maintaining old behavior with legacy Xamarin.
2021-10-01 09:40:01 +03:00
[msbuild] Create the directory for the .stamp file for the _CreateBindingResourcePackage target before trying to create the .stamp file. (#13179)
2021-10-29 19:34:01 +03:00
<MakeDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="$([System.IO.Path]::GetDirectoryName($(BindingResourcePath)))"
/>
[msbuild/tools] Augment the CreateBindingResourcePackage to support creating a zipped binding resource package. (#12868) Augment the CreateBindingResourcePackage to support creating a zipped binding resource package (which is just a zipped version of the binding resource package). This can either be manually chosen by the new 'Compressed' property, or automatically detected (create a zipped version when there's a symlink in the binding resource package). The default is to not create a zipped version in legacy Xamarin, and automatically detect for .NET. The problem this is trying to solve is when creating a NuGet package - NuGet doesn't handle symlinks correctly and it's not possible to create a NuGet with symlinks. Instead we need to create a zipfile with all the binding resources. The default has been chosen so that we automatically create a zip file when it's required for .NET, while still maintaining old behavior with legacy Xamarin.
2021-10-01 09:40:01 +03:00
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AlwaysCreate="true"
Files="$(BindingResourcePath).stamp"
>
<Output TaskParameter="TouchedFiles" ItemName="FileWrites" />
</Touch>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</Target>
[dotnet] Add support for 'dotnet pack'. Fixes #12631. (#12900) Add support for 'dotnet pack', by: 1. Add a workaround for the fact that as soon as a project has a 'NativeReference' item, .NET's MSBuild logic wants to include a 'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks, because we don't create such a file, so we work around it by removing the file in question from the corresponding item groups. 2. Add any binding resource packages to the NuGet. 3. Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
2021-10-04 08:43:55 +03:00
<!--
Binding projects may include NativeReference items, which makes the 'pack' target want to include a Native.$(AssemblyName).manifest into the NuGet,
which obviously fails because we don't create such a file. So let's remove that file.
Ref: https://github.com/dotnet/msbuild/blob/3a1e456fe227f3e2b190b434578844c31e8bcb4a/src/Tasks/Microsoft.Common.CurrentVersion.targets#L6111-L6118
Ref: https://github.com/dotnet/msbuild/issues/4584
-->
<PropertyGroup>
<GenerateNuspecDependsOn>
$(GenerateNuspecDependsOn);
_RemoveNativeManifestFromPack;
</GenerateNuspecDependsOn>
</PropertyGroup>
<Target Name="_RemoveNativeManifestFromPack">
<ItemGroup>
<_BuildOutputInPackage Remove="@(_BuildOutputInPackage)" Condition="'%(Filename)%(Extension)' == '$(_DeploymentTargetApplicationManifestFileName)'" />
</ItemGroup>
</Target>
<!--
Add any binding resource packages to the nupkg
Ref: https://github.com/dotnet/sdk/issues/14042#issuecomment-716868311
Ref: https://github.com/NuGet/Home/issues/10063#issuecomment-713083004
Ref: https://github.com/xamarin/xamarin-android/blob/681887ebdbd192ce7ce1cd02221d4939599ba762/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.AndroidLibraries.targets#L86-L99
-->
<PropertyGroup>
<TargetsForTfmSpecificContentInPackage>$(TargetsForTfmSpecificContentInPackage);_IncludeBindingResourcesInNuGetPackage</TargetsForTfmSpecificContentInPackage>
</PropertyGroup>
<Target Name="_IncludeBindingResourcesInNuGetPackage"
Condition="'$(IsMacEnabled)' == 'true' And '$(IncludeBuildOutput)' != 'false'"
>
<PropertyGroup>
<_HasOldStyleBindingItems Condition="@(ObjcBindingNativeLibrary->Count()) > 0">true</_HasOldStyleBindingItems>
</PropertyGroup>
<Error Condition="'$(_HasOldStyleBindingItems)' == 'true'" Text="Creating a NuGet package is not supported for projects that have ObjcBindingNativeLibrary items. Migrate to use NativeReference items instead." />
<!-- Figure out where to place the binding resources (see references above for more info) -->
<GetNuGetShortFolderName
TargetFrameworkMoniker="$(TargetFrameworkMoniker)"
TargetPlatformMoniker="$(TargetPlatformMoniker)">
<Output TaskParameter="NuGetShortFolderName" PropertyName="_NuGetShortFolderName" />
</GetNuGetShortFolderName>
<!-- The binding project may either produce a 'MyBindingProject.resources' directory, or a compressed 'MyBindingProject.resources.zip' version -->
<PropertyGroup>
<_AppleBindingResourceBasePath>$(TargetDir)$(TargetName).resources</_AppleBindingResourceBasePath>
</PropertyGroup>
<ItemGroup>
<!-- Add all the files that might exist in any binding resource packages -->
<_AppleBindingResource Include="$(_AppleBindingResourceBasePath)\**\*" PackagePath="lib\$(_NuGetShortFolderName)\$(TargetName).resources" />
<!-- Add any compressed files that might exist as well -->
<_AppleBindingResource Include="$(_AppleBindingResourceBasePath).zip" PackagePath="lib\$(_NuGetShortFolderName)" Condition="Exists('$(_AppleBindingResourceBasePath).zip')" />
</ItemGroup>
<!-- Add what we found to the NuGet -->
<ItemGroup>
<TfmSpecificPackageFile Include="@(_AppleBindingResource)" />
</ItemGroup>
</Target>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<!-- Cleaning via FileWrites leaves empty framework directories on disk, so nuke via RemoveDir -->
<PropertyGroup>
<CleanDependsOn>
$(CleanDependsOn);
[msbuild] Share several cleaning targets between Xamarin.iOS and Xamarin.Mac. (#11898) The iOS version of the cleaning tasks were much more comprehensive, so those won out when there were any differences. This also required moving the GetDirectoriesTask to shared code.
2021-06-11 17:39:44 +03:00
_CleanAppBundle;
_CleanBindingResourcePackage;
_CleanDebugSymbols;
_CleanDeviceSpecificOutput;
_CleanIntermediateToolOutput;
_CleanITunesArtwork;
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
</CleanDependsOn>
</PropertyGroup>
[msbuild] Share several cleaning targets between Xamarin.iOS and Xamarin.Mac. (#11898) The iOS version of the cleaning tasks were much more comprehensive, so those won out when there were any differences. This also required moving the GetDirectoriesTask to shared code.
2021-06-11 17:39:44 +03:00
<Target Name="_CleanAppBundle" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="_GenerateBundleName">
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(_AppBundlePath)" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)bundler.stamp" />
</Target>
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<Target Name="_CleanBindingResourcePackage">
<RemoveDir Directories="$(BindingResourcePath);" />
</Target>
[msbuild] Share several cleaning targets between Xamarin.iOS and Xamarin.Mac. (#11898) The iOS version of the cleaning tasks were much more comprehensive, so those won out when there were any differences. This also required moving the GetDirectoriesTask to shared code.
2021-06-11 17:39:44 +03:00
<Target Name="_CleanDebugSymbols" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="_GenerateBundleName">
<GetDirectories SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Path="$(DeviceSpecificOutputPath)" Pattern="*.dSYM">
<Output TaskParameter="Directories" ItemName="_DebugSymbolDir" />
</GetDirectories>
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(AppBundleDir).mSYM;@(_DebugSymbolDir)" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(IsAppExtension)' == 'false'" Files="$(DeviceSpecificOutputPath)*.bcsymbolmap" />
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
<Delete SessionId="$(BuildSessionId)" Condition="(('$(IsMacEnabled)' == 'true' And '$(IsAppExtension)' == 'true') Or '$(_PlatformName)' == 'macOS')" Files="$(DeviceSpecificOutputPath)dsym.items" />
[msbuild] Share several cleaning targets between Xamarin.iOS and Xamarin.Mac. (#11898) The iOS version of the cleaning tasks were much more comprehensive, so those won out when there were any differences. This also required moving the GetDirectoriesTask to shared code.
2021-06-11 17:39:44 +03:00
</Target>
<Target Name="_CleanITunesArtwork" Condition="'$(_CanArchive)' == 'true'" DependsOnTargets="_ComputeTargetArchitectures">
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)iTunesMetadata.plist;$(DeviceSpecificOutputPath)iTunesArtwork@2x;$(DeviceSpecificOutputPath)iTunesArtwork" />
</Target>
<Target Name="_CleanDeviceSpecificOutput" Condition="'$(_CanOutputAppBundle)' == 'true'">
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(IntermediateOutputPath)device-builds;$(OutputPath)device-builds" />
</Target>
<Target Name="_CleanIntermediateToolOutput" DependsOnTargets="_ComputeTargetArchitectures">
<RemoveDir SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="$(DeviceSpecificIntermediateOutputPath)actool;
$(DeviceSpecificIntermediateOutputPath)assetpacks;
$(DeviceSpecificIntermediateOutputPath)codesign;
$(DeviceSpecificIntermediateOutputPath)coremlc;
$(DeviceSpecificIntermediateOutputPath)ibtool;
$(DeviceSpecificIntermediateOutputPath)ibtool-link;
$(DeviceSpecificIntermediateOutputPath)ibtool-manifests;
$(DeviceSpecificIntermediateOutputPath)ipa;
$(DeviceSpecificIntermediateOutputPath)metal;
$(DeviceSpecificIntermediateOutputPath)optimized;
$(DeviceSpecificIntermediateOutputPath)scntool;
$(DeviceSpecificIntermediateOutputPath)TextureAtlas;
$(DeviceSpecificIntermediateOutputPath)mtouch-cache;
$(DeviceSpecificIntermediateOutputPath)" />
<ItemGroup>
<_IpaPackageFile Include="$(DeviceSpecificOutputPath)*.ipa" />
</ItemGroup>
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(IsAppExtension)' == 'true'" Files="$(DeviceSpecificOutputPath)codesign.items" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="@(_IpaPackageFile)" />
</Target>
[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
<Target Name="_AddExtraReferences" BeforeTargets="ResolveAssemblyReferences" Condition="'$(DisableExtraReferences)' != 'true' And '$(UsingAppleNETSdk)' != 'true'">
[msbuild] add System.Drawing.Common ref for bindings (#8528) Fixes: https://github.com/xamarin/xamarin-macios/issues/8265 Usage of `System.Drawing` types in iOS binding projects are failing with: error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'. This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' Consider adding a reference to that assembly. In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS and Mac projects, but mistakenly missing from binding projects. I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`, so it will be used for all project types. I also updated a test, I could merely use `System.Drawing.Color` in `StructsAndEnums.cs` to reproduce the failure.
2020-05-07 23:27:06 +03:00
<ItemGroup>
<!-- https://github.com/mono/mono/issues/13483 -->
<Reference Include="System.Drawing.Common.dll" />
</ItemGroup>
</Target>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<PropertyGroup>
[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
<_CollectBundleResourcesDependsOn>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
$(_CollectBundleResourcesDependsOn);
_ComputeTargetArchitectures;
</_CollectBundleResourcesDependsOn>
<_CollectBundleResourcesDependsOn Condition="'$(IsBindingProject)' != 'true'">
$(_CollectBundleResourcesDependsOn);
[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
_CompileImageAssets;
_CompileInterfaceDefinitions;
_CompileSceneKitAssets;
_CompileColladaAssets;
_CompileTextureAtlases;
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
_CompileCoreMLModels;
[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
</_CollectBundleResourcesDependsOn>
</PropertyGroup>
<Target Name="_CollectBundleResources" DependsOnTargets="$(_CollectBundleResourcesDependsOn)">
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<ReadItemsFromFile File="$(_ProcessedBundleResourcesPath)" Condition="Exists('$(_ProcessedBundleResourcesPath)')">
<Output TaskParameter="Items" ItemName="_ProcessedBundleResources" />
</ReadItemsFromFile>
<ReadItemsFromFile File="$(_ProcessedContentPath)" Condition="Exists('$(_ProcessedContentPath)')">
<Output TaskParameter="Items" ItemName="_ProcessedContent" />
</ReadItemsFromFile>
<ItemGroup>
<BundleResource Remove="@(_ProcessedBundleResources)" />
<Content Remove="@(_ProcessedContent)" />
</ItemGroup>
[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
<CollectBundleResources
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
OptimizePropertyLists="$(OptimizePropertyLists)"
OptimizePNGs="$(OptimizePNGs)"
BundleResources="@(Content);@(BundleResource)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
>
<Output TaskParameter="BundleResourcesWithLogicalNames" ItemName="_BundleResourceWithLogicalName" />
</CollectBundleResources>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(BundleResource)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="BundleResource" File="$(_ProcessedBundleResourcesPath)" Overwrite="true" IncludeMetadata="false" />
<WriteItemsToFile Items="@(Content)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="Content" File="$(_ProcessedContentPath)" Overwrite="true" IncludeMetadata="false" />
<ItemGroup>
<FileWrites Include="$(_ProcessedBundleResourcesPath)" />
<FileWrites Include="$(_ProcessedContentPath)" />
</ItemGroup>
[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
</Target>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<!--
The process to create the final app manifest (aka Info.plist) is a bit convoluted.
1. The user can specify values in multiple ways:
* An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target.
[msbuild] Add a public target/property to make customers able to add to the PartialAppManifest item group in their own targets. Fixes #12336. (#12645) Also add a test. Fixes https://github.com/xamarin/xamarin-macios/issues/12336 (for the second time).
2021-09-08 10:16:57 +03:00
* A partial plist in their project (using the `PartialAppManifest` item group). Developers can add targets to the public CollectAppManifestsDependsOn
property to run targets that add to the `PartialAppManifest` item group before we process them.
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
* Some MSBuild properties can also add values.
The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file.
3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private)
4. We run some other tasks, that depend on the values from `ReadAppManifest`, and adds more entries that should be in the final app manifest. These are written to partial plists, and added to the _PostCompilePartialAppManifest item group.
* _CompileImageAssets
* _CompileCoreMLModels
5. In the `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist.
-->
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
<PropertyGroup>
<_CompileAppManifestDependsOn>
[msbuild] Add a public target/property to make customers able to add to the PartialAppManifest item group in their own targets. Fixes #12336. (#12645) Also add a test. Fixes https://github.com/xamarin/xamarin-macios/issues/12336 (for the second time).
2021-09-08 10:16:57 +03:00
CollectAppManifests;
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
$(_CompileAppManifestDependsOn);
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
_DetectAppManifest;
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
_DetectSdkLocations;
_GenerateBundleName;
_ComputeTargetFrameworkMoniker;
[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
_ComputeTargetArchitectures;
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
</_CompileAppManifestDependsOn>
</PropertyGroup>
[msbuild] Add a public target/property to make customers able to add to the PartialAppManifest item group in their own targets. Fixes #12336. (#12645) Also add a test. Fixes https://github.com/xamarin/xamarin-macios/issues/12336 (for the second time).
2021-09-08 10:16:57 +03:00
<!-- This is a public target that collects all the (partial) app manifests. The recommended way to make sure all
the desired entries are added to PartialAppManifest is to add the target that adds to PartialAppManifest
to the CollectAppManifestsDependsOn property. -->
<Target Name="CollectAppManifests" DependsOnTargets="$(CollectAppManifestsDependsOn)" />
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<!-- This target has no inputs, because it must still be run if there are no input app manifests, to set default values -->
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
<Target Name="_CompileAppManifest"
DependsOnTargets="$(_CompileAppManifestDependsOn)"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
Outputs="$(_TemporaryAppManifest)"
>
[msbuild/dotnet] Include font files by default in .NET apps, and implement a way to automatically register them. Fixes #12536. (#12752) * Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource items (if these files are found within the Resources/ subdirectory). * Add support for a 'RegisterFont' metadata on BundleResource items, where if set to 'true', we'll register the font file in the Info.plist as required by the target platform. * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
2021-09-17 11:18:09 +03:00
<ItemGroup>
<_FontFilesToRegister Include="@(BundleResource)" Condition="'%(BundleResource.RegisterFont)' == 'true'" />
</ItemGroup>
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
<CompileAppManifest
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
ApplicationId="$(ApplicationId)"
[dotnet] Add support for some of the single-project MSBuild properties. (#10545) * [tests] Add test case for single-project properties in .NET. * [msbuild] Add support for the single-project ApplicationId MSBuild property. * [msbuild] Add support for the single-project ApplicationTitle, ApplicationVersion and AppleShortVersion MSBuild properties. * [dotnet] Enable the single-project MSBuild properties by default. * [dotnet] Add a short doc about single project properties. * [tests] Fix the GeneratePlistTaskTests.BundleIdentifier test according to bundle identifier changes. This test asserts that the CFBundleIdentifier value in the Info.plist isn't overwritten, and does so by calling the CompileAppManifest task, giving it a different value for the bundle identifier than what's in the Info.plist. The behavior change is that now we do things in the following manner: DetectSigningIdentityTask will read the Info.plist, compute a bundle identifier (which will be the value from the Info.plist if it's there), and returns it to the MSBuild code. Eventually that value will be passed to the CompileAppManifestTask, which will write it to the Info.plist. However, this test doesn't run the DetectSigningIdentityTask, which means that the initial value for the bundle identifier doesn't come from the Info.plist.
2021-01-29 19:37:37 +03:00
ApplicationTitle="$(ApplicationTitle)"
ApplicationVersion="$(ApplicationVersion)"
[dotnet] rename $(AppleShortVersion) to $(ApplicationDisplayVersion) (#12647) Context: https://github.com/dotnet/maui/issues/1662 Context: https://github.com/xamarin/xamarin-android/pull/6139 Previously: * `$(ApplicationVersion)` mapped to `CFBundleVersion` * `$(AppleShortVersion)` mapped to `CFBundleShortVersionString` To be able to leverage identical property names on iOS/Android, we're changing this to: * `$(ApplicationVersion)` maps to `CFBundleVersion` * `$(ApplicationDisplayVersion)` maps to `CFBundleShortVersionString` Lastly, let's allow `$(ApplicationDisplayVersion)` to set `$(Version)`, so the various C# assembly-level attributes are all set to the same value.
2021-09-08 17:13:29 +03:00
ApplicationDisplayVersion="$(ApplicationDisplayVersion)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
AppBundleName="$(_AppBundleName)"
AppManifest="$(_AppManifest)"
AssemblyName="$(AssemblyName)"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
CompiledAppManifest="$(_TemporaryAppManifest)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
Debug="$(_BundlerDebug)"
DefaultSdkVersion="$(_SdkVersion)"
[msbuild/dotnet] Include font files by default in .NET apps, and implement a way to automatically register them. Fixes #12536. (#12752) * Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource items (if these files are found within the Resources/ subdirectory). * Add support for a 'RegisterFont' metadata on BundleResource items, where if set to 'true', we'll register the font file in the Info.plist as required by the target platform. * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
2021-09-17 11:18:09 +03:00
FontFilesToRegister="@(_FontFilesToRegister)"
[dotnet] Add support for some of the single-project MSBuild properties. (#10545) * [tests] Add test case for single-project properties in .NET. * [msbuild] Add support for the single-project ApplicationId MSBuild property. * [msbuild] Add support for the single-project ApplicationTitle, ApplicationVersion and AppleShortVersion MSBuild properties. * [dotnet] Enable the single-project MSBuild properties by default. * [dotnet] Add a short doc about single project properties. * [tests] Fix the GeneratePlistTaskTests.BundleIdentifier test according to bundle identifier changes. This test asserts that the CFBundleIdentifier value in the Info.plist isn't overwritten, and does so by calling the CompileAppManifest task, giving it a different value for the bundle identifier than what's in the Info.plist. The behavior change is that now we do things in the following manner: DetectSigningIdentityTask will read the Info.plist, compute a bundle identifier (which will be the value from the Info.plist if it's there), and returns it to the MSBuild code. Eventually that value will be passed to the CompileAppManifestTask, which will write it to the Info.plist. However, this test doesn't run the DetectSigningIdentityTask, which means that the initial value for the bundle identifier doesn't come from the Info.plist.
2021-01-29 19:37:37 +03:00
GenerateApplicationManifest="$(GenerateApplicationManifest)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
IsAppExtension="$(IsAppExtension)"
IsWatchApp="$(IsWatchApp)"
IsWatchExtension="$(IsWatchExtension)"
IsXPCService="$(IsXPCService)"
[msbuild] Promote '_PartialAppManifest' to a public item group ('PartialAppManifest'). Fixes #10646. (#12417) * A couple of other changes to make sure we never overwrite the PartialAppManifest item group (as opposed to adding to it). * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/10646.
2021-08-12 16:03:11 +03:00
PartialAppManifests="@(PartialAppManifest)"
[msbuild/dotnet] Include font files by default in .NET apps, and implement a way to automatically register them. Fixes #12536. (#12752) * Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource items (if these files are found within the Resources/ subdirectory). * Add support for a 'RegisterFont' metadata on BundleResource items, where if set to 'true', we'll register the font file in the Info.plist as required by the target platform. * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
2021-09-17 11:18:09 +03:00
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
ResourceRules="$(_PreparedResourceRules)"
TargetArchitectures="$(TargetArchitectures)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
SdkPlatform="$(_SdkPlatform)"
SdkIsSimulator="$(_SdkIsSimulator)"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
SdkVersion="$(_SdkVersion)"
[dotnet] Support SupportedOSPlatformVersion. Fixes #12336. (#12638) * Add support for the SupportedOSPlatformVersion MSBuild property, and write it to the Info.plist for the corresponding minimum OS version. * If there are any minimum OS version in the Info.plist, we'll now show an error if it doesn't match SupportedOSPlatformVersion. This unfortunately means that if there's any minimum OS version in any Info.plist, then that will most likely have to be moved to the SupportedOSPlatformVersion property (or removed entirely if that's the right choice), since it's unlikely to match the default value for SupportedOSPlatformVersion. However, this was deemed to be the best option for the future (it's a one-time pain during migration). Also add new tests, update existing tests, and update the templates. Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
2021-09-08 10:20:05 +03:00
SupportedOSPlatformVersion="$(SupportedOSPlatformVersion)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
DebugIPAddresses="$(_DebugIPAddresses)"
[msbuild] Only validate the Info.plist values if we're actually creating an app manifest.
2021-08-23 18:40:55 +03:00
Validate="$(_CreateAppManifest)"
[msbuild] Unify the CompileAppManifest target. (#8875) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: CompileAppManifestTaskBase └─── iOS/CompileAppManifestTaskCore │ └─── iOS/CompileAppManifest └─── Mac/CompileAppManifestTaskCore │ └─── Mac/CompileAppManifest
2020-06-18 16:46:45 +03:00
>
</CompileAppManifest>
</Target>
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
<PropertyGroup>
<_ReadAppManifestDependsOn>
$(_ReadAppManifestDependsOn);
_DetectAppManifest;
_DetectSdkLocations;
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
_CompileAppManifest;
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
_ComputeTargetFrameworkMoniker;
</_ReadAppManifestDependsOn>
</PropertyGroup>
<Target Name="_ReadAppManifest" DependsOnTargets="$(_ReadAppManifestDependsOn)">
<ReadAppManifest
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
AppManifest="$(_TemporaryAppManifest)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
SdkVersion="$(_SdkVersion)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="CFBundleExecutable" PropertyName="_ExecutableName" />
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
<Output TaskParameter="CFBundleDisplayName" PropertyName="_CFBundleDisplayName" />
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="CFBundleIdentifier" PropertyName="_BundleIdentifier" />
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
<Output TaskParameter="CFBundleVersion" PropertyName="_CFBundleVersion" />
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="CLKComplicationGroup" PropertyName="_CLKComplicationGroup" />
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
<Output TaskParameter="MinimumOSVersion" PropertyName="_MinimumOSVersion" />
<Output TaskParameter="NSExtensionPointIdentifier" PropertyName="_NSExtensionPointIdentifier" />
<Output TaskParameter="UIDeviceFamily" PropertyName="_UIDeviceFamily" />
<Output TaskParameter="WKWatchKitApp" PropertyName="_WKWatchKitApp" />
<Output TaskParameter="XSAppIconAssets" PropertyName="_XSAppIconAssets" />
<Output TaskParameter="XSLaunchImageAssets" PropertyName="_XSLaunchImageAssets" />
</ReadAppManifest>
</Target>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<PropertyGroup>
<_WriteAppManifestDependsOn>
_CompileAppManifest;
_CompileImageAssets;
_CompileCoreMLModels;
</_WriteAppManifestDependsOn>
</PropertyGroup>
<!-- This target will create the $(_AppBundleManifest) file - any task that takes $(_AppBundleManifest) must depend on this target -->
<Target Name="_WriteAppManifest"
Condition="'$(_CreateAppManifest)' == 'true'"
DependsOnTargets="$(_WriteAppManifestDependsOn)"
Inputs="@(_PostCompilePartialAppManifest);$(_TemporaryAppManifest)"
Outputs="$(_AppBundleManifest)"
>
<WriteAppManifest
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleManifest="$(_AppBundleManifest)"
AppManifests="@(_PostCompilePartialAppManifest);$(_TemporaryAppManifest)"
>
</WriteAppManifest>
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(AppBundleDir).dSYM" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)*.bcsymbolmap" />
</Target>
[msbuild] Share the _CompileEntitlements target. (#9323) Use two separate output variables (EntitlementsInExecutable/EntitlementsInSignature) instead of using the same output variable for two different purposes. This makes the code more self-explanatory. Also move the simulator check to the C# code, that way it's easier to re-use elsewhere. * [msbuild] Share the _CompileEntitlements task. * [msbuild] Create the same class hierarchy for Xamarin.Mac and Xamarin.iOS for the CompileEntitlements task. CompileEntitlementsTaskBase └─── iOS/CompileEntitlementsTaskCore │ └─── iOS/CompileEntitlements └─── Mac/CompileEntitlementsTaskCore └─── Mac/CompileEntitlements This also means we can remove a known failure in the list of MSBuild tasks that don't conform to our 'no code in final task implementation' requirements.
2020-08-10 14:55:54 +03:00
<PropertyGroup>
<_CompileEntitlementsDependsOn>
$(_CompileEntitlementsDependsOn);
_DetectSdkLocations;
_GenerateBundleName;
_DetectSigningIdentity;
_ComputeTargetFrameworkMoniker;
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
_ReadAppManifest;
[msbuild] Share the _CompileEntitlements target. (#9323) Use two separate output variables (EntitlementsInExecutable/EntitlementsInSignature) instead of using the same output variable for two different purposes. This makes the code more self-explanatory. Also move the simulator check to the C# code, that way it's easier to re-use elsewhere. * [msbuild] Share the _CompileEntitlements task. * [msbuild] Create the same class hierarchy for Xamarin.Mac and Xamarin.iOS for the CompileEntitlements task. CompileEntitlementsTaskBase └─── iOS/CompileEntitlementsTaskCore │ └─── iOS/CompileEntitlements └─── Mac/CompileEntitlementsTaskCore └─── Mac/CompileEntitlements This also means we can remove a known failure in the list of MSBuild tasks that don't conform to our 'no code in final task implementation' requirements.
2020-08-10 14:55:54 +03:00
</_CompileEntitlementsDependsOn>
</PropertyGroup>
<Target Name="_CompileEntitlements"
Condition="'$(_RequireCodeSigning)' == 'true' Or ('$(CodesignEntitlements)' != '' And '$(_PlatformName)' != 'macOS')"
DependsOnTargets="$(_CompileEntitlementsDependsOn)"
Outputs="$(DeviceSpecificIntermediateOutputPath)Entitlements.xcent">
<CompileEntitlements
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(AppBundleDir)"
AppIdentifier="$(_AppIdentifier)"
BundleIdentifier="$(_BundleIdentifier)"
Entitlements="$(CodesignEntitlements)"
CompiledEntitlements="$(DeviceSpecificIntermediateOutputPath)Entitlements.xcent"
IsAppExtension="$(IsAppExtension)"
ProvisioningProfile="$(_ProvisioningProfile)"
SdkIsSimulator="$(_SdkIsSimulator)"
SdkPlatform="$(_SdkPlatform)"
SdkVersion="$(_SdkVersion)"
SdkDevPath="$(_SdkDevPath)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
Debug="$(_BundlerDebug)"
>
<!-- $(_CompiledEntitlements) will be passed to the MTouch task, it's used to embed the entitlements in the executable -->
<Output TaskParameter="EntitlementsInExecutable" PropertyName="_CompiledEntitlements" />
<!-- $(_CompiledCodesignEntitlements) will be used only with Codesign tasks when building for device. MUST NOT BE SET for iOS Simulator builds. -->
<Output TaskParameter="EntitlementsInSignature" PropertyName="_CompiledCodesignEntitlements" />
</CompileEntitlements>
</Target>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Compilation of InterfaceDefinition assets (*.xib, *.storyboard) -->
<PropertyGroup>
<_CompileInterfaceDefinitionsDependsOn>
$(_CompileInterfaceDefinitionsDependsOn);
_DetectAppManifest;
_DetectSdkLocations;
_ComputeTargetArchitectures;
_RemoveProcessedInterfaceDefinitions;
_BeforeCoreCompileInterfaceDefinitions;
_ReadCoreCompileInterfaceDefinitions;
_CoreCompileInterfaceDefinitions;
</_CompileInterfaceDefinitionsDependsOn>
</PropertyGroup>
<Target Name="_CompileInterfaceDefinitions" DependsOnTargets="$(_CompileInterfaceDefinitionsDependsOn)" />
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedInterfaceDefinitions" Condition="Exists('$(_ProcessedInterfaceDefinitionsPath)')">
<ReadItemsFromFile File="$(_ProcessedInterfaceDefinitionsPath)">
<Output TaskParameter="Items" ItemName="_ProcessedInterfaceDefinitions" />
</ReadItemsFromFile>
<ItemGroup>
<InterfaceDefinition Remove="@(_ProcessedInterfaceDefinitions)" />
</ItemGroup>
</Target>
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
<Target Name="_BeforeCoreCompileInterfaceDefinitions"
Inputs="@(InterfaceDefinition)"
Outputs="$(_IBToolCache)">
<!-- If any InterfaceDefinition is newer than the generated items list, we delete them so that the _CoreCompileInterfaceDefinitions
target runs again and updates those lists for the next run
-->
<Delete Files="$(_IBToolCache)" />
</Target>
<Target Name="_ReadCoreCompileInterfaceDefinitions" DependsOnTargets="_BeforeCoreCompileInterfaceDefinitions">
<!-- If _BeforeCoreCompileInterfaceDefinitions did not delete the generated items lists from _CoreCompileInterfaceDefinitions, then we read them
since that target won't run and we need to the output items that are cached in those files which includes full metadata -->
<ReadItemsFromFile File="$(_IBToolCache)" Condition="Exists('$(_IBToolCache)')">
<Output TaskParameter="Items" ItemName="_BundleResourceWithLogicalName" />
</ReadItemsFromFile>
</Target>
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
<PropertyGroup>
<_CoreCompileInterfaceDefinitionsDependsOn>
_BeforeCoreCompileInterfaceDefinitions;
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
_ReadAppManifest;
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
_DetectSigningIdentity;
_ComputeTargetFrameworkMoniker;
</_CoreCompileInterfaceDefinitionsDependsOn>
</PropertyGroup>
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
<Target Name="_CoreCompileInterfaceDefinitions"
Inputs="@(InterfaceDefinition)"
Outputs="$(_IBToolCache)"
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
DependsOnTargets="$(_CoreCompileInterfaceDefinitionsDependsOn)">
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
<IBTool
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(IBToolExe)"
ToolPath="$(IBToolPath)"
[msbuild] Add a BundleIdentifier property to the XcodeCompilerToolTask. (#10480) * [msbuild] Add a BundleIdentifier property to the XcodeCompilerToolTask. This way we don't have to read the Info.plist to get the bundle identifier, which will be a problem in the future, because the Info.plist might not have the actual bundle identifier we end up using. Instead rely on the _BundleIdentifier MSBuild property, which will contain the final bundle identifier. * [msbuild] Make sure we have a bundle identifier when calling ACTool. * [msbuild] Make sure we have a bundle identifier when calling IBTool if one is needed. At the same time make the BundleIdentifier not required, because IBTool may run for library projects, which doesn't have a bundle identifier. * [msbuild] _DetectSigningIdentity needs to know the bundle name. * [msbuild] It shouldn't be necessary to detect the signing identity to compute the bundle name.
2021-01-28 09:54:06 +03:00
BundleIdentifier="$(_BundleIdentifier)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
CLKComplicationGroup="$(_CLKComplicationGroup)"
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
EnableOnDemandResources="$(EnableOnDemandResources)"
InterfaceDefinitions="@(InterfaceDefinition)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
MinimumOSVersion="$(_MinimumOSVersion)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
NSExtensionPointIdentifier="$(_NSExtensionPointIdentifier)"
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
IsWatchApp="$(IsWatchApp)"
IsWatch2App="$(IsWatch2App)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
SdkDevPath="$(_SdkDevPath)"
SdkBinPath="$(_SdkBinPath)"
SdkUsrPath="$(_SdkUsrPath)"
SdkRoot="$(_SdkRoot)"
SdkPlatform="$(_SdkPlatform)"
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
SdkVersion="$(_SdkVersion)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
UIDeviceFamily="$(_UIDeviceFamily)"
WKWatchKitApp="$(_WKWatchKitApp)"
XSAppIconAssets="$(_XSAppIconAssets)"
XSLaunchImageAssets="$(_XSLaunchImageAssets)"
[msbuild] Unify the iOS and macOS versions of the IBTool task. (#12424) * Have a single implementation of AutoActivateCustomFonts. * Share the GetTargetDevices implementations between ACTool and IBTool, after removing a condition for Xcode 6.0 (which we don't support anymore, so that check could be removed) the implementations were identical.
2021-08-16 11:54:28 +03:00
>
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
<!-- Local items to be persisted to items files -->
<Output TaskParameter="BundleResources" ItemName="_IBTool_BundleResources" />
</IBTool>
<!-- Cached the generated outputs items for incremental build support -->
<WriteItemsToFile Items="@(_IBTool_BundleResources)" ItemName="_BundleResourceWithLogicalName" File="$(_IBToolCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(InterfaceDefinition)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="InterfaceDefinition" File="$(_ProcessedInterfaceDefinitionsPath)" Overwrite="true" IncludeMetadata="false" />
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
<ItemGroup>
<FileWrites Include="$(_IBToolCache)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<FileWrites Include="$(_ProcessedInterfaceDefinitionsPath)" />
[msbuild] Share the _*CompileInterfaceDefinitions targets between Xamarin.iOS and Xamarin.Mac. (#9708) The Xamarin.iOS version seemed more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac. A few differences in the Xamarin.iOS versions are: * The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs (important for incremental builds). * EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded to 'false' (there is no real difference right now, because $(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS)
2020-09-28 10:17:50 +03:00
</ItemGroup>
</Target>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Compilation of ImageAsset items -->
<PropertyGroup>
<_CompileImageAssetsDependsOn>
$(_CompileImageAssetsDependsOn);
_DetectAppManifest;
_DetectSdkLocations;
_ComputeTargetArchitectures;
_RemoveProcessedImageAssets;
_BeforeCoreCompileImageAssets;
_ReadCompileImageAssets;
_CoreCompileImageAssets;
</_CompileImageAssetsDependsOn>
</PropertyGroup>
<Target Name="_CompileImageAssets" DependsOnTargets="$(_CompileImageAssetsDependsOn)" />
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedImageAssets" Condition="Exists('$(_ProcessedImageAssetsPath)')">
<ReadItemsFromFile File="$(_ProcessedImageAssetsPath)">
<Output TaskParameter="Items" ItemName="_ProcessedImageAssets" />
</ReadItemsFromFile>
<ItemGroup>
<ImageAsset Remove="@(_ProcessedImageAssets)" />
</ItemGroup>
</Target>
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<Target Name="_BeforeCoreCompileImageAssets"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
Inputs="@(ImageAsset);$(_TemporaryAppManifest)"
Outputs="$(_ACTool_PartialAppManifestCache);$(_ACTool_BundleResourceCache)"
DependsOnTargets="_ReadAppManifest"
>
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<!-- If any ImageAsset or AppManifest is newer than the generated items list, we delete them so that the _CoreCompileImageAssets
target runs again and updates those lists for the next run
-->
<Delete Files="$(_ACTool_PartialAppManifestCache);$(_ACTool_BundleResourceCache)" />
<RemoveDir Directories="$(DeviceSpecificIntermediateOutputPath)actool" />
</Target>
<Target Name="_ReadCompileImageAssets"
DependsOnTargets="_BeforeCoreCompileImageAssets">
<!-- If _BeforeCoreCompileImageAssets did not delete the generated items lists from _CoreCompileImageAsset, then we read them
since that target won't run and we need the output items that are cached in those files, which includes full metadata -->
<ReadItemsFromFile File="$(_ACTool_PartialAppManifestCache)" Condition="Exists('$(_ACTool_PartialAppManifestCache)')">
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="Items" ItemName="_PostCompilePartialAppManifest" />
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
</ReadItemsFromFile>
<ReadItemsFromFile File="$(_ACTool_BundleResourceCache)" Condition="Exists('$(_ACTool_BundleResourceCache)')">
<Output TaskParameter="Items" ItemName="_BundleResourceWithLogicalName" />
</ReadItemsFromFile>
</Target>
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
<PropertyGroup>
<_CoreCompileImageAssetsDependsOn>
$(_CoreCompileImageAssets);
_ReadAppManifest;
_DetectSdkLocations;
_BeforeCoreCompileImageAssets;
_DetectSigningIdentity;
_ComputeTargetFrameworkMoniker;
</_CoreCompileImageAssetsDependsOn>
</PropertyGroup>
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<Target Name="_CoreCompileImageAssets"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
Inputs="@(ImageAsset);$(_TemporaryAppManifest)"
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
Outputs="$(_ACTool_PartialAppManifestCache);$(_ACTool_BundleResourceCache)"
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
DependsOnTargets="$(_CoreCompileImageAssetsDependsOn)">
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<ACTool
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '@(ImageAsset)' != ''"
ToolExe="$(ACToolExe)"
ToolPath="$(ACToolPath)"
BundleIdentifier="$(_BundleIdentifier)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
CLKComplicationGroup="$(_CLKComplicationGroup)"
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
DeviceModel="$(TargetDeviceModel)"
DeviceOSVersion="$(TargetDeviceOSVersion)"
EnableOnDemandResources="$(EnableOnDemandResources)"
ImageAssets="@(ImageAsset)"
MinimumOSVersion="$(_MinimumOSVersion)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
NSExtensionPointIdentifier="$(_NSExtensionPointIdentifier)"
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
OptimizePNGs="$(OptimizePNGs)"
OutputPath="$(DeviceSpecificOutputPath)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
IsWatchApp="$(IsWatchApp)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
SdkDevPath="$(_SdkDevPath)"
SdkBinPath="$(_SdkBinPath)"
SdkUsrPath="$(_SdkUsrPath)"
SdkPlatform="$(_SdkPlatform)"
[msbuild] Unify the iOS and macOS version of ACToolTaskBase. (#10810) * [msbuild] Unify the iOS and macOS version of ACToolTaskBase. * The ACTool task now needs the target framework moniker.
2021-03-09 19:45:49 +03:00
SdkVersion="$(_SdkVersion)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
[msbuild] Rename the GetMinimumOSVersion task to ReadAppManifest and make it read more properties from the app manifest. (#12485) * Read CFBundleDisplayName and CFBundleVersion and use them in the _CompileITunesMetadata task. * Read numerous other app manifest values and pass them to the ACTool and IBTool tasks. This makes it possible to not parse the Info.plist in these tasks, which will become more complicated in the future, when we might either not have an Info.plist, or have many partial ones. Also enable nullability.
2021-08-20 10:54:59 +03:00
UIDeviceFamily="$(_UIDeviceFamily)"
WKWatchKitApp="$(_WKWatchKitApp)"
XSAppIconAssets="$(_XSAppIconAssets)"
XSLaunchImageAssets="$(_XSLaunchImageAssets)"
[msbuild] Unify the iOS and macOS version of ACToolTaskBase. (#10810) * [msbuild] Unify the iOS and macOS version of ACToolTaskBase. * The ACTool task now needs the target framework moniker.
2021-03-09 19:45:49 +03:00
>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="PartialAppManifest" ItemName="_PostCompilePartialAppManifest" />
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
<!-- Local items to be persisted to items files -->
<Output TaskParameter="PartialAppManifest" ItemName="_ACTool_PartialAppManifest" />
<Output TaskParameter="BundleResources" ItemName="_ACTool_BundleResources" />
</ACTool>
<!-- Cache the generated outputs items for incremental build support -->
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<WriteItemsToFile Items="@(_ACTool_PartialAppManifest)" ItemName="_PostCompilePartialAppManifest" File="$(_ACTool_PartialAppManifestCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<WriteItemsToFile Items="@(_ACTool_BundleResources)" ItemName="_BundleResourceWithLogicalName" File="$(_ACTool_BundleResourceCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(ImageAsset)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="ImageAsset" File="$(_ProcessedImageAssetsPath)" Overwrite="true" IncludeMetadata="false" />
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
<ItemGroup>
<FileWrites Include="$(_ACTool_PartialAppManifestCache);$(_ACTool_BundleResourceCache)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<FileWrites Include="$(_ProcessedImageAssetsPath)" />
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +03:00
</ItemGroup>
</Target>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Compilation of SceneKit assets -->
<PropertyGroup>
<_CompileSceneKitAssetsDependsOn>
$(_CompileSceneKitAssetsDependsOn);
_DetectAppManifest;
_DetectSdkLocations;
_ComputeTargetArchitectures;
_RemoveProcessedSceneKitAssets;
_BeforeCoreCompileSceneKitAssets;
_ReadCoreCompileSceneKitAssets;
_CoreCompileSceneKitAssets;
</_CompileSceneKitAssetsDependsOn>
</PropertyGroup>
<Target Name="_CompileSceneKitAssets" DependsOnTargets="$(_CompileSceneKitAssetsDependsOn)" />
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedSceneKitAssets" Condition="Exists('$(_ProcessedSceneKitAssetsPath)')">
<ReadItemsFromFile File="$(_ProcessedSceneKitAssetsPath)">
<Output TaskParameter="Items" ItemName="_ProcessedSceneKitAssets" />
</ReadItemsFromFile>
<ItemGroup>
<SceneKitAsset Remove="@(_ProcessedSceneKitAssets)" />
</ItemGroup>
</Target>
[msbuild] Share the _*CompileSceneKitAssets targets between Xamarin.iOS and Xamarin.Mac. (#9735) The Xamarin.iOS version is more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac: * The iOS version contains Inputs/Outputs (important for incremental builds). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS) Additionally define the _SceneKitCache variable for macOS as well, previously it was only defined for iOS (I'm adding more variables than just _SceneKitCache to macOS, most of the others will be used in in macOS in upcoming pull requests, and this way turned out to be simplest). And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
2020-10-01 09:37:52 +03:00
<Target Name="_BeforeCoreCompileSceneKitAssets"
Inputs="@(SceneKitAsset)"
Outputs="$(_SceneKitCache)">
<!-- If any SceneKitAsset is newer than the generated items list, we delete them so that the _CoreCompileSceneKitAssets
target runs again and updates those lists for the next run
-->
<Delete Files="$(_SceneKitCache)" />
</Target>
<Target Name="_ReadCoreCompileSceneKitAssets"
DependsOnTargets="_BeforeCoreCompileSceneKitAssets">
<!-- If _BeforeCoreCompileSceneKitAssets did not delete the generated items lists from _CoreCompileSceneKitAssets, then we read them
since that target won't run and we need to the output items that are cached in those files which includes full metadata -->
<ReadItemsFromFile File="$(_SceneKitCache)" Condition="Exists('$(_SceneKitCache)')">
<Output TaskParameter="Items" ItemName="_BundleResourceWithLogicalName" />
</ReadItemsFromFile>
</Target>
<Target Name="_CoreCompileSceneKitAssets"
Inputs="@(SceneKitAsset)"
Outputs="$(_SceneKitCache)"
DependsOnTargets="_BeforeCoreCompileSceneKitAssets;_GenerateBundleName;_ComputeTargetFrameworkMoniker">
<CompileSceneKitAssets
SessionId="$(BuildSessionId)"
AppBundleName="$(_AppBundleName)$(AppBundleExtension)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(CopySceneKitAssetsExe)"
ToolPath="$(CopySceneKitAssetsPath)"
SceneKitAssets="@(SceneKitAsset)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
IsWatchApp="$(IsWatchApp)"
SdkPlatform="$(_SdkPlatform)"
SdkDevPath="$(_SdkDevPath)"
SdkRoot="$(_SdkRoot)"
SdkVersion="$(_SdkVersion)">
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
<!-- Local items to be persisted to items files -->
<Output TaskParameter="BundleResources" ItemName="_SceneKitAssets_BundleResources" />
</CompileSceneKitAssets>
<WriteItemsToFile Items="@(_SceneKitAssets_BundleResources)" ItemName="_BundleResourceWithLogicalName" File="$(_SceneKitCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(SceneKitAsset)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="SceneKitAsset" File="$(_ProcessedSceneKitAssetsPath)" Overwrite="true" IncludeMetadata="false" />
[msbuild] Share the _*CompileSceneKitAssets targets between Xamarin.iOS and Xamarin.Mac. (#9735) The Xamarin.iOS version is more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac: * The iOS version contains Inputs/Outputs (important for incremental builds). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS) Additionally define the _SceneKitCache variable for macOS as well, previously it was only defined for iOS (I'm adding more variables than just _SceneKitCache to macOS, most of the others will be used in in macOS in upcoming pull requests, and this way turned out to be simplest). And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
2020-10-01 09:37:52 +03:00
<ItemGroup>
<FileWrites Include="$(_SceneKitCache)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<FileWrites Include="$(_ProcessedSceneKitAssetsPath)" />
[msbuild] Share the _*CompileSceneKitAssets targets between Xamarin.iOS and Xamarin.Mac. (#9735) The Xamarin.iOS version is more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac: * The iOS version contains Inputs/Outputs (important for incremental builds). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS) Additionally define the _SceneKitCache variable for macOS as well, previously it was only defined for iOS (I'm adding more variables than just _SceneKitCache to macOS, most of the others will be used in in macOS in upcoming pull requests, and this way turned out to be simplest). And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
2020-10-01 09:37:52 +03:00
</ItemGroup>
</Target>
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
<!-- Collada assets -->
<PropertyGroup>
<CompileColladaAssetsDependsOn>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
_RemoveProcessedColladaAssets;
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
_CollectColladaAssets;
_CoreCompileColladaAssets
</CompileColladaAssetsDependsOn>
</PropertyGroup>
<Target Name="_CompileColladaAssets" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="$(CompileColladaAssetsDependsOn)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedColladaAssets" Condition="Exists('$(_ProcessedColladaAssetsPath)')">
<ReadItemsFromFile File="$(_ProcessedColladaAssetsPath)">
<Output TaskParameter="Items" ItemName="_ProcessedColladaAssets" />
</ReadItemsFromFile>
<ItemGroup>
<Collada Remove="@(_ProcessedColladaAssets)" />
</ItemGroup>
</Target>
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
<Target Name="_CollectColladaAssets">
<CollectBundleResources
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
BundleResources="@(Collada)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)">
<Output TaskParameter="BundleResourcesWithLogicalNames" ItemName="_ColladaAssetWithLogicalName" />
</CollectBundleResources>
</Target>
<Target Name="_CoreCompileColladaAssets"
DependsOnTargets="_CollectColladaAssets;_DetectSdkLocations;_ComputeTargetFrameworkMoniker"
Inputs="@(_ColladaAssetWithLogicalName)"
Outputs="$(DeviceSpecificIntermediateOutputPath)%(_ColladaAssetWithLogicalName.LogicalName)"
>
<ScnTool
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
IsWatchApp="$(IsWatchApp)"
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
ToolExe="$(ScnToolExe)"
ToolPath="$(ScnToolPath)"
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
SdkPlatform="$(_SdkPlatform)"
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
SdkRoot="$(_SdkRoot)"
SdkDevPath="$(_SdkDevPath)"
SdkVersion="$(_SdkVersion)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
InputScene="%(_ColladaAssetWithLogicalName.Identity)"
OutputScene="$(DeviceSpecificIntermediateOutputPath)%(_ColladaAssetWithLogicalName.LogicalName)">
</ScnTool>
<CreateItem Include="$(DeviceSpecificIntermediateOutputPath)%(_ColladaAssetWithLogicalName.LogicalName)" AdditionalMetadata="LogicalName=%(_ColladaAssetWithLogicalName.LogicalName);Optimize='False'">
<Output TaskParameter="Include" ItemName="_BundleResourceWithLogicalName" />
</CreateItem>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(_ColladaAssetWithLogicalName)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="_ColladaAssetWithLogicalName" File="$(_ProcessedColladaAssetsPath)" Overwrite="true" IncludeMetadata="false" />
<ItemGroup>
<FileWrites Include="$(_ProcessedColladaAssetsPath)" />
</ItemGroup>
[msbuild] Share targets related to Collada assets. (#10050)
2020-11-05 17:10:19 +03:00
</Target>
[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>
<_ComputeTargetArchitecturesDependsOn>
$(_ComputeTargetArchitecturesDependsOn);
_ComputeTargetFrameworkMoniker;
</_ComputeTargetArchitecturesDependsOn>
</PropertyGroup>
<Target Name="_ComputeTargetArchitectures" DependsOnTargets="$(_ComputeTargetArchitecturesDependsOn)">
[msbuild] Share _ComputeTargetArchitectures and use the output variables for both Xamarin.iOS and Xamarin.Mac. (#8751)
2020-06-04 16:00:28 +03:00
<!--
For now, this target is mostly for Xamarin.iOS, but in order to
use the same variables elsewhere, we have code for Xamarin.Mac
that outputs the same variables. However, as build logic between
Xamarin.iOS and Xamarin.Mac converges, more and more of this logic
will apply to Xamarin.Mac as well.
-->
<ParseDeviceSpecificBuildInformation
SessionId="$(BuildSessionId)"
Condition="'$(DeviceSpecificBuild)' == 'true' And '$(TargetiOSDevice)' != '' And '$(_CanDeployToDeviceOrSimulator)' == 'true' And '$(_PlatformName)' != 'macOS'"
[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
Architectures="$(TargetArchitectures)"
[msbuild] Share _ComputeTargetArchitectures and use the output variables for both Xamarin.iOS and Xamarin.Mac. (#8751)
2020-06-04 16:00:28 +03:00
IntermediateOutputPath="$(IntermediateOutputPath)"
OutputPath="$(OutputPath)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
TargetiOSDevice="$(TargetiOSDevice)"
>
<Output TaskParameter="DeviceSpecificIntermediateOutputPath" PropertyName="DeviceSpecificIntermediateOutputPath" />
<Output TaskParameter="DeviceSpecificOutputPath" PropertyName="DeviceSpecificOutputPath" />
<Output TaskParameter="TargetArchitectures" PropertyName="TargetArchitectures" />
<Output TaskParameter="TargetDeviceModel" PropertyName="TargetDeviceModel" />
<Output TaskParameter="TargetDeviceOSVersion" PropertyName="TargetDeviceOSVersion" />
</ParseDeviceSpecificBuildInformation>
[msbuild] Share the _*CompileSceneKitAssets targets between Xamarin.iOS and Xamarin.Mac. (#9735) The Xamarin.iOS version is more updated, so that's the version now for both Xamarin.iOS and Xamarin.Mac: * The iOS version contains Inputs/Outputs (important for incremental builds). * It doesn't use FileWrites (see e97d69b25cc2b85e89feb775169f46f467c66f7a why this was removed for iOS) Additionally define the _SceneKitCache variable for macOS as well, previously it was only defined for iOS (I'm adding more variables than just _SceneKitCache to macOS, most of the others will be used in in macOS in upcoming pull requests, and this way turned out to be simplest). And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
2020-10-01 09:37:52 +03:00
<PropertyGroup>
[msbuild] Share _ComputeTargetArchitectures and use the output variables for both Xamarin.iOS and Xamarin.Mac. (#8751)
2020-06-04 16:00:28 +03:00
<_MtouchSymbolsList>$(DeviceSpecificIntermediateOutputPath)mtouch-symbols.list</_MtouchSymbolsList>
<!-- actool output caches -->
<_ACTool_PartialAppManifestCache>$(DeviceSpecificIntermediateOutputPath)actool\_PartialAppManifest.items</_ACTool_PartialAppManifestCache>
<_ACTool_BundleResourceCache>$(DeviceSpecificIntermediateOutputPath)actool\_BundleResourceWithLogicalName.items</_ACTool_BundleResourceCache>
<!-- coremlc output caches -->
<_CoreMLModel_PartialAppManifestCache>$(DeviceSpecificIntermediateOutputPath)coremlc\_PartialAppManifest.items</_CoreMLModel_PartialAppManifestCache>
<_CoreMLModel_BundleResourceCache>$(DeviceSpecificIntermediateOutputPath)coremlc\_BundleResourceWithLogicalName.items</_CoreMLModel_BundleResourceCache>
<!-- ibtool output caches -->
<_IBToolCache>$(DeviceSpecificIntermediateOutputPath)ibtool\_BundleResourceWithLogicalName.items</_IBToolCache>
<!-- scntool output caches -->
<_SceneKitCache>$(DeviceSpecificIntermediateOutputPath)copySceneKitAssets\_BundleResourceWithLogicalName.items</_SceneKitCache>
<!-- TextureAtlas output caches -->
<_TextureAtlasCache>$(DeviceSpecificIntermediateOutputPath)atlas\_BundleResourceWithLogicalName.items</_TextureAtlasCache>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- processed items -->
<_ProcessedBundleResourcesPath Condition="'$(_ProcessedBundleResourcesPath)' == ''">$(DeviceSpecificIntermediateOutputPath)\_ProcessedBundleResourcesPath.items</_ProcessedBundleResourcesPath>
<_ProcessedContentPath Condition="'$(_ProcessedContentPath)' == ''">$(DeviceSpecificIntermediateOutputPath)\_ProcessedContentPath.items</_ProcessedContentPath>
<_ProcessedImageAssetsPath Condition="'$(_ProcessedImageAssetsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)actool\_ProcessedImageAssetsPath.items</_ProcessedImageAssetsPath>
<_ProcessedInterfaceDefinitionsPath Condition="'$(_ProcessedInterfaceDefinitionsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)ibtool\_ProcessedInterfaceDefinitionsPath.items</_ProcessedInterfaceDefinitionsPath>
<_ProcessedSceneKitAssetsPath Condition="'$(_ProcessedSceneKitAssetsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)copySceneKitAssets\_ProcessedSceneKitAssetsPath.items</_ProcessedSceneKitAssetsPath>
<_ProcessedColladaAssetsPath Condition="'$(_ProcessedColladaAssetsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)collada\_ProcessedColladaAssetsPath.items</_ProcessedColladaAssetsPath>
<_ProcessedTextureAtlasesPath Condition="'$(_ProcessedTextureAtlasesPath)' == ''">$(DeviceSpecificIntermediateOutputPath)atlas\_ProcessedTextureAtlasesPath.items</_ProcessedTextureAtlasesPath>
<_ProcessedCoreMLModelsPath Condition="'$(_ProcessedCoreMLModelsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)coremlc\_ProcessedCoreMLModelsPath.items</_ProcessedCoreMLModelsPath>
<_SaveProcessedItems Condition="'$(RuntimeIdentifiers)' != '' And '$(UsingAppleNETSdk)' == 'true'">true</_SaveProcessedItems>
[msbuild] Share _ComputeTargetArchitectures and use the output variables for both Xamarin.iOS and Xamarin.Mac. (#8751)
2020-06-04 16:00:28 +03:00
</PropertyGroup>
</Target>
[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
<!-- TODO: check for duplicate items -->
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Target Name="_ComputeBundleResourceOutputPaths" DependsOnTargets="_CollectBundleResources;_GenerateBundleName;_DetectSigningIdentity;_ReadAppManifest">
[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
<ComputeBundleResourceOutputPaths
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppResourcesPath="$(_AppResourcesPath)"
BundleIdentifier="$(_BundleIdentifier)"
BundleResources="@(_BundleResourceWithLogicalName)"
EnableOnDemandResources="$(EnableOnDemandResources)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
OutputPath="$(DeviceSpecificOutputPath)"
>
<Output TaskParameter="BundleResourcesWithOutputPaths" ItemName="_BundleResourceWithOutputPath"/>
</ComputeBundleResourceOutputPaths>
</Target>
<Target Name="_CopyResourcesToBundle" DependsOnTargets="_ComputeBundleResourceOutputPaths"
Inputs = "@(_BundleResourceWithOutputPath)"
Outputs = "@(_BundleResourceWithOutputPath -> '%(OutputPath)')" >
<SmartCopy
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
SourceFiles = "@(_BundleResourceWithOutputPath)"
DestinationFiles = "@(_BundleResourceWithOutputPath -> '%(OutputPath)')"
/>
</Target>
[msbuild] Share the _CreateAppBundle task between Xamarin.Mac and Xamarin.iOS. (#8694) There is a difference for Xamarin.Mac: the task will not be executed anymore if IsAppDistribution is set to true. Given that IsAppDistribution is not used in Xamarin.Mac projects, this is likely a rather uncommon case, and the potential for breaking behavior is outweighed by the advantage of having the same behavior for Xamarin.iOS and Xamarin.Mac.
2020-05-28 09:34:11 +03:00
<Target Name="_CreateAppBundle" Condition="'$(_CanOutputAppBundle)' == 'true' And '$(IsAppDistribution)' != 'true'" DependsOnTargets="$(CreateAppBundleDependsOn)" />
[msbuild] Share the _CreatePkgInfo target between Xamarin.iOS and Xamarin.Mac. (#9770) The Xamarin.Mac version of _CreatePkgInfo had a 'Ditto' call that seemed like a copy-paste error (the target below has the exac same call to 'Ditto'), and there's no reason to call 'Ditto' when creating the PkgInfo file, so I just removed it. The 'Ditto' call was added here: https://github.com/xamarin/xamarin-macios/commit/ca028ea15022ac0358fc1e31b3b8c2e0997eaf8e#diff-ccded350e40e767d69171655acb86b01R586-R606
2020-10-05 09:55:35 +03:00
<Target Name="_ComputePkgInfoPath" DependsOnTargets="_GenerateBundleName">
<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
<_PkgInfoPath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">$(_AppBundlePath)Contents\PkgInfo</_PkgInfoPath>
<_PkgInfoPath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">$(_AppBundlePath)PkgInfo</_PkgInfoPath>
[msbuild] Share the _CreatePkgInfo target between Xamarin.iOS and Xamarin.Mac. (#9770) The Xamarin.Mac version of _CreatePkgInfo had a 'Ditto' call that seemed like a copy-paste error (the target below has the exac same call to 'Ditto'), and there's no reason to call 'Ditto' when creating the PkgInfo file, so I just removed it. The 'Ditto' call was added here: https://github.com/xamarin/xamarin-macios/commit/ca028ea15022ac0358fc1e31b3b8c2e0997eaf8e#diff-ccded350e40e767d69171655acb86b01R586-R606
2020-10-05 09:55:35 +03:00
</PropertyGroup>
</Target>
<Target Name="_CreatePkgInfo" Condition="'$(IsAppExtension)' == 'false'" DependsOnTargets="_ComputePkgInfoPath" Outputs="$(_PkgInfoPath)">
<CreatePkgInfo SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" OutputPath="$(_PkgInfoPath)" />
</Target>
[msbuild] Share the *CompileTextureAtlas targets between Xamarin.iOS and Xamarin.Mac. (#12818) The iOS version is more advanced (has additional fixes for incremental builds), so that's the one that got chosen.
2021-09-24 08:46:50 +03:00
<!-- Compilation of Texture atlases -->
<PropertyGroup>
<_CompileTextureAtlasesDependsOn>
$(_CompileTextureAtlasesDependsOn);
_DetectSdkLocations;
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
_RemoveProcessedTextureAtlases;
[msbuild] Share the *CompileTextureAtlas targets between Xamarin.iOS and Xamarin.Mac. (#12818) The iOS version is more advanced (has additional fixes for incremental builds), so that's the one that got chosen.
2021-09-24 08:46:50 +03:00
_BeforeCompileTextureAtlases;
_ReadCoreCompileTextureAtlases;
_CoreCompileTextureAtlases;
</_CompileTextureAtlasesDependsOn>
</PropertyGroup>
<Target Name="_CompileTextureAtlases" DependsOnTargets="$(_CompileTextureAtlasesDependsOn)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedTextureAtlases" Condition="Exists('$(_ProcessedTextureAtlasesPath)')">
<ReadItemsFromFile File="$(_ProcessedTextureAtlasesPath)">
<Output TaskParameter="Items" ItemName="_ProcessedTextureAtlases" />
</ReadItemsFromFile>
<ItemGroup>
<AtlasTexture Remove="@(_ProcessedTextureAtlases)" />
</ItemGroup>
</Target>
[msbuild] Share the *CompileTextureAtlas targets between Xamarin.iOS and Xamarin.Mac. (#12818) The iOS version is more advanced (has additional fixes for incremental builds), so that's the one that got chosen.
2021-09-24 08:46:50 +03:00
<Target Name="_BeforeCompileTextureAtlases"
Inputs="@(AtlasTexture)"
Outputs="$(_TextureAtlasCache)">
<!-- If any AtlasTexture is newer than the generated items list, we delete them so that the _CoreCompileTextureAtlases
target runs again and updates those lists for the next run
-->
<Delete Files="$(_TextureAtlasCache)" />
</Target>
<Target Name="_ReadCoreCompileTextureAtlases"
DependsOnTargets="_BeforeCompileTextureAtlases">
<!-- If _BeforeCompileTextureAtlases did not delete the generated items lists from _CoreCompileTextureAtlases, then we read them
since that target won't run and we need to the output items that are cached in those files which includes full metadata -->
<ReadItemsFromFile File="$(_TextureAtlasCache)" Condition="Exists('$(_TextureAtlasCache)')">
<Output TaskParameter="Items" ItemName="_BundleResourceWithLogicalName" />
</ReadItemsFromFile>
</Target>
<Target Name="_CoreCompileTextureAtlases"
Inputs="@(AtlasTexture)"
Outputs="$(_TextureAtlasCache)"
DependsOnTargets="_BeforeCompileTextureAtlases">
<TextureAtlas
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(TextureAtlasExe)"
ToolPath="$(TextureAtlasPath)"
AtlasTextures="@(AtlasTexture)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
SdkDevPath="$(_SdkDevPath)"
SdkBinPath="$(_SdkBinPath)"
SdkUsrPath="$(_SdkUsrPath)">
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
<!-- Local items to be persisted to items files -->
<Output TaskParameter="BundleResources" ItemName="_TextureAtlas_BundleResources" />
</TextureAtlas>
<!-- Cached the generated outputs items for incremental build support -->
<WriteItemsToFile Items="@(_TextureAtlas_BundleResources)" ItemName="_BundleResourceWithLogicalName" File="$(_TextureAtlasCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(TextureAtlas)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="TextureAtlas" File="$(_ProcessedTextureAtlasesPath)" Overwrite="true" IncludeMetadata="false" />
[msbuild] Share the *CompileTextureAtlas targets between Xamarin.iOS and Xamarin.Mac. (#12818) The iOS version is more advanced (has additional fixes for incremental builds), so that's the one that got chosen.
2021-09-24 08:46:50 +03:00
<ItemGroup>
<FileWrites Include="$(_TextureAtlasCache)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<FileWrites Include="$(_ProcessedTextureAtlasesPath)" />
[msbuild] Share the *CompileTextureAtlas targets between Xamarin.iOS and Xamarin.Mac. (#12818) The iOS version is more advanced (has additional fixes for incremental builds), so that's the one that got chosen.
2021-09-24 08:46:50 +03:00
</ItemGroup>
</Target>
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Compilation of CoreML models -->
<PropertyGroup>
<_CompileCoreMLModelsDependsOn>
$(_CompileCoreMLModelsDependsOn);
_DetectAppManifest;
_DetectSdkLocations;
_ComputeTargetArchitectures;
_RemoveProcessedCoreMLModels;
_BeforeCompileCoreMLModels;
_ReadCompileCoreMLModels;
_CoreCompileCoreMLModels;
</_CompileCoreMLModelsDependsOn>
</PropertyGroup>
<Target Name="_CompileCoreMLModels" DependsOnTargets="$(_CompileCoreMLModelsDependsOn)" />
<!-- For multi-RID builds, we first build once for each RuntimeIdentifier, then build again to create a universal app bundle.
In the case of resources, it's wasteful to build them multiple times, so we hoist it out to the outer build, and store the
list of resources we've procesed in _Processed*Path. Here we load that file, and remove them from the item group with the resources -->
<Target Name="_RemoveProcessedCoreMLModels" Condition="Exists('$(_ProcessedCoreMLModelsPath)')">
<ReadItemsFromFile File="$(_ProcessedCoreMLModelsPath)">
<Output TaskParameter="Items" ItemName="_ProcessedCoreMLModels" />
</ReadItemsFromFile>
<ItemGroup>
<CoreMLModel Remove="@(_ProcessedCoreMLModels)" />
</ItemGroup>
</Target>
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<Target Name="_BeforeCompileCoreMLModels"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
Inputs="@(CoreMLModel);$(_TemporaryAppManifest)"
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
Outputs="$(_CoreMLModel_PartialAppManifestCache);$(_CoreMLModel_BundleResourceCache)">
<!-- If any CoreMLModel or AppManifest is newer than the generated items list, we delete them so that the _CoreCompileCoreMLModels
target runs again and updates those lists for the next run
-->
<Delete Files="$(_CoreMLModel_PartialAppManifestCache);$(_CoreMLModel_BundleResourceCache)" />
<RemoveDir Directories="$(DeviceSpecificIntermediateOutputPath)coremlc" />
</Target>
<Target Name="_ReadCompileCoreMLModels" DependsOnTargets="_BeforeCompileCoreMLModels">
<!-- If _BeforeCompileCoreMLModels did not delete the generated items lists from _CoreCompileCoreMLModels, then we read them
since that target won't run and we need the output items that are cached in those files, which includes full metadata -->
<ReadItemsFromFile File="$(_CoreMLModel_PartialAppManifestCache)" Condition="Exists('$(_CoreMLModel_PartialAppManifestCache)')">
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="Items" ItemName="_PostCompilePartialAppManifest" />
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
</ReadItemsFromFile>
<ReadItemsFromFile File="$(_CoreMLModel_BundleResourceCache)" Condition="Exists('$(_CoreMLModel_BundleResourceCache)')">
<Output TaskParameter="Items" ItemName="_BundleResourceWithLogicalName" />
</ReadItemsFromFile>
</Target>
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
<PropertyGroup>
<_CoreCompileCoreMLModelsDependsOn>
$(_CoreCompileCoreMLModelsDependsOn);
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
_ReadAppManifest;
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
_DetectSdkLocations;
_BeforeCompileCoreMLModels;
</_CoreCompileCoreMLModelsDependsOn>
</PropertyGroup>
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<Target Name="_CoreCompileCoreMLModels"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
Inputs="@(CoreMLModel);$(_TemporaryAppManifest)"
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
Outputs="$(_CoreMLModel_PartialAppManifestCache);$(_CoreMLModel_BundleResourceCache)"
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
DependsOnTargets="$(_CoreCompileCoreMLModelsDependsOn)">
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<CoreMLCompiler
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(CoreMLCompilerExe)"
ToolPath="$(CoreMLCompilerPath)"
Models="@(CoreMLModel)"
EnableOnDemandResources="$(EnableOnDemandResources)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
SdkDevPath="$(_SdkDevPath)">
<Output TaskParameter="BundleResources" ItemName="_BundleResourceWithLogicalName" />
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Output TaskParameter="PartialAppManifests" ItemName="_PostCompilePartialAppManifest" />
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<!-- Local items to be persisted to items files -->
<Output TaskParameter="PartialAppManifests" ItemName="_CoreMLModel_PartialAppManifest" />
<Output TaskParameter="BundleResources" ItemName="_CoreMLModel_BundleResources" />
</CoreMLCompiler>
<!-- Cache the generated outputs items for incremental build support -->
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<WriteItemsToFile Items="@(_CoreMLModel_PartialAppManifest)" ItemName="_PostCompilePartialAppManifest" File="$(_CoreMLModel_PartialAppManifestCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<WriteItemsToFile Items="@(_CoreMLModel_BundleResources)" ItemName="_BundleResourceWithLogicalName" File="$(_CoreMLModel_BundleResourceCache)" Overwrite="true" IncludeMetadata="true" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<!-- Write out the list of assets we've processed, so that an inner build in a multi-rid build can skip processing them -->
<WriteItemsToFile Items="@(CoreMLModel)" Condition="'$(_SaveProcessedItems)' == 'true'" ItemName="CoreMLModel" File="$(_ProcessedCoreMLModelsPath)" Overwrite="true" IncludeMetadata="false" />
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
<ItemGroup>
<FileWrites Include="$(_CoreMLModel_PartialAppManifestCache);$(_CoreMLModel_BundleResourceCache)" />
[msbuild/dotnet] Compile project-level assets in the outer build for multi-rid builds. Fixes #12410. (#12847) We don't need to compile project-level assets for every RuntimeIdentifier in multi-rid builds, we can instead compile them just once in the outer build. There is also a correctness issue here: we can't compile assets more than once and expect to get the exact same compiled result every time (in particular actool seems to be adding random bytes in to the compiled output), and this creates a problem when trying to merge the different runtime-specific compiled output into a universal binary. We accomplish this by: * Processing these assets in the outer build, before we execute the rid-specific inner builds. * Store the paths to the assets we've processed in a file. * In the inner builds, we read that file, and remove any matches from the corresponding item group. * Make sure to copy the compiled assets to the app bundle at the end of the outer build. These are the assets we currently handle this way: * BundleResource * ImageAsset * InterfaceDefinition * SceneKitAsset * Collada * TextureAtlas * CoreMLModel Also: * Add a new test case (AppWithResource) that contains all these different types of assets. * Add support for the ScnTool task on Mac Catalyst (which the new test case revealed was missing). Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
2021-09-30 09:25:10 +03:00
<FileWrites Include="$(_ProcessedCoreMLModelsPath)" />
[msbuild] Share the *CompileCoreMLModels targets between Xamarin.iOS and Xamarin.Mac. (#9792) Xamarin.Mac didn't have support for CoreML models before, so this effectively adds support for CoreML models to Xamarin.Mac. Also add a test to make sure it actually works.
2020-10-07 09:42:17 +03:00
</ItemGroup>
</Target>
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
<PropertyGroup>
<_SmeltMetalDependsOn>
_DetectSdkLocations;
_ComputeTargetFrameworkMoniker;
_ReadAppManifest;
</_SmeltMetalDependsOn>
</PropertyGroup>
<Target Name="_SmeltMetal" Condition="'$(_CanOutputAppBundle)' == 'true' And '@(Metal)' != ''" DependsOnTargets="$(_SmeltMetalDependsOn)">
[msbuild] Share the _*Metal tasks between Xamarin.iOS and Xamarin.Mac. (#9786) * This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs value didn't match the actual output path (this was fixed in the iOS version). * Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup instead of the CreateItem task.
2020-10-06 15:17:56 +03:00
<Metal
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' and '%(Metal.Identity)' != ''"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
MinimumOSVersion="$(_MinimumOSVersion)"
ProjectDir="$(MSBuildProjectDirectory)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
ResourcePrefix="$(_ResourcePrefix)"
SdkDevPath="$(_SdkDevPath)"
SdkIsSimulator="$(_SdkIsSimulator)"
SdkRoot="$(_SdkRoot)"
SdkVersion="$(_SdkVersion)"
SourceFile="@(Metal)">
<Output TaskParameter="OutputFile" ItemName="_SmeltedMetal" />
</Metal>
</Target>
Remove IsXcode8 (#12671) * Remove IsXcode8 * Remove other _ForgeMetal references
2021-09-09 10:23:32 +03:00
<Target Name="_TemperMetal" Condition="'$(_CanOutputAppBundle)' == 'true' And '@(_SmeltedMetal)' != ''" DependsOnTargets="_GenerateBundleName"
Inputs="@(_SmeltedMetal)" Outputs="$(_AppResourcesPath)default.metallib">
[msbuild] Share the _*Metal tasks between Xamarin.iOS and Xamarin.Mac. (#9786) * This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs value didn't match the actual output path (this was fixed in the iOS version). * Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup instead of the CreateItem task.
2020-10-06 15:17:56 +03:00
<MetalLib
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Remove IsXcode8 (#12671) * Remove IsXcode8 * Remove other _ForgeMetal references
2021-09-09 10:23:32 +03:00
Items="@(_SmeltedMetal)"
[msbuild] Share the _*Metal tasks between Xamarin.iOS and Xamarin.Mac. (#9786) * This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs value didn't match the actual output path (this was fixed in the iOS version). * Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup instead of the CreateItem task.
2020-10-06 15:17:56 +03:00
SdkDevPath="$(_SdkDevPath)"
SdkRoot="$(_SdkRoot)"
OutputLibrary="$(_AppResourcesPath)default.metallib">
</MetalLib>
</Target>
[msbuild] Add a property that specifies the final path to the Info.plist in the app bundle (#12433) * Add an '_AppBundleManifest' property that specifies the final path to the Info.plist in the app bundle. * Remove the '_AppBundleManifestPath' property, it's not used anywhere. * Adjust the CompileAppManifest task to take the final path to the Info.plist, instead of computing it and returning it. This way the CompileAppManifest task does not output anything back into MSBuild (which is important, because the CompileAppManifest task won't execute if the output file is up-to-date, and if it's not executed, any output properties won't be set either).
2021-08-17 16:29:42 +03:00
<Target Name="_DetectAppManifest" DependsOnTargets="_GenerateBundleName">
[msbuild] Unify the _DetectAppManifest target. (#8745) There's one difference for Xamarin.Mac library projects: they'll now have the ability to use an Info.plist to specify a minimum OS version that will be used when compiling storyboards and other compilable files. This is the way it's worked for Xamarin.iOS projects for a long time.
2020-06-04 10:14:58 +03:00
<!--
This targets runs for Library projects as well, so that Library
projects can specify an Info.plist with MinimumOSVersion to pass
to actool, ibtool, and other Xcode tools.
Ref: https://bugzilla.xamarin.com/show_bug.cgi?id=34736
-->
<FindItemWithLogicalName
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
Items="@(None)">
<Output TaskParameter="Item" PropertyName="_AppManifest" />
</FindItemWithLogicalName>
<FindItemWithLogicalName Condition="'$(_AppManifest)' == '' And '$(_CanOutputAppBundle)' == 'true'"
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
Items="@(BundleResource)">
<Output TaskParameter="Item" PropertyName="_AppManifest" />
</FindItemWithLogicalName>
<FindItemWithLogicalName Condition="'$(_AppManifest)' == '' And '$(_CanOutputAppBundle)' == 'true'"
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
Items="@(Content)">
<Output TaskParameter="Item" PropertyName="_AppManifest" />
</FindItemWithLogicalName>
[msbuild] Don't require an Info.plist for .NET builds. (#12661) We either have defaults or MSBuild properties for the most important values that were previously required to be in the Info.plist, so now it doesn't make sense anymore to require an Info.plist, when for simple cases it will just be an empty file. This allows us to simplify some of our test projects and remove a few empty Info.plist files.
2021-09-09 10:08:04 +03:00
<Error Condition="'$(_AppManifest)' == '' And '$(_CanOutputAppBundle)' == 'true' And '$(UsingAppleNETSdk)' != 'true'" Text="Info.plist not found."/>
[msbuild] Put Info.plist in the Contents/ subdirectory in the app for catalyst apps.
2020-11-18 10:38:01 +03:00
<PropertyGroup>
[msbuild] Add a property that specifies the final path to the Info.plist in the app bundle (#12433) * Add an '_AppBundleManifest' property that specifies the final path to the Info.plist in the app bundle. * Remove the '_AppBundleManifestPath' property, it's not used anywhere. * Adjust the CompileAppManifest task to take the final path to the Info.plist, instead of computing it and returning it. This way the CompileAppManifest task does not output anything back into MSBuild (which is important, because the CompileAppManifest task won't execute if the output file is up-to-date, and if it's not executed, any output properties won't be set either).
2021-08-17 16:29:42 +03:00
<_AppBundleManifest>$(_AppBundlePath)$(_AppBundleManifestRelativePath)Info.plist</_AppBundleManifest>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<!-- We should only write out a compiled app manifest if we're creating an app bundle -->
<_CreateAppManifest>$(_CanOutputAppBundle)</_CreateAppManifest>
<_TemporaryAppManifest>$(DeviceSpecificIntermediateOutputPath)AppManifest.plist</_TemporaryAppManifest>
[msbuild] Put Info.plist in the Contents/ subdirectory in the app for catalyst apps.
2020-11-18 10:38:01 +03:00
</PropertyGroup>
[msbuild] Unify the _DetectAppManifest target. (#8745) There's one difference for Xamarin.Mac library projects: they'll now have the ability to use an Info.plist to specify a minimum OS version that will be used when compiling storyboards and other compilable files. This is the way it's worked for Xamarin.iOS projects for a long time.
2020-06-04 10:14:58 +03:00
</Target>
[msbuild] Share the OptimizeImage and OptimizePropertyList tasks and targets between iOS and macOS. (#12819) This brings .png and .plist optimization to macOS (but no behavior is changed, because it's already disabled by default).
2021-09-24 17:26:28 +03:00
<!-- Optimize png images -->
<PropertyGroup>
<OptimizePngImagesDependsOn>
_CollectPngImages;
_CoreOptimizePngImages;
_AfterCoreOptimizePngImages
</OptimizePngImagesDependsOn>
</PropertyGroup>
<Target Name="_OptimizePngImages" DependsOnTargets="$(OptimizePngImagesDependsOn)" />
<Target Name="_CollectPngImages" DependsOnTargets="_CollectBundleResources">
<CreateItem Include="@(_BundleResourceWithLogicalName)" Condition="'%(_BundleResourceWithLogicalName.Extension)' == '.png' And '%(_BundleResourceWithLogicalName.Optimize)' == 'true'">
<Output TaskParameter="Include" ItemName="_PngImage" />
</CreateItem>
</Target>
<Target Name="_CoreOptimizePngImages"
DependsOnTargets="_CollectPngImages;_DetectSdkLocations"
Inputs="@(_PngImage)"
Outputs="@(_PngImage -> '$(DeviceSpecificIntermediateOutputPath)optimized\%(LogicalName)')">
<OptimizeImage
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(PngCrushExe)"
ToolPath="$(PngCrushPath)"
SdkDevPath="$(_SdkDevPath)"
InputImages="@(_PngImage)"
OutputImages="@(_PngImage -> '$(DeviceSpecificIntermediateOutputPath)optimized\%(LogicalName)')">
<Output TaskParameter="OutputImages" ItemName="FileWrites" />
</OptimizeImage>
</Target>
<Target Name="_AfterCoreOptimizePngImages" Condition="'@(_PngImage)' != ''">
<ItemGroup>
<_BundleResourceWithLogicalName Remove="@(_PngImage)" />
</ItemGroup>
<CreateItem Include="$(DeviceSpecificIntermediateOutputPath)optimized\%(_PngImage.LogicalName)" AdditionalMetadata="LogicalName=%(_PngImage.LogicalName);Optimize='false';ResourceTags=%(_PngImage.ResourceTags)">
<Output TaskParameter="Include" ItemName="_BundleResourceWithLogicalName" />
</CreateItem>
</Target>
<!-- Optimize property lists -->
<PropertyGroup>
<OptimizePropertyListsDependsOn>
_CollectPropertyLists;
_CoreOptimizePropertyLists;
_AfterCoreOptimizePropertyLists
</OptimizePropertyListsDependsOn>
</PropertyGroup>
<Target Name="_OptimizePropertyLists" DependsOnTargets="$(OptimizePropertyListsDependsOn)" />
<Target Name="_CollectPropertyLists" DependsOnTargets="_CollectBundleResources">
<CreateItem Include="@(_BundleResourceWithLogicalName)" Condition="'%(_BundleResourceWithLogicalName.Extension)' == '.plist' And '%(_BundleResourceWithLogicalName.Optimize)' == 'true'">
<Output TaskParameter="Include" ItemName="_PropertyList" />
</CreateItem>
<ItemGroup>
<FileWrites Include="$(DeviceSpecificIntermediateOutputPath)optimized\%(_PropertyList.LogicalName)" />
</ItemGroup>
</Target>
<Target Name="_CoreOptimizePropertyLists"
DependsOnTargets="_CollectPropertyLists;_DetectSdkLocations"
Inputs="@(_PropertyList)"
Outputs="$(DeviceSpecificIntermediateOutputPath)optimized\%(_PropertyList.LogicalName)"
>
<OptimizePropertyList
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(PlUtilExe)"
ToolPath="$(PlUtilPath)"
Input="%(_PropertyList.Identity)"
Output="$(DeviceSpecificIntermediateOutputPath)optimized\%(_PropertyList.LogicalName)">
</OptimizePropertyList>
</Target>
<Target Name="_AfterCoreOptimizePropertyLists" Condition="'@(_PropertyList)' != ''">
<ItemGroup>
<_BundleResourceWithLogicalName Remove="@(_PropertyList)" />
</ItemGroup>
<CreateItem Include="$(DeviceSpecificIntermediateOutputPath)optimized\%(_PropertyList.LogicalName)" AdditionalMetadata="LogicalName=%(_PropertyList.LogicalName);Optimize='false'">
<Output TaskParameter="Include" ItemName="_BundleResourceWithLogicalName" />
</CreateItem>
</Target>
<!-- Optimize localization files (*.strings) -->
<PropertyGroup>
<OptimizeLocalizationFilesDependsOn>
_CollectLocalizationFiles;
_CoreOptimizeLocalizationFiles;
_AfterCoreOptimizeLocalizationFiles
</OptimizeLocalizationFilesDependsOn>
</PropertyGroup>
<Target Name="_OptimizeLocalizationFiles" DependsOnTargets="$(OptimizeLocalizationFilesDependsOn)" />
<Target Name="_CollectLocalizationFiles" DependsOnTargets="_CollectBundleResources">
<CreateItem Include="@(_BundleResourceWithLogicalName)" Condition="'%(_BundleResourceWithLogicalName.Extension)' == '.strings' And '%(_BundleResourceWithLogicalName.Optimize)' == 'true'">
<Output TaskParameter="Include" ItemName="_LocalizationFile" />
</CreateItem>
<ItemGroup>
<FileWrites Include="$(DeviceSpecificIntermediateOutputPath)optimized\%(_LocalizationFile.LogicalName)" />
</ItemGroup>
</Target>
<Target Name="_CoreOptimizeLocalizationFiles"
DependsOnTargets="_CollectLocalizationFiles;_DetectSdkLocations"
Inputs="@(_LocalizationFile)"
Outputs="$(DeviceSpecificIntermediateOutputPath)optimized\%(_LocalizationFile.LogicalName)"
>
<OptimizePropertyList
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(PlUtilExe)"
ToolPath="$(PlUtilPath)"
Input="%(_LocalizationFile.Identity)"
Output="$(DeviceSpecificIntermediateOutputPath)optimized\%(_LocalizationFile.LogicalName)">
</OptimizePropertyList>
</Target>
<Target Name="_AfterCoreOptimizeLocalizationFiles" Condition="'@(_LocalizationFile)' != ''">
<ItemGroup>
<_BundleResourceWithLogicalName Remove="@(_LocalizationFile)" />
</ItemGroup>
<CreateItem Include="$(DeviceSpecificIntermediateOutputPath)optimized\%(_LocalizationFile.LogicalName)" AdditionalMetadata="LogicalName=%(_LocalizationFile.LogicalName);Optimize='false'">
<Output TaskParameter="Include" ItemName="_BundleResourceWithLogicalName" />
</CreateItem>
</Target>
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
<PropertyGroup Condition="'$(IsBindingProject)' == 'true'">
<!-- Add our own pre and post build steps -->
<!-- Override the CoreCompile Target to use bgen -->
<CompileDependsOn>
_GenerateBindings;
_PrepareNativeReferences;
_CollectGeneratedSources;
$(CompileDependsOn)
_CreateBindingResourcePackage;
</CompileDependsOn>
</PropertyGroup>
[msbuild] Create a few '_*DependsOn' variables that specifies depend targets. (#9305) The .NET logic will inject an additional dependencies in these variables.
2020-08-07 15:53:49 +03:00
<PropertyGroup>
<_GenerateBindingsDependsOn>
_ComputeTargetFrameworkMoniker;
$(_GenerateBindingsDependsOn);
</_GenerateBindingsDependsOn>
</PropertyGroup>
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
<Target Name="_GenerateBindings"
Inputs="$(MSBuildAllProjects);@(ObjcBindingApiDefinition);@(ObjcBindingCoreSource);@(ReferencePath);@(ObjcBindingNativeLibrary)"
Outputs="$(_GeneratedSourcesFileList)"
[msbuild] Create a few '_*DependsOn' variables that specifies depend targets. (#9305) The .NET logic will inject an additional dependencies in these variables.
2020-08-07 15:53:49 +03:00
DependsOnTargets="$(_GenerateBindingsDependsOn)"
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
Condition="'$(IsBindingProject)' == 'true' And '$(DesignTimeBuild)' != 'true'">
<ItemGroup>
<BTouchReferencePath Include="@(ReferenceCopyLocalPaths)" Condition="'%(Extension)' == '.dll'" />
</ItemGroup>
<PropertyGroup>
<BTouchEmitDebugInformation>false</BTouchEmitDebugInformation>
<BTouchEmitDebugInformation Condition="'$(Debug)' != ''">true</BTouchEmitDebugInformation>
</PropertyGroup>
[msbuild] Create the output directory for generated binding sources.
2020-07-17 17:38:40 +03:00
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(GeneratedSourcesDir)" />
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
<BTouch
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
OutputPath="$(OutputPath)"
ObjectiveCLibraries="@(ObjcBindingNativeLibrary)"
AdditionalLibPaths="$(AdditionalLibPaths)"
AllowUnsafeBlocks="$(AllowUnsafeBlocks)"
ApiDefinitions="@(ObjcBindingApiDefinition)"
[msbuild] Pass the path to the binding attribute assembly to bgen.
2020-07-17 17:38:40 +03:00
AttributeAssembly="$(_GeneratorAttributeAssembly)"
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
BaseLibDll="$(BaseLibDllPath)"
CoreSources="@(ObjcBindingCoreSource)"
DefineConstants="$(DefineConstants)"
EmitDebugInformation="$(BTouchEmitDebugInformation)"
ExtraArgs="$(BTouchExtraArgs)"
GeneratedSourcesDir="$(GeneratedSourcesDir)"
GeneratedSourcesFileList="$(_GeneratedSourcesFileList)"
Namespace="$(Namespace)"
OutputAssembly="$(OutputAssembly)"
ProcessEnums="$(ProcessEnums)"
ProjectDir="$(MSBuildProjectDirectory)"
References="@(ReferencePath);@(BTouchReferencePath)"
[msbuild] Call the generator using a response file. (#12756) Fixes this warning: > Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
2021-09-20 08:40:57 +03:00
ResponseFilePath="$(DeviceSpecificIntermediateOutputPath)response-file.rsp"
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
BTouchToolPath="$(BTouchToolPath)"
BTouchToolExe="$(BTouchToolExe)"
StandardOutputImportance="High"
>
</BTouch>
</Target>
[msbuild] Unify the _GetCompileToNativeInputs target between iOS and Mac. (#10189) * Add a stamp file to the Mac version of _CompileToNative. This is used to force a rebuild of the container app when an app extension changes (and was already implemented for iOS: 8b376efa4b2045f41e8e7eaa71fc45a41a0fa6a0) * Rename the iOS stamp file to 'bundler.stamp' instead of 'mtouch.stamp' to ease code sharing. * Rename the 'MmpReferencePath' and 'MTouchReferencePath' properties to '_BundlerReferencePath' to ease code sharing. * Merge the _GetCompileToNativeInputs targets. The only difference between iOS and Mac (after the above changes) is that the Mac version now includes '@(ReferencePath)' in '_CompileToNativeInput'. This should be fine as far as I know.
2020-12-03 10:12:18 +03:00
<Target Name="_GetCompileToNativeInputs"
DependsOnTargets="ResolveReferences">
<ItemGroup>
<!-- Skip the reference assemblies. Execution may fail at runtime if they're copied to the .app (instead of the implementation assembly), or AOT will fail in both 'mtouch' and 'mmp'. Similar to: https://github.com/xamarin/xamarin-macios/issues/3199 -->
<!-- Remove exact references, such as if a package had a framework reference to 'System' that we already have -->
<!-- This is exactly what "Microsoft.NuGet.Build.Tasks"'s 'ResolveNuGetPackageAssets' target is doing -->
<!-- Effectively 'ResolveNuGetPackageAssets' computes the NuGet packages using their json asset file, adds the full assemblies to 'ReferenceCopyLocalPaths' and outputs the resolved references via '_ReferencesFromNuGetPackages' -->
<ReferencePath Remove="@(_ReferencesFromNuGetPackages)" />
[msbuild] Treat 'ResolvedCompileFileDefinitions' as a list of reference assemblies as well. (#10197) The build logic will put reference assemblies in 'ResolvedCompileFileDefinitions' instead of '_ReferencesFromNuGetPackages' when using the new-style packageref format, so we need to handle 'ResolvedCompileFileDefinitions' the same way we handle '_ReferencesFromNuGetPackages'. I was unfortunately not able to create a unit test for this scenario, because xibuild sets MSBUILD_EXE_PATH to make msbuild look in our local build files, and then the restore fails with: > Issue9266.csproj : error MSB4236: The SDK 'Msbuild.Sdk.Extras/2.1.2' specified could not be found. If I don't use "Msbuild.Sdk.Extras" in the test, then it doesn't hit the broken path this PR is fixing. If I change xibuild to not set MSBUILD_EXE_PATH, we're not testing our local bits anymore, but the system Xamarin.Mac. Fixes https://github.com/xamarin/xamarin-macios/issues/9266.
2020-12-03 17:35:55 +03:00
<!-- It seems newer version of the .NET SDK uses the 'ResolvedCompileFileDefinitions' property instead of '_ReferencesFromNuGetPackages' -->
<ReferencePath Remove="@(ResolvedCompileFileDefinitions)" />
[msbuild] Unify the _GetCompileToNativeInputs target between iOS and Mac. (#10189) * Add a stamp file to the Mac version of _CompileToNative. This is used to force a rebuild of the container app when an app extension changes (and was already implemented for iOS: 8b376efa4b2045f41e8e7eaa71fc45a41a0fa6a0) * Rename the iOS stamp file to 'bundler.stamp' instead of 'mtouch.stamp' to ease code sharing. * Rename the 'MmpReferencePath' and 'MTouchReferencePath' properties to '_BundlerReferencePath' to ease code sharing. * Merge the _GetCompileToNativeInputs targets. The only difference between iOS and Mac (after the above changes) is that the Mac version now includes '@(ReferencePath)' in '_CompileToNativeInput'. This should be fine as far as I know.
2020-12-03 10:12:18 +03:00
<_BundlerReferencePath Include="@(ReferenceCopyLocalPaths)" Condition="'%(Extension)' == '.dll'" />
<_CompileToNativeInput Include="$(TargetDir)$(TargetFileName);@(_BundlerReferencePath)" />
<_CompileToNativeInput Condition="'@(_ResolvedAppExtensionReferences)' != ''" Include="%(_ResolvedAppExtensionReferences.Identity)\..\bundler.stamp" />
</ItemGroup>
</Target>
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
<PropertyGroup>
<_DetectSigningIdentityDependsOn>
$(_DetectSigningIdentityDependsOn);
_DetectSdkLocations;
_ComputeTargetFrameworkMoniker;
_GenerateBundleName;
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
_ReadAppManifest;
[dotnet/msbuild] Create *DependsOn properties for several targets.
2021-08-04 13:42:43 +03:00
</_DetectSigningIdentityDependsOn>
</PropertyGroup>
<Target Name="_DetectSigningIdentity" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="$(_DetectSigningIdentityDependsOn)">
[msbuild] Share the _DetectSigningIdentity target. (#8785) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: DetectSigningIdentityTaskBase └─── iOS/DetectSigningIdentityTaskCore │ └─── iOS/DetectSigningIdentity └─── Mac/DetectSigningIdentityTaskCore │ └─── Mac/DetectSigningIdentity
2020-06-08 09:58:59 +03:00
<DetectSigningIdentity
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleName="$(_AppBundleName)"
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
BundleIdentifier="$(_BundleIdentifier)"
[msbuild] Share the _DetectSigningIdentity target. (#8785) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: DetectSigningIdentityTaskBase └─── iOS/DetectSigningIdentityTaskCore │ └─── iOS/DetectSigningIdentity └─── Mac/DetectSigningIdentityTaskCore │ └─── Mac/DetectSigningIdentity
2020-06-08 09:58:59 +03:00
Keychain="$(CodesignKeychain)"
RequireCodeSigning="$(_RequireCodeSigning)"
RequireProvisioningProfile="$(_RequireProvisioningProfile)"
SdkIsSimulator="$(_SdkIsSimulator)"
SdkPlatform="$(_SdkPlatform)"
ProvisioningProfile="$(CodesignProvision)"
SigningKey="$(_SpecifiedCodesignKey)"
DetectedCodeSigningKey="$(_CodeSigningKey)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
<Output TaskParameter="DetectedAppId" PropertyName="_AppIdentifier" />
<Output TaskParameter="DetectedCodeSigningKey" PropertyName="_CodeSigningKey" />
<Output TaskParameter="DetectedCodesignAllocate" PropertyName="_CodesignAllocate" />
<Output TaskParameter="DetectedDistributionType" PropertyName="_DistributionType" />
<Output TaskParameter="DetectedProvisioningProfile" PropertyName="_ProvisioningProfile" />
</DetectSigningIdentity>
[msbuild] Unify the EmbedProvisionProfile and EmbedMobileProvision tasks between iOS and macOS. (#10322) These two tasks did essentially the same thing, so we can just merge them. I kept the "EmbedProvisionProfile" name, because that sounded like the most applicable to all platforms.
2021-01-11 16:34:19 +03:00
<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
<_EmbeddedProvisionProfilePath Condition="'$(_EmbeddedProvisionProfilePath)' == '' And ('$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst')">$(_AppBundlePath)Contents\embedded.provisionprofile</_EmbeddedProvisionProfilePath>
[msbuild] Unify the EmbedProvisionProfile and EmbedMobileProvision tasks between iOS and macOS. (#10322) These two tasks did essentially the same thing, so we can just merge them. I kept the "EmbedProvisionProfile" name, because that sounded like the most applicable to all platforms.
2021-01-11 16:34:19 +03:00
<_EmbeddedProvisionProfilePath Condition="'$(_EmbeddedProvisionProfilePath)' == '' And ('$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS')">$(_AppBundlePath)embedded.mobileprovision</_EmbeddedProvisionProfilePath>
</PropertyGroup>
[msbuild] Share the _DetectSigningIdentity target. (#8785) Also rework the class hierarchy a little bit, so that Xamarin.iOS and Xamarin.Mac are identical: DetectSigningIdentityTaskBase └─── iOS/DetectSigningIdentityTaskCore │ └─── iOS/DetectSigningIdentity └─── Mac/DetectSigningIdentityTaskCore │ └─── Mac/DetectSigningIdentity
2020-06-08 09:58:59 +03:00
</Target>
[msbuild] Share the _DetectSdkLocations target. (#8755)
2020-06-05 18:08:02 +03:00
<Target Name="_DetectSdkLocations" DependsOnTargets="_ComputeTargetArchitectures;_ComputeTargetFrameworkMoniker">
<DetectSdkLocations
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
SdkVersion="$(_SdkVersion)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
TargetArchitectures="$(TargetArchitectures)"
[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
XamarinSdkRoot="$(_XamarinSdkRootOnMac)"
[msbuild] Share the _DetectSdkLocations target. (#8755)
2020-06-05 18:08:02 +03:00
>
<Output TaskParameter="SdkVersion" PropertyName="_SdkVersion" />
<Output TaskParameter="SdkRoot" PropertyName="_SdkRoot" />
<Output TaskParameter="SdkBinPath" PropertyName="_SdkBinPath" />
<Output TaskParameter="SdkDevPath" PropertyName="_SdkDevPath" />
<Output TaskParameter="SdkUsrPath" PropertyName="_SdkUsrPath" />
<Output TaskParameter="SdkPlatform" PropertyName="_SdkPlatform" />
<Output TaskParameter="SdkIsSimulator" PropertyName="_SdkIsSimulator" />
<Output TaskParameter="XamarinSdkRoot" PropertyName="_XamarinSdkRoot" />
</DetectSdkLocations>
</Target>
[msbuild] Unify the EmbedProvisionProfile and EmbedMobileProvision tasks between iOS and macOS. (#10322) These two tasks did essentially the same thing, so we can just merge them. I kept the "EmbedProvisionProfile" name, because that sounded like the most applicable to all platforms.
2021-01-11 16:34:19 +03:00
<Target Name="_EmbedProvisionProfile" Condition="'$(_ProvisioningProfile)' != ''" DependsOnTargets="_GenerateBundleName;_DetectSigningIdentity"
Outputs="$(_EmbeddedProvisionProfilePath)">
<EmbedProvisionProfile
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
AppBundleDir="$(AppBundleDir)"
ProvisioningProfile="$(_ProvisioningProfile)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
EmbeddedProvisionProfilePath="$(_EmbeddedProvisionProfilePath)"
>
</EmbedProvisionProfile>
</Target>
[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
<Target Name="_PackLibraryResources" Condition="'$(_CanOutputAppBundle)' == 'false'" DependsOnTargets="_CollectBundleResources">
<PackLibraryResources
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
Prefix="$(_EmbeddedResourcePrefix)"
BundleResourcesWithLogicalNames="@(_BundleResourceWithLogicalName)">
<Output TaskParameter="EmbeddedResources" ItemName="EmbeddedResource" />
</PackLibraryResources>
</Target>
<Target Name="_UnpackLibraryResources" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="ResolveReferences;_CollectBundleResources">
<UnpackLibraryResources
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
Prefix="$(_EmbeddedResourcePrefix)"
NoOverwrite="@(_BundleResourceWithLogicalName)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
TargetFrameworkDirectory="$(TargetFrameworkDirectory)"
ReferencedLibraries="@(ReferencePath);@(ReferenceDependencyPaths)">
<Output TaskParameter="BundleResourcesWithLogicalNames" ItemName="_BundleResourceWithLogicalName" />
</UnpackLibraryResources>
</Target>
[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
<Target Name="_ParseBundlerArguments">
<ParseBundlerArguments
ExtraArgs="$(_BundlerArguments)"
NoSymbolStrip="$(_NoSymbolStrip)"
NoDSymUtil="$(_NoDSymUtil)"
[msbuild] Make the ParseBundlerArgumentsTaskBase take the verbosity as input as well. (#12570) This way we'll honor a _BundlerVerbosity value passed on the command line. This fixes an inconvenience when we have when we want to increase verbosity for a test run, which can be done by setting 'MtouchExtraArgs=-v'. This works fine until the test we want to run wants to use MtouchExtraArgs for its own purposes (1). If we set MtouchExtraArgs on the command line, then that value will be global and won't be able to be overridden by the test, and the test will fail. With this fix we can pass _BundlerVerbosity=1 directly when building the test to avoid the whole problem. 1. For instance, most tests pass an argument in MtouchExtraArgs to use dlsym for NUnit.Framework.dll, which contains a P/Invoke to a native function that doesn't exist - see the tests/nunit.framework.targets file.
2021-09-06 16:25:01 +03:00
Verbosity="$(_BundlerVerbosity)"
[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
>
[msbuild] Fix ItemName vs PropertyName confusion in task output. (#10936) There doesn't seem to have been any ill effects from the confusion, but it's better done the right way.
2021-03-25 17:51:37 +03:00
<Output TaskParameter="CustomBundleName" PropertyName="_CustomBundleName" />
[dotnet] Parse --dlsym and pass it to the dotnet-linker tasks.
2021-07-01 17:01:01 +03:00
<Output TaskParameter="DlSym" ItemName="_BundlerDlsym" />
[msbuild/dotnet] Add support for parsing --setenv from bundler arguments. (#10896) Add support for parsing --setenv from bundler arguments and passing them to dotnet-linker so that the environment variables can be baked into the app at launch (like they would be for mtouch/mmp).
2021-03-18 17:15:02 +03:00
<Output TaskParameter="EnvironmentVariables" ItemName="_BundlerEnvironmentVariables" />
[msbuild] Parse --marshal-managed-exceptions and --marshal-objectivec-exceptions in ParseBundlerArgumentsTask. (#9493) Also add some tests.
2020-08-26 20:03:45 +03:00
<Output TaskParameter="MarshalManagedExceptionMode" PropertyName="_MarshalManagedExceptionMode" />
<Output TaskParameter="MarshalObjectiveCExceptionMode" PropertyName="_MarshalObjectiveCExceptionMode" />
[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
<Output TaskParameter="NoSymbolStrip" PropertyName="_NoSymbolStrip"/>
<Output TaskParameter="NoDSymUtil" PropertyName="_NoDSymUtil"/>
[msbuild] Parse the --optimize extra bundler arguments in ParseBundlerArgumentsTask. (#9572) Also add some tests.
2020-09-02 16:05:31 +03:00
<Output TaskParameter="Optimize" PropertyName="_BundlerOptimize"/>
[msbuild] Parse the --registrar extra bundler argument in ParseBundlerArgumentsTask. (#9606) Also add some tests.
2020-09-09 16:42:33 +03:00
<Output TaskParameter="Registrar" PropertyName="_BundlerRegistrar" />
[dotnet] Add Verbosity to the linker configuration. (#9169)
2020-07-23 19:07:05 +03:00
<Output TaskParameter="Verbosity" PropertyName="_BundlerVerbosity" />
[msbuild] Parse the --xml extra bundler argument in ParseBundlerArgumentsTask. (#9639) Also add some tests.
2020-09-16 10:42:21 +03:00
<Output TaskParameter="XmlDefinitions" ItemName="_BundlerXmlDefinitions" />
[msbuild] Add ILStrip'ing for net6 applications. Fixes #11445. (#12563) - Controlled by EnableAssemblyILStripping which defaults to true - Integration test included Before - https://gist.github.com/chamons/c7886f7bacbc2e5ac5966e4251d13e71 After - https://gist.github.com/chamons/148e1bef22fa336f953f3d02dcf20667 859,136 -> 527,872 managed Fixes https://github.com/xamarin/xamarin-macios/issues/11445.
2021-10-05 17:43:22 +03:00
<Output TaskParameter="NoStrip" PropertyName="EnableAssemblyILStripping" />
[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
</ParseBundlerArguments>
[msbuild] Use the ParseBundlerArguments task to parse mmp's --custom_bundle_name argument. (#9709)
2020-09-29 09:42:28 +03:00
<PropertyGroup>
<_CustomBundleName Condition="'$(_CustomBundleName)' == ''">MonoBundle</_CustomBundleName>
</PropertyGroup>
[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
</Target>
[msbuild] Share some of the code signing targets between Xamarin.Mac and Xamarin.iOS. (#8710)
2020-06-01 11:23:17 +03:00
<!-- Code signing -->
<PropertyGroup>
<CoreCodesignDependsOn>
$(CoreCodesignDependsOn);
_CodesignAppBundle;
_CodesignVerify;
</CoreCodesignDependsOn>
<CodesignDependsOn>
$(CodesignDependsOn);
BeforeCodeSign;
CoreCodeSign;
AfterCodeSign;
</CodesignDependsOn>
</PropertyGroup>
<Target Name="BeforeCodesign" />
<Target Name="CoreCodesign" DependsOnTargets="$(CoreCodesignDependsOn)" />
<Target Name="AfterCodesign" />
<Target Name="Codesign" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="$(CodesignDependsOn)" />
[msbuild] Share the CodesignNativeLibraries target between Xamarin.iOS and Xamarin.Mac. (#9775)
2020-10-06 15:18:31 +03:00
<PropertyGroup>
<_CodesignNativeLibrariesDependsOn>
$(_CodesignNativeLibrariesDependsOn);
_DetectSigningIdentity;
_CompileToNative;
</_CodesignNativeLibrariesDependsOn>
</PropertyGroup>
<!-- Note:
Always codesign *.dylibs even for Simulator builds for iOS/tvOS/watchOS. We use $(_CanOutputAppBundle) because dylibs can exist in app extensions as well.
For macOS we sign if _RequireCodeSigning is true
-->
<Target Name="_CodesignNativeLibraries" Condition="'$(_CanOutputAppBundle)' == 'true' And ('$(_RequireCodeSigning)' == 'true' Or '$(_PlatformName)' != 'macOS')" DependsOnTargets="$(_CodesignNativeLibrariesDependsOn)">
<PropertyGroup>
<_CodesignDisableTimestamp>False</_CodesignDisableTimestamp>
<_CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</_CodesignDisableTimestamp>
<_LibraryCodeSigningKey>$(_CodeSigningKey)</_LibraryCodeSigningKey>
<_LibraryCodeSigningKey Condition="'$(_LibraryCodeSigningKey)' == ''">-</_LibraryCodeSigningKey>
</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
<ItemGroup Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">
[msbuild] Share the CodesignNativeLibraries target between Xamarin.iOS and Xamarin.Mac. (#9775)
2020-10-06 15:18:31 +03:00
<_CodesignNativeLibrary Include="$(_AppContentsPath)\**\*.dylib" />
<_CodesignNativeLibrary Include="$(_AppResourcesPath)\**\*.metallib" />
</ItemGroup>
[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
<ItemGroup Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">
[msbuild] Share the CodesignNativeLibraries target between Xamarin.iOS and Xamarin.Mac. (#9775)
2020-10-06 15:18:31 +03:00
<_CodesignNativeLibrary
Include="$(_AppBundlePath)\**\*.dylib;$(_AppBundlePath)\**\*.metallib"
Exclude="$(_AppBundlePath)\Watch\**;$(_AppBundlePath)\PlugIns\**"
/>
</ItemGroup>
<Codesign
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
CodesignAllocate="$(_CodesignAllocate)"
DisableTimestamp="$(_CodesignDisableTimestamp)"
ExtraArgs="$(CodesignExtraArgs)"
IsAppExtension="$(IsAppExtension)"
Keychain="$(CodesignKeychain)"
Resources="@(_CodesignNativeLibrary)"
SigningKey="$(_LibraryCodeSigningKey)"
StampPath="$(DeviceSpecificIntermediateOutputPath)codesign\"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
UseSecureTimestamp="$(UseHardenedRuntime)"
>
</Codesign>
</Target>
[msbuild] Share the _CodesignVerify target between iOS and Mac. (#12142) This brings the iOS logic to verify the signature in app extensions to Mac.
2021-07-22 16:48:19 +03:00
<Target Name="_CodesignVerify" Condition="'$(_RequireCodeSigning)' == 'true' And ('$(IsAppExtension)' == 'false' Or '@(_ResolvedAppExtensionReferences)' != '')" DependsOnTargets="_CodesignAppBundle">
<CodesignVerify
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '@(_ResolvedAppExtensionReferences)' != ''"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
CodesignAllocate="$(_CodesignAllocate)"
Resource="$(_AppBundlePath)PlugIns\%(_ResolvedAppExtensionReferences.Filename)%(_ResolvedAppExtensionReferences.Extension)"
[msbuild] Share the CodesignVerify task implementation between iOS and macOS. (#12918)
2021-10-06 16:51:42 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
[msbuild] Share the _CodesignVerify target between iOS and Mac. (#12142) This brings the iOS logic to verify the signature in app extensions to Mac.
2021-07-22 16:48:19 +03:00
>
</CodesignVerify>
<CodesignVerify
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
CodesignAllocate="$(_CodesignAllocate)"
Resource="$(AppBundleDir)"
[msbuild] Share the CodesignVerify task implementation between iOS and macOS. (#12918)
2021-10-06 16:51:42 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
[msbuild] Share the _CodesignVerify target between iOS and Mac. (#12142) This brings the iOS logic to verify the signature in app extensions to Mac.
2021-07-22 16:48:19 +03:00
>
</CodesignVerify>
</Target>
[mac] Add user-framework support for Xamarin.Mac (#10144) * Move existing tests to iOS subdirectory and adjust reference paths
2020-11-26 16:47:41 +03:00
<PropertyGroup>
<_CollectFrameworksDependsOn>
$(_CollectFrameworksDependsOn);
_CompileToNative;
</_CollectFrameworksDependsOn>
</PropertyGroup>
<Target Name="_CollectFrameworks" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="$(_CollectFrameworksDependsOn)">
<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
<_FrameworksDirectory Condition="'$(_FrameworksDirectory)' == '' And ('$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS')">$(_AppBundlePath)/Frameworks</_FrameworksDirectory>
<_FrameworksDirectory Condition="'$(_FrameworksDirectory)' == '' And ('$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst')">$(_AppBundlePath)/Contents/Frameworks</_FrameworksDirectory>
[mac] Add user-framework support for Xamarin.Mac (#10144) * Move existing tests to iOS subdirectory and adjust reference paths
2020-11-26 16:47:41 +03:00
</PropertyGroup>
<CollectFrameworks
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
FrameworksDirectory="$(_FrameworksDirectory)"
>
<Output TaskParameter="Frameworks" ItemName="_Frameworks"/>
</CollectFrameworks>
</Target>
<Target Name="_CodesignFrameworks" Condition="'$(_CanOutputAppBundle)' == 'true' And '@(_Frameworks)' != ''" DependsOnTargets="_DetectSigningIdentity;_CollectFrameworks"
Inputs="%(_Frameworks.Identity)" Outputs="$(DeviceSpecificIntermediateOutputPath)codesign\%(_Frameworks.Filename)%(_Frameworks.Extension)">
<PropertyGroup>
<_CodesignDisableTimestamp>False</_CodesignDisableTimestamp>
<_CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</_CodesignDisableTimestamp>
<_FrameworkCodeSigningKey>$(_CodeSigningKey)</_FrameworkCodeSigningKey>
<_FrameworkCodeSigningKey Condition="'$(_FrameworkCodeSigningKey)' == ''">-</_FrameworkCodeSigningKey>
</PropertyGroup>
<Codesign
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
CodesignAllocate="$(_CodesignAllocate)"
DisableTimestamp="$(_CodesignDisableTimestamp)"
Keychain="$(CodesignKeychain)"
Resources="@(_Frameworks)"
SigningKey="$(_FrameworkCodeSigningKey)"
ExtraArgs="$(CodesignExtraArgs)"
[msbuild] Set `UseSecureTimestamp` inside `_CodesignFrameworks` too (#12387) That's needed for Xamarin.Mac and was _lost_ when the task was merged between XI and XM. Fixes https://github.com/xamarin/xamarin-macios/issues/11784
2021-08-10 17:39:08 +03:00
UseSecureTimestamp="$(UseHardenedRuntime)"
[mac] Add user-framework support for Xamarin.Mac (#10144) * Move existing tests to iOS subdirectory and adjust reference paths
2020-11-26 16:47:41 +03:00
>
</Codesign>
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(DeviceSpecificIntermediateOutputPath)codesign" />
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AlwaysCreate="true"
Files="$(DeviceSpecificIntermediateOutputPath)codesign\%(_Frameworks.Filename)%(_Frameworks.Extension)"
>
<Output TaskParameter="TouchedFiles" ItemName="FileWrites" />
</Touch>
</Target>
[dotnet] Turn the linker off by default for simulator builds. (#9403) This becomes a bit complicated because we have to wait to determine the default value for the linker until we know if we're building for the simulator or not (which happens in the _DetectSdkLocations target).
2020-08-20 15:26:43 +03:00
<!-- LinkMode -->
<PropertyGroup>
<_ComputeLinkModeDependsOn>
$(_ComputeLinkModeDependsOn);
_DetectSdkLocations;
</_ComputeLinkModeDependsOn>
</PropertyGroup>
<Target Name="_ComputeLinkMode" DependsOnTargets="$(_ComputeLinkModeDependsOn)">
<PropertyGroup>
<_LinkMode Condition="'$(_LinkMode)' == '' And '$(_PlatformName)' == 'macOS'">$(LinkMode)</_LinkMode>
<_LinkMode Condition="'$(_LinkMode)' == '' And '$(_PlatformName)' != 'macOS'">$(MtouchLink)</_LinkMode>
<_LinkMode Condition="'$(_LinkMode)' == ''">$(_DefaultLinkMode)</_LinkMode> <!-- Let the .NET targets chime in -->
<_LinkMode Condition="'$(_LinkMode)' == '' And '$(_PlatformName)' == 'macOS'">None</_LinkMode> <!-- Linking is off by default for macOS apps -->
<_LinkMode Condition="'$(_LinkMode)' == '' And '$(_PlatformName)' != 'macOS'">SdkOnly</_LinkMode> <!-- Default linking is SdkOnly for iOS/tvOS/watchOS apps -->
</PropertyGroup>
</Target>
Add support for arbitrary extensions to be bundled in XI/XM apps (#9048) - This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow extensions written in other languages, such as Swift, to be embedded and signed in an Xamarin App bundle easily. - Example: <AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native"> <Name>NativeTodayExtension</Name> <BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput> <BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput> </AdditionalAppExtensions>
2020-07-16 18:13:15 +03:00
<Target Name="_ExtendAppExtensionReferences" DependsOnTargets="_ResolveAppExtensionReferences" Condition=" '@(AdditionalAppExtensions)' != ''">
<!-- The idea here is that after _ResolveAppExtensionReferences we inject the 3rd party extensions into the list being processed later for embedding and code signing.
- _ResolvedAppExtensionReferences is an item group of the path, so that's easy.
- _AppExtensionCodesignProperties less so. It is generated by reading codesign.items generated by the c# tasks during build, which we don't have.
We also don't have a concrete list of types that get serialized, so I dug for every property referenced and set what I believe are sane values.-->
<ItemGroup>
<_ResolvedAppExtensionReferences Include="%(AdditionalAppExtensions.Identity)/%(AdditionalAppExtensions.BuildOutput)/%(AdditionalAppExtensions.Name).appex" />
<_AppExtensionCodesignProperties Include="%(AdditionalAppExtensions.Name).appex">
Fixed issue with code signing when using multiple AdditionalAppExtensions (#9846)
2020-10-21 17:27:45 +03:00
<Entitlements Condition="Exists('%(AdditionalAppExtensions.Identity)/%(AdditionalAppExtensions.Name).entitlements')">%(AdditionalAppExtensions.Identity)/%(AdditionalAppExtensions.Name).entitlements</Entitlements>
Add support for arbitrary extensions to be bundled in XI/XM apps (#9048) - This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow extensions written in other languages, such as Swift, to be embedded and signed in an Xamarin App bundle easily. - Example: <AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native"> <Name>NativeTodayExtension</Name> <BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput> <BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput> </AdditionalAppExtensions>
2020-07-16 18:13:15 +03:00
<SigningKey>$(CodesignKey)</SigningKey>
<Keychain>$(CodesignKeychain)</Keychain>
<DisableTimestamp>False</DisableTimestamp>
<DisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</DisableTimestamp>
<CodesignAllocate>$(_CodesignAllocate)</CodesignAllocate>
<ResourceRules>$(CodesignResourceRules)</ResourceRules>
<NativeExecutable>%(AdditionalAppExtensions.Filename)</NativeExecutable>
</_AppExtensionCodesignProperties>
</ItemGroup>
</Target>
[msbuild] Move Xamarin.iOS' implementation of the PrepareResourceRules task to Xamarin.MacDev.Tasks. (#9318)
2020-08-07 15:54:38 +03:00
<Target Name="_PrepareResourceRules" DependsOnTargets="_DetectSdkLocations;_GenerateBundleName">
<PrepareResourceRules
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '$(CodesignResourceRules)' != '' And '$(ComputedPlatform)' == 'iPhone'"
AppBundleDir="$(AppBundleDir)"
ResourceRules="$(CodesignResourceRules)"
SdkVersion="$(_SdkVersion)"
>
<Output TaskParameter="PreparedResourceRules" PropertyName="_PreparedResourceRules"/>
</PrepareResourceRules>
</Target>
[msbuild] Share the app extensions targets between iOS and Mac. (#10039) * Share the following targets: * _ResolveAppExtensionReferences * _SplitAppExtensionReferencesByExistent * _AssignAppExtensionConfiguration * _SeparateAppExtensionReferences * _CopyAppExtensionsToBundle The first four were pretty much identical between iOS and Mac already, and needed very few changes. The latter, _CopyAppExtensionsToBundle, required a little bit of tweaking to the targets to make sure it works for both iOS and Mac: * Removed the conditions on the Ditto task to check if we have app extensions - this is unnecessary because Inputs/Outputs on the target itself (which weren't there when the Ditto task conditions were written). * Added a '_PlaceAppExtensions' target that calculates where in the container's app bundle extensions should be placed (the '_AppExtensionRoot' property), and the name of the containing folder (the 'ContainerName' metadata).
2020-11-04 17:39:02 +03:00
<!-- App extensions -->
<Target Name="_AssignAppExtensionConfiguration" Condition="'@(_AppExtensionReference)' != ''">
<!-- assign configs if building a solution file -->
<AssignProjectConfiguration
ProjectReferences = "@(_AppExtensionReference)"
SolutionConfigurationContents = "$(CurrentSolutionConfigurationContents)"
Condition="'$(CurrentSolutionConfigurationContents)' != ''">
<Output TaskParameter="AssignedProjects" ItemName="_AppExtensionReferenceWithConfiguration"/>
</AssignProjectConfiguration>
<!-- Else, just -->
<CreateItem Include="@(_AppExtensionReference)"
Condition="'$(CurrentSolutionConfigurationContents)' == ''">
<Output TaskParameter="Include" ItemName="_AppExtensionReferenceWithConfiguration"/>
</CreateItem>
</Target>
<Target Name="_SeparateAppExtensionReferences" BeforeTargets="AssignProjectConfiguration">
<CreateItem Include="@(ProjectReference)" PreserveExistingMetadata="true" Condition="'%(Identity)' != '' And '%(ProjectReference.IsAppExtension)' == 'true'">
<Output ItemName="_AppExtensionReference" TaskParameter="Include" />
</CreateItem>
<ItemGroup>
<ProjectReference Remove="@(_AppExtensionReference)" />
</ItemGroup>
</Target>
<!-- Split App Extension projects into 2 lists
_AppExtensionReferenceWithConfigurationExistent: Projects existent on disk
_AppExtensionReferenceWithConfigurationNonExistent: Projects non-existent on disk -->
<Target Name="_SplitAppExtensionReferencesByExistent" DependsOnTargets="_AssignAppExtensionConfiguration">
<CreateItem Include="@(_AppExtensionReferenceWithConfiguration)" Condition="'@(_AppExtensionReferenceWithConfiguration)' != ''">
<Output TaskParameter="Include" ItemName="_AppExtensionReferenceWithConfigurationExistent"
Condition="Exists ('%(_AppExtensionReferenceWithConfiguration.Identity)')"/>
<Output TaskParameter="Include" ItemName="_AppExtensionReferenceWithConfigurationNonExistent"
Condition="!Exists ('%(_AppExtensionReferenceWithConfiguration.Identity)')"/>
</CreateItem>
</Target>
<Target Name="_ResolveAppExtensionReferences" DependsOnTargets="_SplitAppExtensionReferencesByExistent">
<PropertyGroup>
<!-- When building a .sln with msbuild, the dependent projects may not be built. So, always build
the referenced projects unless building from IDE. -->
<_BuildReferencedExtensionProjects Condition="'$(BuildingInsideVisualStudio)' != 'true'">true</_BuildReferencedExtensionProjects>
</PropertyGroup>
<!-- If the referenced projects have already been built, then just get the target paths -->
<MSBuild
Projects="@(_AppExtensionReferenceWithConfigurationExistent)"
Targets="GetBundleTargetPath"
Properties="%(_AppExtensionReferenceWithConfigurationExistent.SetConfiguration); %(_AppExtensionReferenceWithConfigurationExistent.SetPlatform)"
Condition="'@(_AppExtensionReferenceWithConfigurationExistent)' != '' and '$(_BuildReferencedExtensionProjects)' != 'true'">
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedAppExtensionReferences" Condition="'%(_AppExtensionReferenceWithConfigurationExistent.ReferenceOutputAssembly)' != 'false'"/>
</MSBuild>
<!-- Build the referenced project if required -->
<MSBuild
Projects="@(_AppExtensionReferenceWithConfigurationExistent)"
Properties="%(_AppExtensionReferenceWithConfigurationExistent.SetConfiguration); %(_AppExtensionReferenceWithConfigurationExistent.SetPlatform)"
Condition="'@(_AppExtensionReferenceWithConfigurationExistent)' != '' and '$(_BuildReferencedExtensionProjects)' == 'true' ">
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedAppExtensionReferences" Condition="'%(_AppExtensionReferenceWithConfigurationExistent.ReferenceOutputAssembly)' != 'false'"/>
</MSBuild>
<Warning Text="Referenced $(_PlatformName) App Extension Project %(_AppExtensionReferenceWithConfigurationNonExistent.Identity) not found, ignoring."
Condition="'@(_AppExtensionReferenceWithConfigurationNonExistent)' != ''"/>
</Target>
<Target Name="_PlaceAppExtensions" DependsOnTargets="_ExtendAppExtensionReferences;_ResolveAppExtensionReferences">
<ItemGroup>
<!-- Add a 'ContainerName' metadata to indicate where the extension should go inside the container's app bundle -->
<_ResolvedAppExtensionReferences Condition="'%(_ResolvedAppExtensionReferences.Extension)' == '.appex'">
<ContainerName>PlugIns</ContainerName>
</_ResolvedAppExtensionReferences>
<_ResolvedAppExtensionReferences Condition="'%(_ResolvedAppExtensionReferences.Extension)' == '.xpc'">
<ContainerName>XPCServices</ContainerName>
</_ResolvedAppExtensionReferences>
</ItemGroup>
<PropertyGroup>
<_AppExtensionRoot Condition="'$(_PlatformName)' == 'macOS'">$(_AppBundlePath)Contents\</_AppExtensionRoot>
<_AppExtensionRoot Condition="'$(_PlatformName)' != 'macOS'">$(_AppBundlePath)</_AppExtensionRoot>
</PropertyGroup>
</Target>
<Target Name="_CopyAppExtensionsToBundle"
DependsOnTargets="_ExtendAppExtensionReferences;_ResolveAppExtensionReferences;_PlaceAppExtensions"
Inputs="@(_ResolvedAppExtensionReferences)"
Outputs="$(_AppExtensionRoot)%(_ResolvedAppExtensionReferences.ContainerName)\%(_ResolvedAppExtensionReferences.FileName)%(_ResolvedAppExtensionReferences.Extension)"
>
<MakeDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="$(_AppExtensionRoot)%(_ResolvedAppExtensionReferences.ContainerName)"
/>
<Ditto
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(DittoExe)"
ToolPath="$(DittoPath)"
Source="@(_ResolvedAppExtensionReferences)"
Destination="$(_AppExtensionRoot)%(_ResolvedAppExtensionReferences.ContainerName)\%(_ResolvedAppExtensionReferences.FileName)%(_ResolvedAppExtensionReferences.Extension)"
/>
<!-- Delete any code signatures and dSYM dirs since they are now invalid -->
<RemoveDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="$(_AppExtensionRoot)%(_ResolvedAppExtensionReferences.ContainerName)\%(_ResolvedAppExtensionReferences.FileName)%(_ResolvedAppExtensionReferences.Extension)\_CodeSignature;
$(_AppBundlePath)..\%(_ResolvedAppExtensionReferences.FileName)%(_ResolvedAppExtensionReferences.Extension).dSYM"
/>
</Target>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Target Name="_GetNativeExecutableName" DependsOnTargets="_DetectAppManifest;_GenerateBundleName;_ReadAppManifest">
[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
<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
<_NativeExecutable Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">$(_AppBundlePath)$(_ExecutableName)</_NativeExecutable>
<_NativeExecutable Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">$(_AppBundlePath)Contents\MacOS\$(_ExecutableName)</_NativeExecutable>
[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
</PropertyGroup>
</Target>
<Target Name="_ReadAppExtensionDebugSymbolProperties">
<ReadItemsFromFile File="%(_ResolvedAppExtensionReferences.Identity)\..\dsym.items" Condition="Exists('%(_ResolvedAppExtensionReferences.Identity)\..\dsym.items')">
<Output TaskParameter="Items" ItemName="_AppExtensionDebugSymbolProperties" />
</ReadItemsFromFile>
</Target>
<Target Name="_GenerateAppExtensionDebugSymbols" Condition="'$(ComputedPlatform)' == 'iPhone' And '$(IsAppExtension)' == 'false'"
DependsOnTargets="_ParseBundlerArguments;_CompileToNative;_ReadAppExtensionDebugSymbolProperties"
Inputs="$(_AppBundlePath)PlugIns\%(_AppExtensionDebugSymbolProperties.Identity)\%(_AppExtensionDebugSymbolProperties.NativeExecutable)"
Outputs="$(AppBundleDir)\..\%(_AppExtensionDebugSymbolProperties.Identity).dSYM\Contents\Info.plist">
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(AppBundleDir)\..\%(_AppExtensionDebugSymbolProperties.Identity).dSYM" />
<!-- run dsymutil on the main bundle -->
<DSymUtil
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '%(_AppExtensionDebugSymbolProperties.NoDSymUtil)' == 'false'"
AppBundleDir="$(_AppBundlePath)PlugIns\%(_AppExtensionDebugSymbolProperties.Identity)"
Architectures="%(_AppExtensionDebugSymbolProperties.CompiledArchitectures)"
DSymDir="$(AppBundleDir)\..\%(_AppExtensionDebugSymbolProperties.Identity).dSYM"
Executable="$(_AppBundlePath)PlugIns\%(_AppExtensionDebugSymbolProperties.Identity)\%(_AppExtensionDebugSymbolProperties.NativeExecutable)"
ToolExe="$(DSymUtilExe)"
ToolPath="$(DSymUtilPath)"
>
</DSymUtil>
<!-- strip the debug symbols from the $(_NativeExecutable) -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '%(_AppExtensionDebugSymbolProperties.NoSymbolStrip)' == 'false'"
Executable="$(_AppBundlePath)PlugIns\%(_AppExtensionDebugSymbolProperties.Identity)\%(_AppExtensionDebugSymbolProperties.NativeExecutable)"
IsFramework="false"
SymbolFile="%(_AppExtensionDebugSymbolProperties.SymbolsList)"
>
</SymbolStrip>
<!-- touch the dSYM Info.plist so that its mtime is newer than the stripped $(_NativeExecutable) -->
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '%(_AppExtensionDebugSymbolProperties.NoSymbolStrip)' == 'false'"
Files="$(AppBundleDir)\..\%(_AppExtensionDebugSymbolProperties.Identity).dSYM\Contents\Info.plist"
>
</Touch>
</Target>
<Target Name="_CopyUserFrameworkDebugSymbols" Condition="('$(_PlatformName)' == 'macOS') Or ('$(ComputedPlatform)' == 'iPhone' And '$(IsWatchApp)' == 'false')" DependsOnTargets="_CompileToNative;_ParseBundlerArguments;"
Inputs="%(_FrameworkNativeReference.Name)"
Outputs="$(AppBundleDir)\..\%(_FrameworkNativeReference.Filename).framework.dSYM\Contents\Info.plist"
>
<PropertyGroup>
<_Source>$([System.IO.Path]::GetDirectoryName(%(_FrameworkNativeReference.Name)))\..\dSYMs\%(_FrameworkNativeReference.Filename).framework.dSYM\</_Source>
<_Destination>$(AppBundleDir)\..\%(_FrameworkNativeReference.Filename).framework.dSYM</_Destination>
</PropertyGroup>
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(_Destination)" />
<!-- if available copy the provided user frameworks .dSYM -->
<Ditto
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And Exists ('$(_Source)')"
Source="$(_Source)"
Destination="$(_Destination)"
>
</Ditto>
</Target>
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
<Target Name="_CalculateFrameworkDebugSymbolPath" DependsOnTargets="_CopyUserFrameworkDebugSymbols;_CollectFrameworks">
<ItemGroup>
<_Frameworks>
<_Destination>$(AppBundleDir)\..\%(Filename).framework.dSYM</_Destination>
</_Frameworks>
<_Frameworks>
<_DestinationExists>$([System.IO.File]::Exists('%(_Destination)'))</_DestinationExists>
</_Frameworks>
</ItemGroup>
</Target>
<Target Name="_GenerateFrameworkDebugSymbols" Condition="(('$(_PlatformName)' == 'macOS') Or (('$(ComputedPlatform)' == 'iPhone' And '$(IsWatchApp)' == 'false') and '$(IsMacEnabled)' == 'true'))" DependsOnTargets="_CopyUserFrameworkDebugSymbols;_CollectFrameworks;_CalculateFrameworkDebugSymbolPath"
[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
Inputs="%(_Frameworks.Identity)"
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
Outputs="%(_Frameworks._Destination)\Contents\Info.plist"
[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
>
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
<!-- Due to MSB4116 we can not check _DestinationExists in the condition for this target, thus all tasks must check it themselves -->
[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
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
<!-- run dsymutil on embedded frameworks -->
<DSymUtil
SessionId="$(BuildSessionId)"
Condition="'$(_NoDSymUtil)' == 'false' and '%(_Frameworks._DestinationExists)' != 'true' "
AppBundleDir="$(AppBundleDir)"
Architectures=""
DSymDir="%(_Frameworks._Destination)"
Executable="%(_Frameworks.Identity)"
ToolExe="$(DSymUtilExe)"
ToolPath="$(DSymUtilPath)">
</DSymUtil>
<!-- strip embedded frameworks -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(_NoSymbolStrip)' == 'false' and '%(_Frameworks._DestinationExists)' != 'true' "
Executable="%(_Frameworks.Identity)"
IsFramework="true"
SymbolFile="">
</SymbolStrip>
[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
<!-- _GenerateDebugSymbols will run spotlight to index the dSYMs -->
</Target>
<Target Name="_PrepareDebugSymbolGeneration" Condition="('$(_PlatformName)' == 'macOS') Or ('$(ComputedPlatform)' == 'iPhone' And '$(IsWatchApp)' == 'false')" DependsOnTargets="_CompileToNative;_ParseBundlerArguments"
Inputs="$(_NativeExecutable)" Outputs="$(DeviceSpecificOutputPath)dsym.items">
[windows][msbuild] Fix the use of a windows path inside `_PrepareDebugSymbolGeneration` (#11870) Revert a small part of #10409 so the path evaluation always happens on the mac computer (even if the build is done from Windows) Also dded a comment to avoid repeating that mistake again Fixes https://github.com/xamarin/xamarin-macios/issues/11817 Move task so it also work for Xamarin.Mac (since this is now shared code)
2021-06-09 16:19:42 +03:00
<!-- For App Extensions, we delay running dsymutil & strip until it has been copied into the main app bundle... -->
<!-- This needs to be executed in a task (and not here inside the target) so the execution always occur on the mac, even when the build is done from Windows -->
<GetFullPath SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" RelativePath="$(_MtouchSymbolsList)">
<Output TaskParameter="FullPath" PropertyName="_SymbolsListFullPath" />
</GetFullPath>
[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
<!-- For App Extensions, we delay running dsymutil & strip until it has been copied into the main app bundle... -->
<PropertyGroup>
<!-- [System.IO.Path]::GetFileName() is safe to use -->
<_NativeExecutableFileName>$([System.IO.Path]::GetFileName('$(_NativeExecutable)'))</_NativeExecutableFileName>
<_AppBundleFileName>$([System.IO.Path]::GetFileName('$(AppBundleDir)'))</_AppBundleFileName>
</PropertyGroup>
<ItemGroup>
<_AppExtensionDebugSymbolProperties Remove="@(_AppExtensionDebugSymbolProperties)" />
<_AppExtensionDebugSymbolProperties Include="$(_AppBundleFileName)">
<CompiledArchitectures>$(_CompiledArchitectures)</CompiledArchitectures>
<NativeExecutable>$(_NativeExecutableFileName)</NativeExecutable>
<NoSymbolStrip>$(_NoSymbolStrip)</NoSymbolStrip>
<SymbolsList>$(_SymbolsListFullPath)</SymbolsList>
<NoDSymUtil>$(_NoDSymUtil)</NoDSymUtil>
</_AppExtensionDebugSymbolProperties>
</ItemGroup>
<WriteItemsToFile
Condition="'$(IsMacEnabled)' == 'true'"
Items="@(_AppExtensionDebugSymbolProperties)"
ItemName="_AppExtensionDebugSymbolProperties"
File="$(DeviceSpecificOutputPath)dsym.items"
IncludeMetadata="true"
Overwrite="true"
/>
</Target>
[msbuild] Fix dSYM generation of iOS binding projects (#13112) - Fixes https://github.com/xamarin/xamarin-macios/issues/13096 - This was broken in https://github.com/xamarin/xamarin-macios/pull/10304
2021-10-29 18:20:44 +03:00
<PropertyGroup>
<GenerateDebugSymbolsDependsOn>
_CompileToNative;
_ParseBundlerArguments;
_CalculateFrameworkDebugSymbolPath;
_GenerateFrameworkDebugSymbols;
_GenerateAppExtensionDebugSymbols;
_PrepareDebugSymbolGeneration
</GenerateDebugSymbolsDependsOn>
</PropertyGroup>
<Target Name="_GenerateDebugSymbols" Condition="('$(_PlatformName)' == 'macOS') Or ('$(ComputedPlatform)' == 'iPhone' And '$(IsWatchApp)' == 'false')" DependsOnTargets="$(GenerateDebugSymbolsDependsOn)"
[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
Inputs="$(_NativeExecutable)" Outputs="$(AppBundleDir).dSYM\Contents\Info.plist">
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(IsAppExtension)' == 'false'" Directories="$(AppBundleDir).dSYM" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(IsAppExtension)' == 'false'" Files="$(DeviceSpecificOutputPath)*.bcsymbolmap" />
<!-- run dsymutil on the main bundle -->
<DSymUtil
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '$(_NoDSymUtil)' == 'false' And '$(IsAppExtension)' == 'false'"
AppBundleDir="$(AppBundleDir)"
Architectures="$(_CompiledArchitectures)"
DSymDir="$(AppBundleDir).dSYM"
Executable="$(_NativeExecutable)"
ToolExe="$(DSymUtilExe)"
ToolPath="$(DSymUtilPath)"
>
</DSymUtil>
<!-- strip the debug symbols from the $(_NativeExecutable) -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '$(_NoSymbolStrip)' == 'false' And '$(IsAppExtension)' == 'false'"
Executable="$(_NativeExecutable)"
IsFramework="false"
[msbuild] Fix copy/paste error from #11196 (#11206) Not sure how I could mess up a copy/paste between file - but I succeeded to create a subtle bug (would have expected it more crash happy) Fix issue #11151
2021-04-14 16:39:39 +03:00
SymbolFile="$(_MtouchSymbolsList)"
[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
>
</SymbolStrip>
<!-- touch the dSYM Info.plist so that its mtime is newer than the stripped $(_NativeExecutable) -->
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '$(_NoSymbolStrip)' == 'false' And '$(IsAppExtension)' == 'false' And Exists('$(AppBundleDir).dSYM')"
Files="$(AppBundleDir).dSYM\Contents\Info.plist"
>
</Touch>
<!-- make sure spotlight indexes everything we've built -->
<SpotlightIndexer
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And '$(_NoDSymUtil)' == 'false' And '$(IsAppExtension)' == 'false'"
Input="$(AppBundleDir)/../"
>
</SpotlightIndexer>
</Target>
[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
<PropertyGroup>
<ArchiveDependsOn>
_CoreArchive
</ArchiveDependsOn>
</PropertyGroup>
<Target Name="Archive" Condition="'$(_CanArchive)' == 'true'" DependsOnTargets="$(ArchiveDependsOn)" />
<Target Name="_CoreArchive" Condition="'$(ArchiveOnBuild)' == 'true'" DependsOnTargets="Codesign">
<Error Text="Code signing must be enabled to create an Xcode archive." Condition="'$(_CodeSigningKey)' == '' And '$(_PlatformName)' != 'macOS' And '$(_PlatformName)' != 'MacCatalyst'" />
<CollectITunesSourceFiles
SessionId="$(BuildSessionId)"
[msbuild] Don't execute the CollectITunesSourceFiles target on desktop platforms.
2021-07-26 14:37:16 +03:00
Condition="'$(IsMacEnabled)' == 'true' And '@(_ITunesSourceFile)' == '' And '$(_PlatformName)' != 'macOS' And '$(_PlatformName)' != 'MacCatalyst'"
[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
OutputPath="$(DeviceSpecificOutputPath)"
>
<Output TaskParameter="ITunesSourceFiles" PropertyName="_ITunesSourceFile"/>
</CollectITunesSourceFiles>
<Archive
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(AppBundleDir)"
AppExtensionReferences="@(_ResolvedAppExtensionReferences)"
CustomBundleName="$(_CustomBundleName)"
InsightsApiKey="$(XamarinInsightsApiKey)"
ITunesSourceFiles="@(_ITunesSourceFile)"
OutputPath="$(DeviceSpecificOutputPath)"
ProjectGuid="$(ProjectGuid)"
ProjectName="$(MSBuildProjectName)"
ProjectTypeGuids="$(ProjectTypeGuids)"
SigningKey="$(_CodeSigningKey)"
SolutionPath="$(SolutionPath)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
WatchAppReferences="@(_ResolvedWatchAppReferences)"
>
<Output TaskParameter="ArchiveDir" PropertyName="ArchiveDir"/>
</Archive>
</Target>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
<Target Name="_GenerateBundleName" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="_ComputeTargetArchitectures;_ParseBundlerArguments">
<PropertyGroup Condition="'$(AppBundleDir)' == ''">
<AppBundleDir Condition="'$(IsAppDistribution)' != 'true'">$(DeviceSpecificOutputPath)$(_AppBundleName)$(AppBundleExtension)</AppBundleDir>
<AppBundleDir Condition="'$(IsAppDistribution)' == 'true'">$(ArchivePath)\Products\Applications\$(_AppBundleName)$(AppBundleExtension)</AppBundleDir>
</PropertyGroup>
<PropertyGroup>
<_AppBundlePath>$(AppBundleDir)\</_AppBundlePath>
[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
<_AppResourcesPath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">$(_AppBundlePath)Contents\Resources\</_AppResourcesPath>
<_AppResourcesPath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">$(_AppBundlePath)</_AppResourcesPath>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +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
<_AppContentsPath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">$(_AppBundlePath)Contents\$(_CustomBundleName)</_AppContentsPath>
<_AppContentsPath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">$(_AppBundlePath)</_AppContentsPath>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
</PropertyGroup>
<PropertyGroup Condition="'$(IsAppExtension)' == 'true'">
<!-- needed for GetTargetPath/Build/Rebuild task outputs -->
<_AppExtensionBundlePath>$(MSBuildProjectDirectory)\$(AppBundleDir)</_AppExtensionBundlePath>
</PropertyGroup>
<ItemGroup Condition="'$(IsAppExtension)' == 'true'">
<_AppExtensionBundlePath Include="$(MSBuildProjectDirectory)\$(AppBundleDir)">
<!-- We need this metadata to fix the source in VS -->
<BuildSessionId>$(BuildSessionId)</BuildSessionId>
<BuildServerPath>..\..\$(BuildAppName)\$(BuildSessionId)\$(AppBundleDir)</BuildServerPath>
</_AppExtensionBundlePath>
</ItemGroup>
</Target>
[msbuild] Rework how the app manifest is created. How we create the app manifest (Info.plist) has to be modified so that we can add support for getting all the values from MSBuild properties (i.e. no Info.plist in the project), as well as having multiple partial app manifests as well, that gets merged into the final app manifest. Here's the new process: 1. The user can specify values in multiple ways: * An Info.plist in their project file (by using a `None` item with filename "Info.plist" or with a `Link` metadata with filename "Info.plist"). We figure this out in the DetectAppManifest target. * A partial plist in their project (using the `PartialAppManifest` item group) * Some MSBuild properties can also add values. The precedence is: MSBuild properties can be overridden by the Info.plist, which can be overridden by a partial plist. 2. In the `CompileAppManifest` target we get all the inputs from above, and compute a temporary app manifest, which is written to a temporary output file. 3. In the `ReadAppManifest` target, we read the temporary output file and outputs numerous MSBuild properties (most of then private) 4. We run other targets that may add more entries to the final app manifest (these tasks might depend on the values from `ReadAppManifest`). These entries are written to partial plists, and added to the _PostCompilePartialAppManifest item group. The targets in question are: * _CompileImageAssets * _CompileCoreMLModels 5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest` + any `_PartialAppManfiest` items and merge them all together to get the final Info.plist. This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity task to the CompileAppManifest task. This also meant reordering these two tasks, so that the DetectSigningIdentity task is executed after the CompileAppManifest task (technically after the ReadAppManifest task), because the DetectSigningIdentity task needs to know the bundle identifier. This way we can handle multiple scenarios easily (most of this is not covered by these changes, and will be implemented separately): * No Info.plist at all, all non-default values come from MSBuild properties. * A single Info.plist, where everything is specified. * An Info.plist with multiple partial app manifests as well.
2021-08-04 13:42:43 +03:00
<Target Name="_CompileProductDefinition" Condition="$(CreatePackage)" DependsOnTargets="_WriteAppManifest;_ComputeTargetArchitectures">
[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
<CompileProductDefinition
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
[msbuild] Both the CompileProductDefinition and the CreateInstaller tasks must take the final app manifest as input. (#12483) Both the CompileProductDefinition and the CreateInstaller tasks must take the final app manifest as input, because there may now be multiple input manifests (or one day none at all), and the final app manifest is the only version that is guaranteed to exist and contain everything.
2021-08-23 10:19:25 +03:00
AppManifest="$(_AppBundleManifest)"
[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
OutputDirectory="$(IntermediateOutputPath)"
ProductDefinition="$(ProductDefinition)"
TargetArchitectures="$(TargetArchitectures)"
>
<Output TaskParameter="CompiledProductDefinition" PropertyName="_CompiledProductDefinition" />
</CompileProductDefinition>
</Target>
Submodule MonoTouch.Dialog. (#13058) * Submodule MonoTouch.Dialog. Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This submodule will become redundant when/if we publish a .NET version of MonoTouch.Dialog, but until that happens we need it at least for our own test suites. This also means we have to copy our NuGet.config and global.json files to the MonoTouch.Dialog project directory so that we point msbuild to use our local build. New commits in spouliot/Touch.Unit: * spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109) Diff: https://github.com/spouliot/Touch.Unit/compare/3345db2f4e6408fdf2e8f099251c5c1310b56937..cbda70358360329854ea399100a2b5b04ae43982 * Use relative path for submodule. And fix indentation and set the branch name. * Don't use 'RootTestsDirectory' when it might not be defined yet. * [tests] Our test projects don't need to reference MonoTouch.Dialog directly. The projects get the MonoTouch.Dialog reference indirectly through the Touch.Client project reference. * [tests] Only validate unique errors in the .NET unit tests. * [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project. * [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere. * [msbuild] Only try to create a package if we're able to create an app bundle. This fixes an issue where a library project would try (and fail) to create a package when 'CreatePackage=true' (which could be set for the executable project, but inherited by the library project since the executable project depends on it). * [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property. MSBuild ends up being very confused when the project we're trying to build depends on other projects, because AssemblyName is set for all the projects being build, and MSBuild complains about ambiguous projects: > error: Ambiguous project name 'bindings-xcframework-test'
2021-10-26 09:18:34 +03:00
<Target Name="_CreateInstaller" Condition="'$(CreatePackage)' == 'true' And '$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="Codesign;_CompileProductDefinition;_WriteAppManifest">
[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
<CreateInstallerPackage
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(AppBundleDir)"
[msbuild] Both the CompileProductDefinition and the CreateInstaller tasks must take the final app manifest as input. (#12483) Both the CompileProductDefinition and the CreateInstaller tasks must take the final app manifest as input, because there may now be multiple input manifests (or one day none at all), and the final app manifest is the only version that is guaranteed to exist and contain everything.
2021-08-23 10:19:25 +03:00
AppManifest="$(_AppBundleManifest)"
[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
EnablePackageSigning="$(EnablePackageSigning)"
MainAssembly="$(TargetPath)"
Name="$(AssemblyName)"
OutputDirectory="$(TargetDir)"
PackageSigningKey="$(PackageSigningKey)"
PackagingExtraArgs="$(PackagingExtraArgs)"
[dotnet] Add support for 'dotnet publish'. Fixes #11807. (#12397) * Add support for 'dotnet publish'. * Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild property to specify the resulting .pkg path, to reflect the existing 'IpaPackagePath' (for iOS and tvOS). * Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever used this... * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
2021-08-11 11:01:16 +03:00
PkgPackagePath="$(PkgPackagePath)"
[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
ProductDefinition="$(_CompiledProductDefinition)"
ProjectPath="$(MSBuildProjectFullPath)"
>
[dotnet] Add support for 'dotnet publish'. Fixes #11807. (#12397) * Add support for 'dotnet publish'. * Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild property to specify the resulting .pkg path, to reflect the existing 'IpaPackagePath' (for iOS and tvOS). * Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever used this... * Add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
2021-08-11 11:01:16 +03:00
<Output TaskParameter="PkgPackagePath" PropertyName="PkgPackagePath" />
[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
</CreateInstallerPackage>
</Target>
[msbuild] Move the CreateIpa target to shared code. There was a main version of this target for Xamarin.iOS, and then numerous dummy targets for two scenarios: * Building app extensions. * Building macOS apps. The first one is handled by the '_CanArchive' property (will be false when building app extensions), and for the second case I've added it to the condition on the CreateIpa target. This way we don't have to have logic elsewhere about when it's valid to call CreateIpa.
2021-07-27 15:41:00 +03:00
<PropertyGroup>
<!-- Extensibility point for VS Publishing Workflow -->
<_BeforeCreateIpaForDistributionDependsOn />
<CreateIpaDependsOn>
_BeforeCreateIpaForDistribution;
_CompileEntitlements;
_CoreCreateIpa;
_PackageOnDemandResources;
_ZipIpa
</CreateIpaDependsOn>
</PropertyGroup>
<Target Name="_BeforeCreateIpaForDistribution" Condition="'$(IsAppDistribution)' == 'true'" DependsOnTargets="$(_BeforeCreateIpaForDistributionDependsOn)" />
[msbuild] Disable the CreateIpa target on macOS and Mac Catalyst.
2021-07-28 19:27:35 +03:00
<Target Name="CreateIpa" Condition="'$(_CanArchive)' == 'true' And '$(_PlatformName)' != 'macOS' And '$(_PlatformName)' != 'MacCatalyst'" DependsOnTargets="$(CreateIpaDependsOn)" />
[msbuild] Move the CreateIpa target to shared code. There was a main version of this target for Xamarin.iOS, and then numerous dummy targets for two scenarios: * Building app extensions. * Building macOS apps. The first one is handled by the '_CanArchive' property (will be false when building app extensions), and for the second case I've added it to the condition on the CreateIpa target. This way we don't have to have logic elsewhere about when it's valid to call CreateIpa.
2021-07-27 15:41:00 +03:00
[msbuild] Add a Xamarin.Shared.ObjCBinding.targets file for shared binding code between Xamarin.iOS and Xamarin.Mac. (#9437) Add a Xamarin.Shared.ObjCBinding.targets file for shared binding code between Xamarin.iOS and Xamarin.Mac and start sharing some of the binding code.
2020-08-21 15:55:00 +03:00
<Import Project="$(MSBuildThisFileDirectory)Xamarin.Shared.ObjCBinding.targets" Condition="'$(IsBindingProject)' == 'true'" />
[msbuild] Share the logic to implicitly include netstandard.dll in the build. (#9146) In addition to the obvious benefit of reducing code duplication, this also means that implicit inclusion of netstandard.dll works for binding projects as well. The existing implementations were slightly different between Xamarin.iOS and Xamarin.Mac, so I tried to figure out the best merging strategy based on git history and looking at the original implementation of this code in MSBuild. I tried to keep close to the original implementation whenever I couldn't find a good reason to do otherwise.
2020-07-22 15:57:35 +03:00
<!-- Xamarin.ImplicitFacade.targets will detect if we need to add an implicit reference to netstandard.dll -->
<Import Project="$(MSBuildThisFileDirectory)Xamarin.ImplicitFacade.targets" Condition="!('$(_PlatformName)' == 'macOS' And '$(TargetFrameworkName)' == 'System')"/>
[msbuild] Share three stub targets for Windows between Xamarin.iOS and Xamarin.Mac. (#9443) These only apply to Xamarin.iOS right now, since they're Windows-specific (and we don't support Xamarin.Mac binding projects on Windows), but if we ever do end up supporting binding projects for Xamarin.Mac on Windows, we'll need these targets there, so just make them shared code.
2020-08-21 19:10:32 +03:00
<Import Project="$(MSBuildThisFileDirectory)Xamarin.Shared.Stubs.targets" />
Add 'NoBindingEmbedding' style binding project support (#5167) - Existing binding projects embed the native libraries within the assembly as managed resource - This does not scale well and has performance implications - This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently. - Existing binding projects are not affected, they will continue as is - I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects. -When we complete some form of msbuild testing reform, we'll revisit these tests. - Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere) - Remove unnecessary sleep and fix broken touch command - Output failing test log to console instead of test output - VSfM does not handle thousands of lines of test failure message well - Add ability to generate binding projects with LinkWith
2018-12-12 17:55:57 +03:00
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets"
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets')"/>
</Project>