* [net6] Fix ILStrip'ed apps to actually work again
- In a late minute change to the ILStrip PR (https://github.com/xamarin/xamarin-macios/pull/12563) a change to support XVS support broke execution of Apps that were stripped
- Applications were broken because none of the stripped assemblies were actually copied into the bundle
- However, the tests still passed, because all assemblies that were there had no IL (zero assemblies total)
Now why did this happen?
- The stripped assemblies were changed to return via an msbuild Output Element
- Output Element can return an Property or ItemGroup, depending if you use the PropertyName or ItemName attributes
- Unfortunately I used PropertyName, when I expected an ItemGroup. So I silently had a property created instead.
- Thus zero items were added to the list of files to copy into the bundle
- Which was undetected as the test did not confirm files were copied in, and manual tests were not run so late into the PR (3 weeks after PR was opened)
How was it fixed?
- Correctly using ItemName on Output created a valid item group to reference
- However, that still failed with an absurdly confusing error:
PATH/Microsoft.NET.Publish.targets(277,5): error MSB3024: Could not copy the file FILE to the destination file PATH, because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles.
- After a splunking through netcore targets, I found the metadata on these assemblies references really matters. Without it, they are not processed correctly at all.
- Thus, I updated ILStripBase to clone the existing metadata when changing the original assembly reference to the stripped path
- Finally, I corrected the test to assert that required files are copied in. I also manually ran our device test.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Subclass NativeObject to reuse object lifetime code. This isn't for CFType
itself, but all its subclasses.
* Add a public default constructor to maintain compat, but remove it for XAMCORE_4_0.
* Add an internal (IntPtr, bool) constructor to follow the NativeObject pattern.
* Enable nullability and fix code accordingly.
* Use CFString.CreateNative/ReleaseNative instead of other means to create
native strings (the fastest and least memory hungry option).
* Use 'nameof (parameter)' instead of string constants.
The deadlock goes like this:
1. Thread A holds the framework_peer_release_lock lock, and tries to lock the
refcount_mutex lock.
2. Thread B holds the refcount_mutex, and is waiting for the GC to complete
3. Thread C is trying to lock the framework_peer_release_lock while running
the GC.
The fix is in thread A, by not doing anything at all with the
framework_peer_release_lock lock locked.
The code contains extensive comments explaining the situation and the solution.
Fixes https://github.com/xamarin/xamarin-macios/issues/13066.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
* Subclass NativeObject to reuse object lifetime code.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use CFString.CreateNative/ReleaseNative instead of other means to create native
strings (the fastest and least memory hungry option).
* Use 'nameof (parameter)' instead of string constants.
* Call 'GetCheckedHandle ()' (which will throw an ObjectDisposedException if
Handle == IntPtr.Zero) instead of manually checking for IntPtr.Zero and throwing
ObjectDisposedException.
* Use CFArray helper methods to create arrays (and implement some helper methods
that didn't exist).
* Add a few tests for the new CFArray helper methods.
* Don't execute .NET tests in the 'legacy' targets (it's wasteful because
we're already executing those .NET tests elsewhere).
* Fix reporting failures in the legacy tests.
This makes it easier to iterate over the platforms we're building for, because
we can use "macOS" to compute the variable names we're interested in (like we
already can for iOS, tvOS, watchOS and MacCatalyst).
* Create all INativeObject subclasses using 'Runtime.GetINativeObject<T>' instead
of 'new T ()'. Although it's somewhat slower, it automatically handles any IntPtr.Zero
handles, and it also makes the generator code simpler. If something turns out to
be a performance problem, we can always add custom static creation methods (like
some of the existing types already have).
* This makes it so that the zero pointer check logic in the generator isn't necessary
anymore.
* The most important part is where we use IntPtr as the marshalling type for returned
INativeObjects in blocks (instead of the INativeObject class - which doesn't make
sense really, because I have no idea how that's marshalled).
Example:
```diff
diff --git a/build/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs b/build-new/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
index 97e58f3a91b..8a40748de8b 100644
--- a/build/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
+++ b/build-new/dotnet/ios/generated-sources/ObjCRuntime/Trampolines.g.cs
@@ -214,7 +214,7 @@ namespace ObjCRuntime {
} /* class NIDAVAudioEngineManualRenderingBlock */
[UnmanagedFunctionPointerAttribute (CallingConvention.Cdecl)]
[UserDelegateType (typeof (global::AVFoundation.AVAudioIONodeInputBlock))]
- internal delegate global::AudioToolbox.AudioBuffers DAVAudioIONodeInputBlock (IntPtr block, uint frameCount);
+ internal delegate IntPtr DAVAudioIONodeInputBlock (IntPtr block, uint frameCount);
//
// This class bridges native block invocations that call into C#
//
@@ -223,11 +223,11 @@ namespace ObjCRuntime {
[Preserve (Conditional = true)]
[global::System.Diagnostics.CodeAnalysis.DynamicDependency ("Handler")]
[MonoPInvokeCallback (typeof (DAVAudioIONodeInputBlock))]
- static unsafe global::AudioToolbox.AudioBuffers Invoke (IntPtr block, uint frameCount) {
+ static unsafe IntPtr Invoke (IntPtr block, uint frameCount) {
var descriptor = (BlockLiteral *) block;
var del = (global::AVFoundation.AVAudioIONodeInputBlock) (descriptor->Target);
AudioToolbox.AudioBuffers retval = del (frameCount);
- return retval;
+ return retval.GetHandle ();
}
} /* class SDAVAudioIONodeInputBlock */
internal sealed class NIDAVAudioIONodeInputBlock : TrampolineBlockBase {
@@ -249,7 +249,7 @@ namespace ObjCRuntime {
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
unsafe global::AudioToolbox.AudioBuffers Invoke (uint frameCount)
{
- var ret = invoker (BlockPointer, frameCount);
+ var ret = Runtime.GetINativeObject<global::AudioToolbox.AudioBuffers> (invoker (BlockPointer, frameCount), false);
return ret!;
}
} /* class NIDAVAudioIONodeInputBlock */
```
* Add an (IntPtr, bool) constructor so that AudioUnit works with Runtime.GetINativeObject.
* Keep track of ownership, so that AudioUnit doesn't free the native resources
when it doesn't own them.
* Update a test to verify that calling 'AVAudioIONode.AudioUnit' multiple
times and disposing the result between them works (this fails if AudioUnit
doesn't keep track of ownership).
Now that macOS runs on ARM64 (and also the simulators soon), we need to have to same logic for all platforms.
Fixes:
Introspection.iOSApiPInvokeTest
[FAIL] Could not find the field 'objc_msgSend_stret' in /usr/lib/libobjc.dylib
[FAIL] Could not find the field 'objc_msgSendSuper_stret' in /usr/lib/libobjc.dylib
[FAIL] SymbolExists : 2 errors found in 5300 functions validated: objc_msgSend_stret, objc_msgSendSuper_stret
Expected: 0
But was: 2
at Introspection.ApiPInvokeTest.SymbolExists() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/introspection/ApiPInvokeTest.cs:line 182
Fixes this when running our test suites on macOS 10.14:
dyld: Library not loaded: /System/Library/Frameworks/AuthenticationServices.framework/Versions/A/AuthenticationServices
Referenced from: /Users/runner/work/1/s/artifacts/mac-test-package/tests/./introspection/dotnet/macOS/bin/Debug/net6.0-macos/osx-x64/introspection.app/Contents/MacOS/introspection
Reason: image not found
make[2]: *** [exec-mac-dotnet-x64-introspection] Abort trap: 6
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.
Fix parsing extra bundler arguments where a space separates the name and the
value of the argument, like this: '--xml file.xml' (as opposed to
'--xml:file.xml' or '--xml=file.xml').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1385946.
* [dotnet-linker] Remove workaround for a dotnet/runtime issue wrt the AOT compiler.
The dotnet/runtime issue has been fixed.
Ref: https://github.com/dotnet/runtime/issues/55733
* [tests] Set the _BundlerVerbosity property instead of MtouchExtraArgs/MonoBundlingExtraArgs to increase verbosity.
This fixes a problem where a test project would try to set the
MtouchExtraArgs/MonoBundlingExtraArgs properties, and it would fail because
the MtouchExtraArgs/MonoBundlingExtraArgs properties were already set from the
command line (and in MSBuild, properties that are set from command line
arguments can't be changed later).
In particular we have logic to pass --dlsym:+nunit.framework.dll for
monotouch-test, and that would just be ignored.
This matters because we use the library defined by the P/Invoke to determine
which frameworks to link with, and if we get it wrong, things like this may
happen:
Undefined symbols for architecture arm64:
"_AudioObjectGetPropertyData", referenced from:
wrapper_managed_to_native_AudioUnit_AudioUnit_AudioObjectGetPropertyData_uint_AudioUnit_AudioObjectPropertyAddress__uint__intptr__uint__uint_ in Xamarin.MacCatalyst.dll.o
because we though that the AudioObjectGetPropertyData function was in the
AudioUnit framework, and not in CoreAudio where it really is, and thus we
didn't link with the CoreAudio framework.
Also add an introspection test to verify that the library our P/Invokes point
to is correct.
* Update to use EnableSGenConc instead of MtouchEnableSGenConc (either works,
the former is the new future).
* Set EnableSGenConc as a top-level property, so we make sure it's set no
matter how the project is executed.
This makes it so that this setting work for .NET projects, where we're not using project configurations.
Skip:
* Any Thumb variation (Thumb code isn't supported anymore in .NET).
* Any AssemblyBuildTarget variation (compiling assemblies to dylibs [fastdev]
or frameworks - neither is supported/implemented for .NET).
This trims down the test list a bit.
This is to set the -dlsym:-nunit.framework.dll option, because nunit.framework.dll
contains a P/Invoke to a function that doesn't exist.
For some reason this is more of a problem in tvOS projects than iOS projects
(although it happens for iOS projects as well).
from Sebastien: "most filters are key-based natively (not-NSObject subclasses)) and we expose them as C# _user-type_ CIFilter-subclasses in recent years _most_ filters have also been exposed natively as protocols (not classes), we expose them as `*Protocol` interface types `CIRAWFilter` is a special case, it's a native `CIFilter` subclass so we're not using [CoreImageFilter] and [CoreImageFilterProperty] attributes to define it which also means we cannot use the "extra" tests to validate the filter properties. So we skip it here. Do not fear it's still tested, like any _normal_, NSObject subclass we have bound :-)"
Apple does this in their headers:
#define DISPATCH_ALIAS_V2(sym) __asm__("_" #sym "$V2")
dispatch_queue_t
dispatch_queue_create_with_target(const char *_Nullable label,
dispatch_queue_attr_t _Nullable attr, dispatch_queue_t _Nullable target)
DISPATCH_ALIAS_V2(dispatch_queue_create_with_target);
Which means that the native compiler will call
'dispatch_queue_create_with_target$V2' when the source code says to call
'dispatch_queue_create_with_target'.
The only place I've run into this problem, is when building for tvOS (device),
and targetting exactly tvOS 10.0 (neither earlier or later), in which case the
linker fails:
Undefined symbols for architecture arm64:
"_dispatch_queue_create_with_target", referenced from:
wrapper_managed_to_native_CoreFoundation_DispatchQueue_dispatch_queue_create_with_target_string_intptr_intptr in Xamarin.TVOS.dll.o
I filed this as a feedback with Apple some time ago [1], and Apple resolved it
as by design, saying "These symbols are renamed, please use the SDK."
Now I ran into it again with .NET, and it's become a bit more important, since
tvOS 10.0 is the earliest tvOS version we support, which means it'll be more
likely that customers use _exactly_ 10.0 as their target tvOS version. So I
looked into it again, and as far as I can tell, we can just call the '$V2'
variant instead of the original name everywhere.
Apple does the same thing for two other functions, but we haven't bound any of
those, so this only affects 'dispatch_queue_create_with_target' for us.
[1]: Bug ID 48076044: Can't reference 'dispatch_queue_create_with_target' when min tvOS version is exactly 10.0
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
Add test case to verify that we pass the right bundle identifier to
DetectSigningIdentity when we're using a partial app manifest to set the
bundle identifier.
This proves that #12051 is already fixed.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
Fixes this error when running on M1 (and Rosetta):
MonoTouchFixtures.CoreFoundation.BundleTest.TestGetBundleIdNull : 0.9134 ms
[FAIL] TestIsArchitectureLoadable : arm64 Expected => false
Expected: False
But was: True
at MonoTouchFixtures.CoreFoundation.BundleTest.TestIsArchitectureLoadable() in xamarin-macios/tests/monotouch-test/CoreFoundation/BundleTest.cs:line 375
* Update dependencies from https://github.com/dotnet/installer build 20210826.20
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21426.20
* Update dependencies from https://github.com/dotnet/installer build 20210827.35
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21427.35
* Update dependencies from https://github.com/dotnet/installer build 20210828.23
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21428.23
* Update dependencies from https://github.com/dotnet/installer build 20210830.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21430.3
* Update dependencies from https://github.com/dotnet/installer build 20210831.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21431.4
* Update dependencies from https://github.com/dotnet/installer build 20210901.9
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21451.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21430.2 (parent: Microsoft.Dotnet.Sdk.Internal
* [tests] Adjust path changes for tvOS
* Update dependencies from https://github.com/dotnet/installer build 20210902.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21452.10
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21430.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Looks like macOS/dotnet is not quite the legacy build (which works)
* Update dependencies from https://github.com/dotnet/installer build 20210903.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21453.10
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210904.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21454.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210904.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21454.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210906.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.2.21425.12 -> To Version 6.0.100-rc.2.21456.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21419.1 -> To Version 6.0.100-preview.6.21452.4 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* [xharness] Unify the list of test projects for .NET between iOS and macOS.
* [xharness] Don't enable all .NET tests if .NET is enabled.
Some tests (such as device tests) have additional checks that must be honored as well.
* [xharness] If a test is ignored, then it doesn't matter what the corresponding build task is doing.
A build task can be shared between multiple tests, and it can be building for
another (enabled) test. This happens for iOS 32-bits and 64-bits simulator:
the app is built once, but have two different tests running.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Web documentation mention them to be available. Introspection disagree.
Since they are all related to a single `VideoCallSupport` category, this
feature is likely not available to Catalyst.
The framework is only available on macOS 12.
It's possible (my guess) that the selectors were renamed after Xcode 13
beta 5 was released. In that case a future (RC?) Xcode will have the
updated headers.
Most selectors are working as expected
```
NSLog (@"%@", [MEMessageAction markAsReadAction]);
Message Action: Destination: (null), Read Status: 1, Flag Change: (null), Message Color: 0
```
while the last 3 do not work, even from an ObjC application
```
NSLog (@"%@", [MEMessageAction flagAction]);
+[MEMessageAction flagAction]: unrecognized selector sent to class 0x7ffa601fc5d8
```
```
NSLog (@"%@", [MEMessageAction unflagAction]);
+[MEMessageAction unflagAction]: unrecognized selector sent to class 0x7ffa601fc5d8
```
```
NSLog (@"%@", [MEMessageAction setColorActionWithColor:(MEMessageActionMessageColorRed) ]);
+[MEMessageAction setColorActionWithColor:]: unrecognized selector sent to class 0x7ffa601fc5d8
```
This fixes an issue where the html report wouldn't show test failures from
timestamped logs (which is the case for macOS test logs).
Also remove a duplicated condition.
How we create the app manifest (Info.plist) has to be modified so that we can
add support for getting all the values from MSBuild properties (i.e. no
Info.plist in the project), as well as having multiple partial app manifests
that all get merged into the final app manifest.
Here's the new process:
1. The user can specify values in multiple ways:
* An Info.plist in their project file (as always, by using a `None` item
with filename "Info.plist" or with a `Link` metadata with filename
"Info.plist"). We find this Info.plist in the DetectAppManifest target.
* A partial plist in their project (using the `PartialAppManifest` item
group)
* Some MSBuild properties can also add values.
The general precedence is: MSBuild properties can be overridden by the
Info.plist, which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and
compute a temporary app manifest, which is written to a temporary output
file.
3. In the `ReadAppManifest` target, we read the temporary output file and
outputs numerous MSBuild properties (most of them private)
4. We run other targets that may add more entries to the final app manifest
(these tasks might depend on the values from `ReadAppManifest`). These
entries are written to partial plists, and added to the
_PostCompilePartialAppManifest item group.
Currently the targets that can add more entries to the app manifest are
_CompileImageAssets and _CompileCoreMLModels.
5. In the new `WriteAppManifest` target, we read the temporary output file
from `ReadAppManifest` + any `_PostCompilePartialAppManifest` files and
merge them all together to get the final Info.plist.
This also required moving the computation of CFBundleIdentifier from the
DetectSigningIdentity task to the CompileAppManifest task, which also meant
reordering these two tasks, so that the DetectSigningIdentity task is executed
after the CompileAppManifest task (technically after the ReadAppManifest
task), because the DetectSigningIdentity task needs to know the bundle
identifier.
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency* attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 6.0.100-preview.6.21416.1 to 6.0.100-preview.6.21419.1 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: df3e6147-3e41-4928-6775-08d8f479343c
- **Build**: 20210823.21
- **Date Produced**: 8/24/2021 12:53 AM
- **Commit**: 5f5d8bb4a209810fb93c86ce6b0b3172bd909134
- **Branch**: refs/heads/release/6.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.100-rc.1.21417.3 to 6.0.100-rc.2.21423.21][1]
- **Microsoft.NET.ILLink.Tasks**: [from 6.0.100-preview.6.21416.1 to 6.0.100-preview.6.21419.1][2]
[1]: 8c86609...5f5d8bb
[2]: 5b2391c...5851f6d
Chris Hamons
Rachel Kang
Rolf Bjarne Kvinge
Alex Soto
Manuel de la Pena
TJ Lambert
Sebastien Pouliot
Filip Navara
dotnet-maestro[bot]