2016-04-21 16:40:25 +03:00
|
|
|
<!--
|
|
|
|
|
***********************************************************************************************
|
|
|
|
|
Xamarin.iOS.Common.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) 2013-2016 Xamarin. All rights reserved.
|
|
|
|
|
***********************************************************************************************
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
2020-08-21 11:13:40 +03:00
|
|
|
<Import Project="$(MSBuildThisFileDirectory)Xamarin.iOS.Common.props" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets"
|
|
|
|
|
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).Before.targets')"/>
|
|
|
|
|
|
2018-12-12 17:55:57 +03:00
|
|
|
<Import Project="$(MSBuildThisFileDirectory)Xamarin.Shared.targets" />
|
|
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<PropertyGroup>
|
2016-12-09 19:55:25 +03:00
|
|
|
<_CanDeployToDeviceOrSimulator>False</_CanDeployToDeviceOrSimulator>
|
2017-04-11 09:17:54 +03:00
|
|
|
<_CanDeployToDeviceOrSimulator Condition="('$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true') And '$(IsWatchApp)' == 'false'">True</_CanDeployToDeviceOrSimulator>
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<_PreparedResourceRules></_PreparedResourceRules>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<!-- Insert our app bundle generation step -->
|
2021-04-22 04:32:33 +03:00
|
|
|
<PropertyGroup Condition="'$(UsingAppleNETSdk)' != 'true'">
|
2016-04-21 16:40:25 +03:00
|
|
|
<BuildDependsOn>
|
|
|
|
|
BuildOnlySettings;
|
|
|
|
|
PrepareForBuild;
|
|
|
|
|
_CollectBundleResources;
|
|
|
|
|
_OptimizePngImages;
|
|
|
|
|
_OptimizePropertyLists;
|
|
|
|
|
_OptimizeLocalizationFiles;
|
|
|
|
|
_PackLibraryResources;
|
|
|
|
|
_UnpackLibraryResources;
|
|
|
|
|
$(BuildDependsOn);
|
|
|
|
|
_GenerateBundleName;
|
|
|
|
|
_CleanUploaded;
|
|
|
|
|
_CreateAppBundle;
|
|
|
|
|
Codesign;
|
|
|
|
|
CreateIpa;
|
|
|
|
|
Archive;
|
|
|
|
|
</BuildDependsOn>
|
|
|
|
|
|
|
|
|
|
<CleanDependsOn>
|
|
|
|
|
$(CleanDependsOn);
|
2017-03-07 09:15:14 +03:00
|
|
|
_ComputeTargetArchitectures;
|
2016-04-21 16:40:25 +03:00
|
|
|
_CleanUploaded;
|
|
|
|
|
</CleanDependsOn>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
2021-04-22 04:32:33 +03:00
|
|
|
<PropertyGroup Condition="'$(UsingAppleNETSdk)' != 'true'">
|
2016-04-21 16:40:25 +03:00
|
|
|
<CreateAppBundleDependsOn>
|
2021-08-05 09:17:44 +03:00
|
|
|
$(CreateAppBundleDependsOn);
|
2016-04-21 16:40:25 +03:00
|
|
|
_DetectSigningIdentity;
|
|
|
|
|
_CopyResourcesToBundle;
|
|
|
|
|
_CreateAssetPackManifest;
|
|
|
|
|
_SmeltMetal;
|
|
|
|
|
_TemperMetal;
|
2017-11-28 19:16:44 +03:00
|
|
|
_CompileCoreMLModels;
|
2016-04-21 16:40:25 +03:00
|
|
|
_PrepareResourceRules;
|
|
|
|
|
_CompileEntitlements;
|
[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;
|
2017-01-09 19:38:20 +03:00
|
|
|
_GetNativeExecutableName;
|
2020-07-13 15:56:34 +03:00
|
|
|
_ParseBundlerArguments;
|
2017-01-09 19:38:20 +03:00
|
|
|
_CompileToNative;
|
2016-04-21 16:40:25 +03:00
|
|
|
_CompileITunesMetadata;
|
|
|
|
|
_CollectITunesArtwork;
|
|
|
|
|
_CopyITunesArtwork;
|
|
|
|
|
_CreateDebugSettings;
|
|
|
|
|
_CreateDebugConfiguration;
|
|
|
|
|
_CreatePkgInfo;
|
|
|
|
|
_CopyAppExtensionsToBundle;
|
2016-06-27 22:22:45 +03:00
|
|
|
_CopyWatchOS2AppsToBundle;
|
2022-02-11 15:55:22 +03:00
|
|
|
_PostProcessAppBundle;
|
2016-04-21 16:40:25 +03:00
|
|
|
_ValidateAppBundle;
|
|
|
|
|
</CreateAppBundleDependsOn>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<PropertyGroup>
|
2020-06-01 11:23:17 +03:00
|
|
|
<CoreCodesignDependsOn>
|
2017-02-06 21:52:30 +03:00
|
|
|
$(_CodesignAppBundleDependsOn);
|
2020-06-01 11:23:17 +03:00
|
|
|
$(CoreCodesignDependsOn);
|
|
|
|
|
</CoreCodesignDependsOn>
|
2016-04-21 16:40:25 +03:00
|
|
|
</PropertyGroup>
|
|
|
|
|
|
2020-04-06 13:47:01 +03:00
|
|
|
<Target Name="ValidateAppStoreBundle" DependsOnTargets="_DetectSdkLocations;_ComputeTargetFrameworkMoniker">
|
2019-07-29 21:46:12 +03:00
|
|
|
<ALToolValidate
|
2019-08-23 18:08:22 +03:00
|
|
|
SessionId="$(BuildSessionId)"
|
2019-07-25 22:55:17 +03:00
|
|
|
Username="$(Username)"
|
|
|
|
|
Password="$(Password)"
|
|
|
|
|
FilePath="$(FilePath)"
|
2020-03-06 20:28:58 +03:00
|
|
|
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
|
2019-07-25 22:55:17 +03:00
|
|
|
SdkDevPath="$(_SdkDevPath)"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2020-04-06 13:47:01 +03:00
|
|
|
<Target Name="UploadAppStoreBundle" DependsOnTargets="_DetectSdkLocations;_ComputeTargetFrameworkMoniker">
|
2019-08-05 19:07:33 +03:00
|
|
|
<ALToolUpload
|
2019-08-23 18:08:22 +03:00
|
|
|
SessionId="$(BuildSessionId)"
|
2019-08-05 19:07:33 +03:00
|
|
|
Username="$(Username)"
|
|
|
|
|
Password="$(Password)"
|
|
|
|
|
FilePath="$(FilePath)"
|
2020-03-06 20:28:58 +03:00
|
|
|
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
|
2019-08-05 19:07:33 +03:00
|
|
|
SdkDevPath="$(_SdkDevPath)"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2017-03-07 09:15:14 +03:00
|
|
|
<Target Name="_CleanUploaded" Condition="'$(_CanOutputAppBundle)' == 'true'" DependsOnTargets="_ComputeTargetArchitectures">
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(DeviceSpecificOutputPath).uploaded" />
|
2016-04-21 16:40:25 +03:00
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_CreateAssetPackManifest" DependsOnTargets="_CopyResourcesToBundle">
|
|
|
|
|
<CreateAssetPackManifest
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
AppBundleDir="$(AppBundleDir)"
|
|
|
|
|
InitialInstallTags="$(OnDemandResourcesInitialInstallTags)"
|
|
|
|
|
PrefetchOrder="$(OnDemandResourcesPrefetchOrder)"
|
|
|
|
|
OutputPath="$(DeviceSpecificOutputPath)"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2020-02-14 16:26:48 +03:00
|
|
|
<Target Name="_GetWatchAppBundlePath" DependsOnTargets="_GenerateBundleName;$(_GetWatchAppBundlePathDependsOn)">
|
|
|
|
|
<PropertyGroup>
|
|
|
|
|
<!-- needed for GetTargetPath/Build/Rebuild task outputs -->
|
|
|
|
|
<_WatchAppBundlePath>$(MSBuildProjectDirectory)\$(AppBundleDir)</_WatchAppBundlePath>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<_WatchAppBundlePath Include="$(MSBuildProjectDirectory)\$(AppBundleDir)">
|
|
|
|
|
<!-- We need this metadata to fix the source in VS -->
|
|
|
|
|
<BuildSessionId>$(BuildSessionId)</BuildSessionId>
|
|
|
|
|
<BuildServerPath>..\..\$(BuildAppName)\$(BuildSessionId)\$(AppBundleDir)</BuildServerPath>
|
|
|
|
|
</_WatchAppBundlePath>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<Target Name="GetAppBundleDir" DependsOnTargets="_GenerateBundleName" Returns="$(AppBundleDir)"/>
|
|
|
|
|
|
2020-06-18 16:46:45 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<_CompileAppManifestDependsOn>
|
|
|
|
|
$(_CompileAppManifestDependsOn);
|
|
|
|
|
_PrepareResourceRules;
|
|
|
|
|
_ResolveWatchAppReferences;
|
|
|
|
|
_DetectDebugNetworkConfiguration;
|
|
|
|
|
</_CompileAppManifestDependsOn>
|
|
|
|
|
</PropertyGroup>
|
2016-04-21 16:40:25 +03:00
|
|
|
|
2021-08-04 13:42:43 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<_CompileITunesMetadataDependsOn>
|
|
|
|
|
$(_CompileITunesMetadataDependsOn);
|
|
|
|
|
_DetectSdkLocations;
|
|
|
|
|
_GenerateBundleName;
|
|
|
|
|
_ReadAppManifest;
|
|
|
|
|
</_CompileITunesMetadataDependsOn>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<Target Name="_CompileITunesMetadata" Condition="'$(ComputedPlatform)' == 'iPhone' And '$(IsAppExtension)' == 'false' And '$(IsWatchApp)' == 'false'"
|
2021-08-04 13:42:43 +03:00
|
|
|
DependsOnTargets="$(_CompileITunesMetadataDependsOn)"
|
2021-08-20 10:54:59 +03:00
|
|
|
Inputs="@(ITunesMetadata)"
|
2021-09-23 16:32:35 +03:00
|
|
|
Outputs="$(DeviceSpecificOutputPath)iTunesMetadata.plist" >
|
2016-04-21 16:40:25 +03:00
|
|
|
<CompileITunesMetadata
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2021-08-20 10:54:59 +03:00
|
|
|
CFBundleIdentifier="$(_BundleIdentifier)"
|
|
|
|
|
CFBundleVersion="$(_CFBundleVersion)"
|
|
|
|
|
CFBundleDisplayName="$(_CFBundleDisplayName)"
|
2016-04-21 16:40:25 +03:00
|
|
|
ITunesMetadata="@(ITunesMetadata)"
|
|
|
|
|
OutputPath="$(DeviceSpecificOutputPath)iTunesMetadata.plist"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_CollectITunesArtwork" Condition="'$(ComputedPlatform)' == 'iPhone' And '$(IsAppExtension)' == 'false' And '$(IsWatchApp)' == 'false'">
|
|
|
|
|
<CollectITunesArtwork
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ITunesArtwork="@(ITunesArtwork)"
|
|
|
|
|
>
|
|
|
|
|
<Output TaskParameter="ITunesArtworkWithLogicalNames" ItemName="_ITunesArtworkWithLogicalName"/>
|
|
|
|
|
</CollectITunesArtwork>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_CopyITunesArtwork" Condition="'$(ComputedPlatform)' == 'iPhone' And '$(IsAppExtension)' == 'false' And '$(IsWatchApp)' == 'false'"
|
|
|
|
|
DependsOnTargets="_CollectITunesArtwork"
|
|
|
|
|
Inputs="@(_ITunesArtworkWithLogicalName)" Outputs="$(DeviceSpecificOutputPath)%(_ITunesArtworkWithLogicalName.LogicalName)">
|
|
|
|
|
<Copy
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
SourceFiles="@(_ITunesArtworkWithLogicalName)"
|
|
|
|
|
DestinationFiles="$(DeviceSpecificOutputPath)%(_ITunesArtworkWithLogicalName.LogicalName)"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<PropertyGroup>
|
|
|
|
|
<_CompileToNativeDependsOn>
|
2020-08-20 15:26:43 +03:00
|
|
|
_ComputeLinkMode;
|
2020-04-06 13:47:01 +03:00
|
|
|
_ComputeTargetFrameworkMoniker;
|
2016-04-21 16:40:25 +03:00
|
|
|
_DetectSdkLocations;
|
|
|
|
|
_GenerateBundleName;
|
|
|
|
|
_DetectSigningIdentity;
|
|
|
|
|
_CompileEntitlements;
|
[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;
|
2016-04-21 16:40:25 +03:00
|
|
|
_ResolveAppExtensionReferences;
|
2020-07-16 18:13:15 +03:00
|
|
|
_ExtendAppExtensionReferences;
|
2017-03-16 22:32:04 +03:00
|
|
|
_GetNativeExecutableName;
|
2018-12-12 17:55:57 +03:00
|
|
|
_GetCompileToNativeInputs;
|
|
|
|
|
_ExpandNativeReferences;
|
2016-04-21 16:40:25 +03:00
|
|
|
</_CompileToNativeDependsOn>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
[msbuild] $(ProduceReferenceAssembly) support (#6458)
Context: http://feedback.devdiv.io/600039
Context: https://github.com/xamarin/xamarin-android/blob/63219342370430031507d789fabcb46e1d0db515/Documentation/guides/MSBuildReferenceAssemblies.md
Context: https://github.com/dotnet/roslyn/blob/master/docs/features/refout.md#msbuild
For Xamarin.Android, we have been doing a bit of work to enable a new
MSBuild/Roslyn feature called "reference assemblies". You can opt into
this by setting $(ProduceReferenceAssembly)=true in a netstandard
project.
The benefit being that if the public API doesn't change in the
netstandard library, the head projects don't need to run `CoreCompile`
or `<Csc/>` during an incremental build.
Unfortunately, this seems to have uncovered a problem in the
Xamarin.iOS MSBuild targets. If you do a build with a XAML-only change,
you get:
Target "_CompileToNative" in file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets":
Skipping target "_CompileToNative" because all output files are up-to-date with respect to the input files.
Input files: /Users/jonathanpeppers/Projects/HelloForms/HelloForms.iOS/bin/iPhoneSimulator/Debug/HelloForms.iOS.exe
Output files: bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/HelloForms.iOS.app/HelloForms.iOS;bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/mtouch.stamp
Because we are using `$(ProduceReferenceAssembly)` the
`HelloForms.iOS.exe` assembly will have no changes. Only
`HelloForms.dll`, the netstandard project, has changes. We were able
to skip `CoreCompile` in the iOS head project. Faster builds, yeah!
However, we actually need `_CompileToNative` to run, or we won't see
any changes on the device or simulator... It only runs if
`$(TargetPath)` changes.
The fix here is to add new `Inputs`, so `_CompileToNative` runs when
any referenced assemblies change:
<_CompileToNativeInput Include="$(TargetDir)$(TargetFileName);@(ReferencePath);@(MTouchReferencePath)" />
This fixes incremental builds (or changes) for:
* Any `<ProjectReference/>` that has `$(ProduceReferenceAssembly)`
* Any NuGet package that ships a reference assembly alongside its
"regular" assembly
I also moved the `<ItemGroup>`'s, just so the code made sense --
so we have all the important `<ItemGroup>`'s in one place.
I also updated the `XamarinForms` test to verify things are working.
I added a couple helpers to assist in writing MSBuild tests:
* `IsTargetSkipped` to check if a specific MSBuild target ran
* `Logger.Clear` to clear past MSBuild events within a single test
2019-07-12 22:34:06 +03:00
|
|
|
<Target Name="_CompileToNative" DependsOnTargets="$(_CompileToNativeDependsOn)"
|
2021-04-22 04:32:33 +03:00
|
|
|
Condition = "'$(IsAppDistribution)' != 'true' And '$(UsingAppleNETSdk)' != 'true'"
|
2021-09-17 17:02:09 +03:00
|
|
|
Inputs="@(_CompileToNativeInput);@(_FileNativeReference)"
|
2020-12-03 10:12:18 +03:00
|
|
|
Outputs="$(_NativeExecutable);$(DeviceSpecificOutputPath)bundler.stamp">
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<MTouch
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(MtouchExe)"
|
|
|
|
|
ToolPath="$(MtouchPath)"
|
|
|
|
|
AppBundleDir="$(AppBundleDir)"
|
|
|
|
|
Architectures="$(TargetArchitectures)"
|
|
|
|
|
ExecutableName="$(_ExecutableName)"
|
2017-11-29 23:26:29 +03:00
|
|
|
CompiledEntitlements="$(_CompiledEntitlements)"
|
2020-06-15 10:17:17 +03:00
|
|
|
Debug="$(_BundlerDebug)"
|
2020-07-13 15:56:34 +03:00
|
|
|
ExtraArgs="$(_BundlerArguments)"
|
2016-04-21 16:40:25 +03:00
|
|
|
FastDev="$(MtouchFastDev)"
|
|
|
|
|
HttpClientHandler="$(MtouchHttpClientHandler)"
|
|
|
|
|
I18n="$(MtouchI18n)"
|
|
|
|
|
IntermediateOutputPath="$(DeviceSpecificIntermediateOutputPath)mtouch-cache"
|
|
|
|
|
IsAppExtension="$(IsAppExtension)"
|
2016-04-26 23:14:29 +03:00
|
|
|
LinkDescriptions="@(LinkDescription)"
|
2016-04-21 16:40:25 +03:00
|
|
|
LinkerDumpDependencies="$(MtouchLinkerDumpDependencies)"
|
2020-06-05 18:07:16 +03:00
|
|
|
LinkMode="$(_LinkMode)"
|
2016-04-21 16:40:25 +03:00
|
|
|
MainAssembly="$(TargetPath)"
|
2020-06-16 18:40:04 +03:00
|
|
|
MinimumOSVersion="$(_MinimumOSVersion)"
|
[msbuild] Simplify resolving xcframeworks (#10376)
TD&LR: This PR simplifies how we refer to user frameworks and fixes both
warnings and non-optimal (app) output.
Much longer story:
Additional testing on macOS showed some build-time warnings and an
[extra (dupe) file](https://github.com/spouliot/xcframework/commit/a20f8aba419e32e2338cb7c5e4b45d0f38862893#diff-54fd7d9cd5deae57f30195be0a43133eace03c1132401741a317e0ae8d5e13fdR34).
Logs shows that we referred to the xcframework several times, where once
should have been enough.
```
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework/macos-arm64_x86_64/Universal.framework
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework/macos-arm64_x86_64/Universal.framework/Universal
```
The first `/native-reference` line produced a warning like:
```
MMP warning MM2006: Native library 'Universal.xcframework' was referenced but could not be found.
```
which makes sense as the tools (both `mmp` and `mtouch`) are not, by
design, aware of (unresolved) xcframeworks.
Removing `{NativeReference}` from `Xamarin.Mac.Common.targets` (and
`Xamarin.iOS.Common.targets`) as it has already been processed by
`_ExpandNativeReferences` solves this.
The other part of the issue (next two lines) is because `msbuild` does
not track changes to directories like it does for files - and the
workaround (in `_ExpandNativeReferences`) had to be copied in other
places (both XI and XM `_CompileToNative`) and that was not enough (and
would eventually need to be duplicated again and again).
This could lead to duplicate entries (i msbuild logs) like
```
NativeReferences
../../Universal.xcframework/macos-arm64_x86_64/Universal.framework
../../Universal.xcframework/macos-arm64_x86_64/Universal.framework/Univeral
```
which maps to our extra entries.
In order to simplify things we make the `_ExpandNativeReferences` resolve
the full path to the library name (not the `.framework` directory) which
simplifies both `_CompileToNative` and ensure a single way (at least for
`msbuild`) to provide this data to the tools (`mmp` and `mtouch`).
Using a file, instead of a directory, is also more consistent for the
existing `-framework` option, e.g. we provide the names like:
```
--framework=CoreLocation
--framework=ModelIO
```
So adding a full path that include the name is more appropriate, e.g.
``` --framework=/Users/poupou/git/master/xamarin-macios/tests/xharness/tmp-test-dir/xcframework-test760/bin/AnyCPU/Debug/bindings-xcframework-test.resources/XTest.xcframework/ios-i386_x86_64-simulator/XTest.framework/XTest
```
Finally for macOS applications it turns out we were embedding yet another
copy of the framework's library inside the `MonoBundle`, which is clearly
wrong, because of the last entry.
```
$ l bin/Release/xcf-mac.app/Contents/MonoBundle/Universal
-rwxr-xr-x 1 poupou staff 167152 2 Dec 16:16 bin/Release/xcf-mac.app/Contents/MonoBundle/Universal
```
The tool now checks if a provided library is inside a framework (or not)
which is a good validation to have anyway when it gets called directly,
i.e. not thru `msbuild`.
2021-01-13 00:02:01 +03:00
|
|
|
NativeReferences="@(_FrameworkNativeReference);@(_FileNativeReference)"
|
2016-04-21 16:40:25 +03:00
|
|
|
OutputPath="$(DeviceSpecificOutputPath)"
|
|
|
|
|
Profiling="$(MtouchProfiling)"
|
|
|
|
|
ProjectDir="$(MtouchProjectDirectory)"
|
2020-12-03 10:12:18 +03:00
|
|
|
References="@(ReferencePath);@(_BundlerReferencePath)"
|
2022-08-18 18:21:48 +03:00
|
|
|
Registrar="$(Registrar)"
|
2018-03-05 19:59:53 +03:00
|
|
|
ResponseFilePath="$(DeviceSpecificIntermediateOutputPath)response-file.rsp"
|
2016-04-21 16:40:25 +03:00
|
|
|
SdkRoot="$(_SdkDevPath)"
|
|
|
|
|
SdkIsSimulator="$(_SdkIsSimulator)"
|
2020-04-28 15:55:35 +03:00
|
|
|
SdkVersion="$(_SdkVersion)"
|
2016-04-21 16:40:25 +03:00
|
|
|
SymbolsList="$(_MtouchSymbolsList)"
|
2020-03-06 20:28:58 +03:00
|
|
|
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
|
2016-04-21 16:40:25 +03:00
|
|
|
UseLlvm="$(MtouchUseLlvm)"
|
|
|
|
|
UseFloat32="$(MtouchFloat32)"
|
|
|
|
|
UseThumb="$(MtouchUseThumb)"
|
|
|
|
|
EnableBitcode="$(MtouchEnableBitcode)"
|
2021-07-28 10:17:53 +03:00
|
|
|
EnableSGenConc="$(EnableSGenConc)"
|
2018-10-10 18:02:28 +03:00
|
|
|
Interpreter="$(MtouchInterpreter)"
|
2016-04-21 16:40:25 +03:00
|
|
|
AppExtensionReferences="@(_ResolvedAppExtensionReferences)"
|
2016-05-31 18:57:47 +03:00
|
|
|
ArchiveSymbols="$(MonoSymbolArchive)"
|
2016-04-21 16:40:25 +03:00
|
|
|
Verbosity="$(MtouchVerbosity)"
|
2019-10-26 00:44:35 +03:00
|
|
|
StandardOutputImportance="High"
|
2020-03-11 21:02:43 +03:00
|
|
|
XamarinSdkRoot="$(_XamarinSdkRoot)"
|
2016-04-21 16:40:25 +03:00
|
|
|
>
|
|
|
|
|
</MTouch>
|
2017-03-16 22:32:04 +03:00
|
|
|
|
|
|
|
|
<Touch
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
|
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
|
|
|
|
AlwaysCreate="true"
|
2020-12-03 10:12:18 +03:00
|
|
|
Files="$(DeviceSpecificOutputPath)bundler.stamp"
|
2017-03-16 22:32:04 +03:00
|
|
|
>
|
|
|
|
|
<Output TaskParameter="TouchedFiles" ItemName="FileWrites" />
|
|
|
|
|
</Touch>
|
2016-04-21 16:40:25 +03:00
|
|
|
</Target>
|
|
|
|
|
|
2020-10-29 10:59:11 +03:00
|
|
|
<Target Name="_ValidateAppBundle" Condition="'$(IsAppExtension)' == 'false' And '$(IsWatchApp)' == 'false'" DependsOnTargets="_DetectSdkLocations;_ComputeTargetFrameworkMoniker;_GenerateBundleName">
|
2016-04-21 16:40:25 +03:00
|
|
|
<ValidateAppBundleTask
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
SessionId="$(BuildSessionId)"
|
|
|
|
|
AppBundlePath="$(_AppBundlePath)"
|
|
|
|
|
SdkIsSimulator="$(_SdkIsSimulator)"
|
2020-03-06 20:28:58 +03:00
|
|
|
TargetFrameworkMoniker="$(_ComputedTargetFrameworkMoniker)"
|
2016-04-21 16:40:25 +03:00
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_SeparateWatchAppReferences" BeforeTargets="AssignProjectConfiguration" Condition="'$(IsAppExtension)' == 'true' Or '$(OutputType)' == 'Exe'">
|
|
|
|
|
<CreateItem Include="@(ProjectReference)" PreserveExistingMetadata="true" Condition="'%(Identity)' != '' And '%(ProjectReference.IsWatchApp)' == 'true'">
|
|
|
|
|
<Output ItemName="_WatchAppReference" TaskParameter="Include" />
|
|
|
|
|
</CreateItem>
|
|
|
|
|
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ProjectReference Remove="@(_WatchAppReference)" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
|
|
|
|
<!--<Warning Text="_SeparateWatchAppReferences: '@(_WatchAppReference)'"/>-->
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_AssignWatchAppConfiguration" Condition="'@(_WatchAppReference)' != ''">
|
|
|
|
|
<!-- assign configs if building a solution file -->
|
|
|
|
|
<AssignProjectConfiguration
|
|
|
|
|
ProjectReferences = "@(_WatchAppReference)"
|
|
|
|
|
SolutionConfigurationContents = "$(CurrentSolutionConfigurationContents)"
|
|
|
|
|
Condition="'$(CurrentSolutionConfigurationContents)' != ''">
|
|
|
|
|
|
|
|
|
|
<Output TaskParameter="AssignedProjects" ItemName="_WatchAppReferenceWithConfiguration"/>
|
|
|
|
|
</AssignProjectConfiguration>
|
|
|
|
|
|
|
|
|
|
<!-- Else, just -->
|
|
|
|
|
<CreateItem Include="@(_WatchAppReference)"
|
|
|
|
|
Condition="'$(CurrentSolutionConfigurationContents)' == ''">
|
|
|
|
|
<Output TaskParameter="Include" ItemName="_WatchAppReferenceWithConfiguration"/>
|
|
|
|
|
</CreateItem>
|
|
|
|
|
|
|
|
|
|
<!--<Warning Text="_AssignWatchAppConfiguration: '@(_WatchAppReferenceWithConfiguration)'"/>-->
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<!-- Split iOS Watch App projects into 2 lists
|
|
|
|
|
_WatchAppReferenceWithConfigurationExistent: Projects existent on disk
|
|
|
|
|
_WatchAppReferenceWithConfigurationNonExistent: Projects non-existent on disk -->
|
2021-08-11 15:06:50 +03:00
|
|
|
<Target Name="_SplitWatchAppReferencesByExistent" DependsOnTargets="_SeparateWatchAppReferences;_AssignWatchAppConfiguration">
|
2016-04-21 16:40:25 +03:00
|
|
|
<CreateItem Include="@(_WatchAppReferenceWithConfiguration)" Condition="'@(_WatchAppReferenceWithConfiguration)' != ''">
|
|
|
|
|
<Output TaskParameter="Include" ItemName="_WatchAppReferenceWithConfigurationExistent"
|
|
|
|
|
Condition="Exists ('%(_WatchAppReferenceWithConfiguration.Identity)')"/>
|
|
|
|
|
|
|
|
|
|
<Output TaskParameter="Include" ItemName="_WatchAppReferenceWithConfigurationNonExistent"
|
|
|
|
|
Condition="!Exists ('%(_WatchAppReferenceWithConfiguration.Identity)')"/>
|
|
|
|
|
</CreateItem>
|
|
|
|
|
|
|
|
|
|
<!--<Warning Text="_SplitWatchAppReferencesByExistent: '@(_WatchAppReferenceWithConfigurationExistent)'"/>-->
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_ResolveWatchAppReferences" DependsOnTargets="_SplitWatchAppReferencesByExistent">
|
[msbuild] Fix app extension builds with msbuild for XI and XM (#1124)
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
2016-11-07 03:15:30 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<!-- When building a .sln with msbuild, the dependent projects may not be built. So, always build
|
|
|
|
|
the referenced projects unless building from IDE. -->
|
2019-12-16 21:05:40 +03:00
|
|
|
<_BuildReferencedExtensionProjects Condition="'$(BuildingInsideVisualStudio)' != 'true'">true</_BuildReferencedExtensionProjects>
|
[msbuild] Fix app extension builds with msbuild for XI and XM (#1124)
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
2016-11-07 03:15:30 +03:00
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<!-- If the referenced projects have already been built, then just get the target paths -->
|
2016-04-21 16:40:25 +03:00
|
|
|
<MSBuild
|
|
|
|
|
Projects="@(_WatchAppReferenceWithConfigurationExistent)"
|
|
|
|
|
Targets="GetBundleTargetPath"
|
|
|
|
|
Properties="%(_WatchAppReferenceWithConfigurationExistent.SetConfiguration); %(_WatchAppReferenceWithConfigurationExistent.SetPlatform)"
|
[msbuild] Fix app extension builds with msbuild for XI and XM (#1124)
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
2016-11-07 03:15:30 +03:00
|
|
|
Condition="'@(_WatchAppReferenceWithConfigurationExistent)' != '' and '$(_BuildReferencedExtensionProjects)' != 'true'">
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedWatchAppReferences" />
|
|
|
|
|
</MSBuild>
|
|
|
|
|
|
[msbuild] Fix app extension builds with msbuild for XI and XM (#1124)
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
2016-11-07 03:15:30 +03:00
|
|
|
<!-- Build the referenced project if required -->
|
2016-04-21 16:40:25 +03:00
|
|
|
<MSBuild
|
|
|
|
|
Projects="@(_WatchAppReferenceWithConfigurationExistent)"
|
|
|
|
|
Properties="%(_WatchAppReferenceWithConfigurationExistent.SetConfiguration); %(_WatchAppReferenceWithConfigurationExistent.SetPlatform)"
|
[msbuild] Fix app extension builds with msbuild for XI and XM (#1124)
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
2016-11-07 03:15:30 +03:00
|
|
|
Condition="'@(_WatchAppReferenceWithConfigurationExistent)' != '' and '$(_BuildReferencedExtensionProjects)' == 'true' ">
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedWatchAppReferences" />
|
|
|
|
|
</MSBuild>
|
|
|
|
|
|
|
|
|
|
<Warning Text="Referenced iOS Watch App Project %(_WatchAppReferenceWithConfigurationNonExistent.Identity) not found, ignoring."
|
|
|
|
|
Condition="'@(_WatchAppReferenceWithConfigurationNonExistent)' != ''"/>
|
|
|
|
|
|
|
|
|
|
<PropertyGroup>
|
2016-10-03 20:44:31 +03:00
|
|
|
<IsWatchExtension Condition="'$(IsAppExtension)' == 'true' And '@(_ResolvedWatchAppReferences)' != ''">True</IsWatchExtension>
|
2016-04-21 16:40:25 +03:00
|
|
|
</PropertyGroup>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2016-06-27 22:22:45 +03:00
|
|
|
<Target Name="_CopyWatchOS2AppsToBundle" Condition="'$(OutputType)' == 'Exe'" DependsOnTargets="_ResolveWatchAppReferences">
|
2016-04-21 16:40:25 +03:00
|
|
|
<Ditto
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '@(_ResolvedWatchAppReferences)' != '' And '%(_ResolvedWatchAppReferences.Identity)' != ''"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(DittoExe)"
|
|
|
|
|
ToolPath="$(DittoPath)"
|
|
|
|
|
Source="@(_ResolvedWatchAppReferences)"
|
|
|
|
|
Destination="$(_AppBundlePath)Watch\%(_ResolvedWatchAppReferences.FileName)%(_ResolvedWatchAppReferences.Extension)"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2019-08-16 12:00:20 +03:00
|
|
|
<Target Name="_CoreCreateIpa" Condition="'$(BuildIpa)' == 'true'" DependsOnTargets="Codesign">
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(DeviceSpecificIntermediateOutputPath)ipa" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(DeviceSpecificIntermediateOutputPath)ipa\Payload" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<PropertyGroup>
|
|
|
|
|
<_IpaAppBundleDir>$(DeviceSpecificIntermediateOutputPath)ipa\Payload\$(_AppBundleName).app\</_IpaAppBundleDir>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<!-- Clone the compiled app bundle into the IPA's Payload directory... -->
|
|
|
|
|
<Ditto
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(DittoExe)"
|
|
|
|
|
ToolPath="$(DittoPath)"
|
|
|
|
|
Source="$(AppBundleDir)"
|
|
|
|
|
Destination="$(_IpaAppBundleDir)"
|
|
|
|
|
/>
|
|
|
|
|
|
2016-06-15 14:50:27 +03:00
|
|
|
<FindWatchOS2AppBundle
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '@(_ResolvedWatchAppReferences)' != ''"
|
2016-06-15 14:50:27 +03:00
|
|
|
WatchAppReferences="@(_ResolvedWatchAppReferences)"
|
|
|
|
|
>
|
|
|
|
|
<Output TaskParameter="WatchOS2AppBundle" PropertyName="_WatchOS2AppBundle"/>
|
|
|
|
|
</FindWatchOS2AppBundle>
|
|
|
|
|
|
|
|
|
|
<Copy
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2022-12-15 13:08:49 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '$(_WatchOS2AppBundle)' != '' And Exists('$(_WatchOS2AppBundle)\_WatchKitStub\WK')"
|
2016-06-15 14:50:27 +03:00
|
|
|
SourceFiles="$(_WatchOS2AppBundle)\_WatchKitStub\WK"
|
|
|
|
|
DestinationFolder="$(DeviceSpecificIntermediateOutputPath)ipa\WatchKitSupport2"
|
|
|
|
|
/>
|
|
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<CollectITunesSourceFiles
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
OutputPath="$(DeviceSpecificOutputPath)"
|
|
|
|
|
>
|
|
|
|
|
<Output TaskParameter="ITunesSourceFiles" ItemName="_ITunesSourceFile"/>
|
|
|
|
|
</CollectITunesSourceFiles>
|
|
|
|
|
|
|
|
|
|
<Copy
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '@(_ITunesSourceFile)' != ''"
|
2016-04-21 16:40:25 +03:00
|
|
|
SourceFiles="@(_ITunesSourceFile)"
|
|
|
|
|
DestinationFolder="$(DeviceSpecificIntermediateOutputPath)ipa"
|
|
|
|
|
/>
|
|
|
|
|
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\Payload" />
|
|
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\WatchKitSupport" Condition="Exists ('$(DeviceSpecificIntermediateOutputPath)ipa\WatchKitSupport\WK')" />
|
2016-06-15 14:50:27 +03:00
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\WatchKitSupport2" Condition="Exists ('$(DeviceSpecificIntermediateOutputPath)ipa\WatchKitSupport2\WK')" />
|
2016-04-21 16:40:25 +03:00
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\iTunesMetadata.plist" Condition="'$(IpaIncludeArtwork)' == 'true' And Exists ('$(DeviceSpecificIntermediateOutputPath)ipa\iTunesMetadata.plist')" />
|
|
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\iTunesArtwork@2x" Condition="'$(IpaIncludeArtwork)' == 'true' And Exists ('$(DeviceSpecificIntermediateOutputPath)ipa\iTunesArtwork@2x')" />
|
|
|
|
|
<_IpaPackageSource Include="$(DeviceSpecificIntermediateOutputPath)ipa\iTunesArtwork" Condition="'$(IpaIncludeArtwork)' == 'true' And Exists ('$(DeviceSpecificIntermediateOutputPath)ipa\iTunesArtwork')" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
|
|
|
|
|
<PropertyGroup>
|
2016-07-01 07:22:41 +03:00
|
|
|
<!-- Calculate IpaPackageDir and IpaPackageName based on IpaPackagePath, if defined. -->
|
2021-08-11 11:01:16 +03:00
|
|
|
<IpaPackageDir Condition="'$(IpaPackagePath)' != ''">$([System.IO.Path]::GetDirectoryName('$(IpaPackagePath)'))</IpaPackageDir>
|
|
|
|
|
<IpaPackageName Condition="'$(IpaPackagePath)' != ''">$([System.IO.Path]::GetFileName('$(IpaPackagePath)'))</IpaPackageName>
|
2017-01-10 00:11:50 +03:00
|
|
|
|
2016-06-27 21:39:38 +03:00
|
|
|
<!-- Calculate an IPA package directory path if not already defined by the developer. -->
|
|
|
|
|
<!--<IpaPackageDir Condition="'$(IpaPackageDir)' == ''">$([System.Environment]::GetEnvironmentVariable('IPA_PACKAGE_DIR'))</IpaPackageDir>-->
|
2017-01-19 00:07:30 +03:00
|
|
|
<IpaPackageDir Condition="'$(IpaPackageDir)' == ''">$(DeviceSpecificOutputPath)</IpaPackageDir>
|
2016-06-27 21:39:38 +03:00
|
|
|
|
|
|
|
|
<!-- Calculate an IPA package name if not already defined by the developer. -->
|
|
|
|
|
<!--<IpaPackageName Condition="'$(IpaPackageName)' == ''">$([System.Environment]::GetEnvironmentVariable('IPA_PACKAGE_NAME'))</IpaPackageName>-->
|
2016-04-21 16:40:25 +03:00
|
|
|
<IpaPackageName Condition="'$(IpaPackageName)' != '' And !$(IpaPackageName.EndsWith ('.ipa', StringComparison.OrdinalIgnoreCase))">$(IpaPackageName).ipa</IpaPackageName>
|
|
|
|
|
<IpaPackageName Condition="'$(IpaPackageName)' == ''">$(_AppBundleName).ipa</IpaPackageName>
|
|
|
|
|
|
2016-06-27 21:39:38 +03:00
|
|
|
<!-- Calculate the full path of the IPA package if not already defined by the developer. -->
|
|
|
|
|
<!--<IpaPackagePath Condition="'$(IpaPackagePath)' == ''">$([System.Environment]::GetEnvironmentVariable('IPA_PACKAGE_PATH'))</IpaPackagePath>-->
|
|
|
|
|
<IpaPackagePath Condition="'$(IpaPackagePath)' == ''">$(IpaPackageDir)\$(IpaPackageName)</IpaPackagePath>
|
2016-04-21 16:40:25 +03:00
|
|
|
</PropertyGroup>
|
|
|
|
|
</Target>
|
|
|
|
|
|
2017-05-26 21:52:07 +03:00
|
|
|
<Target Name="_PackageOnDemandResources" Condition="'$(BuildIpa)' == 'true' And '$(EnableOnDemandResources)' == 'true' And ('$(_DistributionType)' == 'AppStore' Or '$(_DistributionType)' == 'AdHoc')" >
|
2016-04-21 16:40:25 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<_PayloadDir>$(DeviceSpecificIntermediateOutputPath)ipa\Payload\</_PayloadDir>
|
|
|
|
|
<_IpaAppBundleDir>$(_PayloadDir)$(_AppBundleName).app\</_IpaAppBundleDir>
|
2017-01-10 00:11:50 +03:00
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<_IntermediateODRDir Condition="'$(_DistributionType)' == 'AppStore'">$(_PayloadDir)OnDemandResources\</_IntermediateODRDir>
|
|
|
|
|
<_IntermediateODRDir Condition="'$(_DistributionType)' == 'AdHoc' And '$(EmbedOnDemandResources)' == 'true'">$(_IpaAppBundleDir)OnDemandResources\</_IntermediateODRDir>
|
|
|
|
|
<_IntermediateODRDir Condition="'$(_DistributionType)' == 'AdHoc' And '$(EmbedOnDemandResources)' == 'false'">$(DeviceSpecificIntermediateOutputPath)OnDemandResourcesPackage\OnDemandResources\</_IntermediateODRDir>
|
|
|
|
|
|
2017-04-24 23:31:36 +03:00
|
|
|
<OnDemandResourcesUrl Condition="'$(OnDemandResourcesUrl)' == '' And '$(_DistributionType)' == 'AdHoc' And '$(EmbedOnDemandResources)' == 'true'">OnDemandResources</OnDemandResourcesUrl>
|
2017-01-20 19:28:34 +03:00
|
|
|
|
2016-04-27 00:26:11 +03:00
|
|
|
<IsStreamable>false</IsStreamable>
|
2017-04-24 23:31:36 +03:00
|
|
|
<IsStreamable Condition="'$(EmbedOnDemandResources)' == 'false'">true</IsStreamable>
|
2017-01-20 19:28:34 +03:00
|
|
|
|
|
|
|
|
<_CodesignDisableTimestamp>False</_CodesignDisableTimestamp>
|
2020-06-15 10:17:17 +03:00
|
|
|
<_CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</_CodesignDisableTimestamp>
|
2016-04-21 16:40:25 +03:00
|
|
|
</PropertyGroup>
|
|
|
|
|
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(_IntermediateODRDir)" />
|
2016-08-25 23:46:34 +03:00
|
|
|
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And Exists('$(DeviceSpecificOutputPath)OnDemandResources\')" Directories="$(_IntermediateODRDir)" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<!-- Clone the compiled assetpack bundle... -->
|
|
|
|
|
<Ditto
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And Exists('$(DeviceSpecificOutputPath)OnDemandResources\')"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(DittoExe)"
|
|
|
|
|
ToolPath="$(DittoPath)"
|
|
|
|
|
Source="$(DeviceSpecificOutputPath)OnDemandResources\"
|
|
|
|
|
Destination="$(_IntermediateODRDir)"
|
|
|
|
|
/>
|
|
|
|
|
|
|
|
|
|
<!-- Look for the *.assetpack folders in the ODR folder -->
|
|
|
|
|
<CollectAssetPacks
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And Exists('$(_IntermediateODRDir)')"
|
2016-04-21 16:40:25 +03:00
|
|
|
OnDemandResourcesPath="$(_IntermediateODRDir)"
|
|
|
|
|
>
|
|
|
|
|
|
|
|
|
|
<Output TaskParameter="AssetPacks" ItemName="_AssetPack"/>
|
|
|
|
|
</CollectAssetPacks>
|
|
|
|
|
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<_AssetPack>
|
|
|
|
|
<_DirectoryName>$([System.IO.Path]::GetDirectoryName('%(Identity)'))</_DirectoryName>
|
|
|
|
|
</_AssetPack>
|
|
|
|
|
<_AssetPack>
|
|
|
|
|
<DirectoryName>$([System.IO.Path]::GetFileName('%(_AssetPack._DirectoryName)'))</DirectoryName>
|
|
|
|
|
</_AssetPack>
|
2022-02-11 23:33:24 +03:00
|
|
|
<_AssetPack>
|
|
|
|
|
<CodesignStampFile>$(DeviceSpecificOutputPath)OnDemandResources-codesign\%(DirectoryName)</CodesignStampFile>
|
|
|
|
|
</_AssetPack>
|
2016-04-21 16:40:25 +03:00
|
|
|
</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="@(_AssetPack->'%(CodesignStampFile)')"
|
|
|
|
|
/>
|
|
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
<!-- Sign assetpacks -->
|
|
|
|
|
<Codesign
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '@(_AssetPack)' != '' And '$(_DistributionType)' == 'AppStore'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(CodesignExe)"
|
|
|
|
|
ToolPath="$(CodesignPath)"
|
|
|
|
|
CodesignAllocate="$(_CodesignAllocate)"
|
2017-01-20 19:28:34 +03:00
|
|
|
DisableTimestamp="$(_CodesignDisableTimestamp)"
|
2016-04-21 16:40:25 +03:00
|
|
|
Keychain="$(CodesignKeychain)"
|
2017-11-29 23:26:29 +03:00
|
|
|
Entitlements="$(_CompiledCodesignEntitlements)"
|
2017-01-18 23:12:14 +03:00
|
|
|
Resources="@(_AssetPack)"
|
2016-04-21 16:40:25 +03:00
|
|
|
SigningKey="$(_CodeSigningKey)"
|
|
|
|
|
ExtraArgs="$(CodesignExtraArgs)"
|
|
|
|
|
>
|
|
|
|
|
</Codesign>
|
|
|
|
|
|
|
|
|
|
<WriteAssetPackManifest
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '$(_DistributionType)' == 'AdHoc' And Exists('$(_IntermediateODRDir)')"
|
2016-04-21 16:40:25 +03:00
|
|
|
TemplatePath="$(_IpaAppBundleDir)AssetPackManifestTemplate.plist"
|
|
|
|
|
OutputFile="$(_IpaAppBundleDir)AssetPackManifest.plist"
|
|
|
|
|
OnDemandResourceUrl="$(OnDemandResourcesUrl)"
|
2016-04-27 00:26:11 +03:00
|
|
|
IsStreamable="$(IsStreamable)"
|
2016-04-21 16:40:25 +03:00
|
|
|
/>
|
|
|
|
|
|
2016-08-25 23:46:34 +03:00
|
|
|
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(_DistributionType)' == 'AdHoc' And Exists('$(_IntermediateODRDir)')" Files="$(_IpaAppBundleDir)AssetPackManifestTemplate.plist" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
2016-04-27 00:26:11 +03:00
|
|
|
<!-- Re-sign app bundle if anything changed inside of it -->
|
2022-02-11 23:33:24 +03:00
|
|
|
<ItemGroup>
|
|
|
|
|
<_IpaAppBundleToSign Include="$(_IpaAppBundleDir)">
|
|
|
|
|
<CodesignStampFile>$(DeviceSpecificOutputPath)OnDemandResources-codesign\$(_AppBundleName).app</CodesignStampFile>
|
|
|
|
|
</_IpaAppBundleToSign>
|
|
|
|
|
</ItemGroup>
|
2016-04-26 18:32:15 +03:00
|
|
|
<Codesign
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '$(_DistributionType)' == 'AdHoc' And Exists('$(_IntermediateODRDir)')"
|
2016-04-26 18:32:15 +03:00
|
|
|
ToolExe="$(CodesignExe)"
|
|
|
|
|
ToolPath="$(CodesignPath)"
|
|
|
|
|
CodesignAllocate="$(_CodesignAllocate)"
|
2017-01-20 19:28:34 +03:00
|
|
|
DisableTimestamp="$(_CodesignDisableTimestamp)"
|
2016-04-26 18:32:15 +03:00
|
|
|
Keychain="$(CodesignKeychain)"
|
2017-11-29 23:26:29 +03:00
|
|
|
Entitlements="$(_CompiledCodesignEntitlements)"
|
2016-04-26 18:32:15 +03:00
|
|
|
ResourceRules="$(_PreparedResourceRules)"
|
2022-02-11 23:33:24 +03:00
|
|
|
Resources="@(_IpaAppBundleToSign)"
|
2016-04-26 18:32:15 +03:00
|
|
|
SigningKey="$(_CodeSigningKey)"
|
|
|
|
|
ExtraArgs="$(CodesignExtraArgs)"
|
|
|
|
|
/>
|
|
|
|
|
|
2016-08-25 23:46:34 +03:00
|
|
|
<RemoveDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(EmbedOnDemandResources)' == 'false'" Directories="$(IpaPackageDir)\OnDemandResources\" />
|
|
|
|
|
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true' And '$(EmbedOnDemandResources)' == 'false'" Directories="$(IpaPackageDir)\OnDemandResources\" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<CreateAssetPack
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '$(EmbedOnDemandResources)' == 'false'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(ZipExe)"
|
|
|
|
|
ToolPath="$(ZipPath)"
|
|
|
|
|
Source="%(_AssetPack.Identity)"
|
2016-07-01 07:22:41 +03:00
|
|
|
OutputFile="$(IpaPackageDir)OnDemandResources\%(_AssetPack.DirectoryName)"
|
2016-04-21 16:40:25 +03:00
|
|
|
/>
|
|
|
|
|
|
|
|
|
|
<Copy
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
2016-08-25 23:46:34 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true' And '$(EmbedOnDemandResources)' == 'false'"
|
2016-04-21 16:40:25 +03:00
|
|
|
SourceFiles="$(_IpaAppBundleDir)AssetPackManifest.plist"
|
2016-07-01 07:22:41 +03:00
|
|
|
DestinationFolder="$(IpaPackageDir)\OnDemandResources\"
|
2016-04-21 16:40:25 +03:00
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_ZipIpa" Condition="'$(BuildIpa)' == 'true'">
|
2016-07-01 07:22:41 +03:00
|
|
|
<MakeDir SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Directories="$(IpaPackageDir)" />
|
|
|
|
|
<Delete SessionId="$(BuildSessionId)" Condition="'$(IsMacEnabled)' == 'true'" Files="$(IpaPackagePath)" />
|
2016-04-21 16:40:25 +03:00
|
|
|
|
|
|
|
|
<Zip
|
|
|
|
|
SessionId="$(BuildSessionId)"
|
[msbuild] Rename and unify to IsMacEnabled (#193)
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
2016-06-16 20:14:43 +03:00
|
|
|
Condition="'$(IsMacEnabled)' == 'true'"
|
2016-04-21 16:40:25 +03:00
|
|
|
ToolExe="$(ZipExe)"
|
|
|
|
|
ToolPath="$(ZipPath)"
|
|
|
|
|
Recursive="true"
|
|
|
|
|
Symlinks="true"
|
|
|
|
|
Sources="@(_IpaPackageSource)"
|
|
|
|
|
OutputFile="$(IpaPackagePath)"
|
|
|
|
|
WorkingDirectory="$(DeviceSpecificIntermediateOutputPath)ipa"
|
2017-01-10 00:11:50 +03:00
|
|
|
>
|
|
|
|
|
<Output TaskParameter="OutputFile" ItemName="FileWrites" />
|
|
|
|
|
</Zip>
|
2016-04-21 16:40:25 +03:00
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Import Project="$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets"
|
|
|
|
|
Condition="Exists('$(MSBuildThisFileDirectory)$(MSBuildThisFileName).After.targets')"/>
|
[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
|
|
|
|
2016-04-21 16:40:25 +03:00
|
|
|
</Project>
|
