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.
Add a default MAUI and a default Xamarin.Forms project as size comparison apps
(both created from templates).
This reveals that a MAUI app is ~30% bigger than a Xamarin.Forms app (42MB vs
31MB). Notably there's 21% *less* managed code, but 33% *more* native code.
https://gist.github.com/rolfbjarne/d294171969226f7511d90a817b9ac328
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
* Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource
items (if these files are found within the Resources/ subdirectory).
* Add support for a 'RegisterFont' metadata on BundleResource items, where if set
to 'true', we'll register the font file in the Info.plist as required by the target
platform.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
Context: https://github.com/dotnet/sdk/pull/19596
Context: https://github.com/xamarin/xamarin-android/pull/6184
If we use the version number string of `**FromWorkload**`, then our
runtime packages don't need to be resolved from a NuGet feed. They can
be resolved from the `dotnet/packs` directory.
This completely eliminates the need for a `NuGet.config` file when
building a .NET 6 app with a local build of xamarin-macios.
You will no longer need a feed such as:
<add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" />
To further clean things up, I removed the need for:
* Any NuGet feed named `local-dotnet-feed`
* `$(DOTNET_FEED_DIR)`
* Generation of `dotnet/Workloads/NuGet.config`
to make sure the latest locally build nuget are used
Also document `make strip-dotnet` as a time-saver to analyze the binary
assemblies produced for dotnet
* Add a configure option to use a locally built dotnet/runtime.
* Add documentation how to build dotnet/runtime the way we need it built.
* Modify our build to consume the custom dotnet/runtime if so configured.
This is useful when trying to debug the runtime locally, or trying out new
features there are no packages for yet.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
- Make git ignore the generated `report.md`
- Fix `.aotdata` reported total size in reports (was always 0)
- Add option to strip the dotnet app bundle (until [1]) so it's easier to compare with _oldnet_ sizes.
[1] https://github.com/xamarin/xamarin-macios/issues/11445
* [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.
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.
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.
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
Sebastien Pouliot
Chris Hamons
Jonathan Peppers