I have cleaned the yaml files while I was trying to debug the issue with
the provisioning of the simulators on Xcode 16. We should back port this
change there.
Add support for signing with a placeholder key ("-") from the developer,
and then use this to sign the prebuilt HotRestart app this way.
The app will have to be signed anyway on the end user machine, so this
shouldn't have any real effect (I've tested it locally and Hot Restart
still works).
This simplifies our build (both locally and on bots), because we won't
need a certificate around to do the actual signing.
* Remove code to test NWPath.EnumerateInterfaces, because this method is already tested elsewhere.
* Assume that if the test fails to find any gateways, it might be because the
current machine doesn't have any (which happens on one of my machines), and
in that case ignore the test.
Move the architecture-specific vargs implementation of UIAppearance.GetAppareance into a more generic way of calling objc_msgSend with variadic arguments.
This prepares the way for more APIs with variadic arguments (which is coming in Xcode 16).
When building universal apps, each inner build must add the runtime identifier to the output path, otherwise the inner builds may conflict with eachother, overwriting eachother's files.
That's bad.
So we explicitly set `AppendRuntimeIdentifierToOutputPath` to `true` when building inner builds.
* xtro: Fix how we build the u2todo project to actually build the correct project.
* Don't import eng/Versions.props in several test projects, it's already imported in a Directory.Build.props further up the directory hierarchy.
Split installing new and old simulators, so that we can choose to only
install the old simulators if we want so.
And then only install the old simulators when we're doing beta builds,
because that's the only time we need them.
Ignore a few warnings by default, when reporting about types that we
couldn't register because they're deprecated/removed.
Also add a way to re-enable these warnings.
Fixes https://github.com/xamarin/xamarin-macios/issues/20670.
Add a simple makefile to the src/bgen directory that only builds and
tests bgen.
This is very useful when working on bgen to make sure your changes are
at building and working.
Convert all projects except xtro-sharpie.csproj to .NET projects.
xtro-sharpie.csproj can't be converted yet, because it depends on
Objective-Sharpie, which hasn't been converted yet.
Apple says the bug on their side causing a runtime crash has been fixed since
macOS 12, so unignore the code and add a version check for macOS 12.
Fixes https://github.com/xamarin/maccore/issues/2345.
The C# build server makes trouble for us, because:
* We're using parallel make, and parallel make will start a jobserver, managed
by file descriptors, where these file descriptors must be closed in all
subprocesses for make to realize it's done.
* 'dotnet build' might have started a build server
* The build server does not close any file descriptors it may have inherited
when daemonizing itself.
* Thus the build server (which will still be alive after we're done building)
might have a file descriptor open which make is waiting for.
* The proper fix is to fix the build server to close its file descriptors.
* The intermediate working is to shut down the build server instead. An
alternative solution would be to pass /p:UseSharedCompilation=false to
'dotnet pack' to disable the usage of the build server.
* Note that build server will exit automatically after 10 minutes of idle
time, so the hang is only a 10 minute delay at works.
For the siminstaller, which builds using the system .NET, the simplest
solution is to just not use the build server.
This fixes a problem where the build would hang for 10 minutes after running
the system dependency check (which builds and runs siminstaller).
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: 80cb9ffd-f92f-4fc8-9f8b-08dbca46abfb
- **Build**: 20240624.1
- **Date Produced**: June 24, 2024 9:52:55 PM UTC
- **Commit**: 03065cafae0f89b376fa983773e909e341db96c0
- **Branch**: refs/heads/release/8.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.107-servicing.24317.4 to 8.0.107-servicing.24324.1][14]
[14]: de7be3dce6...03065cafae
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
When finding an enumerator for the given code:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
// ...
}
```
the C# compiler will first look for any `GetEnumerator` methods. The non-generic `NSSet` class defines a `IEnumerator<NSObject> GetEnumerator<NSObject> ()` method, which, since the generic `NSSet<T>` class doesn't define such a method, is selected.
The end result is that the type of the foreach element is `NSObject`
(`GetEnumerator`'s return type') - which is somewhat unexpected:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // error CS1061: 'NSObject' does not contain a definition for 'LongValue'
}
```
The fix is to define a `IEnumerator<T> GetEnumerator<T> ()` method in the
generic `NSSet<T>` class, which the C# will find and choose over the base
class' method. Then the type of the foreach element is the correct type, and
the following code works:
```cs
var collection = new NSSet<NSNumber> ();
foreach (var item in collection) {
Console.WriteLine (item.LongValue); // it works!
}
```
Do this for all our generic collection classes.
Also document these methods + all the other public `GetEnumerator` methods.
This way it can easily be overridden when building from the command line (to provide a different url if the normal url doesn't work for some temporary reason).
There's no need to support `RuntimeIdentifiers` (plural) for Hot Restart
(because we don't have any scenarios where multiple runtime identifiers
applies to iOS; a single runtime identifier can always be used).
Adding support would make our code base more complex, so just avoid it by
showing an early error if someone tries (which is likely to be accidental
anyways).
This way we show an actionable error message for a scenario customers will
probably be confused about (because the build would fail in rather
inexplicable ways) if they run into it.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/19262.
This reverts commit f8552e9294.
This change is only supposed to be released with .NET 9, and we might
release new .NET 8 updates from main. Thus we need to make sure these
changes are only in the net9.0 branch (they already are).
We fixed the credscan issue in two diff ways:
1. When the job allows it, we checkout all repos using our own checkout template.
2. When the jib does not allow it, we create an empty json file. In the future we can add any needed exception.
We also needed to fix the signature because the VS code moved to net core which changed the extension of their build.exe to build.dll.
Fix BuildBindingsTest expectations to expect the resources in either a sidecar or a zipped sidecar.
Fixes this test failure:
Xamarin.Tests.DotNetProjectTest.BuildBindingsTest(TVOS): Bundle existence
Expected: file or directory exists
But was: "/Users/builder/azdo/_work/1/s/xamarin-macios/tests/bindings-test/dotnet/tvOS/bin/Debug/net8.0-tvos/bindings-test.resources.zip"
We need the backwards compatible code for the
AVSampleCursorAudioDependencyInfo struct (i.e. use the
AVSampleCursorAudioDependencyInfo_Blittable version), so adjust the ifdefs
accordingly - which wasn't obvious at first, because __IOS__ is defined for
Mac Catalyst.
Also fix the corresponding test, because it would cache the result of
computing whether a struct was blittable or not, but that's not true across
platforms ("AVSampleCursorAudioDependencyInfo" is blittable on iOS, but not on
Mac Catalyst). The result was that the test would incorrectly pass if we
processed Microsoft.iOS.dll before Microsoft.MacCatalyst.dll. The fix is to
cache per platform, instead of using a global cache.
* Set the Architectures array, which Xcode does. This requires passing RuntimeIdentifier(s)
to the task, so do that.
* Set SchemeName, which Xcode does.
This is a partial fix for https://github.com/xamarin/xamarin-macios/issues/20714.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
This is part of the effort to migrate the Pair to Mac agents .NET.
As the Xamarin.iOS.Tasks.Windows project targets netstandard2.0, I'm
removing the Build agent reference, and modifying the Makefile to take
it from it's output directory. Note: the agent zip file is generated in
the intermediate output directory.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Mauro Agnoletti <mauro.agnoletti@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
dotnet-maestro[bot]
Manuel de la Pena
Rolf Bjarne Kvinge
Alex Soto
Mike Bond
Emanuel Fernandez Dell'Oca