Naming could be problematic when generating code, move the logic out of
the generator class to a helper class whose only job is to name classes
and keep track of names.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This pull request updates the following dependencies
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230215.6
- **Date Produced**: February 16, 2023 6:00:46 AM UTC
- **Commit**: b68fd882623b528fd4ef78b122209710f17bacdb
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.4 to 7.0.4][1]
Code is complicated, lets remove as much noise as possible to focus on
the important parts.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Use a class that we can have to store the types and a single place to
locate the types to load.
Later we can use the class to write tests and move to a Dictionary
implementation that passes the tests and is more efficient.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Group all attr methods in the attr manager class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Several changes:
- Refactored AsyncMethodInfo and move the collection extensions out of
the Generator class.
- Added tests for the collection extension methods.
- Fix a mistake/bug in which Last was used instead of LastOrDefault
(funny comment was close to the right reason).
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Move all the string methods that can be an extension to a static class
(re-use the present one) and add tests.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
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 7.0.100-1.22579.2 to 7.0.100-1.23062.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 7.0.2 to 7.0.3 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 50c9492e-4671-4d1d-7920-08dabd1031a2
- **Build**: 20230214.27
- **Date Produced**: February 15, 2023 2:49:17 AM UTC
- **Commit**: 6d3cb5a4f9f758114727bce6a7fd965097a763fa
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.104-servicing.23109.16 to 7.0.104-servicing.23114.27][1]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22579.2 to 7.0.100-1.23062.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.2 to 7.0.3][3]
[1]: 0709aa6...6d3cb5a
[2]: 8db10f4...19fa656
[3]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GC7c81065&targetVersion=GCfebee99&_a=files
We need to use 'DOTNET_MANIFEST_VERSION_BAND' instead of
'DOTNET_VERSION_BAND', because the former always ends with '00' (which
manifest version bands are supposed), while the latter can have other numbers
(for instance 7.0.100 vs 7.0.101 - the former is a valid manifest version
band, the latter isn't).
Cleaned some code that could be simpler too.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Remove more indirections that make the code more complicated to follow
that it really needs to be.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Added Ventura machines to macTestConfigurations within both the
build-ci-pipeline and the build-pr-pipelines.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This pull request updates the following dependencies
## From https://github.com/dotnet/runtime
- **Subscription**: 38d2313f-22d5-4062-c8e1-08dabd6d8c77
- **Build**: 20230211.3
- **Date Produced**: February 11, 2023 7:03:02 PM UTC
- **Commit**: a1136a901d67e88d070136b6684825285c756eef
- **Branch**: refs/heads/release/7.0
- **Updates**:
- **Microsoft.NETCore.App.Ref**: [from 7.0.3 to 7.0.4][10]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100**: [from 7.0.3 to 7.0.4][11]
[10]: 7db1c33...a1136a9
[11]: 67006e8...ba16583
## 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.3 to 7.0.4 (parent: Microsoft.NETCore.App.Ref)
Updates the pinvokes in CoreFoundation to have blittable types.
I intentionally did *not* do `CFReadStream` and `CFWriteStream` as the
changes needed for those are may create a breaking API change, so those
should probably be their own PR for closer scrutiny.
Please look closely at CFProxySupport as that was the least
straightforward of the changes.
Modify the code to add Xcode (DT*) variables to the Info.plist:
* Do it for all platforms, not only mobile platforms. Apple uses these fields to
determine if an app was built with a prerelease or old version of Xcode, and will
reject any app submissions if this validation fails.
* Change the behavior to do not distinguish simulator builds, a bit of testing
in Xcode shows that Xcode always adds these values to the Info.plist, even for
simulator builds. This is probably something that changed in Xcode a *long* time
ago, since this code is old (from the initial import of the build logic from MonoDevelop
around 10 years ago).
* Also bump Xamarin.MacDev to get a related fix:
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@74c95ee [Xamarin.MacDev] Always fetch the DTSDKBuild variable.
Diff: 14d53612d4..74c95ee1c3
Fixes https://github.com/xamarin/xamarin-macios/issues/13300.
This is needed in order to read the correct value of the
"IsHotRestartBuild" property set by the VS extension. Doing it in a
PropertyGroup at evaluation was not getting the correct value since it
was not being set as an MSBuild global property
This PR is related to this other one in the XVS extension:
https://github.com/xamarin/XamarinVS/pull/13612
This will allow the latest runtime identifier values to be evaluated in time during the MSBuild property evaluation phase.
Related and dependent of this PR: https://github.com/xamarin/XamarinVS/pull/13606
Use a make template for the build logic for our platform assemblies, so that we don't
unintentionally have slightly different build code for different platforms (especially
when making changes to the build this way ensures that we make the same change on all
platforms).
This also makes the code significantly shorter, and will make it easier to add more
platforms in the future if we ever need that.
Manuel de la Pena
dotnet-maestro[bot]
Rolf Bjarne Kvinge
Haritha Mohan
dustin-wojciechowski
Steve Hawley
Emanuel Fernandez Dell'Oca
github-actions[bot]
Mauro Agnoletti