* Don't load maccore/mk/versions.mk anymore, which means we're not checking
any subsequent dependencies listed in maccore. Note that we still need the
maccore dependency itself for a little while longer.
* Remove some outdated testing code that called into maccore.
* Don't recurse into the maccore directory during make.
* Remove some code checking for ENABLE_XAMARIN that's not used anymore, in
particular in xharness.
Download mlaunch from NuGet instead of building from maccore, and copy the
downloaded files into the packages we ship (both legacy Xamarin's pkg and .NET
nupkgs).
Eventually we'll want to reference the mlaunch NuGet from the .NET nupkgs, but
that's a later step.
Remove our dependency on Visual Studio. Use the 'dotnet-t4' tool instead of
invoking the t4 tool embedded in Visual Studio.
Fixes this build error after installing VS Mac 2022:
> Cannot open assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe': No such file or directory.
Switch to getting mono-api-[info|html] from a newly created repository we
control and where we can easily fix issues, since mono/mono isn't getting many
fixes anymore. In the past I know I've been reluctant to look at these tools,
just because of the hassle of setting things up to debug, and then the
paperwork to get the fixes in mono/mono, and then backported to the branch
where we need them.
This repo has a few other benefits:
* The tools are built using normal projects, which means they're easy to debug
in an IDE (mono/mono's code has generated project files, which used in-tree versions
of the BCL, and it got quite complex quite fast).
* One fewer dependency on the mono archive, so we're getting closed to be able
to drop it completely when we drop support for legacy Xamarin.
* #13669 is already fixed there.
* It contains a few other misc fixes.
Fixes https://github.com/xamarin/xamarin-macios/issues/13669.
New commits in mono/mono:
* mono/mono@f34bd77e39 [2020-02][Android] Workaround for invalid return value from clock_nanosleep
* mono/mono@0f5e80e577 Disable ClientWebSocketTest tests that started failing for no reason
Diff: 4efc825e83..f34bd77e39
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
New commits in mono/mono:
* mono/mono@4efc825e83 [Tools] Fix mono-api-html MarkdownFormatter.cs to avoid a NRE
* mono/mono@6171c87180 vtable setup fix for generic default interface methods in mono runtime
* mono/mono@148f536b0b [2020-02] [AOT] Use .short directive instead of .hword
* mono/mono@a6f3e8f179 Avoid an assert in ves_icall_RuntimeFieldInfo_SetValueInternal
* mono/mono@3c4f3de377 Add correct InetAccess category to HttpClientTest.Proxy_Disabled test and disable Ping tests
* mono/mono@9f35bf1b80 Add missing handle function enter/return macros
Diff: 45efaa3b6f..4efc825e83
In .NET, all files that should be published (put into the final .app bundle) are put into the @(ResolvedFileToPublish) item group, and at the end of the build process, .NET will publish all the files in that item group. Which files are in this item group, and how they're put in there, is out of our control (it's just how the build process works in .NET), so we'll have to cope.
Additionally, publishing an app for Apple platforms is different than publishing other .NET apps, because we can't just put all the files in the a directory like .NET usually does, we have a fairly strict directory structure we need to follow, and it also differs between platforms (the structure is different between macOS and iOS for instance).
This means that for every file in the `ResolvedFileToPublish` item group, we have to figure out:
* Should it be put into the app bundle in the first place?
* If so, in which subdirectory (if any)?
This PR implements these changes. The exact details are explained in a document in the PR, but the general logic is:
* We make an educated guess for some types of files we know about (assemblies, unmanaged libraries, images, etc).
* We provide a way to set metadata on each item specifying which type of item it is (assembly, unmanaged library, image, etc), and we'll treat the item as such. This method can also be used to override the guess we made (for files that shouldn't be published for instance).
* We warn if we run into files we're not educated enough to be able to guess about, and for which there's no custom metadata set.
Fixes https://github.com/xamarin/xamarin-macios/issues/12572.
New commits in mono/mono:
* mono/mono@b8d7525156 [2020-02] [cominterop] Add coop handle enter/return on native CCW methods
* mono/mono@2ca650f1f6 [2020-02] Adds full path to libcairo for correct assembly directory resolution in monterey
* mono/mono@e750cb3ee5 [aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking.
* mono/mono@b32801a63c Remove NuGet.config
* mono/mono@dfcef74640 Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well.
* mono/mono@5ce143a1a8 Revert "[2020-02] Start a dedicated thread for MERP crash reporting (mono/mono#21126)"
Diff: 4150e65c9e..b8d7525156
* 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'
Alex Soto
Rolf Bjarne Kvinge
Manuel de la Pena