This PR resolves a crash when running the linker on publishing iOS extensions.
The crash would occur here in failing to resolve corelib.
The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies.
This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib.
After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish.
_ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true'
Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target.
This means we'd fail to set SelfContained until after the condition, and not run.
This was verified by setting /p:SelfContained=true to true.
I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
Properly synchronize access to the current writer in the generator tests'
ThreadStaticTextWriter class.
Should fix this random failure:
Error Message:
System.NullReferenceException : Object reference not set to an instance of an object.
Stack Trace:
at Xamarin.Tests.ThreadStaticTextWriter.WriteLine(String value) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 478
at System.IO.TextWriter.SyncTextWriter.WriteLine(Object value)
at System.Console.WriteLine(Object value)
at Xamarin.Tests.BGenTool.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 235
at Xamarin.Tests.BGenTool.AssertExecute(String message) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 207
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, IEnumerable`1 references, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 780
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 766
at GeneratorTests.BGenTests.BuildFile(Profile profile, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 756
at GeneratorTests.BGenTests.VSTS970507() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 650
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21465.13 -> To Version 6.0.100-rtm.21466.6
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
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.