During the investigation for a System.Configuration race in bug #53461 [1]
it was found that we did not pass the computed value for
`TLSMinimumSupportedProtocol` based on `ServicePointManager.SecurityProtocols`
to the `NSUrlSession`, in effect allowing what the OS does, by default,
and not what the application requested.
This replace an earlier attempt to fix the race in PR #1889
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=53461
[2] https://github.com/xamarin/xamarin-macios/pull/1889
* [generator] Fix bug 42742 The advice attribute doesn't make it to the generated code
https://bugzilla.xamarin.com/show_bug.cgi?id=42742
The Advice attribute used in our bindings was not making
into the generated code. This fixes it.
Also added unit test for it
* [generator] Merged PrintFooAttributes into one
Merged PrintPlatformAttributes, PrintPreserveAttribute and
PrintAdviceAttribute into a single method PrintAttributes.
This is due to sometimes we call three times in a row the same method:
```csharp
PrintPlatformAttributes (pi.GetGetMethod ());
PrintPreserveAttribute (pi.GetGetMethod ());
PrintAdviceAttribute (pi.GetGetMethod ());
```
We now do
```csharp
PrintAttributes (pi, platform:true, preserve:true, advice:true);
```
Also removed a not used instance (internal field) of AdviceAttribute
* [Versions-ios.plist.in] added sgen-concurrent-gc
Partial fix for bug #53316
* Added sgen-concurrent-gc key for Mac as well
* Added other feature keys supported by Xamarin.Mac
* [Versions-mac.plist.in] Drop "activation" as a Feature
* [Versions-*.plist.in] Synced up and renamed modern-http-client
This is the first step for documenting the error messages in the generator:
create a document for the error messages.
The entries in the document are the same as the ones listed in the error.cs
file (which I've now removed to prevent duplication), with some very minor
editing.
The document is not yet published to the documentation repository (since this
is just the first step).
When using debug simulator we don't generate main.m so we were not passing the gc options.
The MONO_GC_PARAMS variable is not in app.EnvironmentVariables (which only contains environment variables passed to mtouch using --setenv), which is why the above condition does not trigger.
No frameworks should be bundled in WatchKit 1 extensions, they should be
bundled in the container (iOS) app.
This broke when merging the equivalent fix for master into the framework-sdk
branch (i.e. a broken merge).
* [Contacts] Fix bug 52571 - Missing API due to binding error
https://bugzilla.xamarin.com/show_bug.cgi?id=52571
Unfortunately [Static] methods inside [Category] lead to bad code
I have exposed alternative methods that call the static extensions
and when XAMCORE_4_0 is a thing they will get inlined in their
respective class
iOS 10 added a new `textFieldDidEndEditing:reason:` to `UITextField`. It
gets called, if set, before the older `textFieldDidEndEditing`.
This cause a problem for code that does add events for both since the
internal `*Delegate` does override both (to allow events) so the call
might be "lost" without additional logic.
This fix makes sure that even using one (or the two) events will work
across all versions of iOS.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=53174
* [Darwin] Fix kqueue/kevent bindings to actually work.
Fix kqueue/kevent bindings to actually work. The P/Invoke signatures were
badly broken (missing an argument), so there's no way this could ever have
worked.
Additionally obsoletes kevent signatures that return bool (they're ignoring
vital information: how many events were actually returned from kevent), and
add overloads that do the right thing.
* [Darwin] Improve input validation and add more tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=52570
In some cases you will find **static** members inside categories like in the following example:
```objc
@interface FooObject (MyFooObjectExtension)
+ (BOOL)boolMethod:(NSRange *)range;
@end
```
This will lead to an **incorrect** Category C# interface definition:
```csharp
[Category]
[BaseType (typeof (FooObject))]
interface FooObject_Extensions {
// Incorrect Interface definition
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
This is incorrect because in order to use the `BoolMethod` extension you need an instance of `FooObject` but you are binding an ObjC **static** extension, this is a side effect due to the fact of how C# extension methods are implemented.
The only way to use the above definitions is by the following ugly code:
```csharp
(null as FooObject).BoolMethod (range);
```
The recommendation to avoid this is to inline the `BoolMethod` definition inside the `FooObject` interface definition itself, this will allow you to call this extension like it is intended `FooObject.BoolMethod (range)`.
```csharp
[BaseType (typeof (NSObject))]
interface FooObject {
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
We will issue a warning (BI1117) whenever we find a `[Static]` member inside a `[Category]` definition. If you really want to have `[Static]` members inside your `[Category]` definitions you can silence the warning by using `[Category (allowStaticMembers: true)]` or by decorating either your member or `[Category]` interface definition with `[Internal]`.
- Significant changes to target file under msbuild, ImplicitFacade processing in particular
- Tests are disabled due to https://bugzilla.xamarin.com/show_bug.cgi?id=53164 where we can't tests local target files only global
- Requires a mono msbuild with 95ab657a90 for tests to pass
- Until then, this is a workaround:
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Roslyn/System.Reflection.Metadata.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/
* [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.
Sebastien Pouliot
Alex Soto
Timothy Risi
Jeffrey Stedfast
Rolf Bjarne Kvinge
Vlad Brezae
Chris Hamons
Marek Safar
Emanuel