* [msbuild] Improved logic for obtaining local IP addresses for WiFi debug
* If we can't resolve the local host, connect to microsoft.com and use LocalEndPoint
* Use UDP instead of TCP to avoid network latency
Exclude tests whose category is !BITCODE when running on watchOS/Release. This
also requires a minor update to xharness to add a BITCODE conditional
compilation flag to generated watchOS/Release projects configurations.
This partially fixes#59947 (the fix will be complete once we bump to mono/2017-08).
https://bugzilla.xamarin.com/show_bug.cgi?id=59947
* Change BlockLiteral.SetupBlock to keep a reference to the delegate passed as the trampoline.
Change BlockLiteral.SetupBlock to keep a reference to the delegate passed as
the trampoline, so that it's safer for normal users (crashes due to incorrect
usage are rare and random, and as such they're also hard to track down).
Additionally introduce a BlockLiteral.SetupBlockUnsafe method, that still has
the old behavior, so that we can use it in our own (reviewed) code.
* [ObjCRuntime] Add some validation to BlockLiteral.SetupBlock.
* Use BlockLiteral.SetupBlockUnsafe instead of .SetupBlock
Use SetupBlockUnsafe in our own code, because we know our own code is using it
correctly (by passing a trampoline stored in a static field, so that the GC
doesn't free it).
* [tests] Fix xammac tests build.
* [xharness] Don't list unusable devices.
* [xharness] Show the list of candidate devices in the html report.
* [xharness] Prioritize devices depending on the interface speed.
* [xharness] Simplify code a bit.
Logs are TextWriters by themselves, so no need to get a StreamWriter to pass
to API that takes TextWriter, when we can just pass the log instance itself.
This makes it possible to timestamp external process output (because
Log.Timestamp is honored instead of bypassed).
* [xharness] Timestamp install logs.
So that we get exact numbers of how long it takes to install on watch (and if
the watch installation stalls, or just times out because it takes too long).
Always wait for processes to exit, even if they're killed.
Also make absolutely sure that we can safely handle any exception when getting
the ExitCode, no matter what.
https://bugzilla.xamarin.com/show_bug.cgi?id=57846
The registrar requires the availability attributes to work properly, which is
non-trivial when the linker is being used, because the linker runs before the
registrar, and will remove availability attributes.
For this reason we store the availability attributes separately when the
linker removes them so that the registrar can still find them, but
unfortunately it's not enough to store the CustomAttribute instance, because
it may end up crippled: if the attribute type itself is removed by the linker,
then it's not possible to get the attribute type from the CustomAttribute
instance, because 'attribute.Constructor.DeclaringType' returns null (the
linker sets the declaring type of the constructor to null).
Solution: store the attribute type separately; now we use a Tuple of
CustomAttribute and TypeReference.
Fixes this ugly exception:
System.NullReferenceException: Object reference not set to an instance of an object
at XamCore.Registrar.Registrar.RegisterAssembly (Mono.Cecil.AssemblyDefinition assembly) [0x00146] in /work/maccore/master/xamarin-macios/src/ObjCRuntime/Registrar.cs:2316
at XamCore.Registrar.StaticRegistrar.Generate (System.Collections.Generic.IEnumerable`1[T] assemblies, System.String header_path, System.String source_path) [0x00035] in /work/maccore/master/xamarin-macios/tools/common/StaticRegistrar.cs:4197
at Xamarin.Bundler.RunRegistrarTask.Execute () [0x00001] in /work/maccore/master/xamarin-macios/tools/mtouch/BuildTasks.mtouch.cs:154
* [registrar] Remove useless interface.
* [registrar] Don't store LinkContext in the static registrar when in can be fetched from the Target. Partially fixes#59617.
This avoids a problem where our code would store null because LinkContext
wasn't created yet when the static registrar instance was created.
This fixes the missing error from bug #59617.
https://bugzilla.xamarin.com/show_bug.cgi?id=59617
* [registrar] Don't verify the SDK for protocol members. Partially fixes#59617.
It's not needed, because protocol members don't end up in the registrar output
anyway (and would thus not prevent the registrar code from compiling).
Classes that implement any protocol members would still run into the SDK
check, so this should not prevent real problematic code from being reported
either.
https://bugzilla.xamarin.com/show_bug.cgi?id=59617
* [tests][mtouch] Fix tests after registrar changes.
It does not make sense to create Xamarin.iOS projects that don't reference
Xamarin.iOS.dll, so make this an explicit error.
This fixes a NullReferenceException which could (when building for device, or
when not using simlauncher) occur, and instead shows the MT0123 error.
> MTOUCH : error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
> System.NullReferenceException: Object reference not set to an instance of an object
> at Xamarin.Bundler.Target.GatherFrameworks () [0x00065] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/common/Target.cs:122
> at Xamarin.Bundler.Target.ProcessAssemblies () [0x000c2] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Target.cs:802
> at Xamarin.Bundler.Application.ProcessAssemblies () [0x0002f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:1407
> at Xamarin.Bundler.Application.BuildManaged () [0x00001] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:831
> at Xamarin.Bundler.Application+<>c.<BuildAll>b__134_1 (Xamarin.Bundler.Application v) [0x00000] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x00024] in <48b95f3df5804531818f80e28ec60191>:0
> at Xamarin.Bundler.Application.BuildAll () [0x00050] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x00481] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:1420
> at Xamarin.Bundler.Driver.Main (System.String[] args) [0x0000f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:945
https://bugzilla.xamarin.com/show_bug.cgi?id=59798
Otherwise copying OpenTK-1.0.dll.config to its target destination would fail
because the target directory didn't exist:
> make[2]: *** [build/tvos/reference/OpenTK-1.0.dll.config] Error 1
https://bugzilla.xamarin.com/show_bug.cgi?id=59432
We already have this logic for frameworks we detect according to the namespace
of the used types, but not for frameworks we detect from P/Invokes.
Fix this by using the same framework exclusion logic for frameworks detected
from P/Invokes: don't link with frameworks not available in the current SDK.
https://bugzilla.xamarin.com/show_bug.cgi?id=59636
Unset XCODE_DEVELOPER_DIR_PATH when building mac binding projects, so that
when building from VSfM when the Xcode in VSfM differs from the system Xcode
(according to xcode-select) the Xcode command-line tools don't end up confused
and fail in strange ways.
- https://bugzilla.xamarin.com/show_bug.cgi?id=59647
- There is no reasonable knob on the AOT process to not generate dSYM so delete after processing (these specific files are spawned only by/during AOT)
- AppStore complains if you ship bundles with dSYM fils present
- Fix mmp unit test stand alone execution (make run in tools/mmp uses different (faster) build system than full mmp tests)
https://bugzilla.xamarin.com/show_bug.cgi?id=59537
Removes constants from `CATextLayer` (only for XAMCORE_4_0) and creates
two smart enums `CATextLayerTruncationMode` and `CATextLayerAlignmentMode`.
Also this introduces two new strong properties into CATextLayer class,
`TextTruncationMode` and `TextAlignmentMode` that takes the new enums
respectively, these new properties are meant to replace their
string counterparts `TruncationMode` and `AlignmentMode`.
Only apply smart enum conversion to enums, and downgrade related warnings to log messages.
This avoids spurious warnings like this:
> warning MT4124: Invalid BindAsAttribute found on 'Bindings.Test.ObjCRegistrarTest.GetBooleanArray': could not find the smart extension type System.BooleanExtensions. Please file a bug report at https://bugzilla.xamarin.com
when the BindAs attribute is valid, but just not about a smart enum in the first place.
Prevents these little gems:
> warning MT4124: Invalid BindAsAttribute found on 'Mono.Cecil.MethodReturnType': could not find the smart extension type ...
--aot[=VALUE] Specify assemblies that should be AOT compiled
- none - No AOT (default)
- all - Every assembly in MonoBundle
- core - Xamarin.Mac, System, mscorlib
- sdk - Xamarin.Mac.dll and BCL assemblies
- |hybrid after option enables hybrid AOT which
allows IL stripping but is slower (only valid
for 'all')
- Individual files can be included for AOT via +
FileName.dll and excluded via -FileName.dll
Examples:
--aot:all,-MyAssembly.dll
--aot:core|hybrid,+MyOtherAssembly.dll,-
mscorlib.dll
Jeffrey Stedfast
Rolf Bjarne Kvinge
Alexander Köplinger
Chris Hamons
Sam Schwarz
Sebastien Pouliot
Jon Goldberger
Timothy Risi
Alex Soto