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.
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).
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]`.
* [generator] Have WrapAttribute generate virtual members
WrapAttribute now has a boolean optional parameter named isVirtual,
this instructs the generator to add the virtual keyword to generated
members.
This is useful when fixing breaking changes so we can keep the wrong
signature generated instead of having manual code files.
* [docs] Add docs about virtual to WrapAttribute
Warn if mtouch loads an assembly from a different location than requested
(which might be because there are multiple assemblies with the same name).
Also rework the MT0023 check a bit by explicitly loading the root assembly
first, and then detecting if any loaded assemblies matches the root assembly.
This results in code that's a bit more obvious, and it also works correctly
with extensions (previously the entire MT0023 check was skipped for
extensions).
The AOT-compilation occurs in the AOT-task now, and then we compile the result
using CompileTask.
This means that the error message in CompileTask was slightly incorrect, so
rectify it.
Create a custom AssemblyCollection class that contains a dictionary with
assembly identity (name) -> Assembly mapping.
This also means that we can detect if we end up loading multiple assemblies
with the same identity, and show an error in that case (even if that case
should never happen since we cache assemblies based on the identity, it's nice
to have code that ensures it).
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=52238
If you give mtouch/mmp a linker xml file with bad input for
example a Xamarin.iOS app and the linker.xml has a reference
to Xamarin.Mac instead of X.I.dll i.e.
<?xml version="1.0" encoding="UTF-8" ?>
<linker>
<assembly fullname="Xamarin.Mac">
<type fullname="ObjCRuntime.Constants"/>
</assembly>
</linker>
You will get a not so helpful generic error
MT2001 Could not link assemblies. Reason: Failed to process XML description: <unspecified>
It seems that when you use a xml file for linker you get a
`XmlResolutionException` from cecil when it fails to resolve
and the better error comes from the inner exception so we use
that instead.
New error output for XmlResolutionException:
MT2017: Could not process XML description: Failed to resolve assembly: 'Xamarin.Mac, Culture=neutral, PublicKeyToken=null'
Most projects building to bitcode (any kind of bitcode, this includes the
marker-only version as well), will fail to link when linking with third-party
libraries and incremental builds are enabled.
So automatically disable incremental builds when we detect this scenario.
This is only a workaround until we can make this scenario build correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [generator] Add BindAs support for NSValue and NSNumber
https://trello.com/c/RYCPEnkh
The intent of BindAs attribute is to have a binding definition as
[return: BindAs (typeof (bool?))]
[Export ("boolMethod:")]
NSNumber BoolMethod (int arg1);
and our generator outputs
[Export ("boolMethod:")]
public virtual global::System.Nullable<bool> BoolMethod (int arg1) { ... }
So we internally do the NSNumber <-> bool conversion, this also
applies to properties, parameters and methods.
* [generator] Fix a small formating issue
* [tests] Add BindAsAttribute generator tests
* [generator] Implement @spouliot's feedback
* [tests] Add BI1048 and BI1049 error tests for [BindAs]
* [generator] Implement Rolf's suggestion to avoid almost all string comparisons in [BindAs] for types
* [generator] Add BindAs support for smart enums and arrays with tests
* [generator] Some code clean up and implementation of PR feedback
* [generator] Add Protocol|Model checks and tests also a NRE check in NSArray creator
BindAs attribute cannot be used in Protocol|Model interfaces
* [generator] Add NSNumber <-> Enum support
* [docs] add BindAs documentation
* [docs] Implement documentation feedback for BindAs
This allows mtouch to give better error message when something unexpected
occurs in the linker pipeline (at least for the sub-steps).
Practically it means fewer, contextless MT2001 errors. The replacements
error code are more precise, e.g.
* what was being done;
* what was being processed
and helps both diagnosing and, possibly, gives clues for workarounds
* [Doc] Introduce xamarin-analysis-doc-tool
This tool is responsible of producing the xamarin-analysis.md file which is
our Xamarin.Analysis rules documentation.
It will always override the content of the previous xamarin-analysis.md file.
We generate the documentation based on the existing rules in xamarin-analysis/shared/Xamarin.Analysis/Xamarin.iOS.Analysis.targets
Trello: https://trello.com/c/mKsUDti8
This adds a new overload to our Notifications class
Current:
public static NSObject ObserveDidStart (EventHandler<NSNotificationEventArgs> handler)
New overload:
public static NSObject ObserveDidStart (NSObject objectToObserve, EventHandler<NSNotificationEventArgs> handler)
This allows our users to have single object subscription to our
easy to find notifications.
Also this commit adds an Advice attribute encouraging to use the
Notifications class instead of the NSString based notifications
- `LoggingExtensions` has a new `MTError` extension method that helps generate
an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
The old `legacy` option will now be reported as a warning.
That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE).
This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls
Note: The BCL changes will happen in later stages.
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.
So make it a warning instead (and document what the user has to do to fix the
warning).
https://bugzilla.xamarin.com/show_bug.cgi?id=46552
Sebastien Pouliot
Vincent Dondain
Alex Soto
Rolf Bjarne Kvinge
Vincent Dondain
Vincent Dondain