Some changes:
1. Move all the static attr related methods to the attr factory.
2. Make it simpler to see the diff between NET and not by using a
partial class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Set the GenerateRuntimeConfigurationFiles (GRCF) property to true
to avoid warnings at build time + add test for change.
Diving deeper into the fix...
- This warning only occurs with .NET apps which is why GRCF
is only updated in the dotnet directory and not msbuild (legacy)
- After examining the binlog (see issue), it was found that the GRCF
was contingent upon the HasRuntimeOutput property, which is only
defined for executable projects. And in this case, the user's project
output type is library thus both the RuntimeOutput and consequently
GRCF properties were not enabled.
- By setting the GRCF to true we can address the original warning of
concern while ensuring the rest of the projects's behavior is not
altered
in mysterious ways (i.e. by touching the RuntimeOutput property or the
project output type instead, these changes could have extraneous
effects).
Fixes#17543
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Because depending on other options the default can be either 'true' or
'false', and this way we always ask mlaunch to do the right thing.
Also ensure any additional arguments are added last, so they can
override any other argument.
We have some code that verifies a list of failures against a known set of
failures and:
* Fails if any known failure is fixed.
* Fails if there any new (unknown) failures.
Create a helper method that contains this logic, since it's duplicated quite a
few times across various tests.
With a project structure like this:
* Executable project references a library project.
* The library project references a binding project (or assembly).
The binding project's assembly will be copied to the library project's
output directory during the build. Unless we also make sure any binding
resource packages are copied as well, the executable project won't find those,
and the final app won't contain any native bits from the binding project.
The solution is to add any binding resource packages to the list of
files to be copied to the library's output directory.
Fixes https://github.com/xamarin/xamarin-macios/issues/13910.
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 7.0.3 to 7.0.4 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: fffd7604-ce46-455f-0f2f-08db24524baf
- **Build**: 20230320.23
- **Date Produced**: March 21, 2023 6:36:46 AM UTC
- **Commit**: 332c2bc24954c8305a1985bd8e52088cc6b6a677
- **Branch**: refs/heads/release/7.0.2xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.105-servicing.23165.29 to 7.0.203-servicing.23170.23][8]
[8]: f7fbfe4...332c2bc
If there are more than one simulator runtime for a given platform, then
remove all of them.
This will hopefully fix a few problems we're having with hard drive
space issues (we end up with a lot of identical simulator runtimes
downloaded).
Encode the .NET version we're targeting in the third NuGet version number by
adding X000 (where X is the .NET version) to the commit distance.
This accomplishes a few goals:
* We automatically compute a different NuGet version depending on the .NET version we're targeting.
* Versions are sorted correctly (.NET 7 nugets have a higher version number than .NET 6 nugets).
* It's possible to see which .NET version a NuGet is targeting from the version.
The downside is:
* The scheme breaks down if we need more than three digits for the commit
distance (possible solution: add another zero, so we add X0000 instead of
X000).
This is automatically done by 'dotnet build', but we don't use 'dotnet build'
to build our platform assemblies, so we have to do it manually since we want
to use these defines in our code.
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.4 to 7.0.4 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230314.7
- **Date Produced**: March 15, 2023 2:10:03 AM UTC
- **Commit**: 1377e5e24afeb8aa919c3dc9772efcc68e28139c
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.5 to 7.0.5][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100**: [from 7.0.4 to 7.0.4][4]
[3]: ca584ef...1377e5e
[4]: ba16583...3d7178d
It seems we can get different results depending on OS versions, but I had no
success figuring out the conditions that make the results differ, so just
accept all variations we get.
There's not a finite list if measurement units, apps can create their own, so
we have to allow weakly typed measurement units (the normal property is bound
using a strong enum to NSRulerViewUnits).
Fixes https://github.com/xamarin/xamarin-macios/issues/17742.
## siminstaller
We are getting a `System.IO.IOException: Resource busy`
when trying to detach with hdiutil on Ventura. When reaching
this spot we are really done with the mounted resource so
let's force detaching and in the event that it fails let's
just log since at this point the simulator is installed.
## CI
Bump bots to use the Ventura images, and Add `macOSName`
parameter to our yaml templates.
`macOSName` maps to the `macOS.Name` capability in our bots, this
way we can set the macOS name we want to use on the bots in bot build and tests.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Manuel de la Pena
TJ Lambert
Haritha Mohan
Rolf Bjarne Kvinge
Peter Collins
dotnet-maestro[bot]
Steve Hawley
Alex Soto