The build is somewhat frequently failing on the bots with this:
> /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/NuGet.targets(131,5): error : Could not find file "/Users/builder/azdo/_work/2/a/change-detection/tmp/src/xamarin-macios/packages/mono.options/6.12.0.148/qo8orsfq.fp5"
Although I haven't been able to reproduce it, I believe it to be a race
condition between building the .NET version of the generator and the legacy
Xamarin version of the generator: if they both try to restore NuGet packages
at the same time, things may break.
Fix this by introducing an artificial dependency between the generators, so
that they're not built simultaneously, but instead sequentially.
This might make the build a few seconds slower, but predicable builds on the
bots are way more important. Also the speed will be back to normal once we
stop building legacy Xamarin.
Delete several file that weren't included in the build:
* WebKit/DomCssRuleList.cs: Apple has deprecated this API, so no need to add
any extra manual bindings.
* CoreImage/CIKernel.cs: this proposed API would:
* Store a delegate as an instance field (this is prone to memory cycles)
Adds state (the delegate in the previous type) to a wrapper type (which
complicates object lifetime), and no way to clear said state.
* No tests.
While some of these issues are fixable, some are not without a redesign, so
just remove this code completely.
* System.ComponentModel/CancelEventArgs.cs: this is shipped with the BCL.
* Security/*: only enums that don't look important.
* Chip/ChipKeypair.cs: only contains legacy code.
Add a cecil test to verify a few common capitalization issues:
* All APIs must start with an upper-cased letter (except parameter names, which must start with a lower-cased letter).
* The term "URL" should always be capitalized as "Url".
Sonoma is pickier now with the way we create a CoreGraphics.CGImage,
meaning that if we do not pass the correct flags, the OS will return a
nil object (might be a good idea to move away from constructors to
factory methods).
Before this change we would get the following errors:
* CAKeyFrameAnimation_ValuesTests: System.Exception : Could not
initialize an instance of the type 'CoreGraphics.CGImage': handle is
null. It is possible to ignore this condition by setting
ObjCRuntime.Class.ThrowOnInitFailure to false.
* CALayer_ValuesTests: System.Exception : Could not initialize an
instance of the type 'CoreGraphics.CGImage': handle is null. It is
possible to ignore this condition by setting
ObjCRuntime.Class.ThrowOnInitFailure to false.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Before this commit we had the following failing test:
```
Error: Exception Message
Expected: String matching "Objective-C exception thrown. Name: _HKObjectValidationFailureException Reason: Type HKSample can not have endDate of NSDate.distantFuture"
But was: "Objective-C exception thrown. Name: _HKObjectValidationFailureException Reason: startDate (0001-01-01 00:00:00 +0000) and endDate (4001-01-01 00:00:00 +0000) exceed the maximum allowed duration for this sample type. Maximum duration for type
```
The new exception does not happen on macOS but does on iOS.
The released commit for .NET 8 isn't the exact same commit as the one
referenced here, because the build.zip file wasn't produced in that commit -
this was fixed, so it's a few commits later. There were no API changes between
these commits though, so the API references are identical.
Calling the direct functions instead of sending messages is slightly faster,
and additionally it may make some static analyzers think we've enabled ARC for
our Objective-C code (which we don't, because we need to manually manage
reference counting).
These direct functions aren't in any public header (they're in a private header),
but they're documented as part of ARC here: https://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support,
and clang emits references to these methods from user code, so it should be safe for us to use them.
Fixes https://github.com/xamarin/xamarin-macios/issues/19413.
Lets remove little by little the need to have an object with all the
knowledge, BT has a God complex that is not helping us.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
We currently detect/resolve binding resource packages (the sidecar) in two places:
* The ResolveNativeReferences MSBuild task.
* Inside mtouch/mmp/dotnet-linker.
Which means we end up passing every native library or framework twice to the native linker.
This is usually not a problem, the native linker will ignore duplicated
arguments, except when building remotely from Windows, in which case the build
process may end up with native libraries in different locations, because files
may end up in multiple places on the remote Mac if using absolute paths (see
https://github.com/xamarin/xamarin-macios/issues/18997 for a thorough explanation).
So completely remove the logic to detect/resolve binding resource packages in
mtouch/mmp/dotnet-linker, which will avoid the issue completely.
A few mtouch tests also needed updating, since they're calling mtouch directly instead
of going through the msbuild targets.
Fixes https://github.com/xamarin/xamarin-macios/issues/19378.
This is easier than maintaining four different template files, also there will
be significant changes in the WorkloadManifest.targets file with the upcoming
multi-targeting changes, so this makes those changes simpler.
Introduces the TypeCache class, which pulls out the public
properties that existed in TypeManager for each type.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Manuel de la Pena
Michael Cummings (MSFT)
Rolf Bjarne Kvinge
dustin-wojciechowski
dotnet-maestro[bot]
VS MobileTools Engineering Service 2
Haritha Mohan
Emanuel Fernandez Dell'Oca