Our min OS target versions are different between legacy Xamarin and .NET
(former supports earlier versions). The list of versions in the Versions.plist
contain all the versions supported by legacy Xamarin, but that's not correct
for .NET, so don't list any version in Version.plist that's lower than the
minimum OS version we support for a given platform.
This enables Visual Studio to set a specific `RuntimeIdentifier` for each platform when building all target frameworks in a MAUI project.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22201.10 -> To Version 6.0.300-preview.22204.3
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Use 'Microsoft.<platform>' as the product name instead of 'Xamarin.[iOS|Mac]' for .NET builds. That makes error messages like this:
> [...]\Microsoft.iOS.Sdk\15.4.200-ci.windows2.62\tools\msbuild\iOS\Xamarin.Shared.targets(1676,3): Could not find Xamarin.iOS in /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/15.4.200-ci.windows2.62/.
look a bit better in .NET:
> [...]\Microsoft.iOS.Sdk\15.4.200-ci.windows2.62\tools\msbuild\iOS\Xamarin.Shared.targets(1676,3): Could not find Microsoft.iOS in /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/15.4.200-ci.windows2.62/.
* Make the custom-type-assembly library build using assemblies relative to
MAC_DESTDIR, instead of poking into $(TOP)/_mac-build (for legacy Xamarin).
* Build the custom-type-assembly using a project file for .NET (and use our
local .NET).
* Change the default for [IOS|MAC]_DESTDIR when TESTS_USE_SYSTEM is set to
point to the system installation.
* Make sure 'MSBuildSDKsPath' isn't set when building the custom-type-assembly
(set by xibuild), it breaks a lot of things.
* Move logic to validate the UIDeviceFamily value to shared code.
* Remove logic related to watchOS 1 apps, it's been dead for a while.
* Change logic to not overwriting any existing UIDeviceFamily values in the customer's
Info.plist.
This makes the code more platform-agnostic and easier to work with across all platforms
(such as adding new validations).
Fixes this warning from the Codesign task:
C:\Users\rolf\...\Microsoft.iOS.Sdk\15.4.200-...\tools\msbuild\iOS\Xamarin.Shared.targets(2045,3): Cannot create 'C:\Users\rolf\source\iOSApp4\bin\Debug\net6.0-ios\ios-arm64\device-builds\iphone14.2-15.3.1\iOSApp4.app\Frameworks\ArcGIS-arm64.framework' because a file or directory with the same name already exists.
C:\Users\rolf\...\Microsoft.iOS.Sdk\15.4.200-...\tools\msbuild\iOS\Xamarin.Shared.targets(2045,3): Cannot create 'C:\Users\rolf\source\iOSApp4\bin\Debug\net6.0-ios\ios-arm64\device-builds\iphone14.2-15.3.1\iOSApp4.app\Frameworks\Runtimecore.framework' because a file or directory with the same name already exists.
which occurs when the Codesign task asks XVS to create output files for files from
inside ditto'ed directories, and if XVS created output files for those directories
in the Ditto task, then XVS would be trying to create files inside these output files
as if they were directories. That doesn't work (thus the warning).
I've fixed this by:
* Removing the 'ShouldCreateOutputFile' implementation. The ShouldCreateOutputFile
method is called on Windows, and we can't determine from Windows whether the destination
is a directory or a file.
* Remove the [Output] attribute for the Destination property, this way XVS doesn't
automatically try to create an output file for whatever the destination is.
* Add another CopiedFiles output property, which contains all the copied files
(and only files), so that XVS mirrors this with output files on Windows.
Fixes part of https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/.
* [ScreenCaptureKit] Add ScreenCaptureKit bindings up to Xcode 13.3
* Use more appropriate exceptions.
* Remove ScreenCaptureKit from Mac Catalyst.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Fix multiple API mistakes made in define removal
* Revert "[Quicklook]Remove unnecessary conditional defines from quicklook.cs (#14491)"
This reverts commit ff048c38b0.
* Fix API breaks reverting quicklook PR
When XVS creates output/stamp files on Windows, the paths must be relative,
because otherwise XVS will append the full macOS path to the current Windows
directory and get garbage.
XVS also expects only files as output, so don't return any directories.
Fixes part of https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/.
* Fix resolving paths to required test files (test files can be found relative to the root path of the repository, not relative to where Xamarin.Mac is installed)
* Don't try to sign symlinks - we can end up trying to sign the target of the symlink twice simultaneously.
* Fix finding libxammac.dylib and Xamarin.Mac.dll when testing a system installation (when MAC_DESTDIR or TESTS_USE_SYSTEM are set).
* Remove a few .NET tests we don't need anymore.
Fixes https://github.com/xamarin/maccore/issues/2560.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Since we're not planning on any more breaking changes after RC 1, we can
ensure we don't have any accidental breaking changes by using the RC 1
assemblies as the baseline.
Fixes this NUnit warning:
> labels=All is deprecated and will be removed in a future release. Please use labels=Before instead.
We don't follow the suggestion from the warning, because the advantage of
writing the label after each test is that the test result will also be
printed, which means it's possible to see if any tests failed during the test
run, as opposed to having to wait until the entire test run is completed
(which can take a while) to realize that pretty much every test failed with
some silly mistake which could have been quickly fixed before re-running the
tests.
The bug in the AOT compiler is being fixed, but until then we can just ignore
the warning, with the idea of removing this code once the AOT bug has been
fixed.
Fixes these MTouch test failures:
* Xamarin.MTouch.BuildWithCulture("sl_SI"):
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory107/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
* Xamarin.MTouch.BuildWithCulture("ur_IN"):
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory109/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
* Xamarin.MTouch.MT0095_NotSharedCode:
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory274/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory272/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Ref: https://github.com/xamarin/xamarin-macios/issues/14601
Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/
- Fixes https://github.com/xamarin/xamarin-macios/issues/14450
- There is a significant amount of additional bindings to be done, but this way
we at least get the trivia one in now.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Move the logic to create the Xamarin.iOS and Xamarin.Mac symlinks together,
so easier spot differences (both expected and unexpected).
* Fix an issue with the logic where we'd make
/Library/Frameworks/Xamarin.iOS.framework/Versions/git point to
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current.
The corresponding project was renamed some time ago, but not all places that
used the derived Make variable were updated at the same time as they should
have been.
* Update dependencies from https://github.com/dotnet/installer build 20220401.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22181.4 -> To Version 6.0.300-preview.22201.1
* Update dependencies from https://github.com/dotnet/installer build 20220401.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22181.4 -> To Version 6.0.300-preview.22201.10
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
The headers do not say that a null parameter is allowed, but the
documentation and tests state otherwise:
https://developer.apple.com/documentation/foundation/nsurl/1572047-urlwithstring
The URL string with which to initialize the NSURL object. Must be a URL that conforms to RFC 2396. This method parses URLString according to RFCs 1738 and 1808.
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
TJ Lambert
Rolf Bjarne Kvinge
Chris Hamons
Manuel de la Pena
Alex Soto
Emanuel Fernandez Dell'Oca
dotnet-maestro[bot]
Mauro Agnoletti
Přemek Vysoký
Steve Hawley