Update the .NET unit tests to parse the binlog instead of standard output for
specific build output, since we're not printing a diagnostic build log to
standard output anymore.
This fixes numerous test failures in the .NET unit tests:
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest("watchOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBundledResources("iOS","monotouch"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildEmbeddedResourcesTest("iOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBundledResources("watchOS","monotouch"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest2("tvOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest("tvOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest("iOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBundledResources("tvOS","monotouch"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildMyTVApp: Linker did not executed as expected.
Expected: String containing "Building target "_RunILLink" completely."
But was: "Microsoft (R) Build Engine version 16.8.0-preview-20475-05+aed5e7ed0 for .NET [...]"
* Xamarin.Tests.DotNetProjectTest.BuildMySingleView: Linker did not executed as expected.
Expected: String containing "Building target "_RunILLink" completely."
But was: "Microsoft (R) Build Engine version 16.8.0-preview-20475-05+aed5e7ed0 for .NET [...]"
* Xamarin.Tests.DotNetProjectTest.BuildInterdependentBindingProjects("iOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildEmbeddedResourcesTest("tvOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest2("watchOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildFSharpLibraryTest("tvOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildFSharpLibraryTest("watchOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildEmbeddedResourcesTest("watchOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildBindingsTest2("iOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildInterdependentBindingProjects("tvOS"): Assemblies
Expected: not <empty>
But was: <empty>
* Xamarin.Tests.DotNetProjectTest.BuildFSharpLibraryTest("iOS"): Assemblies
Expected: not <empty>
But was: <empty>
Port the iOS/tvOS/watchOS msbuild test projects to .NET, and add a unit test
that builds both the old-style and new-style test projects and compares the
output in the resulting .app directories.
There are many expected differences in the apps, those will be ignored during
the comparison.
There are also numerous features that are not implemented yet in .NET, with
the corresponding adjustments in the comparison logic (they show up as TODO in
the code), these TODOs will be removed as features are implemented in the .NET
build.
There are a couple of test projects that can't be compared yet, because they
just don't build yet. Those are also TODOs.
Make the bgen tests pass in the path to the attribute library, platform
assembly and all the .NET reference assemblies to bgen. This way we execute
these tests using the .NET version of everything.
* [src] Build the .NET version of our product assemblies using a .NET 5 BCL.
We're not shipping the .NET product assemblies in any stable release, so we
can use a preview version of the .NET 5 BCL.
Also:
* Add all the nuget feeds we need to the top-level NuGet.config, even for .NET
5/6, there shouldn't be any conflicts with stable feeds since we use exact
version numbers.
* Generate a top-level global5.json which is copied to every directory that
needs a .NET 5 global.json (overriding the .NET 3.1 global.json in the root
directory).
* Use the expected dotnet binary during our local build.
* [tests] Fix the bgen tests to use .NET 5.
* [xharness] Set the current directory to the project directory when running .NET tests.
This way we end up using the dotnet version that's configured in global.json for the tests.
* [dotnet] Pass the Optimize flags from the extra bundler arguments to the linker configuration.
Also call Application.InitializeCommon to initialize the application instance. The
important part here is that InitializeCommon calls Optimizations.Initialize to compute
the default optimizations. It also calls Set*ExceptionMode and sets the default EnableCoopGC
value (so we don't need to call/set those anymore), and it does a few other initialization
tasks which we don't need yet, but eventually will.
And finally remember to parse the bundler arguments before using them in the dotnet
build logic. How did this not cause problems before? 🤦
* [tests] Set the verbosity using the additional args instead of an internal variable.
The internal _BundlerVerbosity variable is overwritten now (with the verbosity
value from the additional args).
* [xharness] Disable tvOS generation for the introspection/.NET test, it incorrect and needs fixing.
* Port the BundledResources test to .NET.
* Fix a minor issue in the BundledResources test to make sure it works on macOS.
* Add a unit test to make sure resources are bundled as expected.
* Modify the .NET build logic to bundle/unbundle resources.
* Bump .NET 5 and the linker.
The old linker run into a problem that seems fixed in the new linker, so bump.
* [tests] Add a workaround for a .NET bug in the fsharplibrary tests.
It's now the default to produce reference assemblies, but the F# compiler
doesn't support producing reference assemblies, so when there's no reference
assembly afterwards the MSBuild tasks complain. So explicitly disable
reference assemblies for our F# library.
* [tests] Skip reference assemblies when iterating over produced assemblies in the .NET unit tests.
Also simplify the code a little bit.
This happens because producing reference assemblies is now the default.
Put NuGet packages in tests/dotnet, instead of a directory next to the project
file, so that default item inclusions / globs don't pick up anything from
them.
This fixes an issue where the build would pick up a Program.cs that ships with NUnitLite,
and include it in the build, which would then cause build failures because that Program.cs
has a Main method, which would conflict with our Main method.
* [dotnet] Only pass a single custom step to the linker.
The linker will load the assemblies with the custom steps once per custom step
argument, which means that each step is effectively in a different assembly,
making it impossible to share state between steps.
This behavior is filed as a linker bug: https://github.com/mono/linker/issues/1314
Until this is fixed, we can just have a single step that injects all the other
steps programmatically.
* [tests] Adjust .NET tests according to new behavior.
This avoids a possible difference in behavior, because in our system
dependency check we verify that the system has a specific version (which might
succeed), but if we don't pick a specific dotnet version in global.json,
dotnet will pick the latest version, which may behave differently than the one
we have in Make.config.
Thus always use the exact same version, so that we don't run into a difference
in behavior between developers and/or bots.
* Create a simple Xamarin.Utils.Execution class that can handle all our
process execution needs:
* Captures or streams stdout/stderr (in UTF8).
* Supports async
* Supports a timeout
* Does not depend on any other source file we have, only uses BCL API.
* Have the execution helper classes from mtouch/mmp
(Xamarin.BundlerDriver.RunCommand) and the tests
(Xamarin.Tests.ExecutionHelper) use this new class.
* Some simplifications were made:
* All API that took a string array for the environment now takes a
Dictionary<string, string>.
* The Driver.RunCommand methods were split out to a separate file. This
file also contains a Verbosity field, which is conditioned on not being
in mtouch nor mmp, which makes including this file from other projects
simpler (such as bgen - in particular bgen was modified to use this
Verbosity field instead of its own).
* [dotnet] Detect, compile and publish Info.plist into the app.
* Automatically detect any property lists in the root project directory, and
include them into the build.
* Introduce the existing build targets to detect and compile Info.plist into
the .NET build.
* Add documentation for default inclusion. This document will grow over time
as more file types are automatically included.
* Add some tests.
* [dotnet] Adjust default inclusion behavior.
* Use a single platform-specific variable to control all types of
platform-specific inclusions.
* [dotnet] Move the default inclusion to .targets instead of .props, so that .NET's default inclusion logic is already imported.
.NET sets EnableDefaultItems in their .targets: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L16
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
Also add another nuget source to get Mono's net5 runtime packs.
This makes the tests/dotnet/MySingleView test app:
* Compile managed code successfully, referencing Xamarin.iOS.dll.
* Resolve the correct targeting and runtime packs (aka Mono).
The compiled result is not put into an .app bundle as iOS expects, so the
result isn't actually executable.
Also add a very simple net5 test app (which doesn't build yet).
Current (expected) build result:
> xamarin-macios/tests/dotnet/MySingleView $ dotnet build
Microsoft (R) Build Engine version 16.7.0-preview-20258-02+26f6d1d87 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.ios-x64 with version (= 5.0.0-preview.6.20264.1)
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in nuget.org [ Nearest version: 5.0.0-preview.4.20251.6 ]
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in Nuget Official [ Nearest version: 5.0.0-preview.4.20251.6 ]
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in local-dotnet-feed
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in Dotnet arcade
Failed to restore xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj (in 951 ms).
This fails because the .NET build logic isn't being told that it should look
for the mono runtime packs instead of the .NET Core runtime packs.
Rolf Bjarne Kvinge
Manuel de la Pena