* [msbuild] Fixed PathUtils.AbsoluteToRelative() logic
Don't require the 'absolute' path argument to be a FullPath.
The code already calls Path.GetFullPath() on the 'absolute'
path anyway.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53176
* Fixed ResolveSymbolicLinks() to return the input path if realpath() fails
Fixes bug #52758 (https://bugzilla.xamarin.com/show_bug.cgi?id=52758)
For appex the MainAssembly path should be absolute, since mtouch will generate a build-arguments.txt file that then will be used to build the extension in the same mtouch process than the container app. Due to this, if the path stored is relative mtouch won't be able to find the assembly.
* Bump maccore to get fix for launching the simulator for app extensions.
* [runtime] Don't look in shared memory for debug data in normal apps.
Don't look in shared memory for debug data in normal apps, because it
interferes when debugging extensions from the same solution as a container
app:
Example, for a keyboard extension:
1. Run extension in XS.
2. Manually launch the extension's container app (which contains a textbox
that can be used to launch the keyboard).
3. The container app reads the debug data in shared memory which was intented
for the extension, and takes over the debugger.
4. Launch keyboard, which will not be able to connect to the IDE because the
container app already connected to the IDE.
Log this as an error even if the log file does not exist and/or
is parseable.
Previously, it was possible that if the log file didn't exist
or it was perfectly validly formatted, we would never log that
error code and so it's possible that we wouldn't log *any*
error at all (e.g. empty log file).
Fixes bug #52982: [iOS]Metal samples fail to build with Xcode8.3
(https://bugzilla.xamarin.com/show_bug.cgi?id=52982)
Basically with Xcode8 Apple stopped using an intermediary step to generate the
default.metallib. This was what our `_ForgeMetal` target was doing, generate a `default.metal-ar`
file which was used as input for `_TemperMetal` and then generate the default.metallib.
Instead with Xcode8 you can just give Shaders.air directly to the metallib tool.
The fix in this commit is made in such a way that it still supports Xcode7.
if !Xcode8 then don't change anything.
if Xcode8+ then have `_ForgedMetal` output equal `@(_SmeltedMetal)` (basically skip the _ForgeMetal target).
Xamarin.Mac binding projects would show this error:
> /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.ObjcBinding.CSharp.targets: error : Unknown target framework identifier: Xamarin.Mac.
while at the same time not actually failing the build (so nothing broke,
making it harder to notice).
The error is printed in BTouchTaskBase, which was previously only used for
Xamarin.iOS. Now we're using it for both Xamarin.iOS and Xamarin.Mac (in which
case it's subclassed), so make sure to not validate the
TargetFrameworkIdentifier according to only valid TargetFrameworkIdentifiers
for Xamarin.iOS.
This is accomplished by adding a new virtual overload to validate (and get the
right /target-framework argument for the generator), and override that method
in Xamarin.Mac's BTouch subclass.
* Bump maccore to get partial fix for bug #52710.
Bump maccore to get partial fix for bug #52710 (can't launch/debug today
extensions more than once).
https://bugzilla.xamarin.com/show_bug.cgi?id=52710
* Bump maccore to make the (partial) fix for #52710 work on device as well.
Even if it's in UIKit, this is not a UI type and does not _suffer_ from
the UI thread restriction. In fact it's used with file coordination which
implies threading is required.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=53075
Taken out of our Xcode8 post-mortem: it's easy to forget (while adding)
or miss (while auditing) a `[Async]` attribute on the API that would
benefit from them.
API that are decorated with either:
* [Obsolete] (managed); or
* [Obsoleted] or [Deprecated] (native)
are not to be added *Async methods (or at least be reported as missing)
This also includes updated introspection tests that found the missing *Async API., ensuring that future API addition will immediately notice is an `[Async]` sounds useful.
It was left out by mistake when added (to classic only). Since then macOS
also added support for the API.
references
bugzilla: https://bugzilla.xamarin.com/show_bug.cgi?id=53083
xtro: common.unclassified:!missing-selector! MKLocalSearchRequest::initWithCompletion: not bound
Some of the Clean steps need the _ComputeTargetArchitectures
target to run before they can properly do their thing because
they depend on DeviceSpecific paths.
Also added logic to rm -rf extension *.dSYM and framework *.dSYM
dirs in the container app bin dir (which fails on xbuild due to
a bug in xbuild... yay!)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53007
A `[Native]` enum is either 32 bits or 64 bits depending on the CPU,
i.e. it's a `NS[U]Integer`. However the managed representation is
*always* 64 bits, a `long` enum, which means it cannot be used
directly (without a cast) when declaring code that match native.
This also enable us to remove the hack from PR1751 to ignore some
generated trampoline code.
reference:
* https://bugzilla.xamarin.com/show_bug.cgi?id=53058
* generated code diff: https://gist.github.com/spouliot/f6196aa892a7a33257fe2cf421fffc2e
Presently we're looking if enums decorated with [Native] are used, just
like we do for p/invokes and delegate types decorated with a
[MonoNativeFunctionWrapper] attribute.
Testing properly required to add a property to MonoPInvokeCallbackAttribute
so we can get back the type given as it's argument.
* Also check for generics in delegates, ref: #42699
* Ignore failures filed as https://bugzilla.xamarin.com/show_bug.cgi?id=53058
We cannot use generics in native signatures but, with some care (and
generator work), we can still expose nullable on our public delegate API.
AUImplementorStringFromValueCallback is presently the only case of such
an API.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=42699
Apple has both an Empty and Null constants. Our implementation is largely
done in managed code and, for historical reasons [1], match System.Drawing
behaviour. Still the constant is useful for other (e.g. 3rd party) APIs.
Also add CFRect.Infinite for the missing CGRectInfinite symbol.
[1] In the original classic we only provided RectangleF not CGRect
references:
* https://bugzilla.xamarin.com/show_bug.cgi?id=43628
* xtro
common.unclassified:!missing-field! CGRectNull not bound
common.unclassified:!missing-field! CGRectInfinite not bound
IKVM doesn't have API that supports looking for inherited attributes (we'd
have to implement the logic ourselves if we needed it), so I decided to check
if we really need to fetch inherited attributes.
Turns out we don't: removing all lookup for inherited attributes does not
change the generated output, nor does it fail any of our tests.
A few more reasons I think this is fairly safe:
* For events and properties, the `inherits` flag is ignored according to MSDN,
so removing it does not change anything at all.
* Fields can't be inherited (they're not virtual), so asking for inherited
attributes doesn't even make sense.
* Our binding syntax generally does not use inheritance (a base type is
expressed by putting the `[BaseType]` attribute on the binding interface,
not making the binding interface actually inherit from its alleged base
type).
* Even when the syntax does use inheritance (to inline protocols), the inlined
protocols do not use inheritence themselves, so none of the members in the
inlined protocols will override base class member (since there is no base
class).
Generator diff: https://gist.github.com/rolfbjarne/6a767517a9db76e415827039885c6b09 (all changes are unrelated)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52745
Added a new CodesignNativeLibraries task that scans for
and then codesigns each *.dylib and *.metallib in the
app bundle (minus those in the PlugIns and Watch dirs).
Marek Safar
Jeffrey Stedfast
Rolf Bjarne Kvinge
Alex Soto
Emanuel
Vincent Dondain
Sebastien Pouliot