Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Public fields shouldn't start with a lower-cased letter.
Also provide public properties in legacy Xamarin so that we can write
identical code for both, and obsolete the lower-cased fields.
This turned out a bit complicated, because we're lipo'ing together both the simulator
and device slices, and that doesn't work anymore when ARM64 is both a simulator and
a device architecture. The solution is a custom lipo logic that doesn't include the
simulator version of the ARM64 architecture in the final binary.
* [tests] Create a libtest.xcframework and libtest2.xcframework
* [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library
* [msbuild] Add support for xcframeworks with static libraries in them.
* List the frameworks libtest needs.
* [tests] Update .NET unit tests according to test project changes.
* [tests] Add new test to verify that packing an old-style binding project doesn't work.
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
.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.
It's a bit weird to build it twice, but it's the most straight forward way of
making the test work if either the .NET build or the legacy build is disabled.
When checking whether a type is a user type or not, we might have to do a
dynamic check if the dynamic registrar is available. Otherwise we may run into
a situation where the static registrar ran during the app build, but then the
app loaded additional assemblies at runtime, and those assemblies contained
user types that were registered using the dynamic registrar, so the static
registrar doesn't know about those custom types (in other words: we need to
check at runtime).
* 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.
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
* [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.
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.
* [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>
We've modified our NUnitLite to special-case the native types, so that they
can easily be compared with the standard types, but that doesn't work anymore
when switching to the official NUnit[Lite], so change all asserts to
explicitly convert whenever needed.
In make 4.3 the pattern `.libs/watchos/%.arm64_32.dylib` in mk/rules.mk takes
precedence over the pattern `.libs/watchos/libtest.%.dylib` in
tests/test-libraries/Makefile when the pattern replacements are 'libtest' and
'arm64_32' respectively, because the former is shorter.
This seems to be a bug (in make 3.81) that has been fixed, because that's the
documented behavior.
Rewrite the logic to not use a pattern target in test/test-libraries/Makefile.
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Fix building the test libraries so that the native compiler gets passed the
right arguments (which makes us build the tvOS and watchOS versions of these
libraries with bitcode).
This fixes a build problem with the framework-test test for tvOS and watchOS.
Also remove an outdated comment.
This has a couple of advantages:
* It makes it easier to add a catalyst version of these libraries (because it
becomes cumbersome to build for catalyst when the build rules assumes we're
building for both simulator and device).
* It makes it easier to create an xcframework of our libraries, because the
contents in an xcframework is split like this.
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.