The generator needs a library name for the generated `_domain` field.
Here's an example for the generated `ARErrorCodeExtensions` class ("ARKit" is
the library name):
```cs
[Field ("ARErrorDomain", "ARKit")]
static NSString? _domain;
```
In order to find the library name, the generator would look at the first enum
field with a `[Field]` attribute, and get the `LibraryName` property from that
`[Field]` attribute. Unfortunately error enums don't necessarily have `[Field]`
attributes on their enum fields. This works fine for our own bindings, because
the generator will fall back to the enum's namespace, but for third-party
bindings this would be the result:
> error BI1042: bgen: Missing '[Field (LibraryName=value)]' for ErrorDomainNS.EWithDomain. (e.g."__Internal")
Note that the error message is rather confusing: it's trying to report a
missing `LibraryName` property for a `[Field]` attribute, but there's no `[Field]`
attribute anywhere in the enum in question.
So fix this by:
* Adding the `LibraryName` property on the `[ErrorDomain]` attribute.
* Implement support for looking at this new property in the generator.
* Report a better error if it's not there.
Note that this document is currently not published on our documentation web site.
* Consolidate on a single way to specify message arguments (* instead of {...}).
* Mark messages that will only be show in legacy as such (but keep them)
* Escape star characters in headers.
* Remove mentions of Xamarin.
* Misc other updates.
* Unpack into a per-assembly directory. This way identically named resources from
different assemblies won't overwrite eachother.
* Remove logic to detect overwriting of existing bundle resources, because it's broken.
In particular this piece of code is missing a single character (there should be a `!` in the condition):
```cs
if (string.IsNullOrEmpty (logicalName))
ignore.Add (logicalName);
```
This means we're only ignoring bundle resources without LogicalName, which shouldn't
happen. So just remove the code, since it doesn't do anything useful. A proper fix
for resource collision is in progress and will come in a separate pull request.
* Fix task to work for incremental builds. Previously we'd detect that any resources
had been extracted and not re-extract, but we wouldn't add those extracted resources
to the `_BundleResourceWithLogicalName` item group. The end result would be that
on incremental builds, any bundled resources wouldn't be picked up at all. Typically
this wouldn't be a problem (because the resources would be in the resulting app
bundle), but doing anything out of the ordinary could cause problems. The fix is
to write the unpacked items + their metadata to a file, and load those when we
detect that no re-extraction is necessary (this file also does double duty as a
stamp file in the code).
* Augment `WriteItemsToFile` to make its `Write` method accessible from different classes.
* Improve logging a bit.
By default we limit the error message to 1024 characters in case the native
linker fails. The problem is that the native linker may show a lot of warnings
in the beginning, so if that happened, the error output would show only a list
of warnings and nothing else, which is rather confusing.
So change the output slightly when reporting an error in the native linker:
* Try to filter out warnings.
* Show a max of 25 lines of errors (as opposed to 1024 characters, which tended to be 3-4 lines).
So now instead of this error:
[...]/targets/Xamarin.Shared.Sdk.targets(1623,3): clang++ exited with code 1:
ld: warning: object file ([...]/packs/Microsoft.NETCore.App.Runtime.Mono.maccatalyst-arm64/8.0.3/runtimes/maccatalyst-arm64/native/libSystem.Globalization.Native.a(pal_calendarData.c.o)) was built for newer Mac Catalyst version (14.2) than being linked (14.0)
ld: warning: object file ([...]/packs/Microsoft.NETCore.App.Runtime.Mono.maccatalyst-arm64/8.0.3/runtimes/maccatalyst-arm64/native/libSystem.IO.Compression.Native.a(pal_zlib.c.o)) was built for newer Mac Catalyst version (14.2) than being linked (14.0)
ld: warning: object file ([...]/packs/Microsoft.NETCore.App.Runtime.Mono.maccatalyst-arm64/8.0.3/runtimes/maccatalyst-arm64/native/libSystem.IO.Compression.Native.a(constants.c.o)) was built for newer Mac Catalyst versio
we get:
[...]/targets/Xamarin.Shared.Sdk.targets(1623,3): clang++ exited with code 1:
Undefined symbols for architecture arm64:
"__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from:
__swift_FORCE_LOAD_$_swiftCompatibility56_$_main in libSwiftTest.a(libSwiftTest.arm64.o)
(maybe you meant: __swift_FORCE_LOAD_$_swiftCompatibility56_$_main)
"__swift_FORCE_LOAD_$_swiftCompatibilityConcurrency", referenced from:
__swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_main in libSwiftTest.a(libSwiftTest.arm64.o)
(maybe you meant: __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_main)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
which makes much more sense for an error.
The full linker output is still available in the build log if needed.
Make sure Microsoft.\<platform\>.Sdk.DefaultItems.props is rebuilt if the
current hash changes.
This fixes a local rebuild issue, where we'd rebuild
Microsoft.\<platform\>.Sdk.Versions.props, but not
Microsoft.\<platform\>.Sdk.DefaultItems.props.
A build failure like this would thus result:
tools/msbuild/iOS/Xamarin.Shared.targets(606,3): error : A bundle identifier is required. Either add an 'ApplicationId' property in the project file, or add a 'CFBundleIdentifier' entry in the project's Info.plist file.
because:
* We store the current git hash in both of the files mentioned above.
* We only include default items in a build if the git hashes match.
* Since the files weren't both rebuilt, they'd contain different hashes, and
thus we wouldn't include Info.plist in the build, leading to the build
error.
It's been a few years since we've synchronized the documentation here with the
documentation in the documentation repository
(https://github.com/MicrosoftDocs/xamarin-docs-pr/), so bring all updates done
there over here.
This PR is probably best reviewed commit-by-commit.
The GKHybridStrategist type doesn't exist in iOS. This was probably a type
initially introduced in a beta version, and then removed in a later beta
version, and then we didn't notice.
Stop using the term 'Xamarin' in our error messages.
🙈🙊🙉
Note: this may not be complete, since we compute error messages in numerous
places, and those aren't fixed here (if there are any that still says
'Xamarin' in any way).
---------
Co-authored-by: Michael Cummings (MSFT) <mcumming@microsoft.com>
By adding the 'LinkWithSwiftSystemLibraries=true' property in a project file, we'll
now add the location of Swift's system libraries to the linker arguments.
Fixes https://github.com/xamarin/xamarin-macios/issues/18848.
* Adding xml documentation to the t4 file will make it quite complicated and
ugly.
* The code for these types change very rarely, so at this point there's not
much advantage to generating it.
So just copy the expanded t4 code into the correct C# files and remove the t4
code.
NUnit is not trimmer-safe, and produces a lot of trimmer warnings.
Ideally we'll fix NUnit or come up with an alternative (see #19911), but
that's a significant amount of work.
We also want to turn warnings into errors (to avoid adding more trimmer
warnings by accident).
So we disable trimmer warnings from NUnit. The method is somewhat complex,
because there's no built-in way to ignore warnings for a given assembly, but
both ILC and ILLink provides a way to collapse multiple warnings into a single
warning (with a specific code) on a per assembly basis, and we can levarage
this:
* We enable all warnings for all assemblies (by setting
`TrimmerSingleWarn=false`).
* We enable the single-warning mode for NUnit only.
* We ask the trimmer to not warn about the specific warning code given for the
single-warning produced.
The end result is that we won't get any trimmer warnings for NUnit.
An xharness fix was also needed to make xharness not get confused with
ItemGroups inside Targets when cloning project files.
Ref: https://github.com/xamarin/xamarin-macios/issues/19911
We can determine whether we're building for the simulator or not as soon as we know
the RuntimeIdentifier, so do that, and set _SdkIsSimulator accordingly.
In legacy Xamarin we had to execute a target in order to compute _SdkIsSimulator
(_DetectSdkLocations), but with this change we won't have to in .NET anymore, which
makes it possible to simplify some logic.
The first thing we do here is to also move the computation of the trimmer configuration
to right after computing _SdkIsSimulator (because we only need to know three things
to compute the default trimmer mode: the target platform + whether we're building
for the simulator or not + the configuration, and those are all known at this point
now).
This will make it possible to stop suppressing trimmer warnings depending on the
trimming mode in effect (we have to suppress (or decide not to) the warnings in the
initial MSBuild evaluation phase, before any targets are executed, because the properties
in question are read during the evaluation phase in .NET). Note that this PR is not
changing any trimmer warnings, that will only happen in .NET 9.
To reduce reliance on xamjenkinsartifact.
Also remove MIN_XM_MONO_URL, it is not used anymore.
---------
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
The UITextAttributes.Dictionary property is supposed to work like the
UIStringAttributes.Dictionary property, but there's one big difference: the
UITextAttributes version can (and calling code does) be disposed, while the
UIStringAttributes version can't.
This is because the UITextAttributes version creates a new dictionary every
time, while the UIStringAttributes version doesn't.
Since properties shouldn't really do much, it makes sense to remove the
UITextAttributes version, and instead rely on the
UITextAttributes.ToDictionary method, where the difference in behavior is more
obvious.
This required a few changes in calling code, which used either UITextAttributes
or UIStringAttributes using conditional compilation.
Fixes https://github.com/xamarin/xamarin-macios/issues/20409.
We have a minor behavioral difference between bgen and csc:
* In bgen, `--warnaserror:` enables all warnings.
* In csc, `--warnaserror:` does nothing.
So we now pass:
* `--warnaserror:` to bgen.
* `--warnaserror+` to csc.
Fixes this test failure:
MonoTests.System.Net.Http.MessageHandlerTest.GHIssue16339
[FAIL] GHIssue16339() : ReasonPhrase #1
Expected string length 2 but was 11. Strings differ at index 0.
Expected: "OK"
But was: "Bad Gateway"
Also expose both getter and setter methods using the enum itself, so we don't
have to make getter and setter properties for each of the enum fields.
This required making CGEventField a public enum, so do that.
And finally document all the new APIs, and some of the old ones.
Fixes https://github.com/xamarin/xamarin-macios/issues/12650.
Rolf Bjarne Kvinge
Alexander Köplinger
Matt Sylvia
Matt Sylvia
dotnet-maestro[bot]