We used to do the following:
1. Have abstract task classes in the Xamarin.*.Task.Core assembly (with all
the actual code for the task in question to work properly on macOS).
2. Subclassed task in the Xamarin.*.Task assembly, which did nothing.
3. On Windows we'd inject a different Xamarin.*.Task assembly, with
Windows-specific overrides for the implementation in the abstract base
class.
However, we no longer do point 3, which means that we no longer need to split
our tasks across two assemblies.
This means that we can remove the Xamarin.\*.Task.Core assemblies, and move all
the code into the corresponding Xamarin.\*.Task assembly instead.
This simplifies our code and speeds up the build.
There are more simplifications that can be done; those will come in later PRs.
NuGet seems to struggle with the network on the bots for this particular test,
so ignore the test if there are any nuget failures.
Fixes https://github.com/xamarin/maccore/issues/2612.
* Update dependencies from https://github.com/dotnet/runtime build 20220727.6
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.8
* Update dependencies from https://github.com/dotnet/runtime build 20220727.6
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.8
* Update dependencies from https://github.com/dotnet/runtime build 20220813.7
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.8 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220815.11
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220816.8
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* Update dependencies from https://github.com/dotnet/runtime build 20220819.3
Microsoft.NETCore.App.Ref
From Version 6.0.8 -> To Version 6.0.9
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.9 (parent: Microsoft.NETCore.App.Ref
* [tests] Adjust InvalidRuntimeIdentifier_Restore to expect failure for Mac Catalyst.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes these compiler warnings:
xamarin-macios/src/ObjCRuntime/ErrorHelper.cs(22,17): warning CS0436: The type 'ProductException' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs' conflicts with the imported type 'ProductException' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
xamarin-macios/tools/common/error.cs(10,34): warning CS0436: The type 'ErrorHelper' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs' conflicts with the imported type 'ErrorHelper' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
When working on the bindings we can use the "AUTO_SANITIZE" env var to
let xtro know that we want the lines that have been fixed to be removed,
unfortunatly this mode has a bug. When we autosanitized we should do the
same as the skip and not return the lines that have been cleaned as the
return code.
Returning the error code meant that when we did make all, the
first target (classic) would work, but the second target would not
because the first one failed.
Doing this allows to work on the bindings and have AUTO_SANITIZE work
both for classic and dotnet when doing make all.
Fixes these test failures:
Xamarin.MTouch.FastDev_LinkAll(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll_Then_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll_Then_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkSDK(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkSDK(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkWithTest(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkWithTest(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkAll(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkAll(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_Sim(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_Sim(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.RebuildWhenReferenceSymbolsInCode: System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
This allows the CI to run ALL the tests that the project has in
parallel. This is divided in two main changes:
1. Xharness - We move away from using boolenas to use a flag that states
the tests to run.
2. yaml - We have move the code to use a template per label. This new
jobs all run in parallel and the results are later collected by a
funel job
3. pwsh - Added a new class that understands that we have several mark
downs with the tests results. The classes parses them and them writes
a single comment (and example can be found here: https://github.com/xamarin/xamarin-macios/pull/15201#issuecomment-1162366240
The changes gives the following advantages vs how we used to run tests:
1. The CI run for all tests moves from taking 13 hours to 3/4 hours
(depending on the number of bots in the pool).
2. The download needed to verify the results on a case of failure is
smaller. Rather than downloading several GBs we now just download
that part of the html that we are interested in.
3. Better bot utlization. Bots are just used to a max of 2 hours, this
means that we can use the bots better since they are fragmented.
4. Less VMs. VSDrops has added support for macOS and Linux, we take
advanges of that here.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Collect diagnostic logs from the simulator to try to get better diagnostic information for https://github.com/xamarin/maccore/issues/2558.
Interestingly it seems like just collecting diagnostic information makes the problem much less likely to occur...
Tests work because other tests do use the nugets and gets picked up by
the runner. Yet, if we execute this projects witjout others, the tests
will fail when trying to use the nunit2 format.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This makes it not necessary to check for the currently selected Xcode in our
system dependency check. It also means it'll become much easier to work with
multiple branches simultaneously where each branch needs its own Xcode.
When we changed SCNMatrix4 to be column-major instead of row-major in .NET, there
were several other related changes we should have done but didn't do. In particular
we should have made transformation operations based on column-vectors instead of
row-vectors.
In legacy Xamarin, a vector would be transformed by a transformation matrix by doing
matrix multiplication like this:
[ x y z w] * [ 11 21 31 41 ]
| 12 22 32 42 |
| 13 23 33 43 |
[ 14 24 34 41 ]
In this case the vector is a row-vector, and it's the left operand in the multiplication.
When using column-major matrices, we want to use column-vectors, where the vector
is the right operand, like this:
[ 11 21 31 41 ] * [ x ]
| 12 22 32 42 | | y |
| 13 23 33 43 | | z |
[ 14 24 34 41 ] [ w ]
This affects numerous APIs in SCNMatrix4, SCNVector3 and SCNVector4:
* The M## fields have been changed to make the first number the column and the
second number the row, to reflect that it's a column-major matrix (this is
also how it's defined in the native SCNMatrix4 type).
* Functions that return a transformation matrix have been modified to return column-vector
transformers. Technically this means that these matrices are transposed compared
to legacy Xamarin. The functions involved are:
* CreateFromAxisAngle
* CreateRotation[X|Y|Z]
* CreateTranslation
* CreatePerspectiveFieldOfView
* CreatePerspectiveOffCenter
* Rotate
* LookAt
* Combining two column-vector transforming transformation matrices is done by multiplying
them in the reverse order, so the Mult function (and the multiplication operator)
have been modified to multiply the given matrices in the opposite order (this matches
how the SCNMatrix4Mult function does it). To make things clearer I've changed the
parameter names for XAMCORE_5_0.
* Functions that transform a vector using a transformation matrix have been modified
to do a column-vector transformation instead of a row-vector transformation. This
involves the following functions:
* SCNVector3.TransformVector
* SCNVector3.TransformNormal
* SCNVector3.TransformNormalInverse
* SCNVector3.TransformPosition
* SCNVector4.Transform
* Numerous new tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/15094.
This was mostly a clean merge, with a few minor differences:
* We no longer compute whether we're running in the simulator or not when building for Mac Catalyst.
* The task now supports building remotely for macOS (due to code sharing).
Will be useful if we ever support building macOS apps remotely.
* We now call AppleSdkSettings.Init () on macOS. No idea why we weren't
before, but it seems logical for macOS to behave like our other platforms.
There shouldn't be any other functional differences.
* Validating Null ignores and adding tests
* add nullability
* use is null
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Ignore anything Chip-related, the framework was removed from macOS.
* Fix reporting errors some protocol-related errors so that they're actually
reported as errors (by calling 'ReportError' instead of just adding the
errors to a list that doesn't affect anything else).
* Ignore the NSUserActivityRestoring protocol, according to the macOS headers
it's attached to NSResponder using a category, which is invisible at
runtime. Due to the previous point this didn't show up before, but once at
least another error (which happened with the Chip framework), then this was
listed as well.
* Add ignores for a couple of protocols.
Fixes https://github.com/xamarin/xamarin-macios/issues/15229.
Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
These changes correct some of the nullability attributes for the UIKit bindings. Although UIKit has several hundred lines of xtro-sharpie ignores related to nullability, this PR only fixes a few of them.
I wasn't sure where to draw the line, but in the end, I essentially fixed most of `UIViewController` and all of `UITableView` and `UICollectionView`. These classes were the ones that led to the most `// ReSharper disable` comments being added in my team's codebase, and/or that led to crashes being introduced by devs following ReSharper's suggestions to remove "unnecessary" null-checks.
These changes were largely based on the instructions given by @spouliot in [#6154](https://github.com/xamarin/xamarin-macios/issues/6154#issuecomment-620014843). However, I noticed the xtro-sharpie ignore files have been duplicated in the `api-annotations-dotnet` directory since then, so I updated the .ignore and .todo files in that directory as well.
If the process has changed since that comment was written, I can make any additional changes that are needed.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Haritha Mohan
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Marius Ungureanu
TJ Lambert
Manuel de la Pena
Ryan Pendleton