This fixes a problem where we'd build the same project reference from
dotnet-shared.csproj in parallel, and each build would stomp on eachother
(because we'll now clone the project references in dotnet-shared.csproj).
This als required updating project files to use MSBuildThisFileDirectory
instead of MSBuildProjectDirectory, which makes it easier for xharness to
inline/process these files, because MSBuildThisFileDirectory is easy to know
when processing a file, while MSBuildProjectDirectory depends on the calling
project, which complicates matters significantly.
A fix in MonoTouch.Dialog was also required.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@59fbf5b [dotnet] Shared project files don't need the DefaultTargets/ToolsVersion/xmlns attributes.
Diff: 4d0e0a9a5f..59fbf5bb1b
Fixes https://github.com/xamarin/maccore/issues/2527.
* Make the .NET project files for BundleResources and EmbeddedResources follow
the pattern of all the other test projects.
* Move the LangVersion and AllowUnsafeBlocks propertieso to the shared project
file.
I recently deleted the generated makefile support for building and running our
test suites. It turned out that it was used for building the packaged
Xamarin.Mac tests, so it wasn't as unused as I thought.
So fix the building and packaging of Xamarin.Mac tests to not use the
(non-existent) makefile targets, but instead replicate it with manual make
code.
Also take the opportunity to add packaging and execution of the .NET versions
of these test suites we execute on other macOS versions (both for macOS and
the Mac Catalyst).
* [devops] Use stricter matching when finding the Xamarin.Mac pkg link.
Otherwise the branch name in any package could end up matching the pattern we
were looking for:
XM_PACKAGE=https://bosstoragemirror.blob.core.windows.net/wrench/tests-package-xamarin-mac-tests/15759261d425ae08494b0a26862a0b1356c5f8ec/5268864/package/Microsoft.iOS.Bundle.15.0.101-ci.tests-package-xamarin-mac-tests.68.pkg
is just clearly wrong.
This fixes a problem where the build from the different projects could stomp
on eachother in the obj/bin folders. It's technically possible to make this
work by setting up custom [Base][Intermediate][OutputPath] properties in the
project files, but the simplest solution is to just make sure there's no more
than a single project per directory.
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
Manually added `NoBindingEmbedding` to bindings .csproj and removed
`[LinkWith]` attributes.
Also added support for NativeReference to harness and updated the
workaround for watchOS (since it can't link against ModelIO)
Fixed/adapted unit tests wrt change
Fixes: https://github.com/xamarin/xamarin-macios/issues/8265
Usage of `System.Drawing` types in iOS binding projects are failing with:
error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'.
This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
Consider adding a reference to that assembly.
In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS
and Mac projects, but mistakenly missing from binding projects.
I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`,
so it will be used for all project types.
I also updated a test, I could merely use `System.Drawing.Color` in
`StructsAndEnums.cs` to reproduce the failure.
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).
This has a couple of advantages:
* It makes it easier to add a catalyst version of these libraries (because it
becomes cumbersome to build for catalyst when the build rules assumes we're
building for both simulator and device).
* It makes it easier to create an xcframework of our libraries, because the
contents in an xcframework is split like this.
Fixes this test:
Xamarin.MTouch.AppAndExtensionWithBindingFramework: Expected execution to succeed, but exit code was 1, and there were 2 error(s): build app
error MT5210: Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
error MT5202: Native linking failed. Please review the build log.
* Add a server mode, which launches a web server (and a web page) that can be
used to interactively run tests and view their results.
* Add support for running test assemblies in a today extension (generating a
new set of projects, similar to how we generate tvOS/watchOS projects based
on the iOS project, we now generate a today extension project in addition to
the tvOS and watchOS projects).
* Load all the different tests (and show them in the html report, although
they show up as 'ignored'), even for disabled/ignored tests. This makes
disabled/ignored tests more visible, and also makes it possible to actually
run them using the embedded web server.
* Add support for running tests on device. Tests will be executed on multiple
devices simulatenously (any connected devices will be used).
Rolf Bjarne Kvinge
Sebastien Pouliot
Jonathan Peppers
Sebastien Pouliot