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>
This change allows cascading pipelines to download the configuration
file and use it rather than recalculating the configuration. This is the
first step to ensure that cascading pipelines use the same config, a
second one is needed to load the configuration in those pipelines.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Few comments:
1. Extends cannot be used on templates. So we have to do a single extend
and have duplicated code.
2. There are some common templates that we are working around using the
use1ES parameter.
3. We are reusing the configure steps on other pipelines. That step
should only be done in the build, that change is too big for this PR.
4. The governance template is not longer needed since the 1ES template
provides it.
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
In addition to being good by itself, by fixing all the resulting nullability
warnings, this random problem goes away:
Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
at xsiminstaller.MainClass.Main (System.String[] args) [0x006ca] in /Users/builder/azdo/_work/4/s/xamarin-macios/tools/siminstaller/Program.cs:228
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
at xsiminstaller.MainClass.Main (System.String[] args) [0x006ca] in /Users/builder/azdo/_work/4/s/xamarin-macios/tools/siminstaller/Program.cs:228
Also use HttpClient instead of WebClient (which is deprecated).
Change how we compute DTPlatformName so that it's 'macosx' for Mac Catalyst.
The PlatformUtils.GetTargetPlatform returns SdkPlatform for all platforms
except Mac Catalyst, where it returns the same as for macOS (i.e. 'macosx').
It also returns a lowercased value, so we don't need to do that either.
This is a partial fix for https://github.com/xamarin/xamarin-macios/issues/20714.
The api diff generates a number of artefacts that are not released. The
way it works is that it compiles the project twice and compares the
reuslts, therefore it has no dependency on the build pipeline or in the
tests. Moving the step to its own pipeline simplifies the migration to
the 1ES template AND allows use to identify exactly what failed.
The two new pipelines are:
- ci:
https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=9690468&view=results
- pr: https://dev.azure.com/devdiv/DevDiv/_build?definitionId=22268
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This check is redundant now, because the post-build test pipeline just
won't run in this case.
This fixes an issue where the GitHub comment reports 0 tests passing,
because we'd detect that the tests failed to build even when they didn't.
There is no need to pass the GIT_HASH variable from job to job since it
is calculated by the checkout template in the fix_commit step. We just
need to update the variables usage.
The Xcode 16 release notes have this note:
CFNetwork Resolved Issues
* Fixed: CFNetworkExecuteProxyAutoConfigurationScript and
CFNetworkExecuteProxyAutoConfigurationURL have always returned a +1
retained CF type object, but the function declarations were not
decorated with the CF_RETURNS_RETAINED attribute until iOS 18, macOS 15,
tvOS 18, and visionOS 2.
For C-based languages, the clang static analyzer might note if the
object is leaked. No source code changes are required, but they are
encouraged to fix the leak.
For Swift, this changes the return type of these functions from
Unmanaged<> to the actual CF type returned, which will require a source
change to fix when compiling with newer SDKs. However, Swift programs
compiled with older SDKs will continue to work on the new OSes, though
the returned CF type object will continue to leak as it did prior to
this change. (126154509)
So update our code accordingly to take into account that
CFNetworkExecuteProxyAutoConfigurationScript and
CFNetworkExecuteProxyAutoConfigurationURL return retained objects.
In these cases the APIs in question aren't used in P/Invokes at the moment,
but that may change, so just make as much as we can blittable by removing any
MarshalAs attributes.
Rolf Bjarne Kvinge
Manuel de la Pena
dotnet-maestro[bot]
Mike Bond
Emanuel Fernandez Dell'Oca