Added some information to the MacCatalyst templates based on comments from the community
on how to publish MacCatalyst apps on the App Store.
Fixes#17591
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.
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.ILLink.Tasks**: from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.3.23127.13 to
8.0.0-preview.4.23171.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4 (parent: Microsoft.Dotnet.Sdk.Internal)
-
**Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**:
from 8.0.0-preview.2.23113.1 to 8.0.0-preview.3.23167.1 (parent:
Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.23113.1 to
0.11.4-alpha.23163.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230322.3
- **Date Produced**: March 22, 2023 10:38:15 AM UTC
- **Commit**: 27622e389865f58c1d9293a4175f5d8f2cc44a2b
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.3.23157.7 to
8.0.100-preview.4.23172.3][6]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4][7]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.3.23127.13 to
8.0.0-preview.4.23171.7][8]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4][7]
-
**Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**:
[from 8.0.0-preview.2.23113.1 to 8.0.0-preview.3.23167.1][9]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.2.23127.4 to
8.0.0-preview.3.23171.4][7]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.23113.1 to
0.11.4-alpha.23163.1][10]
[6]: 790a290...27622e3
[7]: 2bdc3cb...edb161a
[8]: 3265dc6...16907a1
[9]: d7ff0aa...25d9f7a
[10]: 68e0c35...f32e148
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.
Rolf Bjarne Kvinge
Alex Soto
TJ Lambert
dustin-wojciechowski
Manuel de la Pena
Haritha Mohan
dotnet-maestro[bot]
Peter Collins
Steve Hawley