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.
* 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).
* 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.
* 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.
Xamarin.Mac didn't have support for CoreML models before, so this effectively adds
support for CoreML models to Xamarin.Mac.
Also add a test to make sure it actually works.
* This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs
value didn't match the actual output path (this was fixed in the iOS version).
* Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup
instead of the CreateItem task.
The Xamarin.Mac version of _CreatePkgInfo had a 'Ditto' call that seemed like
a copy-paste error (the target below has the exac same call to 'Ditto'), and
there's no reason to call 'Ditto' when creating the PkgInfo file, so I just
removed it.
The 'Ditto' call was added here: ca028ea150 (diff-ccded350e40e767d69171655acb86b01R586-R606)
The Xamarin.iOS version is more updated, so that's the version now for both
Xamarin.iOS and Xamarin.Mac:
* The iOS version contains Inputs/Outputs (important for incremental builds).
* It doesn't use FileWrites (see e97d69b25c why
this was removed for iOS)
Additionally define the _SceneKitCache variable for macOS as well, previously
it was only defined for iOS (I'm adding more variables than just
_SceneKitCache to macOS, most of the others will be used in in macOS in
upcoming pull requests, and this way turned out to be simplest).
And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
Merge the CodesignNativeLibraries task into the Codesign task, since they're almost
identical (so this turns out to be a significant code reduction).
* Add a StampPath property to Codesign task, which, if set, specifies if and where
a stamp file should be created for each signed file/directory. This replaces the
IntermediateOutputPath property from the CodesignNativeLibraries task.
* Copy logic to detect if a file/directory needs to be resigned from the CodesignNativeLibraries
task to the Codesign task, using any stamp files.
* Use the more descriptive error messages E0004/E0005 from the CodesignNativeLibraries
task.
* The CodesignNativeLibraries task recursed into directories to find *.dylibs and
*.metallib files to sign; replace this with MSBuild item group globbing.
The Xamarin.iOS version seemed more updated, so that's the version now for
both Xamarin.iOS and Xamarin.Mac.
A few differences in the Xamarin.iOS versions are:
* The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs
(important for incremental builds).
* EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded
to 'false' (there is no real difference right now, because
$(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac).
* It doesn't use FileWrites (see e97d69b25c why
this was removed for iOS)
- Fixes https://github.com/xamarin/xamarin-macios/issues/9458
- Defining the variable over multiple lines changes output to include incorrect newline
- Auto tests did not catch, as they don't sign on bots due to infrastructure issues.
- Was refactored _after_ manual tests and not retested
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
There were 2 differences that had to be reconciled:
* The Xamarin.Mac version took 'IntermediateOutputPath' as the intermediate
output path, while the Xamarin.iOS version used
'DeviceSpecificIntermediateOutputPath'.
'DeviceSpecificIntermediateOutputPath' is defined to be
'IntermediateOutputPath' for Xamarin.Mac, so make the shared version use
'DeviceSpecificIntermediateOutputPath', since that works in both cases.
* The Xamarin.Mac version was writing the output of PackLibraryResources to
the FileWrites item group. This was removed on purpose from the Xamarin.iOS
version in e97d69b25c, so it seemed best to
leave it out in the shared version as well.
Also re-use the _EmbeddedResourcePrefix variable to determine the resource prefix.
These only apply to Xamarin.iOS right now, since they're Windows-specific (and
we don't support Xamarin.Mac binding projects on Windows), but if we ever do
end up supporting binding projects for Xamarin.Mac on Windows, we'll need
these targets there, so just make them shared code.
This becomes a bit complicated because we have to wait to determine the default value
for the linker until we know if we're building for the simulator or not (which happens
in the _DetectSdkLocations target).
Use two separate output variables (EntitlementsInExecutable/EntitlementsInSignature)
instead of using the same output variable for two different purposes. This makes
the code more self-explanatory.
Also move the simulator check to the C# code, that way it's easier to re-use elsewhere.
* [msbuild] Share the _CompileEntitlements task.
* [msbuild] Create the same class hierarchy for Xamarin.Mac and Xamarin.iOS for the CompileEntitlements task.
CompileEntitlementsTaskBase
└─── iOS/CompileEntitlementsTaskCore
│ └─── iOS/CompileEntitlements
└─── Mac/CompileEntitlementsTaskCore
└─── Mac/CompileEntitlements
This also means we can remove a known failure in the list of MSBuild tasks that don't
conform to our 'no code in final task implementation' requirements.
In addition to the obvious benefit of reducing code duplication, this also
means that implicit inclusion of netstandard.dll works for binding projects as
well.
The existing implementations were slightly different between Xamarin.iOS and
Xamarin.Mac, so I tried to figure out the best merging strategy based on git
history and looking at the original implementation of this code in MSBuild. I
tried to keep close to the original implementation whenever I couldn't find a
good reason to do otherwise.
`GetMinimumOSVersion` should not be run if there's no Mac available because it depends on `_DetectSdkLocations` to calculate the value of `_SdkVersion`, and this will only happen if there's a Mac connected. This change fixes offline builds (plain IL builds) and Hot Restart builds on Windows.
Co-authored-by: emaf <ema@xamarin.com>
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
* Change the parsing code slightly, to make it easier to parse other arguments
(coming soon).
* Add the parsing task to Xamarin.Mac projects, and use it there as well. The
parsed result isn't used yet, but it will be soon.
* Unify a few related MSBuild properties (MtouchNoSymbolStrip and
MtouchNoDSymUtil).
Some of these have been duplicated across various targets files, and when
adding a new task it's annoying to forget to add it somewhere.
So just have them all in the same place, so that they're loaded in every file.
There are still duplicates between the iOS and Mac tasks, but those will be
unified in a later PR.
* For Xamarin.Mac, this means using the _ComputeBundleResourceOutputPaths and
_CopyResourcesToBundle targets from Xamarin.iOS instead of the
_CopyContentToBundle target (which is now unused and thus removed).
* Adapt the Xamarin.iOS logic (now shared) to handle the fact that the
resources shouldn't always go into the root appbundle directory (since they
go into Contents/Resources/ for macOS apps), by using the
'_AppResourcesPath' variable to specify just this.
Once upon a time the Xamarin.iOS logic was identical to the Xamarin.Mac logic,
but then we implemented support for asset packs
(a98693f07e)
and the code diverged. This means that unifying the logic again is a step
towards making asset packs work for Xamarin.Mac apps.
* [msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties.
* [msbuild] Fix/unify more resource collection code.
* Remove the _CollectBundleResources target for Xamarin.iOS binding projects,
we now have a single one for all project types.
* Add an IsBindingProject property to distinguish binding projects from other
projects.
* Use the IsBindingProject to only depend on the other _Compile<ResourceType>
targets when we're not building a binding project (which seems to be the
reason why the _CollectBundleResources target was duplicated between normal
projects and binding projects for both Xamarin.iOS and Xamarin.Mac: the
binding project version didn't have any dependencies).
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
CompileAppManifestTaskBase
└─── iOS/CompileAppManifestTaskCore
│ └─── iOS/CompileAppManifest
└─── Mac/CompileAppManifestTaskCore
│ └─── Mac/CompileAppManifest
This makes it possible for several other tasks to take the MinimumOSVersion as
direct input, instead of the app manifest's path. Previously the app manifest
(Info.plist) was loaded and parsed in each task, slightly differently in each
place, and in addition there are differences between macOS and other
platforms, which made it even worse. This code refactoring also made it
possible to remove an error code which wasn't necessary anymore.
This task also computes the default MinimumOSVersion if none is specified in
the app manifest.
There is one breaking change: a library project could previously specify an
inexistent Info.plist, and it would build fine. This will now result in a
"Error loading 'Info.plist': File not found" error. This is trivial to fix:
just remove the Info.plist from the project file (or an alternative solution
could be to condition the inclusion of the Info.plist in the project file on
the existence of the Info.plist).
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73)
Diff: 45c5a680e2..a1bc6f39b3
* [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures.
* [msbuild] Use $(ComputedPlatform) instead of $(_Platform).
They're identical, and this avoids using $(_Platform) before it's defined.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
DetectSigningIdentityTaskBase
└─── iOS/DetectSigningIdentityTaskCore
│ └─── iOS/DetectSigningIdentity
└─── Mac/DetectSigningIdentityTaskCore
│ └─── Mac/DetectSigningIdentity
There's one difference for Xamarin.Mac library projects: they'll now have the
ability to use an Info.plist to specify a minimum OS version that will be used
when compiling storyboards and other compilable files.
This is the way it's worked for Xamarin.iOS projects for a long time.
There is a difference for Xamarin.Mac: the task will not be executed anymore
if IsAppDistribution is set to true. Given that IsAppDistribution is not used
in Xamarin.Mac projects, this is likely a rather uncommon case, and the
potential for breaking behavior is outweighed by the advantage of having the
same behavior for Xamarin.iOS and Xamarin.Mac.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8265
Usage of `System.Drawing` types in iOS binding projects are failing with:
error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'.
This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
Consider adding a reference to that assembly.
In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS
and Mac projects, but mistakenly missing from binding projects.
I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`,
so it will be used for all project types.
I also updated a test, I could merely use `System.Drawing.Color` in
`StructsAndEnums.cs` to reproduce the failure.
Sebastien Pouliot
Rolf Bjarne Kvinge
Wojciech Kulik
monojenkins
Chris Hamons
Jonathan Peppers