The exact values are not what we need to test for and varies with
different OS versions - making tests fails for no good reason (i.e.
they are not canary used to detect changes)
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=51801
Apparently Xcode 8.3 does not like the iPhone 5s simulator, and deletes it.
Every time Xcode is updated.
Which is slightly annoying when it affects the bots, since then iPhone 5s have
to be re-created on every bot.
So succumb to the pressure, and switch to using the iPhone 6 simulator instead.
Currently we get a CS2019 warning whenever we use AsyncAttribute
because we ignore the `result` variable on methods whose return
type is != `void` which is the expected behaviour.
This is specially more annoying on third party bindings,
the generated code did not disable this warning so you get
an "unfixable" warning on the generated code and the user
has no way to fix this on their own.
We now remove the unused `result` varibale to avoid the warning.
Nobody likes warnings that are not their fault.
build diff:
https://gist.github.com/dalexsoto/313f913c394d8eb46f95200524eae2e2
https://bugzilla.xamarin.com/show_bug.cgi?id=53076
When [Async] was used on a member of a [Model][Protocol][Basetype]
interface the ModelClass ended up with additional FooAsync methods that
are not really part of the Model.
This commit removed any instances of FooAsync members from model classes
and also fixes any breaking changes in the currently bound classes.
Added test case using Model.
build diff:
https://gist.github.com/dalexsoto/75cb8424f2462bd6b513049f00bba6a8
Currently we get a CS2019 warning whenever we use AsyncAttribute
because we ignore the `result` variable on methods whose return
type is != `void` which is the expected behaviour.
This is specially more annoying on third party bindings,
the generated code did not disable this warning so you get
an "unfixable" warning on the generated code and the user
has no way to fix this on their own.
We now disable and restore CS2019 in the generated code as needed.
Nobody likes warnings that are not their fault.
Added unit test.
Build diff:
https://gist.github.com/dalexsoto/6f57d3f84b039b9fda863e2f8cfcf365
We do support the use of [Async] on methods that do not return void,
we generate an overload with am out parameter to retrieve the returned value
```csharp
[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1)
{
var tcs = new TaskCompletionSource<bool> ();
var result = BarString(arg1, (obj_) => {
if (obj_ != null)
tcs.SetException (new NSErrorException(obj_));
else
tcs.SetResult (true);
});
return tcs.Task;
}
[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1, out string result)
{
var tcs = new TaskCompletionSource<bool> ();
result = BarString(arg1, (obj_) => {
if (obj_ != null)
tcs.SetException (new NSErrorException(obj_));
else
tcs.SetResult (true);
});
return tcs.Task;
}
```
Modified the introspection test to repor this, updated documentation
and update API definitions reported by introspection.
Fixes these compiler warnings:
Foundation/ExportAttribute.cs(96,10): warning CS0618: `XamCore.Foundation.ExportAttribute.ExportAttribute()' is obsolete: `Every exported selector must include a name'
Foundation/ExportAttribute.cs(102,10): warning CS0618: `XamCore.Foundation.ExportAttribute.ExportAttribute()' is obsolete: `Every exported selector must include a name'
If the request is canceled, the inflight data is cleaned up. That allows
us to know that the NSUrlSessionTask should be canceled, which will
execute the DidCompleteWithError that will take care of the cleanup of
resources and will ensure that everything is back to a known situation.
* Do check for managed cancelations in the GetInflightData so that it is check in all handlers.
* [msbuild] Implemented GetFiles and GetFullPath tasks to fix the vs build
Hopefully fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53410
* [msbuild] Added GetDirectories task and fixed GetFiles to handle Path not existing
Array.Empty<T> did not exist in earlier versions of .NET, so this would build
fine on the command-line (which builds using the system's latest .NET
version), but not with the project file (which apparently defaults to .NET 4.5
unless otherwise specified).
So bump the .NET version in the project file so that compilation works the
same in both cases.
SystemSoundTest.FromFile was requesting to be called back when the sound
completed playback. This causes problems when the sound is disposed after it
has started playing, because in that case disposing it won't prevent the
callback from being called, but instead random InvalidCastExceptions / crashes
would occur.
https://bugzilla.xamarin.com/show_bug.cgi?id=52903
* SystemSound.PlaySystemSound doesn't work in the simulator.
https://stackoverflow.com/a/24973240/183422
Sebastien Pouliot
Alex Soto
Vincent Dondain
Vincent Dondain
Rolf Bjarne Kvinge
Marek Safar
Alex Soto
Jeffrey Stedfast
Matt Sylvia
Manuel de la Pena