It's not tested, and thus has probably already bitrotted. If we add support
for watchOS to .NET in the future, it would likely be easier to start from
scratch (copying some of the other platforms), than having incomplete and
bitrotted code.
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21464.10 -> To Version 6.0.100-rc.2.21465.13
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* 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.
We either use the html web page, or for .NET tests there are custom makefile
logic.
This avoids having to maintain the makefile generation to keep up with our new
tests, and it fixes numerous warnings like this:
Makefile-mac.inc:56: warning: overriding recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:41: warning: ignoring old recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:59: warning: overriding recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:44: warning: ignoring old recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:62: warning: overriding recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:47: warning: ignoring old recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:65: warning: overriding recipe for target 'run-mac-modern-macOS'
Makefile-mac.inc:50: warning: ignoring old recipe for target 'run-mac-modern-macOS'
MonoTouch.NUnit.UI.MacRunner.MainAsync will try to invoke things on the main
thread, and at the same time execute a runloop, and if the runloop isn't
executing on the main thread, we end up with a deadlock, where we keep waiting
on the main thread to process stuff enqueued by the background thread, while
the main thread is waiting for the background thread to finish.
Solve this by fixing the F# code to call
MonoTouch.NUnit.UI.MacRunner.MainAsync on the main thread.
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21463.12 -> To Version 6.0.100-rc.2.21464.10
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
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.
Fixes this test failure when running monotouch-test with the dynamic registrar and
linking has been enabled:
MonoTouchFixtures.ObjCRuntime.RegistrarTest
[FAIL] TestProtocolRegistration : UIApplicationDelegate/17669
Expected: True
But was: False
This is a port of what we do during linking for legacy Xamarin apps.
Ref: 682f54da87
Fixes https://github.com/xamarin/xamarin-macios/issues/12644.
* [dotnet-linker] Remove workaround for a dotnet/runtime issue wrt the AOT compiler.
The dotnet/runtime issue has been fixed.
Ref: https://github.com/dotnet/runtime/issues/55733
* [tests] Set the _BundlerVerbosity property instead of MtouchExtraArgs/MonoBundlingExtraArgs to increase verbosity.
This fixes a problem where a test project would try to set the
MtouchExtraArgs/MonoBundlingExtraArgs properties, and it would fail because
the MtouchExtraArgs/MonoBundlingExtraArgs properties were already set from the
command line (and in MSBuild, properties that are set from command line
arguments can't be changed later).
In particular we have logic to pass --dlsym:+nunit.framework.dll for
monotouch-test, and that would just be ignored.
For historical reason `NSAutoreleasePool` is bound manually. However it
can still be optimized, which is nice since it's not a type that is
likely to be subclassed.
The default `IsDirectBinding`, from `NSObject`, does the right job.
Optimized code, inside app, will look like:
```csharp
[Export("init")]
public NSAutoreleasePool()
: base(NSObjectFlag.Empty)
{
base.Handle = Messaging.IntPtr_objc_msgSend(base.Handle, Selector.GetHandle("init"));
}
```
This matters because we use the library defined by the P/Invoke to determine
which frameworks to link with, and if we get it wrong, things like this may
happen:
Undefined symbols for architecture arm64:
"_AudioObjectGetPropertyData", referenced from:
wrapper_managed_to_native_AudioUnit_AudioUnit_AudioObjectGetPropertyData_uint_AudioUnit_AudioObjectPropertyAddress__uint__intptr__uint__uint_ in Xamarin.MacCatalyst.dll.o
because we though that the AudioObjectGetPropertyData function was in the
AudioUnit framework, and not in CoreAudio where it really is, and thus we
didn't link with the CoreAudio framework.
Also add an introspection test to verify that the library our P/Invokes point
to is correct.
* Update dependencies from https://github.com/dotnet/installer build 20210910.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21458.9 -> To Version 6.0.100-rc.2.21460.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21452.4 -> To Version 6.0.100-1.21459.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210910.37
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21458.9 -> To Version 6.0.100-rc.2.21460.37
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21452.4 -> To Version 6.0.100-1.21459.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Add dotnet-tools to our NuGet feeds to work around an msbuild/nuget bug.
Ref: https://github.com/dotnet/msbuild/issues/6834
* [src] Add an additional HttpClientHandler property to NSUrlSessionHandler.
We need this otherwise we get linker warnings which results in test failures
(because we verify that building a template doesn't show any warnings):
* Xamarin.Tests.TemplateTest.CreateAndBuildTemplate("iOS","ios"): Build warnings:
System.Net.Http.HttpClientHandler.GetServerCertificateCustomValidationCallback(): No members were resolved for 'get_ServerCertificateCustomValidationCallback'.
System.Net.Http.HttpClientHandler.SetServerCertificateCustomValidationCallback(Func<HttpRequestMessage,X509Certificate2,X509Chain,SslPolicyErrors,Boolean>): No members were resolved for 'set_ServerCertificateCustomValidationCallback'.
Ref: fc631442f9
Ref: 679cd97153
* Update dependencies from https://github.com/dotnet/installer build 20210913.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21458.9 -> To Version 6.0.100-rc.2.21463.12
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21452.4 -> To Version 6.0.100-1.21459.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Defining xm_nint_t to be 32-bit sized only on i386 is not the right thing to do for armv7.
Strangely enough this caused just a single test failure:
MonoTouchFixtures.Foundation.CalendarTest
[FAIL] TestFindNextDateAfterDateMatching : Expected: <Foundation.MonoTouchException>
But was: null
at MonoTouchFixtures.Foundation.CalendarTest.TestFindNextDateAfterDateMatching()
and that happened because:
1. We use a wrapper function around objc_msgSend:
void *
xamarin_IntPtr_objc_msgSend_IntPtr_IntPtr_nuint_exception (id self, SEL sel, void * p0, void * p1, xm_nuint_t p2, GCHandle *exception_gchandle)
{
@try {
return ((func_xamarin_IntPtr_objc_msgSend_IntPtr_IntPtr_nuint_exception) objc_msgSend) (self, sel, p0, p1, p2);
} @catch (NSException *e) {
xamarin_process_nsexception_using_mode (e, true, exception_gchandle);
return NULL;
}
}
2. Note that the second to last argument is an 'xm_nuint_t'. We told the
native compiler this was a 64-bit value, when the managed P/Invoke would
give it a 32-bit value. This had no effect on the 'p2' parameter, but it
meant that clang would thing the next argument, 'exception_gchandle', would
be somewhere it wasn't (the managed function would pass two 32-bit values,
'p2' and 'exception_gchandle', which clang would merge into a single 64-bit
'p2' argument, and then read random stuff for 'exception_gchandle').
3. Finally things would go sideways when we caught the exception and passed
'exception_gchandle' to xamarin_process_nsexception_using_mode. In effect
we'd ask xamarin_process_nsexception_using_mode to store the resulting
gchandle in random memory. Amazingly it only resulted in a test failure
(because upon return the managed location for the 'exception_gchandle'
wasn't touched, and would have its initial value of 0, thus managed code
would think no exception occurred).
So fix this to use the correct underlying types, instead of trying to figure
out the correct #if condition.
I'm not sure why we're using our own types here anyways, but this fix is the
smallest.
We are adding the warnings for net6 for customers, but those same
warnins do appear when we build the intermediate assembly and makes it
very very noise and hard to find errors. We can disable them for our
projects via stating that they are generated.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Alex Soto
TJ Lambert
Manuel de la Pena
Sebastien Pouliot
Rachel Kang
github-actions[bot]
Mauro Agnoletti