Once upon a time we needed to special case a higher min OS version that the
min OS version we supported for certain compiler/linker arguments, because we
used features not supported in the min OS version we supported.
That time has passed; in all cases our min OS version is now higher than the
special-cased min OS versions passed to native compilers/linkers, so we can
just use the actual min OS version we support.
This deduplicates some code, and also ensures we specifiy a max limit to the
level of parallelism. This fixes an issue in the AOTCompile and ScnTool tasks,
where we'd have no limit, launching as many subprocesses as tasks there are to
execute. In particular for the AOTCompile task, this can put a rather heavy
burden on build machines, slowing everything down to a crawl.
Fixes https://github.com/xamarin/xamarin-macios/issues/20210.
We've recently had a few test failures like this:
MonoTests.System.Net.Http.MessageHandlerTest.GHIssue16339
[FAIL] GHIssue16339() : IsSuccessStatusCode #1
Expected: True
But was: False
which doesn't provide much info into what went wrong.
It turns out this particular assert for IsSuccessStatusCode is redundant,
because we assert on the exact StatusCode a bit later, and if that assert
fails, we'll know a bit more.
So just remove this redundant assert for IsSuccessStatusCode.
NSObject.CreateNSObject is trimmer-safe, we tell the trimmer(s) about any
types we'd want to create so they're all available.
Contributes towards #10405.
If a project tried to use a .NET 9 project (say TargetFramework=net9.0-ios), then
we used to show these rather unhelpful errors:
error NETSDK1147: The target platform identifier ios was not recognized.
The underlying problem is that we don't support .NET 9 yet, so with this fix we now show:
error NETSDK1202: The current .NET SDK does not support targeting .NET 9.0. Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0. Download the .NET SDK from https://aka.ms/dotnet/download
which is much more helpful.
This is accomplished by loading our workload even when using newer .NET
versions we don't support, because the .NET build logic will show the better
error later on.
The generator needs these attributes in certain cases when a third-party library implements a protocol that subclasses a platform protocol where members of the platform protocol has members with parameters with these attributes.
That's a rather long sentence: in fact there are fewer words in the test verifying this behavior!
We currently have an issue with codesigning duplicated files in parallel
(#20193). The proper fix is somewhat complex, so this implements a simple
workaround for customers, where they can just disable parallelism if they run
into this problem (and since it's simple, it's easier to backport too).
Additionally, it's not a bad idea to be able to configure the level of parallelism.
Ref: #20193.
Bumps
[peterjgrainger/action-create-branch](https://github.com/peterjgrainger/action-create-branch)
from 2.4.0 to 3.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/peterjgrainger/action-create-branch/releases">peterjgrainger/action-create-branch's
releases</a>.</em></p>
<blockquote>
<h2>v3.0.0</h2>
<p>Change node 16 to node 20 fixes <a
href="https://redirect.github.com/peterjgrainger/action-create-branch/issues/394">#394</a></p>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/peterjgrainger/action-create-branch/compare/v2.4.0...v3.0.0">https://github.com/peterjgrainger/action-create-branch/compare/v2.4.0...v3.0.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="10c7d26815"><code>10c7d26</code></a>
update to node 20</li>
<li>See full diff in <a
href="https://github.com/peterjgrainger/action-create-branch/compare/v2.4.0...v3.0.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
We have split the workloads in two pools:
1. VSEngSS-MicroBuild2022-1ES - Signing dedicated.
2. MAUI-1ESPT - APIScan dedicated.
This allows to manage machines better and we could request better
machines if needed for APIScan.
If we copy a file back to Windows during the remote build, we don't want to
also create the output file, because then we'll just replace the file we
copied with a zero-length version.
* Enumerate files and directories instead of fetching them all in one go. This
is more efficient when there are a lot of files and directories to process,
but most importantly it'll also make enumeration cancellable.
* Stop enumerating if cancellation was requested.
* Add a few logging statements.
This might at least help to get better diagnostic information if for some
reason this task takes too long to execute. Ref: #20183.
The extracted files show up in the build later on, and if only the 0-length
mirror file exists on Windows, it'll be copied as such to the Mac, producing
incorrect build results.
Of course all our public APIs aren't documented, so there's a *huge* list
of known failures.
But at least this way we won't add more undocumented APIs by accident
(although new APIs will show up every time we add more bindings, in particular
in Xcode season).
---------
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
This particular condition shouldn't happen, but occasional build errors in the
wild (with exception stack traces) seem to indicate otherwise, so be a bit
defensive here.
Add multi-targeting support for our initial .NET 8 packs (for Xcode
15.0).
This means a library/binding project can do:
```xml
<TargetFrameworks>net8.0-ios17.0;net8.0-ios17.2</TargetFrameworks>
```
and the library will be built in two varieties: once using our iOS 17.0
bindings, and once using our iOS 17.2 bindings.
An app project can also do:
```xml
<TargetFramework>net8.0-ios17.0</TargetFramework>
```
to build with the iOS 17.0 bindings (which is typically not very useful,
since building with the latest iOS SDK is usually best).
This makes the linker able to trim away a few methods that aren't trim-safe
when using the managed static registrar (and thus not warn about these methods
doing un-trimmable stuff).
Contributes towards #10405.
Fixes https://github.com/xamarin/xamarin-macios/issues/18968
We provide a mapping to the checked in source files via SourceLink.json
and the rest of the generated/untracked sources are embedded into the
PDB to provide a more comprehensive debugging experience. Since we
invoke CSC directly, there were a few workarounds that had to be
implemented (ex: implementing a helper script to account for untracked
sources instead of simply using the EmbedUntrackedSources MSBuild
property).
As for testing, the newly added support was validated via the dotnet
sourcelink tool which confirmed all the sources in the PDB either had
valid urls or were embedded.
`sourcelink test Microsoft.MacCatalyst.pdb` —> `sourcelink test passed:
Microsoft.MacCatalyst.pdb`
The PDB size does increase in size after embedding;
Microsoft.MacCatalyst.pdb went from 5 MB to 15.7 MB.
But considering it would significantly help improve the debugging
experience, be consistent with Android’s offerings, and it’s a
highlighted attribute on the NuGet package explorer I think it’s a
worthy size increase.
Refs:
https://github.com/xamarin/xamarin-android/pull/7298https://github.com/dotnet/roslyn/issues/12625https://github.com/dotnet/sourcelink/tree/main/docs
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Michael Cummings (MSFT) <mcumming@microsoft.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
DevOps automatically sets statuses as the pipeline progresses, so we
don't have to.
This fixes a problem where we'd have multiple statuses for each thing we
do:
Note how the macOS .NET tests have two statuses, one pending and one
failure. This is because it failed once (thus the failure), and was then
rerun (thus pending). This has a few issues:
1. The statuses don't match... which can be confusing. Are we running or
did we fail? YES! 🤔
2. We have more than one status for each thing, which is redundant.
So just don't add our own statuses, because Azure DevOps will.
Note that we still add statuses with package links.
The stage attempt number increases every time the entire stage is rerun
(which
must happen for the Windows tests stage for instance, but can happen for
other
stages as well).
This paves the way for collecting test results from multiple stages (and
eventually we'll have a single GitHub comment with all the test results,
instead of multiple comments like we have now).
Rolf Bjarne Kvinge
dependabot[bot]
dotnet-maestro[bot]
Manuel de la Pena
Yauheni Pakala
Haritha Mohan