* [Perf] Use Runtime.IntPtrEqualityComparer everywhere
This avoid boxing the key for Dictionaries which take IntPtr as keys.
* [Perf] Avoid Tuple allocations and boxing of tuple items
The default implementation of Tuple IEquatable uses EqualityComparer<Object>.Default, which causes boxing for IntPtr.
Implement a hand-made IntPtr-Type tuple that also uses custom comparers defined Runtime, for IntPtr and Type equality.
This should improve allocations done by GetDelegateForBlock
Fixes bug #44874: Problems with NetworkExtension.NETunnelProviderManager
(https://bugzilla.xamarin.com/show_bug.cgi?id=44874)
Using the default constructor doesn't return null anymore, this might be a
change we missed in one of the betas.
In the recent Cecil update Cecil changed from loading assemblies in memory to
keep a FileStream around and read whenever necessary [1].
This is problematic for us, because we need all the AssemblyDefinitions in
memory at once, and if there are many assemblies, then we'll run into problems
due to the number of file descriptors in use.
So revert to the behavior for the old Cecil: loading assemblies in memory,
unless the assemblies are big, since in that case we might run out of memory
otherwise.
http://cecil.pe/post/149243207656/mono-cecil-010-beta-1
The problem was that this property was evaluating to True
for the main app bundle because it assumed that if the
project contained a Watch app, that it was the WatchExtension.
This logic only holds true for WatchOS1, but not WatchOS2.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44841
Re-enable some TLS logic on watchOS to fix a few unit tests:
[FAIL] CertificateTest.MailX1 : Same Handle
[FAIL] RecordTest.SecRecordRecordTest : Same Handle
* Added rewritten NSUrlSessionHandler that handles memory better
This is a rewrite of the ModernHttpClient version of NSUrlSessionHandler, it has better handling for memory that provides a more consistant memory footprint. It accomplishes this by using NSInputStream for requests, and reading and disposing directly from NSData instead of transitioning the NSData to a byte[] array.
* Try to fix build of PR #31
* [foundation] Restore compatibility with the new NSUrlSessionHandler
Mostly my comments in PR #174
* Add support for redirection [1]
* Add support for credentials [1]
* Add support for caching [2]
* Remove 2nd dictionary lookup in GetHeaderSeparator
* Avoid extraneous cast for credentialsToUse
PR 177 [3] adds tests that ensure no commits can remove, or change
default values, for handlers.
[1] breaking changes (feature, not API)
[2] breaking change (API removal)
[3] https://github.com/xamarin/xamarin-macios/pull/177
* [foundation] Restore compatibility with the new NSUrlSessionHandler
Mostly my comments in PR #174
* Add support for redirection [1]
* Add support for credentials [1]
* Add support for caching [2]
* Remove 2nd dictionary lookup in GetHeaderSeparator
* Avoid extraneous cast for credentialsToUse
PR 177 [3] adds tests that ensure no commits can remove, or change
default values, for handlers.
[1] breaking changes (feature, not API)
[2] breaking change (API removal)
[3] https://github.com/xamarin/xamarin-macios/pull/177
* Try to fix build of PR #31
* prevent DEADLOCK in UI code
* Added ConfigureAwait(false) to Task.Delay to prevent DEADLOCK when the stream is being awaited on the UI thread
* added a few more ConfigureAwait(false) statments that were missed on first pass
* Fix some small style issues.
* Set the default value of AllowAutoRedirect to true.
* [tests] Remove Classic SDK tests.
* Remove XI/Classic support.
This also means we can remove support for the legacy registrars.
* [monotouch-test] Remove legacy registrar tests.
* [tests/mtouch] Remove Classic tests (and legacy registrar logic).
* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
The current API use `string`, not `NSString` is added as a step forward.
The `NSString` is more correct but it does not ease discoverability (e.g.
code completion) so an enum-based overload is added (as the preferred API).
https://bugzilla.xamarin.com/show_bug.cgi?id=32535
https://bugzilla.xamarin.com/show_bug.cgi?id=44399
We did not fully support passing null to name and objectToObserve in
CFNotificationCenter::AddObserver an ArgumentNullException was thrown
The use case of sending null to both name and objectToObserve is to
observe all notifications posted to the notification center, this
won't work using darwing notification center, it is restricted
by apple.
* Pass -Wl,-no_weak_imports to the linker so that we don't accidentally use
symbols weakly. This would cause problems on older OSes where the symbol
isn't there, because our code is not prepared to deal with weakly linked
symbols.
* Manually disable fstatat and readlinkat (introduced with Xcode 7 in iOS 8 /
macOS 10.10), found by the above.
* Manually disable __thread support for a few targets, since mono's configure
script doesn't properly detect it's not supported.
* Manually disable clock_nanosleep, since mono's configure script doesn't
properly detect it's not supported.
* Bump Mono to mono-4.8.0-branch commit 9437553e545f57443ccc33fe4129cbb6ac94f832.
* Rename MobileCertificateHelper -> AppleCertificateHelper.
All the non-Apple-specific functionality now lives in System.dll's
MobileTlsContext, so it can be shared with BTLS.
* Remove old src/Security/Tls sources which have been moved into System.dll
a couple of weeks ago.
* [msbuild] Set $(CscDebugFileExt) also, whenever overriding $(CscToolExe)
- This property was introduced in mono's msbuild, but will be upstream
also
- This *must* be set before Microsoft.CSharp.targets file is imported.
- Even though the msbuild targets will automatically select `.mdb` if
the `$(CscToolExe)` is `mcs` or `mcs.exe`, it would be a good
practice to set both the properties together.
- This came up in cases where we use `smcs`, because in that case the
msbuild targets end up using `.pdb`.
* [msbuild] Set `$(CscDebugFileExt)` == `.mdb`
Xamarin.ObjcBinding.CSharp.targets: Set the debug file extension also,
since we are overriding the compiler via `$(CscToolExe)`. Also, move
the property definition around to ensure that they are set *before*
importing `Microsoft.CSharp.targets`.
The MT2001 error is a general, something went bad, in the linker code
base. The stack trace is often enough to track down issues but in some
cases it would be easier to ask customers for a specific assembly
(rather than their complete project) to investigate an issue.
Example:
error MT2103: Binding Optimizer failed processing `System.Void GoogleConversionTracking.Unified.GoogleConversionPing::.ctor()`.
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessIsDirectBinding (Mono.Cecil.MethodDefinition caller, Mono.Cecil.Cil.Instruction ins) [0x00026] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:264
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessCalls (Mono.Cecil.MethodDefinition caller, Int32 i) [0x00337] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:197
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.Process (Mono.Cecil.MethodDefinition method) [0x0007b] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:81
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00004] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:48
---
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00014] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:50
at Mono.Tuner.SubStepDispatcher.DispatchMethod (Mono.Cecil.MethodDefinition method) [0x0001d] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:215
at Mono.Tuner.SubStepDispatcher.BrowseMethods (ICollection methods) [0x0001c] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:167
at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) [0x0006b] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:145
at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) [0x00050] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:123
at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) [0x0000f] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:104
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00027] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/linker/Mono.Linker/Pipeline.cs:118
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) [0x000ac] in /Users/poupou/git/xamarin/xamarin-macios/tools/mtouch/Tuning.cs:79
Right now the MT2001 would only include the inner exception, which does
not include any clue to which assembly caused the exception.
Note: The same pattern to be applied to other BaseSubStep subclasses in
separate commits.
Related to (but not the fix for) https://bugzilla.xamarin.com/show_bug.cgi?id=44701
* mono revision at fc99fc4313e7afd75a4605a48b47e7d1273aefe4
* watch-mono revision is more recent to include the BCL adjustments
for types not available on that platform
* Update two linksdk test cases that won't work _normally_ for watchOS
Some binding assemblies contains extra, unneeded code, generated by the C# compiler, e.g.
IL_002f: stloc.0
IL_0030: ldloc.0
which the binding optimizer did not expect.
https://bugzilla.xamarin.com/show_bug.cgi?id=44701
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568