Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
* [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.
* [watchOS] Add x86_64 simulator support
* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64
* [tests] Add x86_64 arch to test-libraries
* Make dotnet package aware of x64
* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.
* [xharness] Re-enable some watchOS tests.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [msbuild] Add SceneKit assets to our items included by default.
There's a minor wrinkle here: we need to calculate the virtual path of the
SceneKit items (relative to the project), but for items included by default
their defining project is not the user's project, but our
Xamarin.Shared.Sdk.DefaultItems.targets file.
The solution is to add metadata for items included by default
('IsDefaultItem'), and if that's found when we calculate the virtual path, use
the executable project to calculate the virtual path, instead of the project
that defined the SceneKit items.
* [msbuild] Use a different temporary directory based on the platform.
This is a temporary solution, until .NET provides a way for us to select which
runtime pack to use.
Also ensure that we're using Mono's dynamic libraries (as opposed to static
libraries) when building for macOS.
* [dotnet] Detect, compile and publish Info.plist into the app.
* Automatically detect any property lists in the root project directory, and
include them into the build.
* Introduce the existing build targets to detect and compile Info.plist into
the .NET build.
* Add documentation for default inclusion. This document will grow over time
as more file types are automatically included.
* Add some tests.
* [dotnet] Adjust default inclusion behavior.
* Use a single platform-specific variable to control all types of
platform-specific inclusions.
* [dotnet] Move the default inclusion to .targets instead of .props, so that .NET's default inclusion logic is already imported.
.NET sets EnableDefaultItems in their .targets: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L16
Also add another nuget source to get Mono's net5 runtime packs.
This makes the tests/dotnet/MySingleView test app:
* Compile managed code successfully, referencing Xamarin.iOS.dll.
* Resolve the correct targeting and runtime packs (aka Mono).
The compiled result is not put into an .app bundle as iOS expects, so the
result isn't actually executable.
Create the various NuGet packages to support .NET 5+. The packages are
currently empty (and not very useful), but the actual content will come later.
The current set of NuGet packages are (this list is duplicated for each
platform: iOS, tvOS, watchOS and macOS):
* Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an
MSBuild Project SDK. Will eventually contain all the build logic. Might also
eventually contain other tools (mlaunch, bgen, etc.), but these might also
end up in a different package.
* Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly.
* Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files
(libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.):
The NuGets built on CI are automatically published to a NuGet feed.
The versioning for the NuGet packages required a few changes: OS bumps are now
changed in Make.versions instead of Make.config (this is explained in the
files themselves as well).
Rolf Bjarne Kvinge
Alex Soto