* Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource
items (if these files are found within the Resources/ subdirectory).
* Add support for a 'RegisterFont' metadata on BundleResource items, where if set
to 'true', we'll register the font file in the Info.plist as required by the target
platform.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
Fix parsing extra bundler arguments where a space separates the name and the
value of the argument, like this: '--xml file.xml' (as opposed to
'--xml:file.xml' or '--xml=file.xml').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1385946.
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
Context: https://github.com/dotnet/maui/issues/1662
Context: https://github.com/xamarin/xamarin-android/pull/6139
Previously:
* `$(ApplicationVersion)` mapped to `CFBundleVersion`
* `$(AppleShortVersion)` mapped to `CFBundleShortVersionString`
To be able to leverage identical property names on iOS/Android,
we're changing this to:
* `$(ApplicationVersion)` maps to `CFBundleVersion`
* `$(ApplicationDisplayVersion)` maps to `CFBundleShortVersionString`
Lastly, let's allow `$(ApplicationDisplayVersion)` to set `$(Version)`,
so the various C# assembly-level attributes are all set to the same value.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
Commit 91c6517f missed a few symbol files because it was tested against
a version of Hot Restart assemblies that had already been inserted into
VS. The Hot Restart package version bump in commit fbbaa7fc triggered
a couple of new SymbolCheck issues that can be fixed by bringing in the
previously missed pdbs.
This way we'll honor a _BundlerVerbosity value passed on the command line.
This fixes an inconvenience when we have when we want to increase verbosity
for a test run, which can be done by setting 'MtouchExtraArgs=-v'. This works
fine until the test we want to run wants to use MtouchExtraArgs for its own
purposes (1). If we set MtouchExtraArgs on the command line, then that value
will be global and won't be able to be overridden by the test, and the test
will fail.
With this fix we can pass _BundlerVerbosity=1 directly when building the test
to avoid the whole problem.
1. For instance, most tests pass an argument in MtouchExtraArgs to use
dlsym for NUnit.Framework.dll, which contains a P/Invoke to a native function
that doesn't exist - see the tests/nunit.framework.targets file.
Context: https://github.com/xamarin/yaml-templates/pull/131
Enables conversion and archiving of symbol files during the VS insertion
stage. Symbol archiving steps will only run if both the
`symbolArtifactName` parameter is provided, and `archiveSymbols` is set
to true. The `symbolConversionFilters` parameter can be used to filter
out paths of symbol files that should not be converted/archived.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We store the macOS version in the Info.plist, and use the iOS version for the MinimumOSVersion
MSBuild variable.
This means that in ReadAppManifest we must convert the min OS version from the Info.plist
from a macOS version to an iOS version (and not do it in CompileAppManifest).
Also add support for the iOS version in the Info.plist for Mac Catalyst, and automatically
convert it to the corresponding macOS version.
* [net6] Bumps Xamarin Hot Restart to 1.0.70
This version contains fixes for building Maui projects with Hot Restart
* [msbuild] Fixes Hot Restart Entitlements.plist compilation
The build was failing if `CodesignEntitlements` was not set, even though the CompileEntitlements task has a default value. That default value is not compatible with Hot Restart because it is a template file that exists on the Mac (and Hot Restart is an offline build from Windows).
So if that property is not set we get the xcent file from the Hot Restart PreBuilt app bundle, which is essentially an empty plist.
* [net6] Makes Hot Restart consider Single Project app title
On a Maui Single Project the app title can be set on the project file using the `ApplicationTitle` property. If that's set Hot Restart should include that value in the compiled app manifest, so the app name is shown on the device when the app is deployed.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
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.
The '_AssignWatchAppConfiguration' target's condition refers to an item group
that is created by '_SeparateWatchAppReferences', which means that we must
ensure that the '_SeparateWatchAppReferences' target is executed before the
'_AssignWatchAppConfiguration' target
* Correct Xamarin.Mac profiling properties
Seems like it was broken as of 7c15428fc2
If MtouchProfiling is not set for Xamarin.Mac apps, it would not have a value. This behavioural change was also not replicated in the IDE, which still sets `Profiling`.
Change the property so it inherits MtouchProfiling if Profiling is not set and detauls to false.
* Update Xamarin.Mac.Common.props
Both the CompileProductDefinition and the CreateInstaller tasks must take the
final app manifest as input, because there may now be multiple input manifests
(or one day none at all), and the final app manifest is the only version that
is guaranteed to exist and contain everything.
* Read CFBundleDisplayName and CFBundleVersion and use them in the
_CompileITunesMetadata task.
* Read numerous other app manifest values and pass them to the ACTool and
IBTool tasks.
This makes it possible to not parse the Info.plist in these tasks, which will
become more complicated in the future, when we might either not have an
Info.plist, or have many partial ones.
Also enable nullability.
The MonoAotCrossCompiler item group is empty when executing remotely from
Windows, so in that case we evaluate a csproj on the Mac side to compute the
AOT compiler path instead of relying in the task input from Windows.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1362367
Refactor the logic to compute the target devices for IBTool/ACTool, so that it
doesn't depend on the existence of the input app manifest, but instead uses
values that either comes from the app manifest, or have a default.
This becomes an important distinction when we add support for multiple partial
app manifests, or none at all (where all the required values come from MSBuild
properties).
* Add an '_AppBundleManifest' property that specifies the final path to the
Info.plist in the app bundle.
* Remove the '_AppBundleManifestPath' property, it's not used anywhere.
* Adjust the CompileAppManifest task to take the final path to the Info.plist,
instead of computing it and returning it. This way the CompileAppManifest
task does not output anything back into MSBuild (which is important, because
the CompileAppManifest task won't execute if the output file is up-to-date,
and if it's not executed, any output properties won't be set either).
* Have a single implementation of AutoActivateCustomFonts.
* Share the GetTargetDevices implementations between ACTool and IBTool, after removing
a condition for Xcode 6.0 (which we don't support anymore, so that check could
be removed) the implementations were identical.
* Add support for 'dotnet publish'.
* Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild
property to specify the resulting .pkg path, to reflect the existing
'IpaPackagePath' (for iOS and tvOS).
* Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever
used this...
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
We extract frameworks from third-party libraries when running the linker, and
we need to store this information on disk and the reload it after the linker
has executed, and add it to the existing MSBuild variables that keep track of
the user frameworks and dynamic libraries that have to be copied to the app
bundle.
Fixes the framework-test tests.
This is what happens:
1. Mono will write crash dumps in the current directory:
57bfe47451/src/mono/mono/utils/mono-state.c (L302-L322)
2. The current directory is by default the root of the app bundle.
3. If there are any files in the root of the app bundle for macOS or Mac
Catalyst, 'codesign' will fail ("unsealed contents present in the bundle
root").
This leads to the following sequence of events:
1. App developer builds & runs a Mac Catalyst app.
2. The app crashes for some reason.
3. Mono creates a crash dump (in the root directory of the app bundle).
4. The app developer changes something in the project and tries again.
5. The build fails, because 'codesign' fails.
Avoid this by deleting any crash dump files from the root of the app bundle
before signing the app.
This is an improvement on how we detect if the file that is going to be copied to the Mac is coming from the output path or not. Copying files from the Windows output dir to the Mac will make the build fail.
There were two problems:
- The paths we were comparing could contain different path separators.
- The item we are trying to copy may be in a folder that is inside the output dir.
For example:
- OutputFile = `obj\Debug\net6.0-ios\iossimulator-x64\nativelibraries/Foo`
- Item to copy: `obj/Debug/net6.0-ios/iossimulator-x64/nativelibraries/aot-output/x86_64/System.Private.CoreLib.dll.o`
The `_AdditionalTaskAssembly` prop was already fixed by 7c66aa3829, so we don't need to do this anymore. This breaks building from Windows because we're missing custom steps.
I missed adding this file to that commit.
On CI we'll collect all the binlogs in the repository and make them available
for post-build analysis if need be, so this will make it easier to diagnose
build problems.
* Rearrange some MSBuild logic so that the packaging/archiving code for macOS
can also be used for Mac Catalyst.
* Make the .NET build logic package/archive when requested to do so.
* Add tests.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/10413.
* [net6] Adds missing custom linker steps when building from Windows
To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`.
When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS.
* [net6] Updates .NET SDK path for remote tasks execution
This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist.
* Adds missing spaces to TaskRunner.cs
There was a main version of this target for Xamarin.iOS, and then numerous dummy targets for two scenarios:
* Building app extensions.
* Building macOS apps.
The first one is handled by the '_CanArchive' property (will be false when
building app extensions), and for the second case I've added it to the
condition on the CreateIpa target.
This way we don't have to have logic elsewhere about when it's valid to call
CreateIpa.
We fail later with an uninformative error ('The "Archive" task was not given a
value for the required parameter "SigningKey"') otherwise, and this way the
user doesn't have to manually enable signing to avoid the this error.
We use two different properties for the same thing: MtouchEnableSGenConc and
EnableSGenConc. Going forward, we're sticking with just EnableSGenConc, but
we'll keep accepting MtouchEnableSGenConc if it's set.
* Add support for the interpreter everywhere.
* Add support for the AOT compiler everywhere we didn't support it before,
because the interpreter needs it (at least System.Private.CoreLib.dll must
be AOT-compiled when using the interpreter).
* Do FullAOT compilation on Mac Catalyst/ARM64 if we're not using the
interpreter, since we can't use the JIT.
* Fix monotouch-test to be green on Mac Catalyst/ARM64.
Fixes https://github.com/xamarin/xamarin-macios/issues/11724.
Fixes https://github.com/xamarin/xamarin-macios/issues/11421.
The iOS version and the Mac version were slightly different in that they were
adding different things to the archive, but both seemed to be resilient to
those files not existing, so I just merged both implementations to try to add
everything to the archive.
Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the
TargetArchitectures property from either the RuntimeIdentifier or
the RuntimeIdentifiers properties.
Also make sure this target is executed before _ComputeTargetArchitectures.
This is required so that we have a correct TargetArchitectures value for
multi-rid builds when compiling the app manifest (Info.plist).
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
The iOS version of the cleaning tasks were much more comprehensive, so those
won out when there were any differences.
This also required moving the GetDirectoriesTask to shared code.
The native 'stat' function is not identical between x64 and arm64:
* The x64 version is the 32-bit version of the function, and takes a 32-bit
version of the stat structure.
* The arm64 version is the 64-bit version of the function, and takes a 64-bit
version of the stat structure.
We used the 32-bit version of the stat structure everywhere, which went
horribly wrong on arm64, because the layout and size of the struct is quite
different (120 bytes vs 144 bytes). The actual result on arm64 was that the
call to stat would null out one of the parameters to the calling function, and
the C# code would throw an ArgumentNullException when the code tried to use
that argument, and you'd end up with this exception which didn't make any
sense at all when looking at the code:
error : System.ArgumentNullException: Parameter "itemSpec" cannot be null. [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName, String resourceName) in Microsoft.Build.Utilities.Core.dll:token 0x6000121+0x20 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName) in Microsoft.Build.Utilities.Core.dll:token 0x6000120+0x0 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Utilities.TaskItem..ctor(String itemSpec) in Microsoft.Build.Utilities.Core.dll:token 0x60003ba+0x6 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.CopyFile(String source, String target, String targetItemSpec) in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 74 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 99 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
So fix the P/Invoke to stat:
* Use the 64-bit version of the stat struct.
* For x64, call the 64-bit version of stat (stat$INODE64), since we're now
using the 64-bit version of the stat struct.
* For arm64, call the standard version of stat (which is the 64-bit version).
And this means that we can now use the ARM64 version of .NET to build .NET
apps.
The entire `.framework` directory needs to be copied back to Windows
when a native reference is a [xc]framework. Otherwise important files
will be missing and the app bundle will be unusable.
Fix https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1339824
Revert a small part of #10409 so the path evaluation always happens on
the mac computer (even if the build is done from Windows)
Also dded a comment to avoid repeating that mistake again
Fixes https://github.com/xamarin/xamarin-macios/issues/11817
Move task so it also work for Xamarin.Mac (since this is now shared code)
* [msbuild] Fixes remote tasks execution
When building from Windows we stopped including the `SessionId` value when executing tasks remotely, because we started using that value to decide whether we should execute a task locally or remotely. The problem is the SessionId is also used from some of the base tasks (like ACToolTaskBase) to execute different code paths depending if the build is being executed from Windows or macOS (regardless where the task is currently being executed). Most of those code paths are related to calculating relative paths, and we started getting reports of weird behaviors like missing icons when deploying apps or even Apple Store submission errors.
To fix this problem we're back propagating the SessionId value when executing tasks remotely, and to decide if a task should be executed remotely or not we also check the Environment.OSVersion.Platform value (because SessionId will have a value on macOS too when executing the task remotely), so we only try to execute tasks remotely if the task is being executed from Windows and SessionId is not empty.
* Bumps Xamarin.Messaging
This version stops filtering the SessionId value when executing tasks remotely
* [msbuild] Adds ShouldExecuteRemotely extension method
* making sure new strings get added to designer and resources plus the test
* Next wave of changes to csproj to incorporate Rolf's changes
* fixing path
* Update tests/msbuild/Xamarin.MacDev.Tasks.Tests/TaskTests/LocalizationStringTest.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update tests/mtouch/LocalizationTests.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* forgot the include
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support
for MSBuild metadata - the CopyToAppBundle property - to avoid copying a
framework / dynamic library to the app bundle).
* Refactor MTouchTaskBase a bit to make parts of it reusable from the
LinkNativeCode task.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
* [msbuild] Fixes watchOS builds from Windows
We need to make sure the MSBuild is connected to XMA before generating the Bundle name (mostly for watchOS and app extension), so the `BuildServerPath` is correctly generated. `_GenerateAppBundleName` and `_GenerateAppExBundleName` do not exist anymore, so instead we should be running `_SayHello` before `_GenerateBundleName`.
* [msbuild] Fixes building binding libraries from Windows
If there's no SessionId we just need to execute the base class and return, because that means we only want to run the task locally.
Besides this was wrong, there was not side effects for builds from macOS because it was running the task locally and then trying to run it remotely, since there is not connection from macOS the whole process was skipped. When building from Windows this fails to run from the XMA Build agent on the Mac because it uses a custom BuildEngine that's not compatible with re-executing tasks remotely (remotely from the agent on the Mac).
If there's a dynamic library in the -L path in addition to the static library,
then the native linker will link with the dynamic library instead, which is
not what we want.
Instead just pass the full path to the static library to the linker.
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
Due to incorrect update while adapting code for translations.
```
<data name="W0073" xml:space="preserve">
<value>The App Extension '{0}' has a CFBundleVersion ({1}) that does not match the main app bundle's CFBundleVersion ({2})
</value>
</data>
<data name="W0074" xml:space="preserve">
<value>The App Extension '{0}' has an unrecognized NSExtensionPointIdentifier value ('{1}').
</value>
</data>
```
Fixes https://github.com/xamarin/xamarin-macios/issues/11581
This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS.
This should not change the original behavior when building from macOS.
* [dotnet] Ship the buildinfo file.
* [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes#10827.
We do this by setting the _XamarinSdkRoot variable in our .NET logic, which
our existing shared build logic reads, passes to the DetectSdkLocations task,
and then sets our override environment variable
(MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that
existing code (which honors the override variable) continues to work as-is.
Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
Build failures will now include things like this for quiet builds:
Tool xcrun execution finished (exit code = 1).
Undefined symbols for architecture x86_64:
"_GlobalizationNative_LoadICUData", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We stopped converting full pdbs to mdbs on Windows, so we need to override the `DebugType` property to `portable` if it's `full`, otherwise the debugger won't work from Visual Studio.
There were 2 "problems":
1- Messaging depends on `System.Net.Mqtt` and not in `System.Net.Mqtt.Server`. It still worked because the latter depends on the former package, but we were restoring unnecessary dependencies.
2- We don't need an excplicit reference, since `Xamarin.Messaging.Build.Client` already depends on it, and by removing it we avoid having another dependency to keep up to date.
* [msbuild] Fixes Windows task namespace
* [msbuild] Fixes unzipping files from Windows
This is the same approach we're using on the Xamarin.iOS.Tasks project, we need to replace the System.Text.Encoding.CodePages reference assembly by it's runtime implementation before ilmerging it, otherwise when trying to unzip files from Windows we'll get a null ref exception because that's what the ref assembly implemented.
* [msbuild] Try to copy output to Windows before ending the XMA connection
When relying on BuildDependsOn we can end up running the targets after _SayGoodBye, which ends the XMA connection. `CopyDSYMFromMac` and `CopyAppBundleFromMac` need an active connection, since both copy files from the Mac to Windows.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The `$(_UsingXamarinSdk)` property has been renamed to help improve
external usability. This change increases parity with the Android SDK,
which currently defines `$(UsingAndroidNETSdk)` for internal and
external use.
Not sure how I could mess up a copy/paste between file - but I succeeded
to create a subtle bug (would have expected it more crash happy)
Fix issue #11151
There's no Hot Restart support for net6 yet, but we should still import those targets if the file exist, because are needed on the legacy iOS Sdk on Windows.
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
With P3 addition on ICU we must now link the native executable as C++.
Remove an old workaround, in many tests, referencing old (5.0/previews)
packages that caused native link time failures.
ref: https://github.com/mono/linker/issues/1139
The way that CoreiOSSdkDirectory was definded ($(MSBuildThisFileDirectory.Replace('...', '...'))) was returning an encoded string value that caused issues in legacy project systems. The reason of the issues is that the CoreiOSSdkDirectory value for legacy project systems is `Program Files (x86)`, and the "Replace'" function was encoding the '(' and ')' causing the "UsingTask" for fail because the Assembly File path was wrong (because it contains those encoding values).
The fix consist of applying the "Replace" function only when the path of the targets belongs to a .net SDK path, in which case it won't fail because it's under "Program Files".
We need to discuss with the MSBuild team to show this issue and know if it's a bug or how we can avoid the failure
iOS Binding projects were not building remotely since 16.9. This commit fixes that and allows to start building remotely.
Xamarin.iOS.ObjCBinding.CSharp.After.props is imported too early and because it was also importing the Messaging targets, some things like RebuildDependsOn and BuildDependsOn were being overridden by other targets, resulting on not hooking up on the remote execution.
Add support for parsing --setenv from bundler arguments and passing them to
dotnet-linker so that the environment variables can be baked into the app at
launch (like they would be for mtouch/mmp).
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
Also
* Fix the Mac Catalyst sample to use the correct contents.json and images sizes
for Mac Catalyst app icons.
* Fix the contents.json and image sizes for the Mac Catalyst test project as well.
* Add unit test for Mac Catalyst that ensures that Assets.car is in the final app.
Fixes https://github.com/xamarin/xamarin-macios/issues/10804.
Code shared between msbuild and mtouch/mmp needs to share the
localization strings, otherwise the exception being thrown is of no help
to solve the issue.
THis happened if a wrong path was given for an `.xcframework` and
`FileCopier` reported an `MT1022` error.
Reference (not a fix for) https://github.com/xamarin/xamarin-macios/issues/10774
* [dotnet] Use the expected case for ARM64.
We use case-sensitive comparisons somewhere else, so make sure to use the same casing
for the architecture as other platforms do.
* [tests] Add tests to verify that Mac Catalyst builds successfully for ARM64.
* [msbuild] Fix platform name in condition.
* [msbuild] Pass -isysroot when building Mac Catalyst apps as well.
Ohterwise clang will use the SDK from the command line tools, which may have
nothing to do with the SDK we want to build with.
* [dotnet] Adds support for dotnet build -t:Run from Windows
What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac
* [dotnet] Fixes illink.dll location when building from Windows
The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
This reverts commit 9a27951a99.
The purpose of the original commit was to take out 4 tasks that were only executed from Windows to the Windows specific pack (and enabling more tasks that need to be executed remotely on that pack).
To execute tasks remotely the build will initially run `SayHello` which connects to the Mac and shares the connection with all the tasks through IBuildEngine4[1]. When that connection object is retrieved on the tasks we need to cast it as a Messaging connection type, and this works from Visual Studio and msbuild because there's just one messaging assembly loaded.
But it doesn't work on dotnet/msbuild, because there's a feature called ALC (AssemblyLoadContext) which will load each assembly task into it's own context[2], loading all its dependencies in that context. In this scenario sharing custom objects between tasks won't work because the original object type could be from a different context than the one retrieving it. This is described here: https://github.com/dotnet/msbuild/issues/5084.
[1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4?view=msbuild-16-netcore
[2] https://github.com/dotnet/msbuild/blob/master/documentation/specs/task-isolation-and-dependencies.md
* [dotnet] Fixes builds for iOS physical devices from Windows
- We need to create output files for the AOTCompile task on Windows and copy the AOT Compiler to the Mac since it is part of a NuGet package that will not exist on the Mac
- The EmbedProvisionProfile task needs to be run remotely so the embedded.mobileprovision file is included in the app bundle
- When copying input files to the Mac for LinkNativeCode we should skip files that already exist on the Mac because those on Windows are empty. If we copy those we are essentially replacing the real files by the empty ones from Windows.
* Bumps Xamarin.Messaging
* Fixes spacing on LinkNativeCode
Changes the HintPath to the Messaging assembly to use OutputPath instead, otherwise the build fails when that property is different than `bin\$(Configuration)\netstandard2.0`
* [dotnet] Stops merging Messaging into Xamarin.iOS.Tasks
- Creates a separate Xamarin.Messaging project that will produce a single assembly after merging all the Xamarin Messaging dependencies.
- Stops merging Messaging into Xamarin.iOS.Tasks to be able to reference it from the Windows specific pack.
- Refactors the ILMerge.targets to reuse common code from ILMerge.Messaging.targets.
* [dotnet] Moves Windows specific tasks to the Windows tasks project
* [dotnet] Adds Xamarin.Messaging.dll to the different packages
* [msbuild] Add logic to build & install Xamarin.Messaging.dll.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Bump .NET to 6.0.100-preview.2.21114.3.
* [dotnet-linker] Several steps are now gone, so load our custom step before the new first step (MarkStep).
* [dotnet-linker] Dump the current steps if we fail to call InsertBefore/InsertAfter.
* [dotnet-linker] Load the CollectAssembliesStep as the first step, and make it load every assembly.
* [dotnet] Set InvariantGlobalization=true because that's the only thing .NET supports for now.
* [dotnet-linker] Use recommended workaround for linker's inability to do load assemblies in custom step.
* [tests] Bump version of MSBuild.StructuredLogger to get support for new log version.
Otherwise this happens in tests that read binary logs:
System.NotSupportedException : Unsupported log file format. Latest supported version is 9, the log file has version 10.
* [introspection] Ignore P/Invokes to QCall for LogThreadPool* P/Invokes.
* [dotnet-linker] Inject a dummy implementation of mono_config_parse_memory as a temporary solution for mono's removal of the same method.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@1e738e9 [Xamarin.MacDev] Extract the code to convert between Mac Catalyst versions to a separate file. (#89)
* xamarin/Xamarin.MacDev@a3bb12c [Xamarin.MacDev] Add methods to map between iOS and macOS versions for Mac Catalyst. (#88)
Diff: 02d6d05be3..1e738e9f7f
* [msbuild] Use the macOS SDK to build Mac Catalyst apps instead of the iOS SDK
From a native compilation perspective, compilating a Mac Catalyst is the macOS SDK
+ a dash of iOS, so use the native macOS SDK to compile, and then do the corresponding
adjustments elsewhere.
At the same time document which version we want for the sdk version and the deployment
target in mtouch, and adjust the code accordingly (sdk version: macOS version; deployment
target: iOS version).
* Update resource files
* Add new entry to canary test for string localization.
In .NET Mac Catalyst will be a platform on the same level as iOS or tvOS, so
reflect this in the build logic by setting _PlatformName to 'MacCatalyst'.
This makes the build logic a lot simpler for .NET.
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>
This requires bumping Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@02d6d05 [Xamarin.MacDev] Add an AppleSdkVersion struct which replaces IPhoneSdkVersion and MacOSXSdkVersion. (#87)
* xamarin/Xamarin.MacDev@e7ec7ef [Xamarin.MacDev] Fail gracefully if trying to grab a PList entry from a file that doesn't exist. (#86)
Diff: fae0237704..02d6d05be3
* Pass and parse the MtouchInterpreter value to dotnet-linker.
* Move required logic from mtouch to shared code to take advantage of existing
code to compute AOT arguments (which we need to compute the correct AOT
arguments for System.Private.Corelib.dll, which is always AOT-compiled).
* Add a linker task to compute the AOT arguments for .NET.
* Add test projects.
This PR is probably best reviewed commit-by-commit.
Fixes https://github.com/xamarin/xamarin-macios/issues/10292.
* [tests] Use the 'Apple Developer' code signing key instead of 'iPhone Developer' for xcframework-test.
* [msbuild] Fix resolving the XCFramework for Mac Catalyst.
* [xharness] Enable xcframework-test by default on Mac Catalyst.
* [tests] Add test case for single-project properties in .NET.
* [msbuild] Add support for the single-project ApplicationId MSBuild property.
* [msbuild] Add support for the single-project ApplicationTitle, ApplicationVersion and AppleShortVersion MSBuild properties.
* [dotnet] Enable the single-project MSBuild properties by default.
* [dotnet] Add a short doc about single project properties.
* [tests] Fix the GeneratePlistTaskTests.BundleIdentifier test according to bundle identifier changes.
This test asserts that the CFBundleIdentifier value in the Info.plist isn't
overwritten, and does so by calling the CompileAppManifest task, giving it a
different value for the bundle identifier than what's in the Info.plist.
The behavior change is that now we do things in the following manner:
DetectSigningIdentityTask will read the Info.plist, compute a bundle
identifier (which will be the value from the Info.plist if it's there), and
returns it to the MSBuild code. Eventually that value will be passed to the
CompileAppManifestTask, which will write it to the Info.plist.
However, this test doesn't run the DetectSigningIdentityTask, which means that
the initial value for the bundle identifier doesn't come from the Info.plist.
* [msbuild] Add a BundleIdentifier property to the XcodeCompilerToolTask.
This way we don't have to read the Info.plist to get the bundle identifier,
which will be a problem in the future, because the Info.plist might not have
the actual bundle identifier we end up using. Instead rely on the
_BundleIdentifier MSBuild property, which will contain the final bundle
identifier.
* [msbuild] Make sure we have a bundle identifier when calling ACTool.
* [msbuild] Make sure we have a bundle identifier when calling IBTool if one is needed.
At the same time make the BundleIdentifier not required, because IBTool may
run for library projects, which doesn't have a bundle identifier.
* [msbuild] _DetectSigningIdentity needs to know the bundle name.
* [msbuild] It shouldn't be necessary to detect the signing identity to compute the bundle name.
* [msbuild] Unify how CFBundleName is calculated.
Previously, CFBundleName would default to:
* iOS: CFBundleDisplayName (if set), otherwise the app bundle name.
* all other platforms: the app bundle name.
Now unify the logic so that we have the same behavior on all platforms.
This is a breaking change under the following conditions:
* Building for iOS
* CFBundleName is not set in the Info.plist
* CFBundleDisplayName is set in the Info.plist
* CFBundleDisplayName from the Info.plist is different from AssemblyName in
the csproj (which is the value used to calculate the app bundle name).
The fix would be to:
* Set CFBundleName in the Info.plist to the desired value.
This change works in previous versions of Xamarin.iOS as well.
* Update tests.
* We assigned the same value to DetectedBundleId in every branch, so instead
assign it once at the beginning.
* We assigned the same value to DetectedAppId to most branches, so instead
assign that value at the beginning as a default value.
Using `Path.Combine` with a full qualified path for the 2nd argument will
return that 2nd argument (ignoring the first one).
That meant the `StampPath` was pointing to the actual files that were
just signed - overwriting them with a 0-length data (empty).
The solution is to make the 2nd argument relative, starting after
`.app/` so `Path.Combine` works as expected (being relative) while
allowing signing multiple files that have the same name (in different
directories).
ref: https://github.com/xamarin/xamarin-macios/issues/10445
TL&DR:
This effectively change nothing - but prevents (warn) if both options
contradict themselves.
Long Story....
So we have two ways to control the codesign's `--timetamp` option but
they both ignore each other so we can end up with the option being
set more than once at build time.
`DisableTimestamp` was the original one. It was meant for iOS (and
derivative OS) and disable the option (which requires the network)
for simulator or debug builds. IOW we _wanted_ timestamps when doing
release builds for devices.
```
DisableTimestamp="$(_CodesignDisableTimestamp)"
```
```
<_CodesignDisableTimestamp>False</_CodesignDisableTimestamp>
<_CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</_CodesignDisableTimestamp>
```
Now disabling the timestamp did not mean it was enabled. We did not ask
for a timestamp, leaving it to the default which from `man codesign`
means:
> If this option is not given at all, a system-specific default behavior is invoked.
> This may result in some but not all code signatures being timestamped.
Then `UseSecureTimestamp` was added for macOS builds. If hardening is
enabled then a secure timestamp is required.
`msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Common.targets` `_CodesignAppBundle`
```
UseSecureTimestamp="$(UseHardenedRuntime)"
```
However it's also exposed for iOS (shared target) in
`msbuild/Xamarin.Shared/Xamarin.Shared.targets` `__CodesignNativeLibraries`
but it would always be `false` in that case.
Adding this option means there's now always a `--timestamp` option given,
either to enable it (no URL so it means using Apple's server) or to
disable it (`=none`) but since it's controlled by `UseHardenedRuntime`,
which is macOS only, then iOS device builds are never timestamped.
An alternative would be to have `UseSecureTimestamp` as a macOS-only
option - but that would change how we currently sign the iOS applications
and I'd rather not change things that are known to work.
Code signing for Mac Catalyst is very much like code signing for macOS, except that:
* If a provisioning profile is required, then we must find a code signing certificate.
* Provide a code signing key even if we don't need a code signing certificate.
This makes the tests in monotouch-test that require a correctly signed app pass.
TL&DR: This PR
1. Removes the creation of the `.dSYM` based on `Debug Information` [1]
2. Adds dSYM support to XM msbuild (now shared with XI implementation)
3. Archive the `.dSYM` directories (plural) properly, e.g.
```
msbuild -p:Configuration=Release -p:ArchiveOnBuild=true
```
Why ? The long story...
Historically `.dSYM` for Xamarin.Mac have not been very useful, largely
because (most of) the code is JITed so not much is known before runtime.
So they were simply not generated during the builds...
However AOT options were added to Xamarin.Mac, making them potentially
more useful. Also symbols from `libmono` and other native libraries /
frameworks can prove useful when diagnosing application crashes.
Unsurprisingly developers looking to get symbols eventually found _a way_
[1] to get a `.dSYM` for their applications - but it was not quite
correct because:
* setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had);
* it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks.
* the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution.
[1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log
Additional fixes
* Use `Directory.Move` instead of running the `mv` command
While the result is identical there is a cost to spawn several `mv`
processes. Doing it in parallel (might have) helped but that setup
also comes at a cost.
`Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while
the existing code took 17 ms to do the same.
* Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
Mac Catalyst needs much of the Mac signing logic, so merge the iOS and Mac
versions of DetectSigningIdentity so that the Xamarin.iOS.Tasks assembly
contains what it needs for Mac Catalyst.
* [msbuild] Unify handling of Sdks.
Create an Sdks class in Xamarin.MacDev.Tasks.Core, which handles both Xamarin.iOS
and Xamarin.Mac. Refactor the MacOSXSdks and IPhoneSdks classes to use the new Sdks
class.
This makes it possible to avoid some code duplication in MacOSXSdks and IPhoneSdks,
and also share code elsewhere.
This requires a bump of Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@fae0237 [Xamarin.MacDev] Add GetAppleDTSettings and GetSdkSettings to the IAppleSdk interface. (#85)
Diff: f665e3a0fc..fae0237704
* Translate exception message.
* Simplify according to review.
* Update list of non-translated strings.
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](a20f8aba41 (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`.
**Example #1.** Signing a framework binary is the **same** thing as
signing the framework directory.
```
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame]
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame]
```
Nice right ? Pretty much until...
**Example #2.** Signing a framework binary is **NOT** the **same** thing
as signing the framework directory.
```
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: signed Mach-O thin (arm64) [flac-55554944583d2f02282c33d8bfed082daa857e30]
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: signed bundle with Mach-O thin (arm64) [org.xiph.flac]
```
In this case signing the binary `flac` does not produce the
`_CodeSignature` directory and fails our msbuild Codesign task
The fix is to detect if we're signing a framework like `A.framework/A`
and change this to sign `A.framework` as this will always work.
These two tasks did essentially the same thing, so we can just merge them. I
kept the "EmbedProvisionProfile" name, because that sounded like the most
applicable to all platforms.
User frameworks comes in different "shapes"
* You can roll your own (like ours are) and they are likely to be similar
to dynamic libraries. Of interest is the fact that the native binary
will include debugging symbols. On which our tools will, at a later
point, run `dsymutil` to create a `dSYM` and `strip` the binary.
* You can create them with a tool, like Xcode, and the build's output
will give you a `dSYM` and a stripped (no debug information) binary.
Now we can't process the later like the former. Because if we execute
`dsymutil` on the **stripped** framework we'll get an _empty_ (no symbol)
`.dSYM`. The tool will issue a warning like:
> warning: no debug symbols in executable (-arch arm64)
which is easy to miss since it's informational (now promoted to a proper
msbuild warning).
The result is that the archive will have our new, but _empty_ .dSYM,
which won't be of any help to symbolicate crashes later.
It's also quite inefficient since
* we run `dsymutil` way too often (to produce nothing useful)
* we run `strip` on the, already stripped, framework binary
The solution is to check if the user framework comes with a `.dSYM`.
If it does then this is the one we should bundle in the archive and we
can skip the `dsymutil` and `strip` steps.
If it does not have one (dSYM) then the current logic is the best we can
do, i.e. assume there might be debug information inside the binary,
extract it (`dsymutil`) and remove it (`strip`) from shipping code.
User frameworks for macOS often uses symlinks (as Xcode creates them
this way).
This cause problem cause the symlink is on the binary and we expected
the `_CodeSignature` directory to by side-by-side with the binary. This
was missing and cause exceptions when codesigning such frameworks.
A second problem happened because `mmp` use `lipo -thin` to remove
non-required architectures. However when a framework has symlinks, like:
```
├── Frameworks
│ └── Universal.framework
│ ├── Resources -> Versions/Current/Resources
│ ├── Universal -> Versions/Current/Universal
│ └── Versions
│ ├── A
│ │ ├── Resources
│ │ │ └── Info.plist
│ │ ├── Universal
│ │ └── _CodeSignature
│ │ └── CodeResources
│ └── Current -> A
```
then this actually replaced the (very small) symlink with a thin version
of the framework. Which means the original one was still _fat_ and the
whole app was now larger than the original version.
Sample used: https://github.com/spouliot/xcframework/tree/main/xamarin/xcf-mac
* [tests] Build test-libraries for Mac Catalyst.
* [msbuild] Add support for Mac Catalyst binding projects.
* [mtouch] Allow frameworks for Mac Catalyst apps.
* [mtouch] Put frameworks in the expected location for Mac Catalyst apps.
* [msbuild] Create the Resources directory before trying to put files in it.
instead _indirectly_ thru a binding project.
It got broken when I fixed the msbuild tests (to avoid re-building
needlessly the project).
Test case: https://github.com/spouliot/xcframework
Also don't resolve when building binding projects - since it's not useful (as we already package the whole .xcframework)
* Install the Mac Catalyst versions of the mono libraries and BCL.
* The BCL is the same as the one for Xamarin.iOS, which means it has to be post-processed a bit to work with a Xamarin.MacCatalyst.dll
* Build our runtime for Mac Catalyst.
* Build a Xamarin.MacCatalyst.dll with the Mac Catalyst API (it compiles, but I haven't looked at the API surface at all). This PR assumes we're going to have a new TargetFrameworkIdentifier for Mac Catalyst, but a final decision has not been made (see https://github.com/dotnet/runtime/issues/44882), so this may change.
* Build a Xamarin.iOS.dll that contains type forwarders to Mac Catalyst for all the types that exist in both Mac Catalyst and Xamarin.iOS.
* Add support to xharness for running introspection on Mac Catalyst (there are a lot of failures because the API surface is wrong)
* Add support to our msbuild tasks and mtouch for building Mac Catalyst apps. This basically comes down to adding a new case in numerous places to either do things the iOS way or the macOS way, depending on each case.
* Add a __MACCATALYST__ define (which is in addition to the __IOS__ define).
Not that it was very slow but it did make to the top 10 of the
archive build I was debugging.
Also reduce allocations in the task itself, for when it's needed.
The build logic will put reference assemblies in
'ResolvedCompileFileDefinitions' instead of '_ReferencesFromNuGetPackages'
when using the new-style packageref format, so we need to handle
'ResolvedCompileFileDefinitions' the same way we handle
'_ReferencesFromNuGetPackages'.
I was unfortunately not able to create a unit test for this scenario, because
xibuild sets MSBUILD_EXE_PATH to make msbuild look in our local build files,
and then the restore fails with:
> Issue9266.csproj : error MSB4236: The SDK 'Msbuild.Sdk.Extras/2.1.2' specified could not be found.
If I don't use "Msbuild.Sdk.Extras" in the test, then it doesn't hit the
broken path this PR is fixing. If I change xibuild to not set
MSBUILD_EXE_PATH, we're not testing our local bits anymore, but the system
Xamarin.Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/9266.
* Add a stamp file to the Mac version of _CompileToNative. This is used to
force a rebuild of the container app when an app extension changes (and was
already implemented for iOS: 8b376efa4b)
* Rename the iOS stamp file to 'bundler.stamp' instead of 'mtouch.stamp' to
ease code sharing.
* Rename the 'MmpReferencePath' and 'MTouchReferencePath' properties to
'_BundlerReferencePath' to ease code sharing.
* Merge the _GetCompileToNativeInputs targets. The only difference between iOS
and Mac (after the above changes) is that the Mac version now includes
'@(ReferencePath)' in '_CompileToNativeInput'. This should be fine as far as
I know.
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
The '_GenerateBundleName' target is defined separately for normal projects and
extension projects, and only one of the was updated in a previous refactoring.
The _ACTool_PartialAppManifestCache and _ACTool_BundleResourceCache are
duplicated (merge conflict resolution failure?), and also already present in
Xamarin.Shared.targets, so just remove these definitions.
* Share the following targets:
* _ResolveAppExtensionReferences
* _SplitAppExtensionReferencesByExistent
* _AssignAppExtensionConfiguration
* _SeparateAppExtensionReferences
* _CopyAppExtensionsToBundle
The first four were pretty much identical between iOS and Mac already, and
needed very few changes.
The latter, _CopyAppExtensionsToBundle, required a little bit of tweaking to
the targets to make sure it works for both iOS and Mac:
* Removed the conditions on the Ditto task to check if we have app extensions
- this is unnecessary because Inputs/Outputs on the target itself (which
weren't there when the Ditto task conditions were written).
* Added a '_PlaceAppExtensions' target that calculates where in the
container's app bundle extensions should be placed (the '_AppExtensionRoot'
property), and the name of the containing folder (the 'ContainerName'
metadata).
This is a step towards making Xamarin.MacDev.Tests run tests out-of-process.
It requires adding '_GenerateBundleName' as a dependency for the
'_ValidateAppBundle' target, because we're invoking the '_ValidateAppBundle'
directly, and we can't depend on any other targets executing
'_GenerateBundleName', because there are no other executed targets.
1. Use `xcrun` to run `ibtool` (and `actool`) and avoid toolchain mismatches
2. Set `DEVELOPER_DIR` so everyone (well `xcrun`) use the same toolchain
3. Workaround for `macos-arm64` issue (FB8827920)
* Start `ibtool` as an `Apple` [Silicon] process
* This will ensure the `ibtoold` daemon is also running as `Apple`
* If `ibtoold` is run as `Intel` then `ibtool` asserts and build fail
```
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.757 ibtoold[37142:6681382] [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEInterfaceBuilder/IDEInterfaceBuilder-17506/InterfaceBuilderKit/Utilities/IBAbstractInterfaceBuilderPlatformToolManager.m:481
LaunchScreen.storyboard : error : Details: Failed to attach to IBAgent-iOS with error: Error Domain=com.apple.InterfaceBuilder Code=-1 "Encountered an error communicating with IBAgent-iOS." UserInfo={NSLocalizedFailureReason=IBAgent-iOS (37146) failed to launch and exited with status 10, NSUnderlyingError=0x7fa4e58fc760 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to launch IBAgent-iOS via CoreSimulator spawn" UserInfo={NSLocalizedDescription=Failed to launch IBAgent-iOS via CoreSimulator spawn, NSUnderlyingError=0x7fa4e5e8a900 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to handshake with platform tool" UserInfo={NSLocalizedFailureReason=Failed to open connection over FIFOs with platform tool, NSLocalizedDescription=Failed to handshake with platform tool, NSUnderlyingError=0x7fa4e5e237c0 {Error Domain=com.apple.InterfaceBuilder Code=-1 "" UserInfo=0x7fa4e5e8bba0 (not displayed)}}}}}, NSLocalizedRecoverySuggestion=Please check Console.app for crash reports for "IBAgent-iOS" for further information., NSLocalizedDescription=Encountered an error communicating with IBAgent-iOS.}
LaunchScreen.storyboard : error : Object: <IBCocoaTouchToolManager>
LaunchScreen.storyboard : error : Method: +_THREADSAFE_launchNewToolWithLaunchContext:executionContext:toolProxyClass:proxyDelegate:failureContext:requestingMethod:error:forReason:
LaunchScreen.storyboard : error : Thread: <NSThread: 0x7fa4e341af70>{number = 1, name = main}
LaunchScreen.storyboard : error : Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.766 ibtoold[37142:6681382] [MT] IBPlatformTool: *** Failed to launch tool with description <IBCocoaTouchPlatformToolDescription: 0x7fa4e5f34160> System content for IBCocoaTouchFramework-fourteenAndLater <IBScaleFactorDeviceTypeDescription: 0x7fa4e5f2fb50> scaleFactor=2x, renderMode.identifier=(null): Encountered an error communicating with IBAgent-iOS. (Failure reason: IBAgent-iOS (37146) failed to launch and exited with status 10): Failed to launch IBAgent-iOS via CoreSimulator spawn: Failed to handshake with platform tool (Failure reason: Failed to open connection over FIFOs with platform tool): : Failed to open FIFOs for handshaking with platform tool (Failure reason: IBAgent-iOS exited before we could handshake)
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error : ibtool exited with code 1
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error :
LaunchScreen.storyboard : ibtool error : Encountered an error communicating with IBAgent-iOS.
```
Note: `main` has diverged quite a bit (net6 support) so this pull request
will need to be re-worked (it won't apply)
Fixes https://github.com/xamarin/xamarin-macios/issues/4634
Foreport of #9965 since the source code diverged from `xcode12.2`
* Add an AOTCompile task that runs the AOT compiler for a given set of input assemblies.
This task will eventually be deprecated by an equivalent task provided by Mono,
but this works for now.
* Add an _AOTCompile target that takes care of running the AOT compiler and compile
the result into object files.
1. Use `xcrun` to run `ibtool` (and `actool`) and avoid toolchain mismatches
2. Set `DEVELOPER_DIR` so everyone (well `xcrun`) use the same toolchain
3. Workaround for `macos-arm64` issue (FB8827920)
* Start `ibtool` as an `Apple` [Silicon] process
* This will ensure the `ibtoold` daemon is also running as `Apple`
* If `ibtoold` is run as `Intel` then `ibtool` asserts and build fail
```
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.757 ibtoold[37142:6681382] [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEInterfaceBuilder/IDEInterfaceBuilder-17506/InterfaceBuilderKit/Utilities/IBAbstractInterfaceBuilderPlatformToolManager.m:481
LaunchScreen.storyboard : error : Details: Failed to attach to IBAgent-iOS with error: Error Domain=com.apple.InterfaceBuilder Code=-1 "Encountered an error communicating with IBAgent-iOS." UserInfo={NSLocalizedFailureReason=IBAgent-iOS (37146) failed to launch and exited with status 10, NSUnderlyingError=0x7fa4e58fc760 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to launch IBAgent-iOS via CoreSimulator spawn" UserInfo={NSLocalizedDescription=Failed to launch IBAgent-iOS via CoreSimulator spawn, NSUnderlyingError=0x7fa4e5e8a900 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to handshake with platform tool" UserInfo={NSLocalizedFailureReason=Failed to open connection over FIFOs with platform tool, NSLocalizedDescription=Failed to handshake with platform tool, NSUnderlyingError=0x7fa4e5e237c0 {Error Domain=com.apple.InterfaceBuilder Code=-1 "" UserInfo=0x7fa4e5e8bba0 (not displayed)}}}}}, NSLocalizedRecoverySuggestion=Please check Console.app for crash reports for "IBAgent-iOS" for further information., NSLocalizedDescription=Encountered an error communicating with IBAgent-iOS.}
LaunchScreen.storyboard : error : Object: <IBCocoaTouchToolManager>
LaunchScreen.storyboard : error : Method: +_THREADSAFE_launchNewToolWithLaunchContext:executionContext:toolProxyClass:proxyDelegate:failureContext:requestingMethod:error:forReason:
LaunchScreen.storyboard : error : Thread: <NSThread: 0x7fa4e341af70>{number = 1, name = main}
LaunchScreen.storyboard : error : Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.766 ibtoold[37142:6681382] [MT] IBPlatformTool: *** Failed to launch tool with description <IBCocoaTouchPlatformToolDescription: 0x7fa4e5f34160> System content for IBCocoaTouchFramework-fourteenAndLater <IBScaleFactorDeviceTypeDescription: 0x7fa4e5f2fb50> scaleFactor=2x, renderMode.identifier=(null): Encountered an error communicating with IBAgent-iOS. (Failure reason: IBAgent-iOS (37146) failed to launch and exited with status 10): Failed to launch IBAgent-iOS via CoreSimulator spawn: Failed to handshake with platform tool (Failure reason: Failed to open connection over FIFOs with platform tool): : Failed to open FIFOs for handshaking with platform tool (Failure reason: IBAgent-iOS exited before we could handshake)
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error : ibtool exited with code 1
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error :
LaunchScreen.storyboard : ibtool error : Encountered an error communicating with IBAgent-iOS.
```
Note: `main` has diverged quite a bit (net6 support) so this pull request
will need to be re-worked (it won't apply)
Fixes https://github.com/xamarin/xamarin-macios/issues/4634
The native linker defaults to the execution architecture, which works fine for
64-bit iOS Simulator (because we target x86_64 and run on x86_64), but it
doesn't work for any other architecture, so make sure to pass the architecture
to the native linker.
Also make sure we only get one architecture, because the native linker doesn't support
building fat libraries (we'll have to add support for manually lipoing the result).
* [msbuild] Change XamarinTask to fail the build if a tool fails to execute.
Also don't show 'xcrun' as the tool, but instead the executable 'xcrun'
executed.
* [msbuild] Make error reporting optional.
This way the caller can choose to either report a better error, or not report
an error at all.
* [msbuild] Make the default value for IsMacEnabled property dependent upon the OS.
Also make it overridable by only setting it if it's not already set.
* Use $([MSBuild]::IsOSPlatform('windows')) instead of $(OS)
The $(OS) value isn't standardized, so there's no sane check we can do against
it.
Split the iOS msbuild tests in two:
* Xamarin.MacDev.Tasks.Tests: contains in-process unit tests for tasks.
* Xamarin.MacDev.Tasks: contains larger tests that either invoke targets or a complete
build. These are currently in-process, but will become out-of-process soon to make
it possible to run them with dotnet.
Also make the new projects non-iOS-specific, because the macOS msbuild tests will
be moved here as well soon.
There is some duplicated code between these two test projects now (all files
that show up as new are copies of existing files), this will be cleaned up in
later pull requests.
There was a race condition in the code that has been removed, which may have
caused actool to randomly hang at exit (https://github.com/xamarin/maccore/issues/1124).
Fix this by re-using existing code we have to launch processes.
* [msbuild] Set DEVELOPER_DIR to the Xcode we're using when calling ibtool.
This fixes strange problems that occur when the system Xcode isn't the same as
the Xcode configured in Visual Studio for Mac, because we'd end up directly
launching VSMac's Xcode's ibtool, which would end up confused because it
wasn't the system ibtool.
Setting DEVELOPER_DIR tells VSMac's Xcode's ibtool that it's the system's ibtool.
* [msbuild] Set IBToolTask.SdkDevPath from the tests as well.
It's already set in the .targets files.
* [msbuild] Move msbuild/tests to tests/msbuild to put all the tests together.
* [tests] Move test projects for Xamarin.Mac to tests/common/TestProjects
* [tests] Move test projects for Xamarin.iOS to tests/common/TestProjects
* Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into
a separate NuGet (to avoid shipping the same mlaunch executable in three different
packages), but that can be done at a later stage.
* Add a GetMlaunchArguments task that computes the mlaunch arguments to install
or launch an app in either the simulator or on device.
* Implement the MSBuild logic to make the Run target (provided by .NET) launch
mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done
by setting the RunCommand and RunArguments properties (which the Run target uses)
to the correct values.
Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which
I haven't figured out yet:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'.
That's for a different pull request though.
Ref: https://github.com/xamarin/net6-samples/issues/35.
Rolf Bjarne Kvinge
Mauro Agnoletti
VS MobileTools Engineering Service 2
Filip Navara
Jonathan Peppers
Peter Collins
Emanuel Fernandez Dell'Oca
Marius Ungureanu
Sebastien Pouliot
TJ Lambert
tj_devel709
Alex Soto
Mauro Agnoletti
mathieubourgeois
Manuel de la Pena
monojenkins
Wojciech Kulik