Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230306.1
- **Date Produced**: March 6, 2023 10:15:46 AM UTC
- **Commit**: 51e06f6931e859f56564556fa6ba519761fa7141
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.2.23108.2 to 8.0.100-preview.3.23156.1][77]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13][79]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4][78]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: [from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1][80]
[77]: 5a84050...51e06f6
[78]: e71a4fb...2bdc3cb
[79]: cec7fbf...3265dc6
[80]: 1d9df33...d7ff0aa
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.2.23107.2 to 8.0.0-preview.3.23127.13 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23107.1 to 8.0.0-preview.2.23127.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100-preview.2**: from 8.0.0-preview.2.23081.3 to 8.0.0-preview.2.23113.1 (parent: Microsoft.NETCore.App.Ref)
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 7.0.100-1.22564.1 to 8.0.100-1.23055.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230113.2
- **Date Produced**: January 13, 2023 12:09:55 PM UTC
- **Commit**: e0284b3f3c72d8f21e4825ed1ac723d2e829d0a5
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.22605.6 to 8.0.100-alpha.1.23063.2][191]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22564.1 to 8.0.100-1.23055.2][192]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7][193]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2][194]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1][195]
[191]: cbc7313...e0284b3
[192]: 13b8d6d...4b3f78c
[193]: 1bee0af...cefc6cc
[194]: dd7fdb7...5da4a9e
[195]: b6656f5...66b9845
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When the autoformatter runs into the '%...%' pattern in *.cs files, it
will re-format the text (to '% ... %'), but that breaks our text replacement
logic. So instead use a valid C# identifier as a replacement token, in which
case the autoformatter won't confuse our replacement logic.
The Xamarin.MacDev.Tasks.sln solution is built with dotnet, while other projects
are still built with msbuild. This becomes a problem when generating Errors.designer.cs,
because depending on the runtime the output is different.
This means that the Errors.designer.cs will sometimes randomly change (depending
on which project re-generated the file), leaving the file modified in git. This is
quite annoying, but it also breaks the api comparison, which depends on the build
not leaving modified files behind. So for now, we generate Errors.designer.cs separately
for Xamarin.MacDev.Tasks.sln to not conflict with the mtouch version.
Also fix capitalization in numerous places to be consistent (it's Errors.designer.cs,
not Errors.Designer.cs).
NuGet seems to struggle with the network on the bots for this particular test,
so ignore the test if there are any nuget failures.
Fixes https://github.com/xamarin/maccore/issues/2612.
Tests work because other tests do use the nugets and gets picked up by
the runner. Yet, if we execute this projects witjout others, the tests
will fail when trying to use the nunit2 format.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* 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>
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.
Use already existing logic in the Configuration class to find files on disk.
Also remove some dead code and use Path.Combine instead of string
concatenation to compute paths.
Fixes https://github.com/xamarin/maccore/issues/2553.
Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
* Update dependencies from https://github.com/dotnet/installer build 20210530.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21274.3 -> To Version 6.0.100-preview.6.21280.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.5.21271.1 -> To Version 6.0.100-preview.6.21277.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Bump to MSBuild.StructuredLogger v2.1.500 to get support for log format v14.
* [tests] Skip code that needs System.ComponentModel.Composition or System.Json due to #11710.
Ref: https://github.com/xamarin/xamarin-macios/issues/11710
* [tests] Adjust logic to find MSBuild items after the last MSBuild.StructuredLogger update.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This test verifies that the build log prints:
"execution started with arguments: actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist "
However, for M1 machines, we don't call actool directly, we go through 'arch'
instead, and this line is printed:
Tool arch execution started with arguments: -arch arm64e /usr/bin/xcrun actool --errors --warnings --notices --output-format xml1 --output-partial-info-plist ...
So adjust the test to cope with both of these behaviors.
* Bump to .NET 6.0.100-preview.3.21152.10
* Bump to 6.0.100-preview.3.21152.10.
* Bump to 6.0.100-preview.3.21161.7.
* Bump to .NET 6.0.100-preview.3.21161.23.
* [dotnet-linker] Bump ILink and use the supported method of getting an assembly's location.
* Bump to MSBuild.StructuredLogger 2.1.364 to get support for newer binlog versions.
* Fix build failure
Fixes:
TestHelpers/BuildEngine.cs(161,24): error CS0433: The type 'ProjectEvaluationFinishedEventArgs' exists in both 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'StructuredLogger, Version=2.1.0.0, Culture=neutral, PublicKeyToken=d4c7181801cb6448' [/Users/builder/azdo/_work/1/s/xamarin-macios/tests/msbuild/Xamarin.MacDev.Tests/Xamarin.MacDev.Tests.csproj]
* Update parsing binlog properties.
* Be more defensive.
* [tests] Make sure the InternalsVisibleToAttribute constructor isn't linked away.
* [tests] Implement better printing of binlogs.
The latest MSBuild.StructuredLogger made some internal changes to the Message
property which confuses some of our test logic. So implement manual printing
of the log entries that we care about to make sure they conform to the
expected format by the tests (the output is mimicing what 'msbuild /v:diag
foo.binlog' would show).
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
TL&DR: This PR
1. Removes the creation of the `.dSYM` based on `Debug Information` [1]
2. Adds dSYM support to XM msbuild (now shared with XI implementation)
3. Archive the `.dSYM` directories (plural) properly, e.g.
```
msbuild -p:Configuration=Release -p:ArchiveOnBuild=true
```
Why ? The long story...
Historically `.dSYM` for Xamarin.Mac have not been very useful, largely
because (most of) the code is JITed so not much is known before runtime.
So they were simply not generated during the builds...
However AOT options were added to Xamarin.Mac, making them potentially
more useful. Also symbols from `libmono` and other native libraries /
frameworks can prove useful when diagnosing application crashes.
Unsurprisingly developers looking to get symbols eventually found _a way_
[1] to get a `.dSYM` for their applications - but it was not quite
correct because:
* setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had);
* it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks.
* the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution.
[1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log
Additional fixes
* Use `Directory.Move` instead of running the `mv` command
While the result is identical there is a cost to spawn several `mv`
processes. Doing it in parallel (might have) helped but that setup
also comes at a cost.
`Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while
the existing code took 17 ms to do the same.
* Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
Rolf Bjarne Kvinge
Steve Hawley
Alex Soto
dotnet-maestro[bot]
Manuel de la Pena
Sebastien Pouliot
mathieubourgeois