#### Background
While cyclic assembly references are unusual they are supported by the runtime and encountered in practice. In our project we use a version of Xamarin.Forms retargeted for a modern .NET (as a stopgap solution before an update to full MAUI stack). Xamarin.Forms historically come with such an assembly cycle: `Xamarin.Forms.Core.dll` -> `Xamarin.Forms.Platform.dll` -> `Xamarin.Forms.Platform.iOS.dll` -> `Xamarin.Forms.Core.dll`. This is produced by first compiling `Xamarin.Forms.Core.dll` against a dummy `Xamarin.Forms.Platform.dll` (`netstandard2.0` assembly). Then the Platform assemblies are built, and finally forwarder versions of `Xamarin.Forms.Platform.dll` are created for each platform. This is all packaged into NuGets in such a way that each TFM gets the same `Xamarin.Forms.Core.dll` but a different set of `Xamarin.Forms.Platform.dll` and `Xamarin.Forms.Platform.<platform>.dll` assemblies.
#### Problem
With current workloads each incremental rebuild fails with:
```
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.7125/targets/Xamarin.Shared.Sdk.targets(1047,3): error : Encountered an assembly reference cycle related to the assembly obj/Debug/net7.0-ios/iossimulator-arm64/linked/Xamarin.Forms.Core.dll
```
#### Solution
The PR updates the algorithm in `AOTCompile` to detect cycles using [Tarjan's algorithm](https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm) for finding [strongly connected components](https://en.wikipedia.org/wiki/Strongly_connected_component) in a graph. When a cycle is detect any assembly in the cycle is considered up-to-date only if all the assemblies in the cycle are up-to-date.
With this change the project does incremental rebuilds correctly. I verified in the build output that the assembly cycle is considered up-to-date, and that any changes to the application assemblies still return `false` from the up-to-date check and get rebuilt.
---------
Co-authored-by: Filip Navara <filip.navara@gmail.com>
The OneLoc team creates these translations to be consumed later on in
the second step of the Localization process. We need to bring these into
the main branch in order to continue the process.
Co-authored-by: CSIGS@microsoft.com <csigs@users.noreply.github.com>
These are lcl files (first part out of two of the localization process)
that contain the not-yet-usable translations. Bringing these manually
since there is an error in the pipeline that should be bringing these
over.
Prior to changing to the new PAT to help with the automatization, we had
these lcl files waiting to be brought over. It's not clear if the new
PAT is fully working - we will need to wait until more translation codes
are added.
When bringing over the translations in this
[PR](https://github.com/xamarin/xamarin-macios/pull/18105), I brought
over a few and did not notice that the old ones were still there. This
removes the duplicates
Co-authored-by: tj-devel709 <tjlambert@microsoft.com>
As mentioned in this issue:
https://github.com/xamarin/maccore/issues/2658
These are being brought over to main in a PR, but then are automatically
closed by `vs-mobiletools-engineering-service2` as you can see here:
https://github.com/xamarin/xamarin-macios/pull/18036
I am still looking into this peculiar behavior, but am bringing over the
new translations until then!
---------
Co-authored-by: CSIGS <csigs@outlook.com>
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>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Filip Navara
VS MobileTools Engineering Service 2
TJ Lambert
github-actions[bot]