Implement a GitHub action to automatically format our source code.
This is implemented in two steps:
1. A restricted action is used to check if the code has any formatting issues, and if so, creates a patch to fix the code.
2. Another action is used to commit and push the patch (and add a comment to the PR notifying the submitter about the problems found).
This is because the first action will call 'dotnet format', which might be insecure in that it can execute code from the repository. This is not safe in a context that is allowed to push commits (because there are secrets in the environment) - so anyone could create a PR that would be executed as a part of 'dotnet format' and then look for our secrets and make them public. The restricted action's environment does not have any secrets, and it's thus safe to execute random code.
The second action will only execute if the corresponding file is in main, so this PR need to be merged before this can be fully implemented, and as such I've made the autoformatting opt-in (by adding the `actions-enable-autoformat` label). Once everything is confirmed to work properly, it will become opt-out instead.
Also, for now only a very simple project is autoformatted (xibuild.csproj), but the
idea is to fix source code incrementally, and add to the list of projects/code
we autoformat.
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.AspNetCore.App.Ref**: from 6.0.5 to 6.0.9 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: be6e1947-9e64-4217-c50e-08da52a3899f
- **Build**: 20220915.1
- **Date Produced**: September 15, 2022 7:51:35 AM UTC
- **Commit**: 1c38151cabb5771a1503aff6e5cecb435be4c69c
- **Branch**: refs/heads/release/6.0.4xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.301-rtm.22280.1 to 6.0.402-servicing.22465.1][147]
- **Microsoft.AspNetCore.App.Ref**: [from 6.0.5 to 6.0.9][148]
[147]: 283e9cf...1c38151
[148]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GCe5f183b&targetVersion=GC3fe12b9&_a=files
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Because we use mtouch and mmp to build the partial static registrar code for .NET.
Eventually we'll look into generating the partial static registrar some other
way, but that's for another time.
Adds missing css files needed on Maui Blazor apps and avoids copying unnecessary files into the bundle (overdue task since the .NET migration).
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The 'Expand tests.' step sometimes fails with:
> ##[error]Bash exited with code '1'.
Which is very unhelpful. Make bash more verbose to see if we can figure out what's going wrong.
Otherwise this happens if the directory is empty:
+ test -d /Users/runner/Library/Logs/DiagnosticReports
+ zip -9rj /Users/runner/work/1/s/crash-reports.zip /Users/runner/Library/Logs/DiagnosticReports
zip error: Nothing to do! (try: zip -9rj /Users/runner/work/1/s/crash-reports.zip . -i /Users/runner/Library/Logs/DiagnosticReports)
Don't try to publish test results unless there are any tests results.
Fixes this [horribly/amusingly incorrect error][1] in the publish task:
##[error]Error: Failed find: ENOENT: no such file or directory, lstat '/System/Library/Frameworks/iTunesLibrary.framework/Versions/Versions'
##[section]Finishing: Publish NUnit Device Test Results
Also stop failing the task on failing tests, because we already have another task that fail if there are failing tests (the task that runs the tests).
[1]: https://github.com/microsoft/azure-pipelines-tasks/issues/16786
* Add support for specifying custom entitlements with an MSBuild item group.
* Use this new support to automatically add the 'com.apple.security.cs.allow-jit'
entitlement to .NET desktop apps when building for release, since all apps that
go through notarization will need it in order to be able to use the JIT.
It's possible to override the default behavior by adding something like this to the project file:
<ItemGroup>
<CustomEntitlements Include="com.apple.security.cs.allow-jit" Type="Remove" />
</ItemGroup>
Fixes https://github.com/xamarin/xamarin-macios/issues/15745.
This is the behavior in legacy Xamarin (for mobile projects): if a project
contains a CodesignEntitlements=Entitlements.plist property, we require a
provisioning profile (and failing the build if none is found).
In .NET, the expected behavior is that if a file is in the project directory,
it should be detected automatically and handled accordingly. We didn't do this
for the initial release of .NET, but we implemented it later
(https://github.com/xamarin/xamarin-macios/pull/15729).
However, this turned out to be complicated, because many templates provide an
Entitlements.plist file, and now suddenly just the presence of such a file
would require a provisioning profile, which also means setting up the whole
rigmarole of Apple's certificates and provisioning profiles (and even
potentially getting a paid Apple Developer account).
This usually worked well in legacy Xamarin, because in templates only the
Release configuration would set the CodesignEntitlements=Entitlements.plist
property, and thus we'd only require a provisioning profile for release builds
(and the Entitlements.plist file would be ignored for Debug builds).
Here we change the default behavior when building for .NET so that we only
require a provisioning profile if the Entitlements.plist file is empty (i.e.
doesn't request any entitlements).
I've also implemented an override, where setting the
CodesignRequireProvisioningProfile=true property will override our default
logic.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1613459.
* Move the bash in the yml file to a separate script file to ease reading, writing & debugging.
* Don't install any symlinks if legacy Xamarin isn't enabled.
* Only install the iOS / macOS symlink if the corresponding build is enabled.
Only install the XI and/or XM package if the corresponding part of the build is enabled.
Also don't install either if the legacy Xamarin build is disabled.
Completed the work for CoreGraphics.
One exception is PDFArray.cs which uses `SetupBlockUnsafe` (noted in the
issue)
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
I always have to look through all the namespaces to figure out where a
specific test is, so this simplifies things a bit.
It's also where the tasks themselves are headed at some point.
Fixes this compiler warning:
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(1733,5): warning : ProjectReference 'xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj' was resolved using '.NETFramework,Version=v4.7.2' instead of the project target framework '.NETStandard,Version=v2.0'. This project may not be fully compatible with your project. [xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj]
* Special characters in powershell are rather, hrm, _uncommon_, in that
they're prefixed with a backtick instead of backslash. Fix code accordingly.
* Use 'Write-Debug' instead of 'Write-Host' in a few places.
* Simplified/improved a few debug statements to make them clearer/less redundant.
* Added tabs in a few places to make debug statements indent properly.
* Fixed a typo.
This will increase app size a little bit: the space for the MVID + 4 bytes for each
assembly, but we'll be able to validate and show a helpful error message if the generated
static registrar code does not match the assembly loaded at runtime.
It's also a step toward per-assembly static registration (ref: #12067).
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Chris Hamons
Emanuel Fernandez Dell'Oca
Steve Hawley
Mauro Agnoletti
Haritha Mohan