_AppBundlePath is relative by default, but if AppBundleDir is set to an
absolute path (or the root path used to compute AppBundleDir is an absolute
path), then we must ensure _AppBundlePath is still a relative path, because
our code depends on this.
Note that there are no tests for this, because:
* The problem is that our code concatenates a path + _AppBundlePath.
* This works fine on macOS, because it still looks like a valid path.
* It does not work fine on Windows, because the resulting path ends up with a
drive letter in the middle.
* We currently don't have any tests on Windows.
Fixes https://github.com/xamarin/xamarin-macios/issues/15130.
* Add additional app extensions to the list of items we need to sign.
* Improve msbuild test for additional app extensions:
* Build for both device and simulator.
* Hopefully fix the signing problems that occurred on the bots last time we tried.
* Assert that both the container and extension are signed during the build when we build for device.
A 10-line fix with 3300 lines of tests...
Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
Fixes:
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Found conflicts between different versions of "System.Reflection.Metadata" that could not be resolved. [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: There was a conflict between "System.Reflection.Metadata, Version=1.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Reflection.Metadata, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: "System.Reflection.Metadata, Version=1.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Reflection.Metadata, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not. [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.Reflection.Metadata, Version=1.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [xamarin-macios/packages/system.reflection.metadata/1.6.0/lib/netstandard2.0/System.Reflection.Metadata.dll]. [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/system.reflection.metadata/1.6.0/lib/netstandard2.0/System.Reflection.Metadata.dll [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "xamarin-macios/packages/system.reflection.metadata/1.6.0/lib/netstandard2.0/System.Reflection.Metadata.dll". [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/system.reflection.metadata/1.6.0/lib/netstandard2.0/System.Reflection.Metadata.dll [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.Reflection.Metadata, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" []. [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/microsoft.net.illink.tasks/6.0.200-1.22219.3/tools/net472/ILLink.Tasks.dll [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "xamarin-macios/packages/microsoft.net.illink.tasks/6.0.200-1.22219.3/tools/net472/ILLink.Tasks.dll". [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: ILLink.Tasks [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Found conflicts between different versions of "System.IO.Compression" that could not be resolved. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: There was a conflict between "System.IO.Compression, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "System.IO.Compression, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: "System.IO.Compression, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "System.IO.Compression, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.IO.Compression, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" [xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.IO.Compression.dll]. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.IO.Compression.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.IO.Compression.dll". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.IO.Compression.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.IO.Compression, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" []. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.dll". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Microsoft.Build [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Xamarin.iOS.Tasks [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.Tasks.Core.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.Tasks.Core.dll". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Microsoft.Build.Tasks.Core [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Xamarin.iOS.Tasks [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Found conflicts between different versions of "System.Net.Http" that could not be resolved. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: There was a conflict between "System.Net.Http, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: "System.Net.Http, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.Net.Http, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Net.Http.dll]. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Net.Http.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Net.Http.dll". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: xamarin-macios/packages/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Net.Http.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: References which depend on "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" []. [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.Tasks.Core.dll [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Project file item includes which caused reference "/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Build.Tasks.Core.dll". [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Microsoft.Build.Tasks.Core [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(2218,5): warning MSB3277: Xamarin.iOS.Tasks [xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj]
Fixes these NuGet warnings:
xamarin-macios/msbuild/Xamarin.MacDev.Tasks/Xamarin.MacDev.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.MacDev.Tasks/Xamarin.MacDev.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.iOS.HotRestart.Client 1.0.93 depends on Merq (>= 1.1.1) but Merq 1.1.1 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
We used to do the following:
1. Have abstract task classes in the Xamarin.*.Task.Core assembly (with all
the actual code for the task in question to work properly on macOS).
2. Subclassed task in the Xamarin.*.Task assembly, which did nothing.
3. On Windows we'd inject a different Xamarin.*.Task assembly, with
Windows-specific overrides for the implementation in the abstract base
class.
However, we no longer do point 3, which means that we no longer need to split
our tasks across two assemblies.
This means that we can remove the Xamarin.\*.Task.Core assemblies, and move all
the code into the corresponding Xamarin.\*.Task assembly instead.
This simplifies our code and speeds up the build.
There are more simplifications that can be done; those will come in later PRs.
These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Compute the .NET version to use when generating the project file to compute
the AOT compiler.
Also include a way to always force the computation, even on macOS (this eases
testing).
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1597624.
Don't blindly set the BuildIpa and CreatePackage values, but instead only set
them (when publishing) if they're not already set.
This makes it possible to publish and not create a package.
Fixes https://github.com/xamarin/xamarin-macios/issues/15696.
I've chosen the iOS implementation, since it's a bit more advanced to support
remote builds (the Mac implementation didn't do anything at all).
This should have no effect, since we don't support remote builds for macOS
anyways.
- Fix AppExtensionReferences ItemSpec in Archive:
when the build is a remote build, we need to fix the ItemSpec of the AppExtensionReferences items so it uses the build server path correctly
- Shorten temp directory for remote zip extractions to avoid long path potential conflicts
Fixes Feedbak Ticket issue: https://developercommunity.visualstudio.com/t/Xamarin-iOS-project-wont-archive-anymor/1587820
I've chosen the iOS implementation, since it's a bit more advanced to support
remote builds (the Mac implementation didn't do anything at all).
This should have no effect, since we don't support remote builds for macOS
anyways.
Fixes this warning:
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Tasks/Codesign.cs(12,27): warning CS0649: Field 'Codesign.cancellationSource' is never assigned to, and will always have its default value null [xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj]
Fixes these warnings:
msbuild/Xamarin.iOS.Tasks/Model/DataItem.cs(25,31): warning CS0169: The field 'DataItem.UnsupportedData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
msbuild/Xamarin.iOS.Tasks/Model/DataSet.cs(12,31): warning CS0169: The field 'DataSet.JsonData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Overriding HOME is dangerous because it could cause unwanted side effects, like breaking the keychain API logic.
For this reason, we need to use a custom environment variable to store the custom home used by the XMA dotnet SDK.
This custom home should be passed everywhere as environment settings when we invoke the dotnet tool
Hot Restart expects the archived-expanded-entitlements.xcent to be empty. If any entitlements are added to that file, the new app signature will be invalid.
These changes ensure that file will be an empty plist when extracting the PreBuilt app.
Partial fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1550700
In the FilterStaticFrameworks task:
* Convert Windows-style paths to Mac-style paths.
* Give a better error if a framework can't be found.
* Don't try to copy frameworks that don't exist on Windows to the Mac.
In the ExtractBindingLibrariesStep:
* Return a relative path to frameworks we've extracted to make things easier for
remote builds.
* In the _ComputeFrameworkFilesToPublish target, don't compute the source
directory for frameworks using RootDir + Directory, because some frameworks
may only exist on the mac, and RootDir + Directory will be a Windows path
when building remotely. Instead use 'Identity', which is a relative path and
will work on both Windows and Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/15289.
This was mostly a clean merge, with a few minor differences:
* We no longer compute whether we're running in the simulator or not when building for Mac Catalyst.
* The task now supports building remotely for macOS (due to code sharing).
Will be useful if we ever support building macOS apps remotely.
* We now call AppleSdkSettings.Init () on macOS. No idea why we weren't
before, but it seems logical for macOS to behave like our other platforms.
There shouldn't be any other functional differences.
Apple removed the -z / --minimize option in Xocde 13.3, so now if you use it
you get a warning: "ignoring unknown option: -z".
So just don't pass -z when using Xcode >= 13.3
Ref: https://github.com/dotnet/runtime/issues/66770
Ref: 5d07dc8977
Only sign the prebuilt hotrestart app in CI, to avoid making it required for
developers to configure code signing.
Also fix DetectSigningIdentity to not require a code signing certificate for
device builds when RequireCodeSigning is false.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
* Unify the CompileSceneKitAsset task implementation between iOS and Mac.
There were no real differences, so might as well use the same code
everywhere.
* Use existing facilities for process launching.
* Parallelize compiling.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
With remote builds, a dedicated dotnet location is being used so the right versioning can be used and managed from VS in Windows. This dedicated dotnet location requires a custom .home location so the donet and nuget caches doesn't conflict with the global installation.
We need to consider and use this custom .home location when running dotnet commands remotely so the right caches are used
This should fix Bug: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1543495
The compiled entitlements should be placed in the intermediate Hot Restart app bundle so those can be picked up by the HotRestart Codesign task. Prior to this change, entitlements set in the project wouldn't be included in the app, making things like Keychain Access fail, even though it was configured.
Fixes https://developercommunity.visualstudio.com/t/Unable-to-use-MSAL-with-locally-connecte/1573064
The current directory at launch is the root directory of the app bundle. This
means that any files written to the current directory when an app is executed,
will be placed there. This becomes a problem when the app is rebuilt (and
resigned), because a valid macOS app bundle doesn't have any files in the root
directory of the app bundle, so signing fails.
We have logic to automatically crash crash reports from the app bundle, but it
turns out this is a more common problem with other types of files (and
folders), so improve the logic a bit:
* Add support for setting a property to automatically clean up everything from
an app bundle we don't think should be there (which is anything not in a
Contents/ subdirectory).
* Use the same property to add support for disabling any cleaning (we already
clean mono's crash reports by default).
* Improve detection of unwanted files to include directories inside the app
bundle, not only files.
Ref: https://github.com/dotnet/maui/issues/7353
Give the full path to the symbols list file in the extension project to the
main project, so that strip can find it.
When building a solution remotely from Windows, we can't compute a relative
path between projects, because they're laid out differently on disk. This
means that we have to use full paths when passing paths between projects (such
as the path to the symbol list file).
Fixes https://github.com/xamarin/xamarin-macios/issues/15046.
Improve error reporting when an external tool fails to print some of stderr (up to 1024 characters).
Before:
error : clang exited with code 1
After:
error : clang exited with code 1:
error : [...]/xamarin-macios/tests/dotnet/MyInterpretedApp/iOS/obj/Debug/net6.0-ios/iossimulator-x64/linker-cache/main.x86_64.mm:58:25: error: use of undeclared identifier 'MONO_AOT_MODE_INTERP_ONLY'; did you mean 'MONO_AOT_MODE_INTERP'?
error : mono_jit_set_aot_mode (MONO_AOT_MODE_INTERP_ONLY);
error : ^~~~~~~~~~~~~~~~~~~~~~~~~
error : MONO_AOT_MODE_INTERP
error : [...]/xamarin-macios/builds/downloads/dotnet-sdk-6.0.301-rtm.22254.17-osx-x64/packs/Microsoft.iOS.Runtime.iossimulator-x64/15.4.16-ci.x64-interpreter-only/runtimes/iossimulator-x64/native/xamarin/mono-runtime.h:452:2: note: 'MONO_AOT_MODE_INTERP' declared here
error : MONO_AOT_MODE_INTERP,
error : ^
* This is a potential mitigation for slower transition to native code when
exception marshalling is enabled (#14812).
* A minor modification was required in the linker, to make sure any modified
assemblies are saved.
Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler
when building a .NET project. This makes it possible to work around #14887 by
manually increasing the number of trampolines.
Ref: https://github.com/xamarin/xamarin-macios/issues/14887
When building a binding project, we need to execute bgen (and csc) on the mac. Figuring
out where these files are on the Mac is rather complicated from a remotely executed
task, so instead we execute a sub-build that computes these properties.
In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props'
file using msbuild, and invoking a custom target that prints the property we're looking
for (the 'targetGetPropertyValue_*' targets).
For multiple reasons this approach doesn't work in .NET anymore (in particular it
seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom
'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved
around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props'
not work correctly since the properties we need wouldn't be set).
So I'm adding a new task that does a sub-build, using either msbuild or dotnet as
appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props'
file, the task creates an actual binding project (an empty one), and executes the
new '_WriteRemoteGeneratorProperties' target in this binding project.
An additional advantage in this new task is that it will only execute one sub-build
where all the properties are computed (the previous approach executed one sub-msbuild
per property).
In order to keep code as similar as possible between legacy Xamarin and .NET, the
new task is being used for legacy Xamarin as well (and the old approach deleted).
This fixes building binding projects on Windows in .NET.
The output directory might or might not be where the app bundle is: by default
it is, but if someone sets the PkgPackageDir variable to provide an alternate
directory for the pkg, then that won't be where we'll find the app bundle.
The good news is that we already have a property that tells us where the app
bundle is (the 'AppBundleDir' property), so just use that instead.
Also:
* Make sure that the output directory exists before we try to write to it.
* Only pass full paths to productbuild, which for some reason doesn't seem to
like relative paths.
Fixes https://github.com/xamarin/xamarin-macios/issues/14751.
It includes a change revert because of threading freeze issues.
An issue has been detected in Xamarin.Messaging 1.5.26 and 1.6.1 that makes the code unstable and sensitive to thread freeze issues, so we are reverting back the changes until we can stabilize it.
This delays the fix of a bug in MSBuild command line builds for iOS remote builds.
This also meant:
* Using 'latest' as the C# language version for all msbuild/ project files.
* Enabling warnaserror for nullability warnings.
* Fix any nullability warnings in the CompileAppManifest files.
* Fix a nullability warning in the Ditto task.
* Fix any '== null' or '!= null' to use 'is null' and 'is not null'.
Use 'Microsoft.<platform>' as the product name instead of 'Xamarin.[iOS|Mac]' for .NET builds. That makes error messages like this:
> [...]\Microsoft.iOS.Sdk\15.4.200-ci.windows2.62\tools\msbuild\iOS\Xamarin.Shared.targets(1676,3): Could not find Xamarin.iOS in /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/15.4.200-ci.windows2.62/.
look a bit better in .NET:
> [...]\Microsoft.iOS.Sdk\15.4.200-ci.windows2.62\tools\msbuild\iOS\Xamarin.Shared.targets(1676,3): Could not find Microsoft.iOS in /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/15.4.200-ci.windows2.62/.
* Move logic to validate the UIDeviceFamily value to shared code.
* Remove logic related to watchOS 1 apps, it's been dead for a while.
* Change logic to not overwriting any existing UIDeviceFamily values in the customer's
Info.plist.
This makes the code more platform-agnostic and easier to work with across all platforms
(such as adding new validations).
Fixes this warning from the Codesign task:
C:\Users\rolf\...\Microsoft.iOS.Sdk\15.4.200-...\tools\msbuild\iOS\Xamarin.Shared.targets(2045,3): Cannot create 'C:\Users\rolf\source\iOSApp4\bin\Debug\net6.0-ios\ios-arm64\device-builds\iphone14.2-15.3.1\iOSApp4.app\Frameworks\ArcGIS-arm64.framework' because a file or directory with the same name already exists.
C:\Users\rolf\...\Microsoft.iOS.Sdk\15.4.200-...\tools\msbuild\iOS\Xamarin.Shared.targets(2045,3): Cannot create 'C:\Users\rolf\source\iOSApp4\bin\Debug\net6.0-ios\ios-arm64\device-builds\iphone14.2-15.3.1\iOSApp4.app\Frameworks\Runtimecore.framework' because a file or directory with the same name already exists.
which occurs when the Codesign task asks XVS to create output files for files from
inside ditto'ed directories, and if XVS created output files for those directories
in the Ditto task, then XVS would be trying to create files inside these output files
as if they were directories. That doesn't work (thus the warning).
I've fixed this by:
* Removing the 'ShouldCreateOutputFile' implementation. The ShouldCreateOutputFile
method is called on Windows, and we can't determine from Windows whether the destination
is a directory or a file.
* Remove the [Output] attribute for the Destination property, this way XVS doesn't
automatically try to create an output file for whatever the destination is.
* Add another CopiedFiles output property, which contains all the copied files
(and only files), so that XVS mirrors this with output files on Windows.
Fixes part of https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/.
When XVS creates output/stamp files on Windows, the paths must be relative,
because otherwise XVS will append the full macOS path to the current Windows
directory and get garbage.
XVS also expects only files as output, so don't return any directories.
Fixes part of https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/.
* Fix resolving paths to required test files (test files can be found relative to the root path of the repository, not relative to where Xamarin.Mac is installed)
* Don't try to sign symlinks - we can end up trying to sign the target of the symlink twice simultaneously.
* Fix finding libxammac.dylib and Xamarin.Mac.dll when testing a system installation (when MAC_DESTDIR or TESTS_USE_SYSTEM are set).
* Remove a few .NET tests we don't need anymore.
Fixes https://github.com/xamarin/maccore/issues/2560.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Sometimes we want to copy the entire input directory from Windows to the Mac
when executing the Ditto task remotely, and sometimes we don't.
In particular we do not want to copy the input directory when the directory on
Windows is an incomplete mirror of what's on the Mac - one scenario being when
copying the app bundle to prepare for IPA creation. The .app directory on
Windows is not complete - all the files are there (maybe? not quite sure, but
that's beside the point here), but some may be empty, because when we only
care about the timestamp for a file, we'll create an empty file on Windows to
mirror the actual file on Mac. Copying this incomplete directory to the Mac,
overwriting the correct files there, will break things badly.
However, sometimes we're not mirroring a directory on Windows, but instead we
have directories as actual build input (for instances frameworks from NuGets),
and in that case we want to copy everything to the Mac.
So this PR adds a parameter to the Ditto task to optionally copy the directory
from Windows for remote builds, and we enable this behavior when we want it -
specifically when copying frameworks.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009 while not
regressing https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009
Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635
Ref: https://github.com/xamarin/xamarin-macios/pull/14375
Updated to 1.5.8, including fixes for a hang in build cancellation during SayHello and also an improvement in the port forwarding logic when establishing the SSH connection
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
Also establish when we should do post processing: only in the outermost build. This
is a slight change from previous behavior, where we'd run strip/dsymutil separately
for app extensions and watch apps.
* Save all the NativeReference metadata in binding resource packages.
* Copy all the NativeReference metadata to new items when resolving native references.
This makes it possible to set custom metadata on NativeReferences, and have that
metadata show up when it's needed, which might not be in the same project (for instance
if the native reference is in a binding project, we might want the custom metadata
when we load the native references from the binding project's resource package -
another case is when app extensions have native references, we might want any custom
metadata in the main executable project to know how to handle certain types of native
references).
Also sort the metadata we write to binding resource packages, so that the output
is stable. This required updating the corresponding tests.
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.
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.
I've verified that this works both by running the submission tests and running
and launching a sample project on device from Windows.
The ComputeCodesignItems does not touch any files, and all the input files
should already exist on the mac, so there's no need to copy files back and
forth.
Mac Catalyst and macOS projects support an 'EnableCodeSigning' property to determine
whether an app is signed or not. In order to bring parity on mobile platforms, add
support for this property for iOS, tvOS and watchOS projects as well - if not set,
we'll still have the old behavior of signing device builds and not signing simulator builds.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The CodesignEntitlements and CodesignResourceRules properties can be relative paths,
and they might be coming from a referenced project. This means that if they're relative
paths, we must resolve them to a full path using the project that defined them (which
is specified using the 'SourceProjectPath' metadata).
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.
I'm removing the old logic first, because the new logic is so different that a diff
just complicates understanding what's happening (there's not much value in comparing
textually what's changed when it's pretty much a complete rewrite).
* [DittoTask] If Source is a folder, add all its content as ITaskItem
* [DittoTask] Undoing undo...
* Accidentally hit Cmd+Z and removed an using statement
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
For reasons I don't quite understand, ditto might fail when executed by XMA:
Target Name=_CopyDirectoriesToBundle Project=C:\Users\rolf\source\iOSApp4\iOSApp4.csproj
Building target "_CopyDirectoriesToBundle" completely.
Output file "bin\Debug\net6.0-ios\iossimulator-x64\publish\..\device-builds\iphone11.6-14.8.1\iOSApp4.app\\Frameworks\\ArcGIS-arm64.framework/ArcGIS-arm64" does not exist.
Output file "bin\Debug\net6.0-ios\iossimulator-x64\publish\..\device-builds\iphone11.6-14.8.1\iOSApp4.app\\Frameworks\\Runtimecore.framework/Runtimecore" does not exist.
Ditto
Assembly = C:\Users\rolf\source\maui\bin\dotnet\packs\Microsoft.iOS.Sdk\15.2.303-ci.ditto-windows.56\tools\msbuild\iOS\..\iOS\Xamarin.iOS.Tasks.dll
Parameters
Destination = bin\Debug\net6.0-ios\iossimulator-x64\publish\..\device-builds\iphone11.6-14.8.1\iOSApp4.app\\Frameworks\\ArcGIS-arm64.framework
TouchDestinationFiles = True
SessionId = <SessionId>
Source = C:\Users\rolf\.nuget\packages\esri.arcgisruntime.runtimes.ios\100.13.0\framework\ios-arm64\native\ArcGIS-arm64.framework\
Ditto: <timestamp> - Started
Ditto: <timestamp> - Initializing
[xma]: Trying to get a Build Connection for Session '<SessionId>': Xamarin.Messaging.Build.Client.BuildConnection.<SessionId>, Lifetime: Build
Ditto: <timestamp> - Initialized
Ditto: <timestamp> - There's no available inputs to copy to the Mac
Ditto: <timestamp> - Serializing intputs
Ditto: <timestamp> - Executing
[xma]: Starting remote task execution for 'iOSApp4': Xamarin.MacDev.Tasks.Ditto
[xma]: Sending Request Xamarin.Messaging.Build.Contracts.ExecuteTaskMessage to topic xvs/build/execute-task/iOSApp4/15f3833002fDitto
[xma]: Received Response of Xamarin.Messaging.Build.Contracts.ExecuteTaskMessage to topic build<SessionId>4396rolf/+/xvs/build/execute-task/iOSApp4/15f3833002fDitto
Ditto: <timestamp> - Logging messages
/usr/bin/ditto C:/Users/rolf/.nuget/packages/esri.arcgisruntime.runtimes.ios/100.13.0/framework/ios-arm64/native/ArcGIS-arm64.framework/ bin/Debug/net6.0-ios/iossimulator-x64/publish/../device-builds/iphone11.6-14.8.1/iOSApp4.app//Frameworks//ArcGIS-arm64.framework
ditto: bin/Debug/net6.0-ios/iossimulator-x64/publish/../device-builds/iphone11.6-14.8.1/iOSApp4.app//Frameworks//ArcGIS-arm64.framework: File exists
Errors
C:\Users\rolf\source\maui\bin\dotnet\packs\Microsoft.iOS.Sdk\15.2.303-ci.ditto-windows.56\targets\Xamarin.Shared.Sdk.targets(668,3): error MSB6006: "ditto" exited with code 1. [C:\Users\rolf\source\iOSApp4\iOSApp4.csproj]
Ditto: <timestamp> - Finished
This doesn't happen when building on macOS, nor if I copy the offending ditto
command and execute it manually on macOS.
Since I don't know why the problem occurs in the first place, I don't know why
passing full paths to 'ditto' works either. It shouldn't cause problems
elsewhere though.
Ref: https://github.com/xamarin/xamarin-macios/issues/13665
* Enable nullability and fix code accordingly.
* Augment it to be able to take multiple files to run dsymutil on at the same time.
* Execute using xcrun (ref: #3931)
* Pass the full path to the executable file to dsymutil, to make command lines
easier to copy-paste.
* Enable nullability and fix code accordingly.
* Augment it to be able to take multiple files to strip at the same time.
* Strip in parallel.
* Execute using xcrun (ref: #3931)
* Pass the full path to the executable file to strip, to make command lines
easier to copy-paste.
* Remove test that is now outdated. We have other tests that run strip
anyways, so this shouldn't be a problem.
This fixes an issue where we'd do logic with Windows-style paths on macOS, and that's
never the right thing to do.
For the LinkNativeCode task, this would manifest as this error when building from windows:
> ld: file too small (length=0) file 'obj/Debug/net6.0-ios/iossimulator-x64/nativelibraries/libSystem.Native.dylib' for architecture x86_64
because the 'ShouldCopyToBuildServer' method would return incorrect results.
For the Codesign task, it would manifest as an exception trying to create a
directory with an empty string (because the directory name of a windows-style
path is an empty string on macOS).
Since this exception was quite useless (just getting the exception message
didn't tell me much about what caused the exception, because it had no stack
trace information), I've also improved error reporting in both of these tasks.
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Mauro Agnoletti
Alex Soto
Manuel de la Pena
Andy Gocke
Andy Gocke
VS MobileTools Engineering Service 2
Israel Soto