Rolf Bjarne Kvinge 342b312a73 Our current behavior is to detect any None, BundleResource or Content item that's (#13550) ... named 'Info.plist', and assume that's the app manifest. That doesn't quite work when we end up with multiple 'Info.plist' entries in any of those item groups (one example being a framework as a BundleResource - all frameworks have an Info.plist, and there's no good way to distinguish what the developer's intention was). So: 1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest detection. 2. Add a public 'AppBundleManifest' property that specifies the app manifest (this is just a renamed version of our previously private '_AppManifest' property). This makes it possible for app developers to: * Disable automatic app manifest detection. * Still have an app manifest by specifying it manually. * Disable automatic app manifest detection, but also not specify an app manifest manually (so no custom app manifest at all). Also: * Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing with the new 'AppBundleManifest' property.		2021-12-14 20:56:52 +01:00
..
CollectAppManifestsTests.cs	[msbuild] Add a public target/property to make customers able to add to the PartialAppManifest item group in their own targets. Fixes #12336. (#12645)	2021-09-08 09:16:57 +02:00
DetectSigningIdentityTests.cs	[tests] Add test case for making sure we have the right bundle identifier when executing DetectSigningIdentity. Fixes #12051. (#12655)	2021-09-08 15:46:59 +02:00
TargetTests.cs	Our current behavior is to detect any None, BundleResource or Content item that's (#13550)	2021-12-14 20:56:52 +01:00
ValidateAppBundleTaskTests.cs	[tests] Clean up Xamarin.MacDev.Tests.	2020-10-29 14:52:31 +01:00