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

2974 строки
148 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.CompileITunesMetadata" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.CreateAssetPack" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask Condition="'$(_PlatformName)' != 'macOS'" TaskName="Xamarin.iOS.Tasks.FindWatchOS2AppBundle" 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.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.Mmp" 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)" />
[msbuild] Unify the CompileAppManifest task logic between iOS and Mac. (#15474)
2022-07-14 17:20:56 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CompileAppManifest" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the CreateEmbeddedResources task between iOS and Mac. (#15500) I've chosen the iOS implementation, since it's a bit more advanced to support remote builds (the Mac implementation didn't do anything at all). This should have no effect, since we don't support remote builds for macOS anyways.
2022-08-18 17:56:23 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateEmbeddedResources" 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 CompileSceneKitAsset task logic between iOS and Mac and improve it. (#15176) * Unify the CompileSceneKitAsset task implementation between iOS and Mac. There were no real differences, so might as well use the same code everywhere. * Use existing facilities for process launching. * Parallelize compiling.
2022-06-07 17:23:44 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CompileSceneKitAssets" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Add a ComputeBundleLocation task
2021-08-12 13:30:57 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ComputeBundleLocation" 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/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ComputeRemoteGeneratorProperties" 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] Move debug-related targets to shared code. (#14180)
2022-02-18 18:35:28 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateDebugConfiguration" AssemblyFile="$(_TaskAssemblyName)" />
<UsingTask TaskName="Xamarin.MacDev.Tasks.CreateDebugSettings" 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] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.ComputeCodesignItems" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Move debug-related targets to shared code. (#14180)
2022-02-18 18:35:28 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.DetectDebugNetworkConfiguration" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the DetectSdkLocations task logic between iOS and Mac. (#15256) This was mostly a clean merge, with a few minor differences: * We no longer compute whether we're running in the simulator or not when building for Mac Catalyst. * The task now supports building remotely for macOS (due to code sharing). Will be useful if we ever support building macOS apps remotely. * We now call AppleSdkSettings.Init () on macOS. No idea why we weren't before, but it seems logical for macOS to behave like our other platforms. There shouldn't be any other functional differences.
2022-06-17 00:52:43 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.DetectSdkLocations" AssemblyFile="$(_TaskAssemblyName)" />
[msbuild] Unify the DetectSigningIdentity task between iOS and Mac. (#15698) I've chosen the iOS implementation, since it's a bit more advanced to support remote builds (the Mac implementation didn't do anything at all). This should have no effect, since we don't support remote builds for macOS anyways.
2022-08-24 19:55:07 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.DetectSigningIdentity" 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] Move the GetFiles task to shared msbuild code (Xamarin.MacDev.Tasks). (#13800)
2022-01-20 18:22:01 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.GetFiles" 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] Unify the PrepareNativeReferences task between iOS and Mac. (#15473)
2022-07-14 17:21:10 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.PrepareNativeReferences" 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] Use our own Unzip task instead of Ditto when extracting compressed plugins. (#18015) This way we can make the extraction work on Windows for Hot Restart, since ditto doesn't exist on Windows. This requires a few other changes: * Move the Unzip task from the HotRestart tasks to be available everywhere. * Change the Unzip task to use our existing decompression logic, which calls 'unzip' on non-Windows platforms in order to correctly support symlinks.
2023-04-13 17:36:24 +03:00
<UsingTask TaskName="Xamarin.MacDev.Tasks.Unzip" 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] Set/fix the PublishFolderType and RelativePath metadata in several places. Set/fix the PublishFolderType and RelativePath metata for returned items in the ComputeBundleLocation and ResolveNativeReferences task, so that the new ComputeHotRestartBundleContents task has enough (and the correct) information to do the right thing with items that are to be copied to the app bundle.
2023-02-16 16:30:19 +03:00
<Target Name="_ExpandNativeReferences" Condition="'$(DesignTimeBuild)' != 'true'" DependsOnTargets="_DetectSdkLocations;_ComputeTargetArchitectures;_GenerateBundleName">
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] Set/fix the PublishFolderType and RelativePath metadata in several places. Set/fix the PublishFolderType and RelativePath metata for returned items in the ComputeBundleLocation and ResolveNativeReferences task, so that the new ComputeHotRestartBundleContents task has enough (and the correct) information to do the right thing with items that are to be copied to the app bundle.
2023-02-16 16:30:19 +03:00
FrameworksDirectory="$(_AppFrameworksRelativePath)"
[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)"
>
[msbuild/tests] Add support for xcframeworks with static libraries in them. (#13459) * [tests] Create a libtest.xcframework and libtest2.xcframework * [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library * [msbuild] Add support for xcframeworks with static libraries in them. * List the frameworks libtest needs. * [tests] Update .NET unit tests according to test project changes. * [tests] Add new test to verify that packing an old-style binding project doesn't work.
2021-11-30 20:19:22 +03:00
<Output TaskParameter="NativeFrameworks" ItemName="_ResolvedNativeReference" />
[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>
[msbuild/tests] Add support for xcframeworks with static libraries in them. (#13459) * [tests] Create a libtest.xcframework and libtest2.xcframework * [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library * [msbuild] Add support for xcframeworks with static libraries in them. * List the frameworks libtest needs. * [tests] Update .NET unit tests according to test project changes. * [tests] Add new test to verify that packing an old-style binding project doesn't work.
2021-11-30 20:19:22 +03:00
<ItemGroup>
<_FrameworkNativeReference Include="@(_ResolvedNativeReference)" Condition="'%(Kind)' == 'Framework'" />
<_FileNativeReference Include="@(_ResolvedNativeReference)" Condition="'%(Kind)' == 'Static' Or '%(Kind)' == 'Dynamic'" />
</ItemGroup>
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
[msbuild] Fix typo in comment. (#17220)
2023-01-13 23:58:57 +03:00
true: compressed (we produce an Assembly.resources.zip file)
false: not compressed (we produce an Assembly.resources directory)
[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
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." />
[msbuild] Hardcode values for the nuget short folder name for legacy builds. Fixes #13469. (#13478) The GetNuGetShortFolderName task only exists in .NET builds, which means we have to find another way to compute the path to resources in nugets for legacy builds. Do it the simple way by hardcoding the possible values. Fixes https://github.com/xamarin/xamarin-macios/issues/13469.
2021-12-02 09:43:23 +03:00
<!-- The 'GetNuGetShortFolderName' task only exists for .NET, so hardcode values for _NuGetShortFolderName for legacy builds -->
<PropertyGroup Condition="'$(UsingAppleNETSdk)' != 'true'">
<_NuGetShortFolderName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.iOS'">xamarinios10</_NuGetShortFolderName>
<_NuGetShortFolderName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.TVOS'">xamarintvos10</_NuGetShortFolderName>
<_NuGetShortFolderName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.WatchOS'">xamarinwatch10</_NuGetShortFolderName>
<_NuGetShortFolderName Condition="'$(TargetFrameworkIdentifier)' == 'Xamarin.Mac'">xamarinmac10</_NuGetShortFolderName>
</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
<!-- Figure out where to place the binding resources (see references above for more info) -->
<GetNuGetShortFolderName
TargetFrameworkMoniker="$(TargetFrameworkMoniker)"
[msbuild] Hardcode values for the nuget short folder name for legacy builds. Fixes #13469. (#13478) The GetNuGetShortFolderName task only exists in .NET builds, which means we have to find another way to compute the path to resources in nugets for legacy builds. Do it the simple way by hardcoding the possible values. Fixes https://github.com/xamarin/xamarin-macios/issues/13469.
2021-12-02 09:43:23 +03:00
TargetPlatformMoniker="$(TargetPlatformMoniker)"
Condition="'$(_NuGetShortFolderName)' == ''"
>
[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
<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>
[dotnet] macOS/MacCatalyst Archive and publishing support (#15720) These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac. Co-authored-by: Alex Soto <alex@alexsoto.me>
2022-08-26 09:18:43 +03:00
<Target Name="_CleanAppBundleRootDirectory" Condition="'$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS'" DependsOnTargets="_GenerateBundleName">
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
<!-- There shouldn't be any files in the root directory of the app bundle for macOS or Mac Catalyst (signing will fail) -->
<!-- Delete any crash dumps in the app bundle that might exist. Ref: https://github.com/xamarin/xamarin-macios/issues/12320 -->
<!-- Use a task to collect the files, so that we get the correct behavior on Windows -->
[msbuild] Improve logic to clean up app bundle for unwanted files. (#15080) The current directory at launch is the root directory of the app bundle. This means that any files written to the current directory when an app is executed, will be placed there. This becomes a problem when the app is rebuilt (and resigned), because a valid macOS app bundle doesn't have any files in the root directory of the app bundle, so signing fails. We have logic to automatically crash crash reports from the app bundle, but it turns out this is a more common problem with other types of files (and folders), so improve the logic a bit: * Add support for setting a property to automatically clean up everything from an app bundle we don't think should be there (which is anything not in a Contents/ subdirectory). * Use the same property to add support for disabling any cleaning (we already clean mono's crash reports by default). * Improve detection of unwanted files to include directories inside the app bundle, not only files. Ref: https://github.com/dotnet/maui/issues/7353
2022-05-30 12:34:45 +03:00
<!-- This is enabled by default, but can be disabled by setting EnableAutomaticAppBundleRootDirectoryCleanup=false -->
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
<GetFileSystemEntries
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And ('$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS')"
DirectoryPath="$(AppBundleDir)"
Pattern="mono_crash.*"
Recursive="false"
IncludeDirectories="false"
>
<Output TaskParameter="Entries" ItemName="_MonoCrashDumpsInAppBundle" />
</GetFileSystemEntries>
<Delete
SessionId="$(BuildSessionId)"
[msbuild] Improve logic to clean up app bundle for unwanted files. (#15080) The current directory at launch is the root directory of the app bundle. This means that any files written to the current directory when an app is executed, will be placed there. This becomes a problem when the app is rebuilt (and resigned), because a valid macOS app bundle doesn't have any files in the root directory of the app bundle, so signing fails. We have logic to automatically crash crash reports from the app bundle, but it turns out this is a more common problem with other types of files (and folders), so improve the logic a bit: * Add support for setting a property to automatically clean up everything from an app bundle we don't think should be there (which is anything not in a Contents/ subdirectory). * Use the same property to add support for disabling any cleaning (we already clean mono's crash reports by default). * Improve detection of unwanted files to include directories inside the app bundle, not only files. Ref: https://github.com/dotnet/maui/issues/7353
2022-05-30 12:34:45 +03:00
Condition="'$(IsMacEnabled)' == 'true' And ('$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS') And '$(EnableAutomaticAppBundleRootDirectoryCleanup)' != 'false'"
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
Files="@(_MonoCrashDumpsInAppBundle)"
/>
<!-- Warn about any files that are left -->
[msbuild] Improve logic to clean up app bundle for unwanted files. (#15080) The current directory at launch is the root directory of the app bundle. This means that any files written to the current directory when an app is executed, will be placed there. This becomes a problem when the app is rebuilt (and resigned), because a valid macOS app bundle doesn't have any files in the root directory of the app bundle, so signing fails. We have logic to automatically crash crash reports from the app bundle, but it turns out this is a more common problem with other types of files (and folders), so improve the logic a bit: * Add support for setting a property to automatically clean up everything from an app bundle we don't think should be there (which is anything not in a Contents/ subdirectory). * Use the same property to add support for disabling any cleaning (we already clean mono's crash reports by default). * Improve detection of unwanted files to include directories inside the app bundle, not only files. Ref: https://github.com/dotnet/maui/issues/7353
2022-05-30 12:34:45 +03:00
<!-- These can be deleted automatically by setting EnableAutomaticAppBundleRootDirectoryCleanup=true (in which case we won't show the warning) -->
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
<GetFileSystemEntries
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And ('$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS')"
DirectoryPath="$(AppBundleDir)"
Pattern="*"
[msbuild] Improve logic to clean up app bundle for unwanted files. (#15080) The current directory at launch is the root directory of the app bundle. This means that any files written to the current directory when an app is executed, will be placed there. This becomes a problem when the app is rebuilt (and resigned), because a valid macOS app bundle doesn't have any files in the root directory of the app bundle, so signing fails. We have logic to automatically crash crash reports from the app bundle, but it turns out this is a more common problem with other types of files (and folders), so improve the logic a bit: * Add support for setting a property to automatically clean up everything from an app bundle we don't think should be there (which is anything not in a Contents/ subdirectory). * Use the same property to add support for disabling any cleaning (we already clean mono's crash reports by default). * Improve detection of unwanted files to include directories inside the app bundle, not only files. Ref: https://github.com/dotnet/maui/issues/7353
2022-05-30 12:34:45 +03:00
Recursive="true"
IncludeDirectories="true"
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
>
<Output TaskParameter="Entries" ItemName="_FilesInAppBundleRootDirectory" />
</GetFileSystemEntries>
[msbuild] Improve logic to clean up app bundle for unwanted files. (#15080) The current directory at launch is the root directory of the app bundle. This means that any files written to the current directory when an app is executed, will be placed there. This becomes a problem when the app is rebuilt (and resigned), because a valid macOS app bundle doesn't have any files in the root directory of the app bundle, so signing fails. We have logic to automatically crash crash reports from the app bundle, but it turns out this is a more common problem with other types of files (and folders), so improve the logic a bit: * Add support for setting a property to automatically clean up everything from an app bundle we don't think should be there (which is anything not in a Contents/ subdirectory). * Use the same property to add support for disabling any cleaning (we already clean mono's crash reports by default). * Improve detection of unwanted files to include directories inside the app bundle, not only files. Ref: https://github.com/dotnet/maui/issues/7353
2022-05-30 12:34:45 +03:00
<!-- Remove anything in the Contents subdirectory from the list of files -->
<!-- You would think that it would be possible to remove using something like this:
<_FilesInAppBundleRootDirectory Remove="$(AppBundleDir)/Contents/**" />
but that doesn't remove directories, only files -->
<ItemGroup>
<_FilesInAppBundleRootDirectoryToRemove Include="@(_FilesInAppBundleRootDirectory)" Condition="$([MSBuild]::ValueOrDefault('%(Identity)', '').StartsWith('$(AppBundleDir)/Contents/'))" />
<_FilesInAppBundleRootDirectory Remove="@(_FilesInAppBundleRootDirectoryToRemove);$(AppBundleDir)/Contents" />
</ItemGroup>
<!-- We may have both files and directories, so just run both the Delete and RemoveDir task on all entries we're to delete -->
<Delete
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And ('$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS') And '$(EnableAutomaticAppBundleRootDirectoryCleanup)' == 'true'"
Files="@(_FilesInAppBundleRootDirectory)"
/>
<!-- Create a separate item group for directories, excluding anything with length <= 1. This is an additional protection against accidentally wiping out the hard drive: https://github.com/dotnet/msbuild/issues/4105 -->
<ItemGroup>
<_DirectoriesInAppBundleRootDirectory Include="@(_FilesInAppBundleRootDirectory)" Condition="$([MSBuild]::ValueOrDefault('%(Identity)', '').Length) &gt; 1" />
</ItemGroup>
<RemoveDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And ('$(_PlatformName)' == 'MacCatalyst' Or '$(_PlatformName)' == 'macOS') And '$(EnableAutomaticAppBundleRootDirectoryCleanup)' == 'true'"
Directories="@(_DirectoriesInAppBundleRootDirectory)"
/>
<Warning
Text="Found files in the root directory of the app bundle. This will likely cause codesign to fail. Files:%0a@(_FilesInAppBundleRootDirectory, '%0a')"
Condition="'$(EnableAutomaticAppBundleRootDirectoryCleanup)' != 'true' And @(_FilesInAppBundleRootDirectory->Count()) &gt; 0"/>
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
</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)" />
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)*.bcsymbolmap" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)postprocessing.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>
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)codesign.items" />
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath)codesign-bundle.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
<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] Make the CollectBundleResourcesDependsOn property public. Fixes #11984. (#14330) Make the CollectBundleResourcesDependsOn property public, so that custom targets can inject themselves into the build early enough to add additional BundleResource or Content items (by adding their custom target's name to the CollectBundleResourcesDependsOn property). Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
2022-03-09 20:19:48 +03:00
<!--
Custom targets that add items to the BundleResource or Content item groups must do so before the _CollectBundleResources target.
This can be achieved by adding your custom target to the CollectBundleResourcesDependsOn property group:
<CollectBundleResourcesDependsOn>
$(CollectBundleResourcesDependsOn);
MyTargetThatAddsBundleResources;
</CollectBundleResourcesDependsOn>
-->
<CollectBundleResourcesDependsOn>
$(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
_ComputeTargetArchitectures;
[msbuild] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
_ComputeTargetFrameworkMoniker;
[msbuild] Make the CollectBundleResourcesDependsOn property public. Fixes #11984. (#14330) Make the CollectBundleResourcesDependsOn property public, so that custom targets can inject themselves into the build early enough to add additional BundleResource or Content items (by adding their custom target's name to the CollectBundleResourcesDependsOn property). Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
2022-03-09 20:19:48 +03:00
</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] Make the CollectBundleResourcesDependsOn property public. Fixes #11984. (#14330) Make the CollectBundleResourcesDependsOn property public, so that custom targets can inject themselves into the build early enough to add additional BundleResource or Content items (by adding their custom target's name to the CollectBundleResourcesDependsOn property). Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
2022-03-09 20:19:48 +03:00
</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
</PropertyGroup>
[msbuild] Make the CollectBundleResourcesDependsOn property public. Fixes #11984. (#14330) Make the CollectBundleResourcesDependsOn property public, so that custom targets can inject themselves into the build early enough to add additional BundleResource or Content items (by adding their custom target's name to the CollectBundleResourcesDependsOn property). Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
2022-03-09 20:19:48 +03:00
<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/dotnet] Rework Hot Restart builds. Rework Hot Restart builds to use as much as possible of the normal build logic, because this is the easiest way to make sure the Hot Restart build is as close as possible to normal builds (and we don't end up missing features). This is done by executing selected parts of a normal build, and a the end we have a new task that computes where each file goes in the various output directories Hot Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir, etc.)
2023-02-16 16:30:19 +03:00
<!-- This task may be executed locally on Windows (for Hot Restart) -->
[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)"
[msbuild/dotnet] Rework Hot Restart builds. Rework Hot Restart builds to use as much as possible of the normal build logic, because this is the easiest way to make sure the Hot Restart build is as close as possible to normal builds (and we don't end up missing features). This is done by executing selected parts of a normal build, and a the end we have a new task that computes where each file goes in the various output directories Hot Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir, etc.)
2023-02-16 16:30:19 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'"
[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
OptimizePropertyLists="$(OptimizePropertyLists)"
OptimizePNGs="$(OptimizePNGs)"
BundleResources="@(Content);@(BundleResource)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
[msbuild] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
[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
>
<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>
[dotnet] Add support for the PublishFolderType metadata on Content and BundleResource items. (#14162) Add support for the PublishFolderType metadata on Content and BundleResource items, which makes it possible to change the location in the app bundle for these items (this was possible to do before with the Link metadata), but most importantly it also makes it possible to choose to *not* bundle these items in the app bundle (which was not possible before with the Link metadata, nor any other means). At first I thought setting CopyToPublishDirectory / CopyToOutputDirectory=Never would accomplish that, but it turns out we don't honor those, and since we already have this behavior of ignoring CopyToPublishDirectory / CopyToOutputDirectory in legacy Xamarin, I didn't want to change it in .NET. So I added support for honoring the PublishFolderType metadata instead, which is new and we already support for other item groups. This is accomplished by adding all Content and BundleResource items with PublishFolderType set to the ResolvedFileToPublish item group (where we already handle any PublishFolderType values), and then we ignore such Content and BundleResource items in our CollectBundleResources task. Also update the documentation and add tests.
2022-02-16 22:54:14 +03:00
<!-- Copy any items with the PublishFolderType metadata directly to the ResolvedFileToPublish item group -->
<ItemGroup>
<ResolvedFileToPublish Include="@(BundleResource)" Condition="'%(BundleResource.PublishFolderType)' != ''" />
<ResolvedFileToPublish Include="@(Content)" Condition="'%(Content.PublishFolderType)' != ''" />
</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)"
[msbuild] Use the general '[Compile|Read|Write]AppManifest' targets for hot restart. And then adjust the resulting app manifest for hot restart in the CompileHotRestartAppManifest target. This makes sure we handle app manifests for hot restart builds just like we do for normal builds.
2023-04-11 23:10:25 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == '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)"
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
AppManifest="$(AppBundleManifest)"
[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
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)"
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
[msbuild] Use the general '[Compile|Read|Write]AppManifest' targets for hot restart. And then adjust the resulting app manifest for hot restart in the CompileHotRestartAppManifest target. This makes sure we handle app manifests for hot restart builds just like we do for normal builds.
2023-04-11 23:10:25 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'"
[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
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
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>
[msbuild] Show a better error when a bundle identifier isn't provided. Fixes #14283. (#14402) Fixes https://github.com/xamarin/xamarin-macios/issues/14283.
2022-03-23 18:49:06 +03:00
<!-- A bundle identifier is required when creating an app bundle. It's not when building a class library -->
<Error
[msbuild] Use the general '[Compile|Read|Write]AppManifest' targets for hot restart. And then adjust the resulting app manifest for hot restart in the CompileHotRestartAppManifest target. This makes sure we handle app manifests for hot restart builds just like we do for normal builds.
2023-04-11 23:10:25 +03:00
Condition="('$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true') And '$(_BundleIdentifier)' == '' And '$(_CanOutputAppBundle)' == 'true'"
[msbuild] Show a better error when a bundle identifier isn't provided. Fixes #14283. (#14402) Fixes https://github.com/xamarin/xamarin-macios/issues/14283.
2022-03-23 18:49:06 +03:00
Text="A bundle identifier is required. Either add an 'ApplicationId' property in the project file, or add a 'CFBundleIdentifier' entry in the project's Info.plist file."
/>
[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
</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>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<!-- This target will create the $(_AppBundleManifestPath) file - any task that takes $(_AppBundleManifestPath) must depend on this 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="_WriteAppManifest"
Condition="'$(_CreateAppManifest)' == 'true'"
DependsOnTargets="$(_WriteAppManifestDependsOn)"
Inputs="@(_PostCompilePartialAppManifest);$(_TemporaryAppManifest)"
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
Outputs="$(_AppBundleManifestPath)"
[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
>
<WriteAppManifest
SessionId="$(BuildSessionId)"
[msbuild] Use the general '[Compile|Read|Write]AppManifest' targets for hot restart. And then adjust the resulting app manifest for hot restart in the CompileHotRestartAppManifest target. This makes sure we handle app manifests for hot restart builds just like we do for normal builds.
2023-04-11 23:10:25 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'"
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
AppBundleManifest="$(_AppBundleManifestPath)"
[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
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"
[msbuild] Execute _CompileEntitlements target on macOS under same conditions as for other platforms. The CompileEntitlements task already handles each platform as it should. This way we have fewer differences in the code between platforms.
2022-02-11 15:55:22 +03:00
Condition="'$(_RequireCodeSigning)' == 'true' Or '$(CodesignEntitlements)' != ''"
[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
DependsOnTargets="$(_CompileEntitlementsDependsOn)"
[dotnet/msbuild] Only compile entitlements once for universal builds. Fixes #15632. (#17096) Fixes https://github.com/xamarin/xamarin-macios/issues/15632.
2023-01-19 18:01:34 +03:00
Outputs="$(_CompiledEntitlementsPath)">
[msbuild] Automatically add the 'com.apple.security.cs.allow-jit' entitlement for desktop release builds. Fixes #15745. (#15927) * Add support for specifying custom entitlements with an MSBuild item group. * Use this new support to automatically add the 'com.apple.security.cs.allow-jit' entitlement to .NET desktop apps when building for release, since all apps that go through notarization will need it in order to be able to use the JIT. It's possible to override the default behavior by adding something like this to the project file: <ItemGroup> <CustomEntitlements Include="com.apple.security.cs.allow-jit" Type="Remove" /> </ItemGroup> Fixes https://github.com/xamarin/xamarin-macios/issues/15745.
2022-09-13 18:41:22 +03:00
<!-- Automatically add the 'allow-jit' entitlement for desktop release builds in .NET -->
<ItemGroup Condition="'$(Configuration)' == 'Release' And ('$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst') And '$(UsingAppleNETSdk)' == 'true'">
<!-- We need to compare the result of AnyHaveMetadataValue to 'true', because if it's empty, the return value is not a boolean, it's an empty string -->
<CustomEntitlements Condition="'@(CustomEntitlements->AnyHaveMetadataValue('Identity','com.apple.security.cs.allow-jit'))' != 'true'" Include="com.apple.security.cs.allow-jit" Type="Boolean" Value="true" />
</ItemGroup>
[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
<CompileEntitlements
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(AppBundleDir)"
AppIdentifier="$(_AppIdentifier)"
BundleIdentifier="$(_BundleIdentifier)"
[msbuild] Automatically add the 'com.apple.security.cs.allow-jit' entitlement for desktop release builds. Fixes #15745. (#15927) * Add support for specifying custom entitlements with an MSBuild item group. * Use this new support to automatically add the 'com.apple.security.cs.allow-jit' entitlement to .NET desktop apps when building for release, since all apps that go through notarization will need it in order to be able to use the JIT. It's possible to override the default behavior by adding something like this to the project file: <ItemGroup> <CustomEntitlements Include="com.apple.security.cs.allow-jit" Type="Remove" /> </ItemGroup> Fixes https://github.com/xamarin/xamarin-macios/issues/15745.
2022-09-13 18:41:22 +03:00
CustomEntitlements="@(CustomEntitlements)"
[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
Entitlements="$(CodesignEntitlements)"
[dotnet/msbuild] Only compile entitlements once for universal builds. Fixes #15632. (#17096) Fixes https://github.com/xamarin/xamarin-macios/issues/15632.
2023-01-19 18:01:34 +03:00
CompiledEntitlements="$(_CompiledEntitlementsPath)"
[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
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" />
[msbuild] Execute _CompileEntitlements target on macOS under same conditions as for other platforms. The CompileEntitlements task already handles each platform as it should. This way we have fewer differences in the code between platforms.
2022-02-11 15:55:22 +03:00
<!-- $(_CompiledCodesignEntitlements) will be used only with Codesign tasks when building for device or desktop. MUST NOT BE SET for iOS Simulator builds. -->
[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
<Output TaskParameter="EntitlementsInSignature" PropertyName="_CompiledCodesignEntitlements" />
</CompileEntitlements>
[msbuild] Resolve the path to the entitlements to a full path. This way the property works when exposed to containing projects as well.
2022-03-16 18:23:23 +03:00
<!-- The path to the entitlements must be resolved to the full path, because we might want to reference it from a containing project that just references this project,
and in that case it becomes a bit complicated to resolve to a full path on disk when building remotely from Windows. Instead just resolve to a full path here,
and use that from now on. This has to be done from a task, so that we get the full path on the mac when executed remotely from Windows. -->
<GetFullPath SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(_CompiledEntitlements)' != ''" RelativePath="$(_CompiledEntitlements)">
<Output TaskParameter="FullPath" PropertyName="_CompiledEntitlements" />
</GetFullPath>
<GetFullPath SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(_CompiledCodesignEntitlements)' != ''" RelativePath="$(_CompiledCodesignEntitlements)">
<Output TaskParameter="FullPath" PropertyName="_CompiledCodesignEntitlements" />
</GetFullPath>
[dotnet/msbuild] Only compile entitlements once for universal builds. Fixes #15632. (#17096) Fixes https://github.com/xamarin/xamarin-macios/issues/15632.
2023-01-19 18:01:34 +03:00
<ItemGroup>
<FileWrites Include="$(_CompiledEntitlementsPath)" />
</ItemGroup>
[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
</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>
[msbuild] Add a public 'CompileImageAssetsDependsOn' property. Fixes #16065. (#16089) Add a public 'CompileImageAssetsDependsOn' property, so that MAUI can inject tasks that must be completed before we compile image assets: ```xml <PropertyGroup> <CompileImageAssetsDependsOn> $(CompileImageAssetsDependsOn); ResizetizeCollectItems; </CompileImageAssetsDependsOn> </PropertyGroup> ``` Fixes https://github.com/xamarin/xamarin-macios/issues/16065.
2022-09-23 17:29:40 +03:00
$(CompileImageAssetsDependsOn);
[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
$(_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)"
Add Accent Color to ACTool task (#16844) This PR addresses https://github.com/xamarin/xamarin-macios/issues/10275 `actool` can set an application's "Global" color set, overwriting the system defaults. XCode sets this as "AccentColor," but when we call it directly, we don't pass in anything. This means a user cannot overwrite this setting themselves unless they rewrite the ACTool task. This PR adds support for the "AccentColor" property to set the accent color. To use this: - Create a new Asset Catalog or use the default. - Add a new ColorSet. - Set the "AccentColor" property in the project file: <PropertyGroup> <AccentColor>AccentColor</AccentColor> </PropertyGroup> You should now see the colors reflected in the application.
2022-11-23 19:15:04 +03:00
AccentColor="$(AccentColor)"
[msbuild] Unify the CompileImageAssets targets between Xamarin.iOS and Xamarin.Mac. (#10809)
2021-03-09 13:24:38 +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] 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/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<_MtouchSymbolsList Condition="'$(_MtouchSymbolsList)' == ''">$(DeviceSpecificIntermediateOutputPath)mtouch-symbols.list</_MtouchSymbolsList>
[msbuild] Share _ComputeTargetArchitectures and use the output variables for both Xamarin.iOS and Xamarin.Mac. (#8751)
2020-06-04 16:00:28 +03:00
<!-- 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>
[dotnet/msbuild] Only compile entitlements once for universal builds. Fixes #15632. (#17096) Fixes https://github.com/xamarin/xamarin-macios/issues/15632.
2023-01-19 18:01:34 +03:00
<_CompiledEntitlementsPath Condition="'$(_CompiledEntitlementsPath)' == ''">$(DeviceSpecificIntermediateOutputPath)Entitlements.xcent</_CompiledEntitlementsPath>
[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
<_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] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
<Target Name="_DetectAppManifest" DependsOnTargets="_GenerateBundleName;_ComputeTargetFrameworkMoniker">
[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
-->
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<FindItemWithLogicalName Condition="'$(AppManifestDetectionEnabled)' != 'false' And '$(AppBundleManifest)' == ''"
[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
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
[msbuild] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
Items="@(None)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<Output TaskParameter="Item" PropertyName="AppBundleManifest" />
[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
</FindItemWithLogicalName>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<FindItemWithLogicalName Condition="'$(AppManifestDetectionEnabled)' != 'false' And '$(AppBundleManifest)' == '' And '$(_CanOutputAppBundle)' == 'true'"
[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
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
[msbuild] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
Items="@(BundleResource)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<Output TaskParameter="Item" PropertyName="AppBundleManifest" />
[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
</FindItemWithLogicalName>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<FindItemWithLogicalName Condition="'$(AppManifestDetectionEnabled)' != 'false' And '$(AppBundleManifest)' == '' And '$(_CanOutputAppBundle)' == 'true'"
[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
SessionId="$(BuildSessionId)"
ProjectDir="$(MSBuildProjectDirectory)"
ResourcePrefix="$(_ResourcePrefix)"
LogicalName="Info.plist"
[msbuild] The CollectBundleResources and DetectAppManifest targets need to know the target framework moniker.
2021-08-12 13:30:57 +03:00
Items="@(Content)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<Output TaskParameter="Item" PropertyName="AppBundleManifest" />
[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
</FindItemWithLogicalName>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<Error Condition="'$(AppBundleManifest)' == '' 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>
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
<_AppBundleManifestPath>$(_AppBundlePath)$(_AppBundleManifestRelativePath)Info.plist</_AppBundleManifestPath>
[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>
[dotnet] macOS/MacCatalyst Archive and publishing support (#15720) These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac. Co-authored-by: Alex Soto <alex@alexsoto.me>
2022-08-26 09:18:43 +03:00
<_CreateAppManifest Condition="'$(IsAppDistribution)' == 'true'">false</_CreateAppManifest>
[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
<_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>
[msbuild/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
[msbuild/generator] Compile api definitions in MSBuild logic instead of inside the generator. (#18398#pullrequestreview-1498787955) This has a few advantages: * A step towards simplifying the generator. * A step towards being able to build binding projects on Windows, since it's easier to build C# code in MSBuild using the Csc task rather than figuring out how to call csc as an external program (which we've already done on macOS, but having a single solution that works on all platforms is preferrable). Note that this is only implemented for .NET, doing this for legacy Xamarin required a lot more work.
2023-06-26 18:29:12 +03:00
<_GenerateBindingsDependsOn Condition="'$(UsingAppleNETSdk)' == 'true'">
_CompileApiDefinitions;
$(_GenerateBindingsDependsOn);
</_GenerateBindingsDependsOn>
[msbuild/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
<_WriteGeneratorPropertiesDependsOn Condition="'$(UsingAppleNETSdk)' == 'true'">
$(_WriteGeneratorPropertiesDependsOn);
_ComputeBindingVariables;
</_WriteGeneratorPropertiesDependsOn>
[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>
[msbuild/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
<!-- We execute this target on the mac from the ComputeRemoteGeneratorProperties task since we can only compute these values from the mac -->
<Target Name="_WriteRemoteGeneratorProperties" DependsOnTargets="$(_WriteGeneratorPropertiesDependsOn)">
<ItemGroup>
<_ComputedRemoteGeneratorProperties Include="BaseLibDllPath=$(BaseLibDllPath)" />
<_ComputedRemoteGeneratorProperties Include="BTouchToolExe=$(BTouchToolExe)" />
<_ComputedRemoteGeneratorProperties Include="BTouchToolPath=$(BTouchToolPath)" />
<_ComputedRemoteGeneratorProperties Include="_DotNetCscCompiler=$(_DotNetCscCompiler)" />
<_ComputedRemoteGeneratorProperties Include="_GeneratorAttributeAssembly=$(_GeneratorAttributeAssembly)" />
</ItemGroup>
<WriteLinesToFile File="$(OutputFilePath)" Lines="@(_ComputedRemoteGeneratorProperties)" />
</Target>
[msbuild/generator] Compile api definitions in MSBuild logic instead of inside the generator. (#18398#pullrequestreview-1498787955) This has a few advantages: * A step towards simplifying the generator. * A step towards being able to build binding projects on Windows, since it's easier to build C# code in MSBuild using the Csc task rather than figuring out how to call csc as an external program (which we've already done on macOS, but having a single solution that works on all platforms is preferrable). Note that this is only implemented for .NET, doing this for legacy Xamarin required a lot more work.
2023-06-26 18:29:12 +03:00
<PropertyGroup>
<_ComputeCompileApiDefinitionsInputsDependsOn Condition="'$(UsingAppleNETSdk)' == 'true'">
$(_ComputeCompileApiDefinitionsInputsDependsOn);
_ComputeBindingVariables;
</_ComputeCompileApiDefinitionsInputsDependsOn>
</PropertyGroup>
<Target Name="_ComputeCompileApiDefinitionsInputs" DependsOnTargets="$(_ComputeCompileApiDefinitionsInputsDependsOn)">
<ItemGroup>
<BTouchReferencePath Include="@(ReferenceCopyLocalPaths)" Condition="'%(Extension)' == '.dll'" />
</ItemGroup>
<PropertyGroup>
<_CompiledApiDefinitionAssembly>$(DeviceSpecificIntermediateOutputPath)compiled-api-definitions.dll</_CompiledApiDefinitionAssembly>
<_CompiledApiDefinitionDefines>$(DefineConstants)</_CompiledApiDefinitionDefines>
<_CompiledApiDefinitionDefines Condition="'$(UsingAppleNETSdk)' == 'true'">$(_CompiledApiDefinitionDefines);NET</_CompiledApiDefinitionDefines>
<_CompiledApiDefinitionLibPaths>$(AdditionalLibPaths);$([System.IO.Path]::GetDirectoryName('$(BaseLibDllPath)'))</_CompiledApiDefinitionLibPaths>
<_CompiledApiDefinitionGlobalUsingsFile Condition="'$(UsingAppleNETSdk)' == 'true' And '$(NoNFloatUsing)' != 'true'">$(DeviceSpecificIntermediateOutputPath)compiled-api-definitions-usings.cs</_CompiledApiDefinitionGlobalUsingsFile>
</PropertyGroup>
<ItemGroup>
<_CompiledApiDefinitionReferences Include="$(_GeneratorAttributeAssembly)" />
<_CompiledApiDefinitionReferences Include="@(ReferencePath)" />
<_CompiledApiDefinitionReferences Include="@(BTouchReferencePath)" />
<_CompiledApiDefinitionsCompile Include="@(ObjcBindingApiDefinition)" />
<_CompiledApiDefinitionsCompile Include="@(ObjcBindingCoreSource)" />
</ItemGroup>
<WriteLinesToFile
Condition="'$(_CompiledApiDefinitionGlobalUsingsFile)' != ''"
File="$(_CompiledApiDefinitionGlobalUsingsFile)"
Lines="global using nfloat = global::System.Runtime.InteropServices.NFloat%3B"
Overwrite="true"
WriteOnlyWhenDifferent="true" />
<ItemGroup Condition="'$(_CompiledApiDefinitionGlobalUsingsFile)' != ''">
<_CompiledApiDefinitionsCompile Include="$(_CompiledApiDefinitionGlobalUsingsFile)" />
</ItemGroup>
</Target>
<Target Name="_CompileApiDefinitions"
Inputs="$(MSBuildAllProjects);
$(_CompiledApiDefinitionLibPaths);
$(_CompiledApiDefinitionGlobalUsingsFile);
@(_CompiledApiDefinitionReferences);
@(_CompiledApiDefinitionsCompile);"
Outputs="$(_CompiledApiDefinitionAssembly)"
DependsOnTargets="_ComputeCompileApiDefinitionsInputs"
Condition="'$(IsBindingProject)' == 'true' And '$(DesignTimeBuild)' != 'true'"
>
<!-- This is a mirror of the method GetCompiledApiBindingsAssembly in BindingTouch.cs where the compilation is done inside bgen -->
<Csc
AdditionalLibPaths="$(_CompiledApiDefinitionLibPaths)"
AllowUnsafeBlocks="true"
DebugType="portable"
DefineConstants="$(_CompiledApiDefinitionDefines)"
DisabledWarnings="436"
NoConfig="true"
NoStandardLib="true"
Deterministic="true"
OutputAssembly="$(_CompiledApiDefinitionAssembly)"
References="@(_CompiledApiDefinitionReferences)"
Sources="@(_CompiledApiDefinitionsCompile)"
TargetType="library"
ToolExe="$(CscToolExe)"
ToolPath="$(CscToolPath)"
UseHostCompilerIfAvailable="$(UseHostCompilerIfAvailable)"
UseSharedCompilation="$(UseSharedCompilation)"
VsSessionGuid="$(VsSessionGuid)"
>
</Csc>
</Target>
[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'">
[msbuild] Show an error when trying to build a binding project from Windows without a Mac connection. (#16612) Building a binding project from Windows without a Mac connection doesn't work, because we need to execute bgen. Currently we just skip every task and target that doesn't work from Windows, but that means nothing at all happens, which is confusing (in particular if the binding project is referenced by other projects, which will also fail to build). So make it more explicit that a connection to a Mac is required to build a binding project by showing a warning when there's no connection (and not an error because that could break existing workflows for customers). Ref: https://github.com/xamarin/xamarin-macios/issues/16611
2022-11-09 09:52:58 +03:00
<Warning Condition="'$(IsMacEnabled)' != 'true'" Text="It's currently not supported to build a binding project from Windows unless a connection to a Mac is available." />
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
<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/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
<!-- Compute some variables on the mac: this task is only executed when building on Windows -->
<ComputeRemoteGeneratorProperties
[msbuild/generator] Pass .NET's C# compiler to bgen to use. Fixes #12922. (#14192) We can't execute mono's C# compiler when using .NET, so we need to tell bgen where csc is in that case. Fixes https://github.com/xamarin/xamarin-macios/issues/12922.
2022-02-23 11:36:43 +03:00
SessionId="$(BuildSessionId)"
[msbuild/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
Condition="'$(IsMacEnabled)' == 'true' And '$(BuildSessionId)' != ''"
IntermediateOutputPath="$(IntermediateOutputPath)"
[msbuild/generator] Pass .NET's C# compiler to bgen to use. Fixes #12922. (#14192) We can't execute mono's C# compiler when using .NET, so we need to tell bgen where csc is in that case. Fixes https://github.com/xamarin/xamarin-macios/issues/12922.
2022-02-23 11:36:43 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
[msbuild/dotnet] Fix building binding projects on Windows in .NET (#14704) When building a binding project, we need to execute bgen (and csc) on the mac. Figuring out where these files are on the Mac is rather complicated from a remotely executed task, so instead we execute a sub-build that computes these properties. In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props' file using msbuild, and invoking a custom target that prints the property we're looking for (the 'targetGetPropertyValue_*' targets). For multiple reasons this approach doesn't work in .NET anymore (in particular it seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom 'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props' not work correctly since the properties we need wouldn't be set). So I'm adding a new task that does a sub-build, using either msbuild or dotnet as appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props' file, the task creates an actual binding project (an empty one), and executes the new '_WriteRemoteGeneratorProperties' target in this binding project. An additional advantage in this new task is that it will only execute one sub-build where all the properties are computed (the previous approach executed one sub-msbuild per property). In order to keep code as similar as possible between legacy Xamarin and .NET, the new task is being used for legacy Xamarin as well (and the old approach deleted). This fixes building binding projects on Windows in .NET.
2022-04-22 17:17:03 +03:00
<Output TaskParameter="BaseLibDllPath" PropertyName="BaseLibDllPath" />
<Output TaskParameter="BTouchToolExe" PropertyName="BTouchToolExe" />
<Output TaskParameter="BTouchToolPath" PropertyName="BTouchToolPath" />
<Output TaskParameter="DotNetCscCompiler" PropertyName="_DotNetCscCompiler" />
<Output TaskParameter="GeneratorAttributeAssembly" PropertyName="_GeneratorAttributeAssembly" />
</ComputeRemoteGeneratorProperties>
[msbuild/generator] Pass .NET's C# compiler to bgen to use. Fixes #12922. (#14192) We can't execute mono's C# compiler when using .NET, so we need to tell bgen where csc is in that case. Fixes https://github.com/xamarin/xamarin-macios/issues/12922.
2022-02-23 11:36:43 +03:00
[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)"
[msbuild/generator] Compile api definitions in MSBuild logic instead of inside the generator. (#18398#pullrequestreview-1498787955) This has a few advantages: * A step towards simplifying the generator. * A step towards being able to build binding projects on Windows, since it's easier to build C# code in MSBuild using the Csc task rather than figuring out how to call csc as an external program (which we've already done on macOS, but having a single solution that works on all platforms is preferrable). Note that this is only implemented for .NET, doing this for legacy Xamarin required a lot more work.
2023-06-26 18:29:12 +03:00
CompiledApiDefinitionAssembly="$(_CompiledApiDefinitionAssembly)"
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
DefineConstants="$(DefineConstants)"
EmitDebugInformation="$(BTouchEmitDebugInformation)"
ExtraArgs="$(BTouchExtraArgs)"
GeneratedSourcesDir="$(GeneratedSourcesDir)"
GeneratedSourcesFileList="$(_GeneratedSourcesFileList)"
Namespace="$(Namespace)"
[runtime] Remove ObjCRuntime.nfloat in favor of System.Runtime.InteropServices.NFloat. (#14197) * Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat). * Automatically add a reference to the System.Runtime.InteropServices.Internal package, so that developers get the new NFloat API (with operators) we've added post .NET 6 (but don't do this for .NET 7). * Automatically add a global using alias for System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the usual `ImplicitUsings` condition our other implicit usings are, because they're off by default for existing projects, and the main target for the global using alias for nfloat is upgraded projects. * Automatically generate a global using alias (like above) in the generator for all code the generator compiles. * Update xtro entries to reference System.Runtime.InteropServices.NFloat instead of ObjCRuntime.nfloat. * Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the wrong runtime pack is selected otherwise (without the new NFloat API, so nothing works at runtime). Ref: https://github.com/xamarin/xamarin-macios/issues/13087
2022-02-24 18:51:12 +03:00
NoNFloatUsing="$(NoNFloatUsing)"
[msbuild] Unify the _GenerateBindings target and a few properties related to binding projects. (#8997)
2020-07-07 16:46:23 +03:00
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)"
[msbuild] Only require a provisioning profile if we have non-empty entitlements. (#15918) This is the behavior in legacy Xamarin (for mobile projects): if a project contains a CodesignEntitlements=Entitlements.plist property, we require a provisioning profile (and failing the build if none is found). In .NET, the expected behavior is that if a file is in the project directory, it should be detected automatically and handled accordingly. We didn't do this for the initial release of .NET, but we implemented it later (https://github.com/xamarin/xamarin-macios/pull/15729). However, this turned out to be complicated, because many templates provide an Entitlements.plist file, and now suddenly just the presence of such a file would require a provisioning profile, which also means setting up the whole rigmarole of Apple's certificates and provisioning profiles (and even potentially getting a paid Apple Developer account). This usually worked well in legacy Xamarin, because in templates only the Release configuration would set the CodesignEntitlements=Entitlements.plist property, and thus we'd only require a provisioning profile for release builds (and the Entitlements.plist file would be ignored for Debug builds). Here we change the default behavior when building for .NET so that we only require a provisioning profile if the Entitlements.plist file is empty (i.e. doesn't request any entitlements). I've also implemented an override, where setting the CodesignRequireProvisioningProfile=true property will override our default logic. Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1613459.
2022-09-13 11:51:41 +03:00
CodesignProvision="$(CodesignProvision)"
CodesignEntitlements="$(CodesignEntitlements)"
CodesignRequireProvisioningProfile="$(CodesignRequireProvisioningProfile)"
[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
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)"
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'"
[msbuild] Detect SdkIsSimulator better for .NET by using the RuntimeIdentifier instead of only the architecture. This way we're able to detect that "iossimulator-arm64" is actually a RID for the simulator.
2021-11-24 00:02:29 +03:00
IsDotNetSimulatorBuild="$(_IsDotNetSimulatorBuild)"
[msbuild] Share the _DetectSdkLocations target. (#8755)
2020-06-05 18:08:02 +03:00
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" />
[dotnet/tools] Disable compact unwind on Xcode 14 to fix linker warnings. Ref: https://codereview.chromium.org/2784253003 Ref: https://github.com/grain-lang/binaryen.ml/pull/136 Ref: https://github.com/ocaml/ocaml/issues/9026 Ref: https://gitlab.haskell.org/ghc/ghc/-/issues/11829
2022-06-13 11:56:01 +03:00
<Output TaskParameter="XcodeVersion" PropertyName="_XcodeVersion" />
[msbuild] Share the _DetectSdkLocations target. (#8755)
2020-06-05 18:08:02 +03:00
</DetectSdkLocations>
[msbuild] Set the '_SdkIsSimulator' property for HotRestart builds. (#17714) This makes it easier to consume other tasks in the future that already takes '_SdkIsSimulator'. It also documents exactly why we hardcode _SdkIsSimulator=false for Hot Restart.
2023-03-07 18:24:28 +03:00
<PropertyGroup Condition="'$(IsHotRestartBuild)' == 'true'">
<!-- hot restart builds are always for device -->
<_SdkIsSimulator>false</_SdkIsSimulator>
</PropertyGroup>
[msbuild] Share the _DetectSdkLocations target. (#8755)
2020-06-05 18:08:02 +03:00
</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>
[msbuild] Don't process assemblies over and over again in the UnpackLibraryResources target. Fixes #16377. (#16416) Fixes #16377 MSbuild has the ability to run `Target` partially. However in order to make sure we can use this, both the `Inputs` and `Outputs` need to have a 1-1 mapping. MSBuild will then use this mapping to figure out which files have actually changed. Then it will call the Target with only those files. In Xamarin.Android we make use of stamp files to provide this 1-1 mapping. We have a `pre` Target which will calculate an ItemGroup which will include a StampFile piece of metadata. We then use this new ItemGroup for both the `Inputs` and `Outputs`, thus meeting the 1-1 requirement. This PR updates the `_UnpackLibraryResources` to run partially. This will hopefully reduce the build time on incremental builds.
2022-11-17 19:30:46 +03:00
<Target Name="_PrepareUnpackLibraryResources">
<PropertyGroup>
<_StampDirectory>$(IntermediateOutputPath)resourcestamps\</_StampDirectory>
</PropertyGroup>
<ItemGroup>
<_UnpackLibraryResourceItems Include="@(ReferencePath);@(ReferenceDependencyPaths)">
<StampFile>%(FileName).stamp</StampFile>
</_UnpackLibraryResourceItems>
</ItemGroup>
</Target>
<Target Name="_UnpackLibraryResources" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="ResolveReferences;_CollectBundleResources;_PrepareUnpackLibraryResources"
Inputs="@(_UnpackLibraryResourceItems)"
Outputs="@(_UnpackLibraryResourceItems->'$(_StampDirectory)%(StampFile)')">
[msbuild/dotnet] Rework Hot Restart builds. Rework Hot Restart builds to use as much as possible of the normal build logic, because this is the easiest way to make sure the Hot Restart build is as close as possible to normal builds (and we don't end up missing features). This is done by executing selected parts of a normal build, and a the end we have a new task that computes where each file goes in the various output directories Hot Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir, etc.)
2023-02-16 16:30:19 +03:00
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'" Directories="$(_StampDirectory)" />
<!-- This task may be executed locally on Windows (for Hot Restart) -->
[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
<UnpackLibraryResources
[msbuild/dotnet] Rework Hot Restart builds. Rework Hot Restart builds to use as much as possible of the normal build logic, because this is the easiest way to make sure the Hot Restart build is as close as possible to normal builds (and we don't end up missing features). This is done by executing selected parts of a normal build, and a the end we have a new task that computes where each file goes in the various output directories Hot Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir, etc.)
2023-02-16 16:30:19 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'"
[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
SessionId="$(BuildSessionId)"
Prefix="$(_EmbeddedResourcePrefix)"
NoOverwrite="@(_BundleResourceWithLogicalName)"
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)"
TargetFrameworkDirectory="$(TargetFrameworkDirectory)"
[msbuild] Don't process assemblies over and over again in the UnpackLibraryResources target. Fixes #16377. (#16416) Fixes #16377 MSbuild has the ability to run `Target` partially. However in order to make sure we can use this, both the `Inputs` and `Outputs` need to have a 1-1 mapping. MSBuild will then use this mapping to figure out which files have actually changed. Then it will call the Target with only those files. In Xamarin.Android we make use of stamp files to provide this 1-1 mapping. We have a `pre` Target which will calculate an ItemGroup which will include a StampFile piece of metadata. We then use this new ItemGroup for both the `Inputs` and `Outputs`, thus meeting the 1-1 requirement. This PR updates the `_UnpackLibraryResources` to run partially. This will hopefully reduce the build time on incremental builds.
2022-11-17 19:30:46 +03:00
ReferencedLibraries="@(_UnpackLibraryResourceItems)">
[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
<Output TaskParameter="BundleResourcesWithLogicalNames" ItemName="_BundleResourceWithLogicalName" />
</UnpackLibraryResources>
[msbuild] Don't process assemblies over and over again in the UnpackLibraryResources target. Fixes #16377. (#16416) Fixes #16377 MSbuild has the ability to run `Target` partially. However in order to make sure we can use this, both the `Inputs` and `Outputs` need to have a 1-1 mapping. MSBuild will then use this mapping to figure out which files have actually changed. Then it will call the Target with only those files. In Xamarin.Android we make use of stamp files to provide this 1-1 mapping. We have a `pre` Target which will calculate an ItemGroup which will include a StampFile piece of metadata. We then use this new ItemGroup for both the `Inputs` and `Outputs`, thus meeting the 1-1 requirement. This PR updates the `_UnpackLibraryResources` to run partially. This will hopefully reduce the build time on incremental builds.
2022-11-17 19:30:46 +03:00
<Touch
SessionId="$(BuildSessionId)"
[msbuild/dotnet] Rework Hot Restart builds. Rework Hot Restart builds to use as much as possible of the normal build logic, because this is the easiest way to make sure the Hot Restart build is as close as possible to normal builds (and we don't end up missing features). This is done by executing selected parts of a normal build, and a the end we have a new task that computes where each file goes in the various output directories Hot Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir, etc.)
2023-02-16 16:30:19 +03:00
Condition="'$(IsMacEnabled)' == 'true' Or '$(IsHotRestartBuild)' == 'true'"
[msbuild] Don't process assemblies over and over again in the UnpackLibraryResources target. Fixes #16377. (#16416) Fixes #16377 MSbuild has the ability to run `Target` partially. However in order to make sure we can use this, both the `Inputs` and `Outputs` need to have a 1-1 mapping. MSBuild will then use this mapping to figure out which files have actually changed. Then it will call the Target with only those files. In Xamarin.Android we make use of stamp files to provide this 1-1 mapping. We have a `pre` Target which will calculate an ItemGroup which will include a StampFile piece of metadata. We then use this new ItemGroup for both the `Inputs` and `Outputs`, thus meeting the 1-1 requirement. This PR updates the `_UnpackLibraryResources` to run partially. This will hopefully reduce the build time on incremental builds.
2022-11-17 19:30:46 +03:00
Files="@(_UnpackLibraryResourceItems->'$(_StampDirectory)%(StampFile)')"
AlwaysCreate="True"
>
<Output TaskParameter="TouchedFiles" ItemName="FileWrites" />
</Touch>
[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>
[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
[msbuild/dotnet] Add support for passing --aot arguments to the AOT compiler. (#14936) Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler when building a .NET project. This makes it possible to work around #14887 by manually increasing the number of trampolines. Ref: https://github.com/xamarin/xamarin-macios/issues/14887
2022-05-10 17:25:19 +03:00
Aot="@(_AotArguments)"
[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
ExtraArgs="$(_BundlerArguments)"
[msbuild] Make the _NoSymbolStrip and _NoDSymUtil properties public by removing the leading underscore. (#14248) These are useful properties that were exposed in legacy Xamarin as Mtouch* properties.
2022-02-28 13:27:44 +03:00
NoSymbolStrip="$(NoSymbolStrip)"
NoDSymUtil="$(NoDSymUtil)"
[dotnet] Fix non-bundling of debug files for release builds. Fixes #14085. (#14103) Fixes https://github.com/xamarin/xamarin-macios/issues/14085.
2022-02-09 18:46:04 +03:00
PackageDebugSymbols="$(PackageDebugSymbols)"
[dotnet] Make it possible to specify the registrar using a 'Registrar' property in MSBuild. (#15483) Co-authored-by: Marius Ungureanu <therzok@gmail.com>
2022-08-18 18:21:48 +03:00
Registrar="$(Registrar)"
[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/dotnet] Add support for passing --aot arguments to the AOT compiler. (#14936) Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler when building a .NET project. This makes it possible to work around #14887 by manually increasing the number of trampolines. Ref: https://github.com/xamarin/xamarin-macios/issues/14887
2022-05-10 17:25:19 +03:00
<Output TaskParameter="Aot" ItemName="_AotArguments" />
[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 the -gcc_flags and -link_flags mtouch/mmp arguments and pass them to the native linker. (#13521)
2021-12-13 10:33:26 +03:00
<Output TaskParameter="CustomLinkFlags" ItemName="_CustomLinkFlags" />
[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 _NoSymbolStrip and _NoDSymUtil properties public by removing the leading underscore. (#14248) These are useful properties that were exposed in legacy Xamarin as Mtouch* properties.
2022-02-28 13:27:44 +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"/>
[dotnet] Fix non-bundling of debug files for release builds. Fixes #14085. (#14103) Fixes https://github.com/xamarin/xamarin-macios/issues/14085.
2022-02-09 18:46:04 +03:00
<Output TaskParameter="PackageDebugSymbols" PropertyName="PackageDebugSymbols" />
[dotnet] Make it possible to specify the registrar using a 'Registrar' property in MSBuild. (#15483) Co-authored-by: Marius Ungureanu <therzok@gmail.com>
2022-08-18 18:21:48 +03:00
<Output TaskParameter="Registrar" PropertyName="Registrar" />
[dotnet] Add support for selecting whether to create P/Invoke wrappers or not. Fixes #4940. (#14961) * This is a potential mitigation for slower transition to native code when exception marshalling is enabled (#14812). * A minor modification was required in the linker, to make sure any modified assemblies are saved. Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
2022-05-11 17:42:01 +03:00
<Output TaskParameter="RequirePInvokeWrappers" PropertyName="_RequirePInvokeWrappers" />
[linker/trimmer] Add opt-in support for not marking NSObjects in user assemblies. Fixes #15723. (#17949) We mark all types that derive from NSObject when we find them in user assemblies, so that these types may be used in storyboards (where the linker can't see them), without having to go through hoops to make sure the linker doesn't remove these types (which would make the storyboard fail to load, because it would reference types that were linked away). However, not everybody uses storyboards, so in some cases it may make sense to link away as much as possible, so make it opt-in to skip this custom marking. This is an experimental feature, and will break at least some apps. It may break most apps, but if someone wants to try it out, they're welcome! It can be turned on by passing `--skip-marking-nsobjects-in-user-assemblies=true` to mtouch/mmp: ```xml <PropertyGroup> <MtouchExtraArgs>--skip-marking-nsobjects-in-user-assemblies=true</MtouchExtraArgs> </PropertyGroup> ``` Fixes #15723.
2023-04-13 17:38:04 +03:00
<Output TaskParameter="SkipMarkingNSObjectsInUserAssemblies" PropertyName="_SkipMarkingNSObjectsInUserAssemblies" />
[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>
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<_CollectCodesigningDataDependsOn>
$(_CollectCodesigningData);
_PlaceAppExtensions;
</_CollectCodesigningDataDependsOn>
<_CollectCodesigningDataDependsOn Condition="'$(_PlatformName)' != 'macOS'">
$(_CollectCodesigningData);
_ResolveWatchAppReferences;
</_CollectCodesigningDataDependsOn>
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
<_CodesignAppBundleDependsOn>
$(_CodesignAppBundleDependsOn);
[dotnet] macOS/MacCatalyst Archive and publishing support (#15720) These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac. Co-authored-by: Alex Soto <alex@alexsoto.me>
2022-08-26 09:18:43 +03:00
_DetectSigningIdentity;
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
_CleanAppBundleRootDirectory;
[msbuild] Unify some of the codesign dependency properties. (#13725)
2022-01-19 20:54:08 +03:00
_EmbedProvisionProfile;
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
_CollectCodesigningData;
_StoreCodesigningData;
[msbuild] Share the _CleanAppBundleRootDirectory target between iOS and Mac logic. (#13680)
2022-01-12 21:21:45 +03:00
</_CodesignAppBundleDependsOn>
[msbuild] Share some of the code signing targets between Xamarin.Mac and Xamarin.iOS. (#8710)
2020-06-01 11:23:17 +03:00
<CoreCodesignDependsOn>
$(CoreCodesignDependsOn);
[msbuild] Unify some of the codesign dependency properties. (#13725)
2022-01-19 20:54:08 +03:00
$(_CodesignAppBundleDependsOn);
[msbuild] Share some of the code signing targets between Xamarin.Mac and Xamarin.iOS. (#8710)
2020-06-01 11:23:17 +03:00
_CodesignAppBundle;
_CodesignVerify;
</CoreCodesignDependsOn>
<CodesignDependsOn>
$(CodesignDependsOn);
[msbuild] Unify some of the codesign dependency properties. (#13725)
2022-01-19 20:54:08 +03:00
_CreateAppBundle;
[msbuild] Share some of the code signing targets between Xamarin.Mac and Xamarin.iOS. (#8710)
2020-06-01 11:23:17 +03:00
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] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<!--
Code signing
============
A main point in code signing is that signing will be done in the
outermost executable project, not in any app extension projects or
watch projects, nor during the RID-specific build of a universal .NET
app. This makes codesigning easier to reason about and other affected
logic (such as strip/dsymutil) easier to handle, in particular for
.NET universal apps.
The first step is to collect all the information we need from the
targets files. Every app bundle (be it app extension, watch app or
main app) will add its own output app bundle (.app/.appex) to the
_CodesignBundle item group. Then every app bundle will load this
information from referenced app bundles, and finally store this
information on disk (in the 'codesign-bundle.items' file). This means
that in the end the main app bundle will have a list of all contained
app bundles in the app (recursively), in the _CodesignBundle item
group.
Separately we keep a list of other items that need signing, in the
_CodesignItems item group, and we do the same store/load logic for
every contained/contained app bundle (in the 'codesign.items' file, so
a the end the main app bundle will have a list of all the
_CodesignItems for all contained app bundles (recursively).
The previous steps occur in the _CollectCodesigningData and
_StoreCodesigningData targets.
The next step is to use the ComputeCodesignItems task to compute
everything we need to know for code signing. This task has the
responsibility for listing all the *.dylib and *.metallib files, and
the *.framework directories in the app bundles, that need signing.
This logic is significantly easier to write, debug and test in C# than
MSBuild.
In addition the ComputeCodesignItems also figures out a stamp file
path we use to determine if something needs (re-)signing.
Finally we give the list of _ComputedCodesignItems to the Codesign
task for signing.
At the very end, and only if we signed the main app bundle, we verify
that the signature is correct (in the _CodesignVerify target).
-->
<!--
_CodesignVerify: verify that the app bundle we've produced is valid and signed properly.
This target is only executed for app bundles (and not when only dylibs and frameworks are signed, but the app bundle itself is not).
-->
<Target
Name="_CodesignVerify"
[msbuild] Verify Mac Catalyst apps like we verify macOS apps. Fixes #17829. (#17835) * For Mac Catalyst apps we must verify the code signature like we do it for macOS apps. Fixes #17829. * Enable nullability and fix code accordingly. * Merge the CodesignVerify and CodesignVerifyTaskBase classes to simplify the code. Submission test is added as well: * https://github.com/xamarin/maccore/pull/2656 * https://github.com/xamarin/SubmissionSamples/pull/51 Fixes https://github.com/xamarin/xamarin-macios/issues/17829.
2023-03-21 20:20:05 +03:00
Condition="'$(_CodesignAppBundleCondition)' == 'true' And '$(_RequireCodeSigning)' == 'true' And '$(DisableCodesignVerification)' != 'true'"
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
DependsOnTargets="_CodesignAppBundle"
>
<CodesignVerify
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
CodesignAllocate="$(_CodesignAllocate)"
Resource="$(_AppContainerDir)\%(_CodesignBundle.Identity)"
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
</CodesignVerify>
</Target>
<!--
_CollectCodesigningData: This target collects all the data required to sign the app bundle.
* We iterate over all app extensions, and load the signing data from
each of them (and since each app extension does the same thing, we
effectively end up collecting codesigning data from nested app
extensions as well).
* We load signing data from any watch apps (which already contains
codesigning data for the watch extension (and any other contained
extensions), we effectively end up collecting codesigning data
recursively).
* We add signing data for the current project's app bundle (if that's
what we're building).
Item groups:
* _CodesignBundle: all the bundles (*.app, *.appex) that must be
signed (including the watch app). The identity is relative to the
output directory where we put the app bundle (because this makes
it easy to update the identity when loading data from contained
projects - we just have to prepend the relative path to where the
contained app bundle is to be placed in the current app bundle)
* _CodesignItems: other files and directories that must be signed
(*.dylib, *.framework, createdump, etc.). The identity is the same
as for _CodesignBundle.
-->
<Target
Name="_CollectCodesigningData"
DependsOnTargets="$(_CollectCodesigningDataDependsOn)"
>
<!-- Get app bundles to sign from app extensions -->
<ReadItemsFromFile File="@(_ResolvedAppExtensionReferences->'%(Identity)\..\codesign-bundle.items')" Condition="Exists('%(Identity)\..\codesign-bundle.items')">
<Output TaskParameter="Items" ItemName="_CodesignAppExtensionBundle" />
</ReadItemsFromFile>
<ItemGroup>
<_CodesignBundle Include="@(_CodesignAppExtensionBundle->'$(_AppBundleName)$(AppBundleExtension)/$(_AppPlugInsRelativePath)/%(Identity)')" />
</ItemGroup>
<!-- Get items to sign from app extensions -->
<ReadItemsFromFile File="@(_ResolvedAppExtensionReferences->'%(Identity)\..\codesign.items')" Condition="Exists('%(Identity)\..\codesign.items')">
<Output TaskParameter="Items" ItemName="_CodesignAppExtensionItem" />
</ReadItemsFromFile>
<ItemGroup>
<_CodesignItems Include="@(_CodesignAppExtensionItem->'$(_AppBundleName)$(AppBundleExtension)/$(_AppPlugInsRelativePath)/%(Identity)')" />
</ItemGroup>
<!-- Get app bundles to sign from watch apps -->
<ReadItemsFromFile File="@(_ResolvedWatchAppReferences->'%(Identity)\..\codesign-bundle.items')" Condition="Exists('%(Identity)\..\codesign-bundle.items')">
<Output TaskParameter="Items" ItemName="_CodesignWatchBundle" />
</ReadItemsFromFile>
<ItemGroup>
<_CodesignBundle Include="@(_CodesignWatchBundle->'$(_AppBundleName)$(AppBundleExtension)/Watch/%(Identity)')" />
</ItemGroup>
<!-- Get items to sign from watch apps -->
<ReadItemsFromFile File="@(_ResolvedWatchAppReferences->'%(Identity)\..\codesign.items')" Condition="Exists('%(Identity)\..\codesign.items')">
<Output TaskParameter="Items" ItemName="_CodesignWatchItem" />
</ReadItemsFromFile>
<ItemGroup>
<_CodesignItems Include="@(_CodesignWatchItem->'$(_AppBundleName)$(AppBundleExtension)/Watch/%(Identity)')" />
</ItemGroup>
[dotnet/msbuild] Add support for skipping/adding items (and bundles) to be signed. Fixes #15594. (#15894) Add support for two new MSBuild item groups: * CodesignBundle: lists additional app bundles inside the main bundle which should be signed (typically manually copied into the app bundle by the developer). * SkipCodesignItems: lists files we'd sign by default, but which shouldn't be signed. Fixes https://github.com/xamarin/xamarin-macios/issues/15594.
2022-09-21 12:38:03 +03:00
<!-- Add any user-specified bundles -->
<ItemGroup>
<_CustomCodesignBundle Include="@(CodesignBundle)" />
<_CustomCodesignBundle>
<CodesignAllocate Condition="'%(_CustomCodesignBundle.CodesignAllocate)' == ''">$(_CodesignAllocate)</CodesignAllocate>
<CodesignDisableTimestamp Condition="'%(_CustomCodesignBundle.CodesignDisableTimestamp)' == ''">false</CodesignDisableTimestamp>
<CodesignDisableTimestamp Condition="'%(_CustomCodesignBundle.CodesignDisableTimestamp)' == '' And ('$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true')">true</CodesignDisableTimestamp>
<CodesignEntitlements Condition="'%(_CustomCodesignBundle.CodesignEntitlements)' == ''">$(_CompiledCodesignEntitlements)</CodesignEntitlements>
<CodesignExtraArgs Condition="'%(_CustomCodesignBundle.CodesignExtraArgs)' == ''">$(CodesignExtraArgs)</CodesignExtraArgs>
<CodesignKeychain Condition="'%(_CustomCodesignBundle.CodesignKeychain)' == ''">$(CodesignKeychain)</CodesignKeychain>
<CodesignResourceRules Condition="'%(_CustomCodesignBundle.CodesignResourceRules)' == ''">$(_PreparedResourceRules)</CodesignResourceRules>
<CodesignSigningKey Condition="'%(_CustomCodesignBundle.CodesignSigningKey)' == ''">$(_CodeSigningKey)</CodesignSigningKey>
<CodesignUseHardenedRuntime Condition="'%(_CustomCodesignBundle.CodesignUseHardenedRuntime)' == ''">$(UseHardenedRuntime)</CodesignUseHardenedRuntime>
<CodesignUseSecureTimestamp Condition="'%(_CustomCodesignBundle.CodesignUseSecureTimestamp)' == ''">$(UseHardenedRuntime)</CodesignUseSecureTimestamp>
<RequireCodeSigning Condition="'%(_CustomCodesignBundle.RequireCodeSigning)' == ''">$(_RequireCodeSigning)</RequireCodeSigning>
<SourceProjectPath>$(MSBuildProjectDirectory)</SourceProjectPath>
</_CustomCodesignBundle>
<_CodesignBundle Include="@(_CustomCodesignBundle)" />
</ItemGroup>
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<!-- Add this app bundle to _CodesignBundle -->
<ItemGroup>
<_CodesignBundle Include="$(_AppBundleName)$(AppBundleExtension)">
<CodesignAllocate>$(_CodesignAllocate)</CodesignAllocate>
<CodesignDisableTimestamp>false</CodesignDisableTimestamp>
<CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">true</CodesignDisableTimestamp>
<CodesignEntitlements>$(_CompiledCodesignEntitlements)</CodesignEntitlements>
<CodesignExtraArgs>$(CodesignExtraArgs)</CodesignExtraArgs>
<CodesignKeychain>$(CodesignKeychain)</CodesignKeychain>
<CodesignResourceRules>$(_PreparedResourceRules)</CodesignResourceRules>
<CodesignSigningKey>$(_CodeSigningKey)</CodesignSigningKey>
<CodesignUseHardenedRuntime>$(UseHardenedRuntime)</CodesignUseHardenedRuntime>
<CodesignUseSecureTimestamp>$(UseHardenedRuntime)</CodesignUseSecureTimestamp>
<RequireCodeSigning>$(_RequireCodeSigning)</RequireCodeSigning>
<SourceProjectPath>$(MSBuildProjectDirectory)</SourceProjectPath>
</_CodesignBundle>
<!-- Set the SourceProjectPath metadata on all items that don't have it already -->
<_CodesignItems>
<SourceProjectPath Condition="'%(_CodesignItems.SourceProjectPath)' == ''">$(MSBuildProjectDirectory)</SourceProjectPath>
</_CodesignItems>
</ItemGroup>
<PropertyGroup>
<!--
We only run the CodesignAppBundle target on the outer-most executable project
* Not on app extensions
* Not on watch apps
[msbuild] Only sign the app bundle if codesigning is enabled. Fixes #16197. (#16266) Only sign the app bundle if codesigning is enabled. This fixes a bug where we'd still try to sign an app bundle, even if the user disabled code signing by setting EnableCodeSigning=false, if the default logic was to sign the app bundle. Fixes https://github.com/xamarin/xamarin-macios/issues/16197.
2022-10-10 16:33:20 +03:00
* Not if explicitly disabled by setting EnableCodeSigning=false
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
-->
[msbuild] Only sign the app bundle if codesigning is enabled. Fixes #16197. (#16266) Only sign the app bundle if codesigning is enabled. This fixes a bug where we'd still try to sign an app bundle, even if the user disabled code signing by setting EnableCodeSigning=false, if the default logic was to sign the app bundle. Fixes https://github.com/xamarin/xamarin-macios/issues/16197.
2022-10-10 16:33:20 +03:00
<_CodesignAppBundleCondition Condition="'$(_CodesignAppBundleCondition)' == '' And '$(IsAppExtension)' != 'true' And '$(IsWatchApp)' != 'true' And '$(_CanOutputAppBundle)' == 'true' And '$(EnableCodeSigning)' != 'false'">true</_CodesignAppBundleCondition>
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<_CodesignAppBundleCondition Condition="'$(_CodesignAppBundleCondition)' == ''">false</_CodesignAppBundleCondition>
</PropertyGroup>
</Target>
<!-- This target writes all the properties required to sign items for this project, so that they can be read in containing projects.
The _CodesignBundle item group also contains items for contained projects this project may have (extension projects may have extension projects, etc.). -->
<Target
Name="_StoreCodesigningData"
DependsOnTargets="_CollectCodesigningData"
>
<WriteItemsToFile
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
Items="@(_CodesignBundle)"
ItemName="_CodesignBundle"
File="$(DeviceSpecificOutputPath)codesign-bundle.items"
IncludeMetadata="true"
Overwrite="true"
/>
<WriteItemsToFile
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
Items="@(_CodesignItems)"
ItemName="_CodesignItems"
File="$(DeviceSpecificOutputPath)codesign.items"
IncludeMetadata="true"
Overwrite="true"
/>
</Target>
<!--
_CodesignAppBundle: sign the app bundle and anything inside that needs
signing
This target does not have Inputs/Outputs, because computing what needs
signing or not is quite complex:
* The ComputeCodesignItems will add items to sign (this computation is
much easier to do in C# than here)
* If any file inside a directory has been modified, we need to
(re)sign
* If any file or directory inside a directory needs to be signed, then
the containing directory must be signed as well
This logic is implemented in the Codesign task.
[dotnet/msbuild] Add support for skipping/adding items (and bundles) to be signed. Fixes #15594. (#15894) Add support for two new MSBuild item groups: * CodesignBundle: lists additional app bundles inside the main bundle which should be signed (typically manually copied into the app bundle by the developer). * SkipCodesignItems: lists files we'd sign by default, but which shouldn't be signed. Fixes https://github.com/xamarin/xamarin-macios/issues/15594.
2022-09-21 12:38:03 +03:00
The SkipCodesignItems item group takes paths relative to the directory where the app bundle is. Example: "foo.app/dontsignme.dylib"
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
-->
<Target Name="_CodesignAppBundle"
Condition="'$(_CodesignAppBundleCondition)' == 'true'"
DependsOnTargets="$(_CodesignAppBundleDependsOn)"
>
<ComputeCodesignItems
Condition="'$(IsMacEnabled)' == 'true'"
SessionId="$(BuildSessionId)"
AppBundleDir="$(AppBundleDir)"
CodesignBundle="@(_CodesignBundle)"
CodesignItems="@(_CodesignItems)"
CodesignStampPath="$(DeviceSpecificIntermediateOutputPath)codesign\"
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
GenerateDSymItems="@(_GenerateDSymItems)"
NativeStripItems="@(_NativeStripItems)"
[dotnet/msbuild] Add support for skipping/adding items (and bundles) to be signed. Fixes #15594. (#15894) Add support for two new MSBuild item groups: * CodesignBundle: lists additional app bundles inside the main bundle which should be signed (typically manually copied into the app bundle by the developer). * SkipCodesignItems: lists files we'd sign by default, but which shouldn't be signed. Fixes https://github.com/xamarin/xamarin-macios/issues/15594.
2022-09-21 12:38:03 +03:00
SkipCodesignItems="@(SkipCodesignItems)"
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
>
<Output TaskParameter="OutputCodesignItems" ItemName="_ComputedCodesignItems" />
</ComputeCodesignItems>
<Codesign
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Resources="@(_ComputedCodesignItems)"
ToolExe="$(CodesignExe)"
ToolPath="$(CodesignPath)"
>
</Codesign>
</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>
[msbuild] Add additional app extensions to the list of items we need to sign. Fixes #15598. (#15829) * Add additional app extensions to the list of items we need to sign. * Improve msbuild test for additional app extensions: * Build for both device and simulator. * Hopefully fix the signing problems that occurred on the bots last time we tried. * Assert that both the container and extension are signed during the build when we build for device. A 10-line fix with 3300 lines of tests... Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
2022-09-07 11:39:05 +03:00
<Target Name="_ExtendAppExtensionReferences" DependsOnTargets="_ResolveAppExtensionReferences;_DetectSigningIdentity" Condition=" '@(AdditionalAppExtensions)' != ''">
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
<!-- 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" />
[msbuild] Add additional app extensions to the list of items we need to sign. Fixes #15598. (#15829) * Add additional app extensions to the list of items we need to sign. * Improve msbuild test for additional app extensions: * Build for both device and simulator. * Hopefully fix the signing problems that occurred on the bots last time we tried. * Assert that both the container and extension are signed during the build when we build for device. A 10-line fix with 3300 lines of tests... Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
2022-09-07 11:39:05 +03:00
<_CodesignBundle Include="$(_AppBundleName)$(AppBundleExtension)\$(_AppPlugInsRelativePath)%(AdditionalAppExtensions.Name).appex">
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
<CodesignAllocate>$(_CodesignAllocate)</CodesignAllocate>
[msbuild] Add additional app extensions to the list of items we need to sign. Fixes #15598. (#15829) * Add additional app extensions to the list of items we need to sign. * Improve msbuild test for additional app extensions: * Build for both device and simulator. * Hopefully fix the signing problems that occurred on the bots last time we tried. * Assert that both the container and extension are signed during the build when we build for device. A 10-line fix with 3300 lines of tests... Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
2022-09-07 11:39:05 +03:00
<CodesignDisableTimestamp>false</CodesignDisableTimestamp>
<CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">true</CodesignDisableTimestamp>
<CodesignEntitlements Condition="Exists('%(AdditionalAppExtensions.Identity)/%(AdditionalAppExtensions.Name).entitlements')">%(AdditionalAppExtensions.Identity)/%(AdditionalAppExtensions.Name).entitlements</CodesignEntitlements>
<CodesignKeychain>$(CodesignKeychain)</CodesignKeychain>
<CodesignResourceRules>$(_PreparedResourceRules)</CodesignResourceRules>
<CodesignSigningKey>$(_CodeSigningKey)</CodesignSigningKey>
<CodesignUseHardenedRuntime>$(UseHardenedRuntime)</CodesignUseHardenedRuntime>
<CodesignUseSecureTimestamp>$(UseHardenedRuntime)</CodesignUseSecureTimestamp>
<RequireCodeSigning>$(_RequireCodeSigning)</RequireCodeSigning>
</_CodesignBundle>
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
</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)"
[msbuild] Touch all files when copying an app extension into the app. (#13721) Touch all files when copying an app extension into the app. This fixes an issue where we'd in some cases run into this scenario: * Build once (successfully), and sign the app (and app extension), including all dylibs. * We build again, copy the (unsigned) app extension into the app again, but not sign dylibs because the timestamp went back into the past.
2022-01-17 11:05:08 +03:00
TouchDestinationFiles="true"
[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
/>
<!-- 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/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<_NativeExecutableRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">$(_ExecutableName)</_NativeExecutableRelativePath>
<_NativeExecutableRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\MacOS\$(_ExecutableName)</_NativeExecutableRelativePath>
<_NativeExecutable>$(_AppBundlePath)$(_NativeExecutableRelativePath)</_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>
[msbuild] Move debug-related targets to shared code. (#14180)
2022-02-18 18:35:28 +03:00
<Target Name="_CreateDebugSettings" Condition="'$(_BundlerDebug)' == 'true' And '$(IsWatchApp)' == 'false' And '$(_PlatformName)' != 'MacCatalyst' And '$(_PlatformName)' != 'macOS'"
DependsOnTargets="_CopyResourcesToBundle"
Outputs="$(_AppBundlePath)Settings.bundle\Root.plist" >
<CreateDebugSettings
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(AppBundleDir)"
DebuggerPort="$(IOSDebuggerPort)"
>
</CreateDebugSettings>
</Target>
<Target Name="_CreateDebugConfiguration" Condition="'$(_BundlerDebug)' == 'true' And '$(IsWatchApp)' == 'false' And '$(_PlatformName)' != 'macOS'"
DependsOnTargets="_CopyResourcesToBundle;_DetectDebugNetworkConfiguration"
Outputs="$(_AppResourcesPath)MonoTouchDebugConfiguration.txt" >
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(_AppResourcesPath)" />
<CreateDebugConfiguration
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
AppBundleDir="$(_AppResourcesPath)"
[runtime] Add support for passing on a connect timeout to sdb. (#18037) The timeout can be given: * By setting the __XAMARIN_DEBUG_CONNECT_TIMEOUT__ environment variable for the app when launching it. * By passing the XamarinDebugConnectTimeout MSBuild property to 'dotnet run' or 'dotnet build /t:Run'. * By setting the IOSDebugConnectTimeout MSBuild property at build time. Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1778177.
2023-04-13 17:34:52 +03:00
ConnectTimeout="$(IOSDebugConnectTimeout)"
[msbuild] Move debug-related targets to shared code. (#14180)
2022-02-18 18:35:28 +03:00
DebugOverWiFi="$(IOSDebugOverWiFi)"
DebugIPAddresses="$(_DebugIPAddresses)"
DebuggerPort="$(IOSDebuggerPort)"
SdkIsSimulator="$(_SdkIsSimulator)"
>
</CreateDebugConfiguration>
</Target>
<Target Name="_DetectDebugNetworkConfiguration" Condition="'$(_BundlerDebug)' == 'true'">
<DetectDebugNetworkConfiguration
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
DebugOverWiFi="$(IOSDebugOverWiFi)"
DebuggerHosts="$(IOSDebuggerHosts)"
SdkIsSimulator="$(_SdkIsSimulator)"
>
<Output TaskParameter="DebugIPAddresses" PropertyName="_DebugIPAddresses" />
</DetectDebugNetworkConfiguration>
</Target>
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<!--
Post processing: this is what happens to the app bundle once it's built.
We must (the order here is important):
a) Run dsymutil on native binaries
b) Strip native binaries
c) Notify spotlight about our finished app bundle
A final step done later is to codesign the app bundle (and all its contained native binaries).
Generating debug symbols (dSYM directories) and stripping binaries.
* First we collect all the frameworks, dylibs and executable files
from both the current project and any contained app extensions.
Note: We don't iterate over all the *.framework and *.dylib files in
the app bundle, we only look in the native references in the project
file (one reason being that we need the metadata from those native
references; although there are ways around that if need be).
* We write a list of all these items in a postprocessing.items file
(so that container projects can load them if need be).
* If we're building the outermost app bundle (not an app extension nor
a watch app, nor a .NET rid-specific app), we
run dsymutil/symbolstrip in the executable project.
* If we're building a universal app in .NET, we don't run
dsymutil/symbolstrip for each rid-specific build, but instead
delay until we've created the universal app bundle.
* Metadata on items:
Apply suggestions from code review Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
2022-03-24 00:24:35 +03:00
* NoSymbolStrip: set to true to not strip native symbols for this item (and false to do it)
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
* NoDSymUtil: set to true to do not run dsymutil for this item (and false do it)
* SymbolFile: The path to a file that contains a list of exported names that should be kept after stripping.
* To change the default behavior for the executable itself, set
NoSymbolStrip=true/NoDSYmUtil=true in the project file (this will
also change the behavior for all frameworks and dylibs in the
project, unless it's overriden per framework/dylib using metadata on
each item).
By default, we generate debug symbols and strip native binaries:
* For iOS, tvOS and watchOS: always
* For macOS and Mac Catalyst: when creating an archive (ArchiveOnBuild=true)
-->
<!-- Compute a few variables for debug symbol generation and native file stripping -->
<PropertyGroup>
<_PrepareForPostProcessingDependsOn>
$(_PrepareForPostProcessingDependsOn);
_PlaceAppExtensions;
</_PrepareForPostProcessingDependsOn>
<_PrepareForPostProcessingDependsOn Condition="'$(_PlatformName)' != 'macOS'">
$(_PrepareForPostProcessingDependsOn);
_ResolveWatchAppReferences;
</_PrepareForPostProcessingDependsOn>
</PropertyGroup>
<Target
Name="_PrepareForPostProcessing"
DependsOnTargets="$(_PrepareForPostProcessingDependsOn)"
>
<PropertyGroup>
<_PostProcessingItemPath Condition="'$(_PostProcessingItemPath)' == ''">$(DeviceSpecificOutputPath)postprocessing.items</_PostProcessingItemPath>
<_OutputDsymLocation>$(_AppContainerDir)</_OutputDsymLocation>
</PropertyGroup>
<ItemGroup>
<_AppExtensionPostProcessingItemsPath Include="@(_ResolvedAppExtensionReferences -> '%(Identity)\..\postprocessing.items')" Condition="Exists('%(Identity)\..\postprocessing.items')" />
<_WatchAppPostProcessingItemPath Include="@(_ResolvedWatchAppReferences -> '%(Identity)\..\postprocessing.items')" Condition="Exists('%(Identity)\..\postprocessing.items')"/>
</ItemGroup>
</Target>
<!--
This target will collect every item in the current project and any app extensions that might need debug symbols / stripping
This target runs always, because container projects might want to create debug symbols or strip even if this project doesn't want to, and
in that case the container project would still need to know what to do for contained projects.
-->
<Target
Name="_CollectItemsForPostProcessing"
DependsOnTargets="_CompileToNative;_ParseBundlerArguments;_ExpandNativeReferences;_PrepareForPostProcessing"
>
<!-- read any data from app extensions -->
<ReadItemsFromFile File="@(_AppExtensionPostProcessingItemsPath)">
<Output TaskParameter="Items" ItemName="_AppExtensionPostProcessingItems" />
</ReadItemsFromFile>
<!-- read any data from watch apps -->
<ReadItemsFromFile File="@(_WatchAppPostProcessingItemPath)">
<Output TaskParameter="Items" ItemName="_WatchAppPostProcessingItems" />
</ReadItemsFromFile>
[msbuild] Use the full path to the symbols list file. Fixes #15046. (#15105) Give the full path to the symbols list file in the extension project to the main project, so that strip can find it. When building a solution remotely from Windows, we can't compute a relative path between projects, because they're laid out differently on disk. This means that we have to use full paths when passing paths between projects (such as the path to the symbol list file). Fixes https://github.com/xamarin/xamarin-macios/issues/15046.
2022-05-30 12:33:11 +03:00
<!--
For App Extensions, we delay running dsymutil & strip until it has been copied into the main app bundle.
This means that we need the path to the symbols list in the main app's project, and it needs to be a full path when executing remotely from Windows,
because the projects are not in the same position relative to eachother when building remotely (so a relative path doesn't work).
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.
Ref: https://github.com/xamarin/xamarin-macios/issues/15046
-->
<GetFullPath SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" RelativePath="$(_MtouchSymbolsList)">
<Output TaskParameter="FullPath" PropertyName="_SymbolsListFullPath" />
</GetFullPath>
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<ItemGroup>
<!-- add frameworks, with the path relative to the app bundle -->
<_PostProcessingItem Include="@(_ResolvedNativeReference->'$(_AppBundleName)$(AppBundleExtension/$(_AppFrameworksRelativePath)%(Filename).framework/%(Filename)')" Condition="'%(_ResolvedNativeReference.Kind' == 'Framework'">
<!-- Store where this item came from -->
<ItemSourcePath>%(_ResolvedNativeReference.Identity)</ItemSourcePath>
<!-- If the item in question came with a .dSYM directory, this would be the path to it: -->
<dSYMSourcePath>$([System.IO.Path]::GetDirectoryName('%(_ResolvedNativeReference.Identity)')).dSYM</dSYMSourcePath>
<!-- This is the name of the dSYM that will be created (if that's the case) -->
<DSymName>%(_ResolvedNativeReference.Filename)%(_ResolvedNativeReference.Extension).dSYM</DSymName>
</_PostProcessingItem>
<!-- add dylibs, with the path relative to the app bundle -->
<_PostProcessingItem Include="@(_ResolvedNativeReference->'$(_AppBundleName)$(AppBundleExtension/$(_AppContentsRelativePath)%(Filename).framework/%(Filename)')" Condition="'%(_ResolvedNativeReference.Kind' == 'Dynamic'">
<!-- Store where this item came from -->
<ItemSourcePath>%(_ResolvedNativeReference.Identity)</ItemSourcePath>
<!-- If the item in question came with a .dSYM directory, this would be the path to it: -->
<dSYMSourcePath>$([System.IO.Path]::GetDirectoryName('%(_ResolvedNativeReference.Identity)')).dSYM</dSYMSourcePath>
<!-- This is the name of the dSYM that will be created (if that's the case) -->
<DSymName>%(_ResolvedNativeReference.Filename)%(_ResolvedNativeReference.Extension).dSYM</DSymName>
</_PostProcessingItem>
<_PostProcessingItem Include="$([System.IO.Path]::GetFileName('$(AppBundleDir)'))/$(_NativeExecutableRelativePath)" Condition="'$(IsWatchApp)' != 'true'">
[msbuild] Use the full path to the symbols list file. Fixes #15046. (#15105) Give the full path to the symbols list file in the extension project to the main project, so that strip can find it. When building a solution remotely from Windows, we can't compute a relative path between projects, because they're laid out differently on disk. This means that we have to use full paths when passing paths between projects (such as the path to the symbol list file). Fixes https://github.com/xamarin/xamarin-macios/issues/15046.
2022-05-30 12:33:11 +03:00
<SymbolFile>$(_SymbolsListFullPath)</SymbolFile>
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<DSymName>$(_AppBundleName)$(AppBundleExtension).dSYM</DSymName>
</_PostProcessingItem>
<_PostProcessingItem>
<NoSymbolStrip Condition="'%(_PostProcessingItem.NoSymbolStrip)' == ''">$(NoSymbolStrip)</NoSymbolStrip>
<NoDSymUtil Condition="'%(_PostProcessingItem.NoDSymUtil)' == ''">$(NoDSymUtil)</NoDSymUtil>
<!-- Did the item in question come with a .dSYM directory? -->
<dSYMSourcePathExists Condition="'$(dSYMSourcePathExists)' == '' And Exists('%(_PostProcessingItem.dSYMSourcePath)')">true</dSYMSourcePathExists>
<dSYMSourcePathExists Condition="'$(dSYMSourcePathExists)' == ''">false</dSYMSourcePathExists>
<!-- Compute info.plist path inside the dSYM -->
<dSYMInfoPlistRelativePath>%(DSymName)\Contents\Info.plist</dSYMInfoPlistRelativePath>
<BCSymbolMapName>%(Filename)%(Extension).bcsymbolmap</BCSymbolMapName>
</_PostProcessingItem>
<!-- Add any items from app extensions -->
[msbuild] Use the full path to the symbols list file. Fixes #15046. (#15105) Give the full path to the symbols list file in the extension project to the main project, so that strip can find it. When building a solution remotely from Windows, we can't compute a relative path between projects, because they're laid out differently on disk. This means that we have to use full paths when passing paths between projects (such as the path to the symbol list file). Fixes https://github.com/xamarin/xamarin-macios/issues/15046.
2022-05-30 12:33:11 +03:00
<_PostProcessingItem Include="@(_AppExtensionPostProcessingItems -> '$(_AppBundleName)$(AppBundleExtension)\$(_AppPlugInsRelativePath)%(Identity)')" Condition="@(_AppExtensionPostProcessingItems->Count()) &gt; 0" /> <!-- The condition here shouldn't be necessary, but https://github.com/dotnet/msbuild/issues/4056 -->
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<!-- Add any items from watch app -->
<!-- We must update metadata with paths relative to the root of the app bundle to be relative to the root of the current app bundle -->
<_PostProcessingItem Include="@(_WatchAppPostProcessingItems -> '$(_AppBundleName)$(AppBundleExtension)/Watch/%(Identity)')" />
<!-- Set the SourceProjectPath metadata on all items that don't have it already -->
<_PostProcessingItem>
<SourceProjectPath Condition="'%(_PostProcessingItem.SourceProjectPath)' == ''" >$(MSBuildProjectDirectory)</SourceProjectPath>
</_PostProcessingItem>
</ItemGroup>
</Target>
<Target
Name="_StoreCollectedItemsForPostProcessing"
DependsOnTargets="_CollectItemsForPostProcessing"
>
<WriteItemsToFile
Condition="'$(IsMacEnabled)' == 'true' And '$(_PostProcessingItemPath)' != ''"
Items="@(_PostProcessingItem)"
ItemName="_PostProcessingItem"
File="$(_PostProcessingItemPath)"
IncludeMetadata="true"
Overwrite="true"
/>
</Target>
<PropertyGroup>
<GenerateDebugSymbolsDependsOn>
$(GenerateDebugSymbolsDependsOn);
_CompileToNative;
_GetNativeExecutableName;
_ParseBundlerArguments;
</GenerateDebugSymbolsDependsOn>
<GenerateDebugSymbolsDependsOn Condition="'$(UsingAppleNETSdk)' == 'true'">
$(GenerateDebugSymbolsDependsOn);
_CollectRidSpecificSymbolLists;
_CollectRidSpecificUserFrameworksWithoutDebugSymbols;
</GenerateDebugSymbolsDependsOn>
<GenerateDebugSymbolsDependsOn>
$(GenerateDebugSymbolsDependsOn);
_CollectItemsForPostProcessing;
_StoreCollectedItemsForPostProcessing;
</GenerateDebugSymbolsDependsOn>
</PropertyGroup>
[msbuild] Create a single target for post-processing (dsymutil/strip) an app bundle
2022-02-11 15:55:22 +03:00
<PropertyGroup>
<_PostProcessAppBundleDependsOn>
$(_PostProcessAppBundleDependsOn);
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
$(GenerateDebugSymbolsDependsOn);
_CollectItemsForPostProcessing;
_StoreCollectedItemsForPostProcessing;
_PreparePostProcessing;
_GenerateDSym;
_NativeStripFiles;
[msbuild] Move spotlight indexing out to its own task. Also establish when we should do post processing: only in the outermost build. This is a slight change from previous behavior, where we'd run strip/dsymutil separately for app extensions and watch apps.
2022-02-11 15:55:22 +03:00
_NotifySpotlight;
[msbuild] Create a single target for post-processing (dsymutil/strip) an app bundle
2022-02-11 15:55:22 +03:00
</_PostProcessAppBundleDependsOn>
</PropertyGroup>
[msbuild] Move spotlight indexing out to its own task. Also establish when we should do post processing: only in the outermost build. This is a slight change from previous behavior, where we'd run strip/dsymutil separately for app extensions and watch apps.
2022-02-11 15:55:22 +03:00
<PropertyGroup Condition="'$(_PostProcess)' == ''">
<!-- we don't run dsymutil/strip in app extensions, only in the main executable project -->
<_PostProcess Condition="'$(IsAppExtension)' == 'true'">false</_PostProcess>
<!-- we don't post-process watch apps, only the main executable project -->
<_PostProcess Condition="'$(IsWatchApp)' == 'true'">false</_PostProcess>
<!-- we don't post-process inner builds of multi-rid builds (in .NET), only the outermost build -->
<_PostProcess Condition="'$(_IsMultiRidBuild)' == 'true'">false</_PostProcess>
<!-- otherwise post-process -->
<_PostProcess Condition="'$(_PostProcess)' == ''">true</_PostProcess>
</PropertyGroup>
[msbuild] Create a single target for post-processing (dsymutil/strip) an app bundle
2022-02-11 15:55:22 +03:00
<Target Name="_PostProcessAppBundle" DependsOnTargets="$(_PostProcessAppBundleDependsOn)" />
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
<Target Name="_PreparePostProcessing" DependsOnTargets="_CollectItemsForPostProcessing">
<ItemGroup>
<_PostProcessingItem>
<DSymDir>$(_OutputDsymLocation)%(DSymName)</DSymDir>
<BCSymbolMapPath>$(_OutputDsymLocation)%(BCSymbolMapName)</BCSymbolMapPath>
<dSYMInfoPlist>$(_OutputDsymLocation)%(dSYMInfoPlistRelativePath)</dSYMInfoPlist>
</_PostProcessingItem>
<_PostProcessingItem>
<dSYMUtilStampFile>%(dSYMInfoPlist)</dSYMUtilStampFile>
<StripStampFile>$(DeviceSpecificIntermediateOutputPath)strip/%(Identity)</StripStampFile>
</_PostProcessingItem>
<_GenerateDSymItems Include="@(_PostProcessingItem)" Condition="'%(NoDSymUtil)' != 'true'" />
<_NativeStripItems Include="@(_PostProcessingItem)" Condition="'%(NoSymbolStrip)' != 'true'" />
</ItemGroup>
</Target>
<!-- This target will execute dsymutil on items in the _GenerateDSymItems item group -->
<Target
Name="_GenerateDSym"
Condition="'$(_PostProcess)' == 'true'"
Inputs="@(_GenerateDSymItems->'$(_AppContainerDir)%(Identity)')"
Outputs="%(_GenerateDSymItems.dSYMUtilStampFile)"
DependsOnTargets="_PreparePostProcessing"
>
<!-- Remove any pre-existing dSYM directories -->
<RemoveDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="%(_GenerateDSymItems.DSymDir)"
/>
<!-- Remove any pre-existing bcsymbolmap files as well -->
<Delete
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Files="%(_GenerateDSymItems.BCSymbolMapPath)"
/>
<!-- run dsymutil on the items in question -->
<DSymUtil
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
DSymDir="%(_GenerateDSymItems.DSymDir)"
Executable="$(_AppContainerDir)%(_GenerateDSymItems.Identity)"
[msbuild] Add an SdkDevPath property to the DSymUtil task. (#17108) Add an SdkDevPath property to the DSymUtil task, and use it to set DEVELOPER_DIR when calling dsymutil. Should fix this: > xcrun: error: unable to find utility "dsymutil", not a developer tool or in PATH when `xcode-select -p` and VSMac are configured with two different Xcodes.
2023-01-12 09:09:57 +03:00
SdkDevPath="$(_SdkDevPath)"
[msbuild/dotnet] Rework how we handle app bundle post processing. Fixes #14067. Change dSYM generation and native stripping to occur immediately before code signing, in a newly minted post processing target. Challenges: * Both calling 'strip' and 'codesign' on an executable modifies that executable, which means that we must make sure to not call 'dsymutil' on the same binary at a later point unless it's been rebuilt. * Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip' and/or 'codesign' on an executable. * Just like for code signing, we must store the libraries (either static or dynamic) we post process in extension/watch/rid-specific projects, so that these libraries can be loaded in containing projects and processed there. * In universal .NET builds, debug symbols are created for the universal app bundle, not for each rid-specific version of the app bundle. So I had to add logic to create the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then collect them and merge those lists for the universal app bundle. The existing SymbolStrip call we did right after linking the native executable has been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols target does). Also add tests. Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
2022-02-11 15:55:22 +03:00
/>
<!-- There's no need to touch the stamp file, because it's a file created by dsymutil -->
</Target>
<!-- This target will execute strip on items in the _NativeStripItems item group -->
<Target
Name="_NativeStripFiles"
Condition="'$(_PostProcess)' == 'true'"
Inputs="@(_NativeStripItems->'$(_AppContainerDir)%(Identity)')"
Outputs="%(_NativeStripItems.StripStampFile)"
DependsOnTargets="_PreparePostProcessing"
>
<!-- strip the debug symbols from the executable -->
<SymbolStrip
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Executable="$(_AppContainerDir)%(_NativeStripItems.Identity)"
Kind="%(_NativeStripItems.Kind)"
SymbolFile="%(_NativeStripItems.SymbolFile)"
/>
<!-- Create/touch the stamp file. -->
<MakeDir
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Directories="$([System.IO.Path]::GetDirectoryName('%(_NativeStripItems.StripStampFile)'))" />
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Files="%(_NativeStripItems.StripStampFile)"
AlwaysCreate="true"
/>
<!--
Also touch the dSYM Info.plist so that its mtime is newer than the stripped executable,
otherwise we might end up re-executing dsymutil on a stripped binary
-->
<Touch
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true' And Exists('%(_NativeStripItems.dSYMInfoPlist)')"
Files="%(_NativeStripItems.dSYMInfoPlist)"
/>
</Target>
[msbuild] Move spotlight indexing out to its own task. Also establish when we should do post processing: only in the outermost build. This is a slight change from previous behavior, where we'd run strip/dsymutil separately for app extensions and watch apps.
2022-02-11 15:55:22 +03:00
<!-- make sure spotlight indexes everything we've built -->
<Target
Name="_NotifySpotlight"
Condition="'$(_PostProcess)' == 'true'"
>
<SpotlightIndexer
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Input="$(_AppContainerDir)"
/>
</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)' == ''">
[msbuild] Rework code signing. The main theme here is that code signing will be done in the outermost executable project, not in any app extension projects or watch projects, nor during the RID-specific build of a .NET universal app. This makes codesigning easier to reason about and other affected logic (such as strip/dsymutil) easier to handle, in particular for .NET universal apps. Another benefit is that the differences between the iOS and macOS code bases have been eliminated. The first step is to collect all the information we need from the targets files. Every app bundle (be it app extension, watch app or main app) will add its own output app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle will load this informarion from referenced app bundles, and finally store this information on disk (in the 'codesign-bundle.items' file). This means that in the end the main app bundle will have a list of all contained app bundles in the app (recursively), in the _CodesignBundle item group. Separately we keep a list of other items that need signing, in the _CodesignItems item group, and we do the same store/load logic for every contained/contained app bundle (in the 'codesign.items' file, so a the end the main app bundle will have a list of all the _CodesignItems for all contained app bundles (recursively). The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData targets. The next step is to use the new ComputeCodesignItems task to compute everything we need to know for code signing. This task takes over the responsibility for listing all the *.dylib and *.metallib files, and the *.framework directories in the app bundles, that need signing (which was previously done in the targets file). This logic is significantly easier to write, debug and test in C# than MSBuild. In addition the ComputeCodesignItems also figures out a stamp file path we use to determine if something needs (re-)signing. Previously .framework directories did not have a stamp location, so they'd always end up resigned in a rebuild, while now we'll automatically skip signing *.framework directories unless something changed in them. I've also tried to comment everything thorougly, for the next poor soul having to deal with any bugs, as well has adding a comprehensive test for the new task. Behavioral differences: * We were always signing *.dylib files for macOS. We're now doing the same thing for all platforms. * We're now always signing *.framework directories for all platforms (like we do for *.dylib files), since frameworks are pretty much like dylibs anyways.
2022-02-11 15:55:22 +03:00
<_AppContainerDir Condition="'$(IsAppDistribution)' != 'true'">$(DeviceSpecificOutputPath)</_AppContainerDir>
<_AppContainerDir Condition="'$(IsAppDistribution)' == 'true'">$(ArchivePath)\Products\Applications\</_AppContainerDir>
<AppBundleDir>$(_AppContainerDir)$(_AppBundleName)$(AppBundleExtension)</AppBundleDir>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
</PropertyGroup>
[msbuild] Compute _AppContainerDir from AppBundleDir if AppBundleDir is set by the developer. Fixes #15014. (#15869) Fixes https://github.com/xamarin/xamarin-macios/issues/15014.
2022-09-07 12:33:39 +03:00
<PropertyGroup Condition="'$(_AppContainerDir)' == ''">
[msbuild] Use the right trailing slash for _AppContainerDir according to the current platform.
2023-04-20 12:03:18 +03:00
<_AppContainerDir>$([MSBuild]::EnsureTrailingSlash($([System.IO.Path]::GetDirectoryName($(AppBundleDir)))))</_AppContainerDir>
[msbuild] Compute _AppContainerDir from AppBundleDir if AppBundleDir is set by the developer. Fixes #15014. (#15869) Fixes https://github.com/xamarin/xamarin-macios/issues/15014.
2022-09-07 12:33:39 +03:00
</PropertyGroup>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
<PropertyGroup>
[msbuild] Make sure '_AppBundlePath' is always relative. Fixes #15130. (#15868) _AppBundlePath is relative by default, but if AppBundleDir is set to an absolute path (or the root path used to compute AppBundleDir is an absolute path), then we must ensure _AppBundlePath is still a relative path, because our code depends on this. Note that there are no tests for this, because: * The problem is that our code concatenates a path + _AppBundlePath. * This works fine on macOS, because it still looks like a valid path. * It does not work fine on Windows, because the resulting path ends up with a drive letter in the middle. * We currently don't have any tests on Windows. Fixes https://github.com/xamarin/xamarin-macios/issues/15130.
2022-09-07 11:42:30 +03:00
<!-- Ensure _AppBundlePath is a relative path (relative to the project directory) and contains a trailing slash -->
<_AppBundlePath>$(AppBundleDir)</_AppBundlePath>
<_AppBundlePath Condition="$([System.IO.Path]::IsPathRooted('$(AppBundleDir)'))">$([MSBuild]::MakeRelative('$(MSBuildProjectDirectory)','$(AppBundleDir)'))</_AppBundlePath>
<_AppBundlePath>$([MSBuild]::EnsureTrailingSlash('$(_AppBundlePath)'))</_AppBundlePath>
[dotnet] Start using the new ComputeBundleLocation task
2021-08-12 13:30:57 +03:00
<_AppResourcesRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\Resources\</_AppResourcesRelativePath>
<_AppResourcesRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'"></_AppResourcesRelativePath>
<_AppResourcesPath>$(_AppBundlePath)$(_AppResourcesRelativePath)</_AppResourcesPath>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
[dotnet] Start using the new ComputeBundleLocation task
2021-08-12 13:30:57 +03:00
<_AppContentsRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\$(_CustomBundleName)</_AppContentsRelativePath>
<_AppContentsRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'"></_AppContentsRelativePath>
<_AppContentsPath>$(_AppBundlePath)$(_AppContentsRelativePath)</_AppContentsPath>
<_AppFrameworksRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\Frameworks\</_AppFrameworksRelativePath>
<_AppFrameworksRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">Frameworks\</_AppFrameworksRelativePath>
<_AppFrameworksPath>$(_AppBundlePath)$(_AppFrameworksRelativePath)</_AppFrameworksPath>
[msbuild] Unify the _GenerateBundleName targets between Xamarin.iOS and Xamarin.Mac (#10621)
2021-02-12 13:23:47 +03:00
[msbuild] Share the logic to CalculateCodesignAppBundleInputs between iOS and Mac. (#13844)
2022-01-25 13:34:42 +03:00
<_AppCodeSignatureRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\</_AppCodeSignatureRelativePath>
<_AppCodeSignatureRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'"></_AppCodeSignatureRelativePath>
<_AppCodeSignaturePath>$(_AppBundlePath)$(_AppCodeSignatureRelativePath)</_AppCodeSignaturePath>
[dotnet] Start using the new ComputeBundleLocation task
2021-08-12 13:30:57 +03:00
<_AppPlugInsRelativePath Condition="'$(_PlatformName)' == 'macOS' Or '$(_PlatformName)' == 'MacCatalyst'">Contents\PlugIns\</_AppPlugInsRelativePath>
<_AppPlugInsRelativePath Condition="'$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS' Or '$(_PlatformName)' == 'watchOS'">PlugIns\</_AppPlugInsRelativePath>
<_AppPlugInsPath>$(_AppBundlePath)$(_AppPlugInsRelativePath)</_AppPlugInsPath>
[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'"
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
AppManifest="$(_AppBundleManifestPath)"
[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>
[dotnet] macOS/MacCatalyst Archive and publishing support (#15720) These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac. Co-authored-by: Alex Soto <alex@alexsoto.me>
2022-08-26 09:18:43 +03:00
<PropertyGroup>
<_CreateInstallerDependsOn>
_GenerateBundleName;
_GetAppBundleEntitlements;
Codesign;
_CompileProductDefinition;
_WriteAppManifest
</_CreateInstallerDependsOn>
</PropertyGroup>
<Target Name="_CreateInstaller" Condition="'$(CreatePackage)' == 'true' And '$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="$(_CreateInstallerDependsOn)">
[dotnet] Put packages (.ipa/.pkg) in the publish directory by default. (#13436) Partial fix for #12997.
2021-11-24 18:00:16 +03:00
<PropertyGroup>
<PkgPackageDir Condition="'$(PkgPackageDir)' == ''">$(TargetDir)</PkgPackageDir>
</PropertyGroup>
[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)"
Our current behavior is to detect any None, BundleResource or Content item that's (#13550) named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.
2021-12-14 22:56:52 +03:00
AppManifest="$(_AppBundleManifestPath)"
[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)"
[dotnet] Put packages (.ipa/.pkg) in the publish directory by default. (#13436) Partial fix for #12997.
2021-11-24 18:00:16 +03:00
OutputDirectory="$(PkgPackageDir)"
[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
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>
[dotnet] macOS/MacCatalyst Archive and publishing support (#15720) These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac. Co-authored-by: Alex Soto <alex@alexsoto.me>
2022-08-26 09:18:43 +03:00
<!--
Creates a plist with the entitlements used to sign the App bundle.
MacCatalyst apps don't have a compiled entitlements file in the app bundle,
so to re-sign the app we need to reuse the entitlements that were originally used to sign it
-->
<Target Name="_GetAppBundleEntitlements" Condition="'$(IsAppDistribution)' == 'true' And '$(CodesignEntitlements)' == '' And Exists('$(AppBundleDir)\Contents\_CodeSignature')">
<PropertyGroup>
<_CompiledCodesignEntitlements>$(DeviceSpecificIntermediateOutputPath)AppBundleEntitlements.plist</_CompiledCodesignEntitlements>
</PropertyGroup>
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(_CompiledCodesignEntitlements)" />
<!-- The following command grabs the entitlements that are part of the signature of the app bundle, and creates a plist containing those -->
<Exec
SessionId="$(BuildSessionId)"
Condition="'$(IsMacEnabled)' == 'true'"
Command="codesign --display --entitlements '$(_CompiledCodesignEntitlements)' --xml '$(AppBundleDir)'" />
</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 -->
[msbuild] Don't use custom logic to handle facades in .NET. (#13461) It's not needed, and may in some cases do the wrong thing: for instance, this logic will automatically reference any *.dll files in the project directory, which breaks the build if those *.dll files aren't actually assemblies.
2021-11-29 09:54:47 +03:00
<Import Project="$(MSBuildThisFileDirectory)Xamarin.ImplicitFacade.targets" Condition="!('$(_PlatformName)' == 'macOS' And '$(TargetFrameworkName)' == 'System') And '$(UsingAppleNETSdk)' != '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
[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>