Since we have several builds per PR and several comments per build, the
comments sections are getting very noise. To fix that, we use GitHub
GraphQL to query all the comments for a PR (includes PR comments and
commit comments), filter them by user and title and minimize them
accordingly.
The behaviour from apple is wrong, PUT and POST are differnet in that PUT is idempotent.
Calling PUT several times successively has the same effect (that is no side effect),
where successive identical POST may have additional effects
We should not let the native code cache the calls.
* Add the resx file for localization and move error and warning strings
* Change NStrings.resx -> Errors.resx
* using the new namespace
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
It includes a change revert because of threading freeze issues.
An issue has been detected in Xamarin.Messaging 1.5.26 and 1.6.1 that makes the code unstable and sensitive to thread freeze issues, so we are reverting back the changes until we can stabilize it.
This delays the fix of a bug in MSBuild command line builds for iOS remote builds.
Add a few classes that will be later used to create the comments for the
tests.
- GitHubStatus/es: Allows to represent a github status, we are addign a
class per concern.
- TestResults: Contains the information and logic of a test result.
Implements the same interface as the other comment objects so that we
resuse the comment code.
Tests have been added and modified the github action to run on pull
requests too.
* enable nullability
* use is null
* use an empty array
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* [NET Attribute Conversion] Chip Framework
* [NET Attribute Conversion] Rerun with many fixes
* Fix generator crash when compiling attributes with no introduced version
* Test changes for availability re-run. One new test
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.300-preview.22204.3 -> To Version 6.0.300-preview.22205.8
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Microsoft.NETCore.App.Ref
From Version 6.0.4 -> To Version 6.0.5
Dependency coherency updates
Microsoft.NET.Workload.Emscripten.Manifest-6.0.100
From Version 6.0.4 -> To Version 6.0.4 (parent: Microsoft.NETCore.App.Ref
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Ask ditto to thin native libraries and frameworks when copying them to the app
bundle to remove slices for architectures we're not building for.
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/13081.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Problem:
* Assembly A is compiled referencing Microsoft.*.dll v1.0.0.123
* Assembly B is compiled referencing assembly A, and Microsoft.*.dll v1.0.0.0
The C# compiler doesn't like this, and says something like:
> error CS1705: Assembly 'A' with identity 'A, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'Microsoft.iOS, Version=1.0.0.123, Culture=neutral, PublicKeyToken=84e04ff9cfb79065' which has a higher version than referenced assembly 'Microsoft.iOS' with identity 'Microsoft.iOS, Version=1.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
The C# compiler is right: you need all your local references to be at least
the version of any indirect references, otherwise you're compiling using
outdated API.
On the other hand, we know that [1] we don't have any API differences (neither
additions nor removals) between stable versions of assemblies where only the
fourth digit is different.
In that case, the C# compiler error is just making things more complicated for
users, because if a upstream dependency is compiled with a newer (but
API-identical) version of Microsoft.*.dll, it forces all their users to update
as well.
The fix is to always use '0' as the fourth digit. That way the C# compiler
will accept different versions of any API-identical assemblies, and everybody
is happy [2].
[1]: We know that we _shouldn't_ have API changes when the fourth digit
changes. Hopefully we won't make any mistakes here...
[2]: However, for people using preview versions, there may very well be API
differences when the fourth digit changes. In that case, you're own your own,
and if the build breaks, you get to guess the actual problem and then figure
out the fix (which would usually be to use the latest version of the preview).
This also meant:
* Using 'latest' as the C# language version for all msbuild/ project files.
* Enabling warnaserror for nullability warnings.
* Fix any nullability warnings in the CompileAppManifest files.
* Fix a nullability warning in the Ditto task.
* Fix any '== null' or '!= null' to use 'is null' and 'is not null'.
Fixes this warning:
> Microsoft.MacCatalyst: The internal attribute name 'LinkerSafeAttribute' being used in the xml is not supported by the linker, check the spelling and the supported internal attributes.
It also probably fixes removal of the [Field] attribute.
* add another nullability change
* Throw better exceptions
* use is null and is not null
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>