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.
Add support for 'dotnet pack', by:
1. Add a workaround for the fact that as soon as a project has a
'NativeReference' item, .NET's MSBuild logic wants to include a
'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks,
because we don't create such a file, so we work around it by removing the
file in question from the corresponding item groups.
2. Add any binding resource packages to the NuGet.
3. Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
Augment the CreateBindingResourcePackage to support creating a zipped binding
resource package (which is just a zipped version of the binding resource
package). This can either be manually chosen by the new 'Compressed' property,
or automatically detected (create a zipped version when there's a symlink in
the binding resource package).
The default is to not create a zipped version in legacy Xamarin, and
automatically detect for .NET.
The problem this is trying to solve is when creating a NuGet package - NuGet
doesn't handle symlinks correctly and it's not possible to create a NuGet with
symlinks. Instead we need to create a zipfile with all the binding resources.
The default has been chosen so that we automatically create a zip file when
it's required for .NET, while still maintaining old behavior with legacy
Xamarin.
We don't need to compile project-level assets for every RuntimeIdentifier in
multi-rid builds, we can instead compile them just once in the outer build.
There is also a correctness issue here: we can't compile assets more than once
and expect to get the exact same compiled result every time (in particular
actool seems to be adding random bytes in to the compiled output), and this
creates a problem when trying to merge the different runtime-specific compiled
output into a universal binary.
We accomplish this by:
* Processing these assets in the outer build, before we execute the
rid-specific inner builds.
* Store the paths to the assets we've processed in a file.
* In the inner builds, we read that file, and remove any matches from the
corresponding item group.
* Make sure to copy the compiled assets to the app bundle at the end of the
outer build.
These are the assets we currently handle this way:
* BundleResource
* ImageAsset
* InterfaceDefinition
* SceneKitAsset
* Collada
* TextureAtlas
* CoreMLModel
Also:
* Add a new test case (AppWithResource) that contains all these different
types of assets.
* Add support for the ScnTool task on Mac Catalyst (which the new test case
revealed was missing).
Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
* MTLCopyAllDevices returns a retained object, so we need to release it.
* MTLCopyAllDevicesWithObserver returns an observer (no need to provide one). This
means we can obsolete the 'ref NSObject' overload (the API doesn't make sense),
and instead add an 'out NSObject' overload.
* The returned observer from MTLCopyAllDevicesWithObserver is retained, so we must
release it.
* The returned array from MTLCopyAllDevicesWithObserver is a retained object, so
we need to release it.
* Simpify the supporting block code for the calls to MTLCopyAllDevicesWithObserver.
* Clean up the block we passed to MTLCopyAllDevicesWithObserver.
We need to strongname our MSBuild assemblies, so that different versions
can be loaded side-by-side (one example being having both a legacy and a
.NET project in the same solution).
This required setting a version for Xamarin.iOS.Tasks.dll and
Xamarin.Mac.Tasks.dll, otherwise strong-naming won't work properly (all
versions of an assembly would have the same identity).
Also sign the corresponding test assemblies, since they poke into the
internals of the task assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/9835.
Removes the following warning during the builds:
```
warning CS8767: Nullability of reference types in type of parameter 'host' of 'bool NSHost.Equals(NSHost host)' doesn't match implicitly implemented member 'bool IEquatable<NSHost>.Equals(NSHost? other)' (possibly because of nullability attributes)
```
Test was added to ensure that we did not throw an exception.
- Added the marshaling attr and a test to ensure it is ok.
- Fix the cecil MarshalAs test to not skip over types when checking.
This revealed multiple tests failures that needed fixing.
fixes: https://github.com/xamarin/maccore/issues/2519
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
For executable projects, we must run the linker (otherwise we won't produce
something that can be executed).
We'll enable the linker by default in these cases, but if the developer has
manually disabled the linker (if the linker fails to execute for any reason,
it will suggest that the developer disables it), then we should show an error
explaining why.
Fixes https://github.com/xamarin/xamarin-macios/issues/12372.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@9e6e29f [Xamarin.MacDev] Return valid iOS/macOS versions when converting betweeen iOS and macOS versions for Mac Catalyst.
Diff: 41d91e0de0..9e6e29f2a4
This PR resolves a crash when running the linker on publishing iOS extensions.
The crash would occur here in failing to resolve corelib.
The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies.
This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib.
After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish.
_ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true'
Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target.
This means we'd fail to set SelfContained until after the condition, and not run.
This was verified by setting /p:SelfContained=true to true.
I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
Properly synchronize access to the current writer in the generator tests'
ThreadStaticTextWriter class.
Should fix this random failure:
Error Message:
System.NullReferenceException : Object reference not set to an instance of an object.
Stack Trace:
at Xamarin.Tests.ThreadStaticTextWriter.WriteLine(String value) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 478
at System.IO.TextWriter.SyncTextWriter.WriteLine(Object value)
at System.Console.WriteLine(Object value)
at Xamarin.Tests.BGenTool.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 235
at Xamarin.Tests.BGenTool.AssertExecute(String message) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTool.cs:line 207
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, IEnumerable`1 references, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 780
at GeneratorTests.BGenTests.BuildFile(Profile profile, Boolean nowarnings, Boolean processEnums, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 766
at GeneratorTests.BGenTests.BuildFile(Profile profile, String[] filenames) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 756
at GeneratorTests.BGenTests.VSTS970507() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/generator/BGenTests.cs:line 650
Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
It's not tested, and thus has probably already bitrotted. If we add support
for watchOS to .NET in the future, it would likely be easier to start from
scratch (copying some of the other platforms), than having incomplete and
bitrotted code.
* 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.
We either use the html web page, or for .NET tests there are custom makefile
logic.
This avoids having to maintain the makefile generation to keep up with our new
tests, and it fixes numerous warnings like this:
Makefile-mac.inc:56: warning: overriding recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:41: warning: ignoring old recipe for target 'build-mac-modern-macOS'
Makefile-mac.inc:59: warning: overriding recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:44: warning: ignoring old recipe for target 'clean-mac-modern-macOS'
Makefile-mac.inc:62: warning: overriding recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:47: warning: ignoring old recipe for target 'exec-mac-modern-macOS'
Makefile-mac.inc:65: warning: overriding recipe for target 'run-mac-modern-macOS'
Makefile-mac.inc:50: warning: ignoring old recipe for target 'run-mac-modern-macOS'
MonoTouch.NUnit.UI.MacRunner.MainAsync will try to invoke things on the main
thread, and at the same time execute a runloop, and if the runloop isn't
executing on the main thread, we end up with a deadlock, where we keep waiting
on the main thread to process stuff enqueued by the background thread, while
the main thread is waiting for the background thread to finish.
Solve this by fixing the F# code to call
MonoTouch.NUnit.UI.MacRunner.MainAsync on the main thread.
Rolf Bjarne Kvinge
Chris Hamons
Manuel de la Pena
Rachel Kang
TJ Lambert
Alex Soto
Sebastien Pouliot