We have noticed that the azure upload steps fail when they are executed
in a on prem windows machine. The infra team does not know what this is
happening. To work around it we are taking the following stes:
- Move the upload to a hosted image, which does work.
- Donot download all artefacts, since hosted images only have a 10 gb
hdd. We download all but the not needed files using negative match
patterns.
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.Workload.Emscripten.net7.Manifest-7.0.100**: from 7.0.2 to 7.0.2 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230109.16
- **Date Produced**: January 10, 2023 8:35:10 AM UTC
- **Commit**: 2f7c3f4a4f4a49362055d45751756eb4224c7414
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.3 to 7.0.3][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100**: [from 7.0.2 to 7.0.2][4]
[3]: a790868...2f7c3f4
[4]: d71ea7c...00fbd97
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Add an SdkDevPath property to the DSymUtil task, and use it to set DEVELOPER_DIR when calling dsymutil.
Should fix this:
> xcrun: error: unable to find utility "dsymutil", not a developer tool or in PATH
when `xcode-select -p` and VSMac are configured with two different Xcodes.
We no longer need two have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
First out is the Mmp task.
Add support to xtro-sharpie for where to look for referenced assemblies, and
adjust assembly resolution to only look in those directories.
This makes sure xtro-sharpie loads the expected references, and fixes a
problem where the (broken) assembly resolution wouldn't find a .NET assembly
because it doesn't exist in legacy Xamarin (where it would look by default).
Fixes this problem that showed up in a different PR (due to new .NET API
referencing the System.Runtime.Loader assembly, which doesn't exist in legacy
Xamarin):
mono64 --debug bin/Debug/xtro-sharpie.exe --output-directory api-annotations-dotnet appletvos16.1-arm64.pch ../../_build/Microsoft.tvOS.Runtime.tvos-arm64/runtimes/tvos-arm64/lib/net7.0/Microsoft.tvOS.dll
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Runtime.Loader, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name, Mono.Cecil.ReaderParameters parameters) [0x000ff] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:172
at Mono.Cecil.BaseAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x00000] in C:\src\cecil\Mono.Cecil\BaseAssemblyResolver.cs:117
at Mono.Cecil.DefaultAssemblyResolver.Resolve (Mono.Cecil.AssemblyNameReference name) [0x0001d] in C:\src\cecil\Mono.Cecil\DefaultAssemblyResolver.cs:33
at Mono.Cecil.MetadataResolver.Resolve (Mono.Cecil.TypeReference type) [0x0003a] in C:\src\cecil\Mono.Cecil\MetadataResolver.cs:110
at Mono.Cecil.ModuleDefinition.Resolve (Mono.Cecil.TypeReference type) [0x00000] in C:\src\cecil\Mono.Cecil\ModuleDefinition.cs:748
at Mono.Cecil.TypeReference.Resolve () [0x0000f] in C:\src\cecil\Mono.Cecil\TypeReference.cs:280
at Extrospection.Helpers.GetName (Mono.Cecil.MethodDefinition self) [0x00051] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Helpers.cs:332
at Extrospection.DesignatedInitializerCheck.VisitManagedMethod (Mono.Cecil.MethodDefinition method) [0x00001] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/DesignatedInitializerCheck.cs:43
at Extrospection.AssemblyReader.ProcessType (Extrospection.BaseVisitor v, Mono.Cecil.TypeDefinition type) [0x0002b] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:104
at Extrospection.AssemblyReader.Process () [0x0008e] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:93
at Extrospection.Runner.Execute (System.String pchFile, System.Collections.Generic.IEnumerable`1[T] assemblyNames, System.String outputDirectory) [0x001af] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Runner.cs:52
at Extrospection.MainClass.Main (System.String[] arguments) [0x0008f] in /Users/rolf/work/maccore/whatever/xamarin-macios/tests/xtro-sharpie/Program.cs:28
make: *** [.stamp-dotnet-classify-tvOS] Error 1
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
In .NET, we changed the API for creating a NSTextList with a specified
NSTextListMarkerFormats, making NSTextListMarkerFormats a strongly typed enum,
and not allowing any other value except those in NSTextListMarkerFormats.
This was a mistake, because NSTextList can be created with other format values
than those available in NSTextListMarkerFormats.
So fix this by:
* Adding another NSTextListMarkerFormats enum value that specifies that the
actual format is a custom one (NSTextListMarkerFormats.CustomString).
* Resurface an 'NSTextListMarkerFormats(string)' constructor that can be used
to create an NSTextListMarkerFormats with a custom string.
* Add a NSTextListMarkerFormats.CustomMarkerFormat property that always
retrieves the underlying string value for the format.
* Add a NSTextListOptions.None enum value, which means no options (since
NSTextListOptions is a set of flags, it should be possible to specify no
flags).
* Add two convenience constructors that don't take a NSTextListOptions value,
defaulting to NSTextListOptions.None.
* Add tests!
Fixes https://github.com/xamarin/xamarin-macios/issues/15766.
Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.
Co-authored-by: csigs <csigs@users.noreply.github.com>
Co-authored-by: CSIGS <csigs@outlook.com>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
* If there's both an UnsupportedOSPlatform and ObsoletedOSPlatform attribute with
the same version, then remove the UnsupportedOSPlatform attribute. This is because
in the past we used [UnsupportedOSPlatform] + [Obsolete] to indicate that an API
is obsolete, but then the [ObsoletedOSPlatform] attribute was added, and we replaced
the [Obsolete] attributes with [ObsoletedOSPlatform] attributes, which makes the
[UnsupportedOSPlatform] attributes redundant/incorrect.
* If there's [UnsupportedOSPlatform] with a version or [ObsoletedOSPlatform] with
a version, then also add [SupportedOSPlatform] in a few cases.
* If there's an [UnsupportedOSPlatform] with a version for API that's obsolete/non-working,
then remove the version.
Closes#16822
This PR adds an F# template to the basic Microsoft.iOS.iOSApp template.
This should allow being able to do either:
```
dotnet new ios -lang C# -n MyApp
dotnet new ios -lang F# -n MyApp
```
I had to move the C# template into a `csharp` folder.
Also added the `groupIdentity` `Microsoft.iOS.iOSApp` and set the identity for both C# and F# respectively to `Microsoft.iOS.iOSApp.CSharp` and `Microsoft.iOS.iOSApp.FSharp`
Co-authored-by: Timothé LARIVIERE <timothe.lariviere@fundourselves.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
NSWindow.ReleasedWhenClosed is a rather annoying API, because it interferes with
reference counting. In effect it behaves kind of like autoreleasing does, except
that the object (window) is released at a different time (when the window is closed,
as opposed to when the autorelease pool drains).
We've tried to fix this in the past in several ways:
* Forcefully disable ReleasedWhenClosed in all the constructors, and if it's set
in the Close method, then add an extra Retain call to offset the imminent extra
release. The unfortunate side-effect is that we also call Dispose, which might
be too early (see #8606).
* Rewrite the code to correctly override the native 'close' method, so we get the
supposedly correct semantics (our special Close code is called) when the window
is closed by Objective-C (for instance when the user hits the red X to close the
window). This doesn't really solve the previous problem (we're calling Dispose
too early), and it doesn't work for non-subclassed NSWindows (see #8717).
So I'm trying another approach: track the value of ReleasedWhenClosed, and call Retain/Release
when the value switches between true/false. This way we don't need any special logic
in the Close method.
I've also:
* Marked the ReleasedWhenClosed property as obsolete, and added a DangerousReleasedWhenClosed
property, to match how we bind the other reference counting methods (retain ->
DangerousRetain, release -> DangerousRelease, etc.).
* Added a ReleaseWhenClosed(bool) method, to be called instead of the ReleasedWhenClosed
property, and this method will call DangerousRetain/DangerousRelease as described
above when the ReleasedWhenClosed property changes value.
This new tracking behavior is opt-in for now, but will become opt-out in .NET 9,
and hopefully we'll be able to make it the only behavior at some point (in .NET 10
maybe?).
Fixes https://github.com/xamarin/xamarin-macios/issues/8606.
Fixes https://github.com/xamarin/xamarin-macios/issues/8607.
Ref: https://github.com/xamarin/xamarin-macios/pull/8717.
Fixes#16865
```
➜ test dotnet build -bl:msbuild.binlog
MSBuild version 17.3.2+561848881 for .NET
/usr/local/share/dotnet/sdk/6.0.403/MSBuild.dll -bl:msbuild.binlog -consoleloggerparameters:Summary -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll -maxcpucount -restore -verbosity:m ./test.csproj
Determining projects to restore...
All projects are up-to-date for restore.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
Build FAILED.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.14
```
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Added GetterExceptionTest, which examines IL of Property Getters for exceptions.
Fixes#16669
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Completely remove a workaround for an issue with the thread pool in Mono.
We've previously turned this workaround off by default, and we got no reports
of any problems.
Fixes https://github.com/xamarin/xamarin-macios/issues/7080.
Move the remaining field in NSAttributedStringDocumentReadingOptionKeys into
NSAttributedStringDocumentReadingOptionKey to share more code, and update code
accordingly.
Also remove redundant [Internal] attributes on
NSAttributedStringDocumentReadingOptionKey fields, because the type itself is
[Internal].
This has no effect on public API, because it's all internal.
Fixes:
xamarin-macios/tests/framework-test/dotnet/shared.csproj(43,3): warning MSB4011: "xamarin-macios/tests/nunit.framework.targets" cannot be imported again. It was already imported at "xamarin-macios/tests/common/shared-dotnet.csproj (69,2)". This is most likely a build authoring error. This subsequent import will be ignored.
Rolf Bjarne Kvinge
Manuel de la Pena
dotnet-maestro[bot]
Steve Hawley
Mauro Agnoletti
github-actions[bot]
TJ Lambert
VS MobileTools Engineering Service 2
Timothé Larivière
Andoni Morales Alastruey
dustin-wojciechowski