In particular NUnit uses reflection to get a private method, and the linker removes
the corresponding private method:
1c680b4dc8/src/NUnitFramework/framework/Internal/TestExecutionContext.cs (L552)
So add an xml definition to keep this private method, and modify project files to
pass the xml definition to mtouch and mmp.
Some care needs to be taken to make sure xharness is still able to clone these project
files.
* Touch.Client references the official NUnitLite package, which means we're using
a non-forked version of NUnit.
* This makes it easier for our .NET 5 effort, since we won't have to port an ancient
version of NUnitLite to .NET 5 (nor will we have to keep using it in our existing
code, we can use more modern NUnit patterns).
* Reference MonoTouch.Dialog from the NuGet package. This also eases the .NET 5 effort,
since we won't have to port MonoTouch.Dialog to .NET 5 (we'll probably still do it
though at some point, but it doesn't have to be done right away), nor build it
ourselves / ship it.
* initial imagio bindings + test project
* remove sample files, update xtro
* clean up
* add new line at eof
* even more cleanup...
* update based on PR feedback
* reformat according to coding standards
* fix all feedback except monotouch tests
* add monotouch-test files
* fix test feedback
* fix PR feedback
* fix timeout in tests, add asserts for status, update return value for APi to CGImageAnimationStatus enum
* fix == asserts
* respond to more pr feedback
* add StrongDictionary, remove Partial
* NSNumber -> nuint for NSUInteger
* add smaller gif
* remove hack.gif from project
* add gif to csproj
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
In iOS 13 it's no longer possible to get PACs from file:// urls (this is
explained in the release notes, so it's expected). So launch a local
httpserver and serve the PAC that way.
- Beta 3 fixed the umbrella header (https://github.com/xamarin/maccore/issues/1781) so the API, from beta 1, are now included
- `NSAttributedString` additions are a category (in ObjC) with only static members so they were inlined in Foundation (as suggested by btouch)
- `NSReadAccessURLDocumentOption` does not seem to work like the headers mention (waiting for real doc to appear). Unit test added.
* [Metal] Sprinkle [return: Release] on all 'new*' selectors. Fixes#5941.
Also add tests for all the API I could figure out how to use.
Fixes https://github.com/xamarin/xamarin-macios/issues/5941.
* [tests] MTLFunctionConstantValues didn't have a default ctor until Xcode 9.
* [tests] Use a higher offset when calling MTLBuffer.CreateTexture to try to comply with the requirements for the API.
Hopefully fixes this assertion:
> 07:42:06.7701360 validateStrideTextureParameters:1512: failed assertion `Linear texture: bytesPerRow (64) must be aligned to 256 bytes'
which doesn't happen on my machine.
* Fix whitespace.
* Simplify nested usings.
* Fix availability correctly.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
I obsoleted `GetProjectPoint` in favor of `Project` because of the introduction of `Unproject` (which made me realize the naming was wrong) and based on the API doc https://developer.apple.com/documentation/arkit/arcamera/2923538-projectpoint?language=objc.
The `CGPoint` returned is the projection of a point. An other naming option would have been `GetProjectedPoint` but I think `Project` is closer to the original and clear enough. You project/unproject something onto something else and you get the projection back.
The original, now obsoleted, `LocalizedString` API returned a .net
`string` which does not work in most cases.
Different versions of iOS seems to return different (public or internal)
subclasses of `NSString` that are understood by other API (like NSString
`localizedStringWithFormat:`) for further customization.
Our logic to convert NSString to string is correct but it cannot
recreate the custom, required subclass to continue the localization.
So the new API return an `NSString` publicly (which is actually a
subclass) that can do the required job.
Adding a test in monotouch-test is presently blocked by #3265 [2]
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41292
[2] https://github.com/xamarin/xamarin-macios/issues/3265
* Add tests for new (and old) NSBundle API and adjust old ones since adding a Base.lproj directories changes things
* Add localization to xammac_tests since it shares the same, updated tests
monotouch-test has a wildcard to automatically include new test files, but
this should not include generated files, because:
* The generated files are generated when needed, which means we can't rely on
the wildcard to trigger their generation, because the wildcard won't find
them before they exist, and as such msbuild won't detect that they're
needed.
* This means the generated files must be listed separately, but in that case
they shouldn't be found by the wildcard too, because that leads to:
/Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.CSharp.Core.targets(84,5): error MSB3105: The item "ObjCRuntime/TrampolineTest.generated.cs" was specified more than once in the "Sources" parameter. Duplicate items are not supported by the "Sources" parameter.
So move the generated files to a different directory, so that the wildcard
doesn't find them.
Fix tests causing trouble for the AOT compiler by not building those tests on
device (they're testing error conditions in the simulator, which means it's
acceptable to exclude these tests for device builds).
This fixes an AOT-compiler assert:
> * Assertion at /Users/builder/data/lanes/1381/d264709b/source/xamarin-macios/external/mono/mono/metadata/marshal.c:8497, condition `sig->param_count == invoke_sig->param_count + 1' not met
due to invalid [MonoPInvokeCallback] attributes.
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`.
The following types will be used by ModelIO bindings
* Fix delta to be double
* Rename Simd-compatible matrices and vectors to match our final naming.
This also means removing the new Vector2 and Vector4 variants (but not
Vector3).
This also requires implementing the corresponding matrix (NMatrix4x3).
Fixes this xtro issue:
> !unknown-simd-type-in-signature! OpenTK.Matrix3 AVFoundation.AVCameraCalibrationData::get_GetIntrinsicMatrix(): the native signature has a simd type (matrix_float3x3), while the corresponding managed method is using an incorrect (non-simd) type.
* Rename them to be OpenTK.NMatrix# (instead of Simd.MatrixFloat#x#).
* Remove the Vector2 and Vector4 variants, we'll use the OpenTK types instead (but we'll keep the NVector3 variant, since it's not identical to the OpenTK version).
* Update the API to match their OpenTK counterparts better:
* NMatrix2 and NMatrix3 have a 0-based R#C# scheme for their fields.
* NMatrix4 has a 1-based M## scheme for its fields (i.e. no change).
https://bugzilla.xamarin.com/show_bug.cgi?id=59433
While fixing bug 59433 I noticed some additional issues outlined below:
AVDepthData:
* Renamed **non** static `Create` methods because `Create` only
makes sense with the **Static** method in this context. Also
by renaming the methods we are now closer to the names that
swift uses.
* Kept descriptive method names in favor of self-documenting code.
`Convert`, `Apply` and `Replace` do not fully give us the intent
of the method.
* Added a convenience `Create` static method that takes a
`CGImageAuxiliaryDataInfo`.
* AvailableDepthDataTypes is now an array of `CVPixelFormatType` instead
of a `NSNumber` array (The aactual fix for bug 59433).
ImageIO:
* Refactored `CGImageAuxiliaryDataInfo` to be a `StrongDictionary` in order
to avoid most of the manual code and also to avoid reimplementing
the `ToDictionary` method (which contained a subtle bug).
* Adjusted code to reflect the above change.
* Added missing `.ctor (IntPtr, bool)` to `CGImageMetadata` so the class
is able to be created by our `Runtime.Get*`.
* Simplified `CopyAuxiliaryDataInfo` method by using `CGImageAuxiliaryDataInfo`
as a `DictionaryContainer`.
Tests:
* Added `xamarinmonkey.heic` which is an image that contains depth data needed
to test above changes.
* Adds `AVDepthDataTests` that touches most of the changes listed here.
- Fixes bug #59363: Missing UIPasteConfigurationSupporting, UITextPasteConfigurationSupporting, UITextDraggable and UITextDroppable on a couple of types
(https://bugzilla.xamarin.com/show_bug.cgi?id=59363)
* [uikit] Remove 129 types in UIPasteConfigurationSupporting case
* Implement Simd vector types (VectorFloat2/3/4/VectorInt4).
* [ARKit/Vision] Use the new simd vector types instead of the OpenTK versions.
* [ModelIO] Use the new simd vectors in new API (MDLVoxelIndexExtent2).
This way we won't have to create a MDLVoxelIndexExtent3 in the future.
* [SpriteKit] Use the new simd vectors in new API.