Some of the Jenkins test tasks are very useful and do A LOT of stuff. So
we try to generalize the base class, to later be able to share the most
usebul ones in the shared lib.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [xcode12] Bump to Xcode 12 Beta 4
* [Tests] Disable Trust_FullChain and Trust2_FullChain tests
These tests started showing a different error than the one we expect
I'll let our security expert chime in
Update the framework to include Xcode beta3 and add support for tvOS.
As of Xcode12 beta 3 it cannot yet be compiled on macOS X, please refer
to https://github.com/xamarin/maccore/issues/2261
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
* [MetalPerformanceShaders] Neural Networks Update to Xcode 11
This includes updates from PRs xamarin/xamarin-macios#6932, xamarin/xamarin-macios#6935 and xamarin/xamarin-macios#7461
It adds new functionality to the neural network components.
This is still not the complete API for 11.3
* Update src/metalperformanceshaders.cs
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Make changes requested by @rolfbjarne
* Fix binding of default random distribution creation
The parameterless function creates new
default distributions and is not a property.
It is a counterpart of CreateUniform.
* Expose public APIs for MPSCnnConvolutionTransposeNode
These APIs are public and documented at: https://developer.apple.com/documentation/metalperformanceshaders/mpscnnconvolutiontransposenode/2942641-initwithsource?language=objc
I have also tested that they work.
* Reintroduce compat API.
* Fix acronym casing.
* Fix introspection tests.
* Fix xtro.
* One last xtro issue.
* Fix more xtro.
* Another introspection fix.
Co-authored-By: Frank A. Krueger <fak@praeclarum.org>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Apply suggestions from code review
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Apply feedback
* Please the typo guardians
Co-authored-by: Frank A. Krueger <fak@praeclarum.org>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Added support for the Xcode 12 beta 2. There are a number of methods
that should be obsoleted, but have not been. Added issue
https://github.com/xamarin/maccore/issues/2265 to let apple now and
track it.
There is an issue in the linker warnings (https://github.com/xamarin/maccore/issues/2264) which makes our CI read. Added a workaround in the test for
the Xcode version until is fixed by Apple.
Includes support for `UTType`-based `[Field]` in the generator as an
hundred (or so) of them were added. Unit test shows the field-based
properties are working as expected.
There are two method not bound due to a dependency on AVAudioSession that
does not seem to be exposed on Mac OS X.
Related issue: https://github.com/xamarin/maccore/issues/2257
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We were using the managed name, e.g. `NSUrl`, instead of the native name,
e.g. `NSURL`, when dealing with categories.
To fix this we must resolve the type and this caused issues as other
assemblies (e.g. OpenTK) were not already loaded/cached and some type
could not be resolved (and this throw exceptions)
The runner now loads all assemblies before starting to visit them.
The fix solved a known issue (iOS-NetworkExtension.ignore), some API
that were already bound (common-Foundation.ignore) and also caught an
additional API where we missed a `[NullAllowed]` on a return value
* [arkit] Remove fields (from beta2) to fix introspection
* [tests][introspection] AVMutableMediaSelection is as bad as it's non mutable parent
* [tools] Update IsFrameworkBroken (remove CoreAudioTypes and MediaPlayer)
* [tests][monotouch-test] MKPinAnnotationView seems fixed in beta 2
* [tests][xtro] Update ARKit todo (with previous fix)
A number of APIs added and deprecated in the same release. We will see
that is that about.
The status property move to be a instance property in CLLocationManager,
we expose those and add a deprecation warning. That needs to be ignored in xtro due to issue https://github.com/xamarin/xamarin-macios/issues/9026
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Add crash reports to a logs collection we care about, instead of to a logs
collection that's promptly forgotten.
This makes sure crash reports actually show up in the html report.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [linker] Fix infinite queue found with nullability PR (#8337)
and removed previous workaround
Replace previous attempt https://github.com/xamarin/xamarin-macios/pull/8336
* [linker] Remove code to deal with ExportedTypes (#8632)
This is now supported by upstream mono/linker
* [linker] Remove internal [NullablePublicOnly] attribute from apps (#8568)
I've only seen it with .net5 so far but it's better handled in master
and flow back into the branch
* [linker] Update custom attributes that can be removed (#8535)
Some are no longer part of the SDK (or converted into new ones
at build time), others were new (and missing).
A full list of attributes and their usage frequency in what we ship can
be seen in https://gist.github.com/spouliot/ca03c6da7d4d75670ca77749350eb8a2
Also update tests: no need to check for removals of stuff that does not
exists anymore.
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
* [AppKit] NSTextView allows passing nil to PasteAsPlainText and PasteAsRichText.
This is documented in Apple's documentation, their headers, and even proved
experimentally.
* Update xtro.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
instead use `Buffer.MemoryCopy`.
Currently only used from `CGDataProvider`. Added unit tests for the
public/indirect, usage of the API (we had none).
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
The test has started failign more commonly, but only in a number of old
OS versions and not all the time. The function should return a new
Pasteboard, but it is true that we are not releasing the old ones,
meaning that the pasteboard is left after the app is done as stated by
the apple documenation.
The test has been updated to:
1. Release the pasteboard.
2. Be inconclusive if the pasteboard service could not create a new one.
fixes: https://github.com/xamarin/xamarin-macios/issues/8787
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Note: affected tools are not included in the code shipping inside the SDK
Usage of deprecated cryptographic algorithms is not approved anymore,
even if not used for cryptographic purpose.
MD5 was used to create immutable GUID since it's output is 128bits which
is just what a GUID wants as it's input (16 bytes). The same can be
achieved (even if a bit slower) with a newer/longer hash function
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1128148
As described in the issue, when the credentials for the base auth are set
to be empty the request reaches a timeout.
The inner issue is that when we have empty credentials the query that
is performed to the credentials db of the system throws an exception.
This exception is not raised to our code, but simply prints out in stderr.
When this situation occurs we get in an infinite loop in which we keep
sending the same credentials, we get another challenge, but the OS does
not do the right thing, we believe that we have to provide the creds
again (which are the same) and we get another challenge.. this goes on
an on until we reach the timeout.
Fortunately we know the number of failed challenges and the failure
response. With this information we can deduce if we already sent the
credentials, and if we did, do not set them again. In this case, the OS
sees no credentials in out delegate, uses the default handler and
correctly returns a 401.
fixes: https://github.com/xamarin/xamarin-macios/issues/8342
Fixes: https://github.com/xamarin/xamarin-macios/issues/8344
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Added nullability attributes to AVFoundation
* Revert AVPlayerItem FromAsset nullability attributes changes to keep existing tests passing and allow backwards compatibility
* Documents common-AVFoundation.ignore entry related to Foundation.NSNumber[] AVFoundation.AVVideoCompositionInstruction::get_RequiredSourceTrackIDs()
!extra-null-allowed! 'Foundation.NSNumber[] AVFoundation.AVVideoCompositionInstruction::get_RequiredSourceTrackIDs()' has a extraneous [NullAllowed] on return type
Co-authored-by: Cosmin Stirbu <stirbucosmin@gmail.com>
PR https://github.com/xamarin/xamarin-macios/pull/8184 removed the
inheritance with TextWriter, therefore the `as` will return null and we
will not generate the Html report. In this particular case, we do not
need an ILog, we just use it to get a path to the correct location,
therefore, we can create the file using the full path and pass it to the
xslt.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8364
VSMac has failing tests when they query the NSScrees.Screens property
which the following swift code shows that it can be executed in a diff
thread:
```swift
import Cocoa
import AppKit
DispatchQueue.global(qos: .background).async {
print("This is run on the background queue")
print(Thread.current)
var screens = NSScreen.screens
print (screens.count)
}
```
Fixes: https://github.com/xamarin/xamarin-macios/issues/8329
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
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).
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
Threading is hard, part 2. We could have a situation in which two tasks
that are instantiated async use the same id. The id is later used to
build the logs directory etc.. When they share the id we end up in a
situation in which the logs overlap.
fixes: https://github.com/xamarin/xamarin-macios/issues/8146
The testing framework dlls come from mono and their paths are harcoded
in the templates. Move the hardcoded paths out to the assembly locator
which know were to find the paths.
This is needed to later allow the cmd to pass the location of the paths.
The assets were being used from the bcl-test directory. Move them as
part of the template. Renamed a file to make things a little easier when
adding the assets (a '.' in the middle of the name made this
complicated).
The template should be selfcotained.
- Code that will later be moved to the `dotnet/xharness` repo is first moved to an isolated project before it will be extracted to the new repo and NuGetified
- New project for the shared code and new test project for tests accompanying the moved code are created
- Only Factories are left behind that are used only by XHarness
The Generator and the Factory classes are a xamarin-macios thing.
Initially, they were separated because the code that generated the bcl
tests was not inside xharness. That is not longer the case. We can merge
both classes, generalize the namespace and be more prepared to move out
of the xamarin-macios repo.
Threading is hard, even with async. We reached a situation in which the
src code of the test applications from the template was being generated
more than once. Ideally, we could have a nice solution with
AsyncLazy<bool> and use the lazy async to copy the code, but it was
moved to netcore 5. The fix is a little uglier but valid, lock and
enure we only generate it once. Please note that you CANNOT use a lock
statement inside a async method.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8240
Remove two classes that are not really needed and a method. We moved to
named tuples to make things simpler. Unfortunally C# does not support:
```csharp
using MyNamedTuple = (string Name, double value, bool answer);
```
But we have to live with this. Makes the namespace simpler and removes
confusion with the already present project classes that are more widely
used.
* [Harness] Remove the BCLTestProjectInfo class.
The class is not really needed. Move to a tuple, make the definition of
the group test project nicer since the dictionary initiallization makes
it cleaner.
Looks like we have cases in which we get empty nodes when listing
devices, which makes the parsing of the nodes fail and crash.
Move the code to a diff method, try to parse the data, if there is an
exception (missing data) return null. If null is returned, do not add
it.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8160
Looks like mono is not investing much time at the moment fixing
https://github.com/mono/mono/issues/18560
The above error happens always on 32b device tests. Added a new known
failure for the monitoring to use in their task so that they do not have
to goole the issue and they know that is knonw already.
Added a test in the xml parser that verifies that the parsing of the xml
is correct and that the correct number of failures is reported in the
human readable form.
fixes: https://github.com/xamarin/xamarin-macios/issues/8214
Remove two classes that are not really needed and a method. We moved to
named tuples to make things simpler. Unfortunally C# does not support:
```csharp
using MyNamedTuple = (string Name, double value, bool answer);
```
But we have to live with this. Makes the namespace simpler and removes
confusion with the already present project classes that are more widely
used.
Ignore a failing test on devices. Related mono issue: https://github.com/mono/mono/issues/19308
Mono has to fix the issue, so we ignore in the meantime.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Refactor result parsing and test it. Make sure that all the possible
corner cases are taken into account. The changes are as follow:
1. Move all the logic to a new class, which will take care of the reustl
parsing.
2. Simplify the parsing method by splitting the noise code to other
functions. There is no need to parse several files in the same method.
3. Add tests that make sure that the correct result is returned when:
a. The app cannot launch.
b. The app timesout.
c. The app crashes.
The _nice_ thing about `NSURLProtocol` is that it does not force the use
of the network - but we inflicted this upon us on tests.
So this updates the test to avoid the network, which should make it
more reliable and not so much influenced by the URL used or the OS
versions where it's executed.
This does not cover as much callback as before. However this it does
test that the NSUrlProtocol is registered correctly (what we care) and
the rest is largely only related the the OS (which is not the target
of our unit tests).
Hopefully fix https://github.com/xamarin/maccore/issues/1956
xcrun can print stuff to stderr even if it succeeds and prints what it found
to stdout, which means we have to separate stdout and stderr when capturing
xcrun's output.
This also means that we need a few changes to our RunCommand API:
* Add support for capturing stdout and stderr separately by providing
different callbacks/StringBuilder instances.
* Use overloads instead of default arguments, because with default arguments
we end up with ambiguous matches in a lot of places with the new overloads.
Fixes https://github.com/xamarin/xamarin-macios/issues/8147.
Backport of #8150.
This is not a complete solution, because it doesn't work when running device
tests, because then we don't build locally. On the other hand, that bug has
never been a problem for device bots, so hopefully that won't change in the
future.
Ref: https://github.com/xamarin/maccore/issues/2177
Manuel de la Pena
Alex Soto
Whitney Schmidt
Sebastien Pouliot
Rolf Bjarne Kvinge
Chris Hamons
monojenkins
Whitney Schmidt
Přemek Vysoký