We were hitting this:
```
fatal error: /Applications/Xcode11-beta1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: can't open input file: /Users/vidondai/Documents/xi-xcode11/xamarin-macios/builds/install/targetwatch64_32/tmp-lib/libmono-native-unified.dylib (No such file or directory)
make[2]: *** [/Users/vidondai/Documents/xi-xcode11/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchOS.sdk/usr/lib/libmono-native-unified.dylib] Error 1
```
Allows to build the project using XCode 11. In order to do so until we
get the mono SDK built in the bots with the Xcode 11 you need to set the
env var MONO_BUILD_FROM_SOURCE=1 so that you build mono in your system.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
It's not allowed to have multiple EditorBrowsable attributes on the same
member, so make sure the generatod doesn't generate such code.
We might want to print an "[EditorBrowsable (Never)]" because a particular API
is obsolete (i.e. has the "[Obsolete]" attribute), but if the API also has an
EditorBrowsable attribute already, use only that one instead.
Fixes https://github.com/xamarin/maccore/issues/1661.
Note that the 'needsPtrZeroCheck' variable is not accurately named anymore,
but given that the code is somewhat impenetrable I wasn't able to come up with
a better name.
Also simplify two consecutive and identical null checks to a single check.
Hopefully fixes this assertion:
> 07:42:06.7701360 validateStrideTextureParameters:1512: failed assertion `Linear texture: bytesPerRow (64) must be aligned to 256 bytes'
which doesn't happen on my machine.
* [xharness] Don't use a dash in the bundle identifer for watchOS projects.
It causes problems with the mscorlib test project, which can't be launched properly.
I'm not sure what's the underlying cause, but here are some of the symptoms:
* The watch app actually shows up fine on the device, but:
* mlaunch isn't notified about the new process, so it thinks the app didn't
launch.
* The new process doesn't receive any environment variables we try to give it,
which for instance means that it won't auto-start the tests upon launch.
* If we ask mlaunch to attach with lldb, mlaunch will ask watchOS to launch
the process in a suspended state while lldb attaches. Yet the watch app
shows up on the device as if not asked to be suspended upon launch.
It seems that the dash (I assume, because I haven't investigated this very
deeply, I just happened to find a solution that worked) makes watchOS launch
the app as if tapped, instead of launched from an IDE.
The strangest part is that this only happens with the mscorlib test project,
not any of the other test projects we run on the watch, and they all have
dashes in their bundle identifiers... yet replacing the dash with another
character (underscore, letter, removing it altogether) all made things work as
expected.
* [monotouch-test] Adjust expected value for watchOS bundle id.
The watchOS bundle ID changed in fc5067ee67, and
the test failure wasn't caught properly.
Basic application (size) for doing an `HttpClient.GetAsync`, release/llvm, 64bits only
- NSUrlSessionHandler (master): 6.4 MB
- NSUrlSessionHandler (PR#5936): 7.7 MB
- NSUrlSessionHandler (this PR): 6.4 MB
The size increase occurs because of the reference to .net `X509*` types.
This brings a lot of additional code, including managed cryptographic
code, inside the application - even when the feature is **not** used.
The solution is to expose an API that only use native (OS) types, which
are mostly already part of the application. This has a very low impact
on existing applications.
It's still possible to hook back to .NET validation if needed (it should
not in most cases) but, in this case, the extra price will only be
_paid_ if used (and can be lower if the code is needed by something else
from the application).
In comparison using other `HttpClient` handler produce app sizes of
- HttpClientHandler (managed): 10.4 MB
- CFNetworkHandler: 6.8 MB
Based on/supersede https://github.com/xamarin/xamarin-macios/pull/5733
Fix https://github.com/xamarin/xamarin-macios/issues/4170
* Choose the first hostname for the HttpTextWriter if there are multiple hosts.
* Open the HttpTextWriter before writing to it.
* Don't overwrite the http writer with another writer immediately after creating it.
* Close the HttpTextWriter when done writing.
* Wait for the HttpTextWriter to complete the final http request before exiting.