The main reason why we use the Tcp Tunnel is because we do have
networking issues, one of them is related to the DNS server. If we use
the tunnel we have made a choice and we are sure we will not need the
IPs.
This solves a case in which we have a network failure when we try
to retrieve the IP address using the DNS lookup.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Make sure to free the weak GCHandles we create to track NSObjects, just
removing them from our dictionary doesn't cut it.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Remove the need to check if we are in a PR, just execute the translations when we are in main, that reduces the complexity of the condition and works.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
With P3 addition on ICU we must now link the native executable as C++.
Remove an old workaround, in many tests, referencing old (5.0/previews)
packages that caused native link time failures.
ref: https://github.com/mono/linker/issues/1139
The main reason why we use the Tcp Tunnel is because we do have
networking issues, one of them is related to the DNS server. If we use
the tunnel we have made a choice and we are sure we will not need the
IPs.
This solves a case in which we have a network failure when we try
to retrieve the IP address using the DNS lookup.
VSTS does not longer have a file with the pat yet it does allow to use
an env variable with the pat provided by the keyvault. Before this
change we have been running all the tests which results in several extra
hours when we do not need to. For example, if nothing was changed in
msbuild, do not run its tests which are 45 mins long.
Changes are:
* provide pat in the env.
* update xharness to use an env var, do not longer read from a file.
fixes: https://github.com/xamarin/xamarin-macios/issues/10923
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We started using `$(SuppressTrimAnalysisWarnings)` by default, because
ILLink started emitting warnings by default in .NET 6 Preview 3.
7bf3e8d8 fixed *most* of these warnings except for `IL2026`:
16aedd6e72/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets (L52-L57)
I get around 20 instances of this warning when building dotnet/maui.
`IL2026` occurs because this logic is evaluated much earlier than the
`PrepareForILLink` MSBuild target:
16aedd6e72/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets (L202)
The MSBuild evaluation order right now is:
* Sdk/Sdk.props
* Microsoft.[platform].Sdk.props
* Xamarin.Shared.Sdk.props
* Microsoft.NET.ILLink.targets
* Microsoft.[platform].Sdk.targets
* Xamarin.Shared.Sdk.targets
We need to set `$(SuppressTrimAnalysisWarnings)` earlier in
`Xamarin.Shared.Sdk.props` to solve the issue here.
On the Android side I got lucky, and it worked first try without
thinking too much. We import a `*.DefaultProperties.targets` before
`Microsoft.NET.ILLink.targets`, and that is why it worked.
VSTS does not longer have a file with the pat yet it does allow to use
an env variable with the pat provided by the keyvault. Before this
change we have been running all the tests which results in several extra
hours when we do not need to. For example, if nothing was changed in
msbuild, do not run its tests which are 45 mins long.
Changes are:
* provide pat in the env.
* update xharness to use an env var, do not longer read from a file.
fixes: https://github.com/xamarin/xamarin-macios/issues/10923
The implementation will be completely different, where the hook into CoreCLR
is in managed code.
We still need to initialize the framework_peer_release_lock mutex, so move
that code out of gc_enable_new_refcount.
Those are called respectively inside `xamarin_vm_initialize` and
`xamarin_bridge_initialize` functions.
This fix the **AppContext.GetData always return null for iOS** issue
https://github.com/dotnet/runtime/issues/50290
Thanks for @filipnavara for diagnosing this quicker than anyone else!
Added unit tests to ensure `AppContext.GetData` can read back the values
we're providing at startup.
Fixes: https://github.com/xamarin/xamarin-macios/issues/10887
After bumping to .NET 6 Preview 3, we get hundreds of ILLINK warnings.
This is because of:
https://github.com/dotnet/sdk/pull/16327
We need to default `$(SuppressTrimAnalysisWarnings)` to ignore these
warnings for now.
We should continue to use `TrimMode=link`, as that is the behavior
Xamarin developers get today.
The type implementation of an interface member does not need to be
`virtual` but, since it's done by _sealing_ the member.
Example
```diff
public virtual ---final--- int Count { get; }
```
* Link FrameworkList.xml to a place where MSBuild SDK actually expects it
* Create necessary directories
* Fix symlinks for packaging
* Add test case
* Minor tweak to test case
* Fix cut & paste error
Co-authored-by: Filip Navara <navara@emclient.com>
Sometimes msbuild wants to restore packages during this process, which may
take a while.
Hopefully fixes errors like this:
Harness exception for 'Tests for C6353E8B-BFDA-4F54-93D9-FF0F838BF8EE': System.Exception: Unable to evaluate the property OutputPath.
at Xharness.AppBundleLocator.GetPropertyByMSBuildEvaluationAsync (System.Xml.XmlDocument csproj, System.String projectPath, System.String evaluateProperty, System.String dependsOnTargets, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x00327] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:109
at Xharness.AppBundleLocator.LocateAppBundle (System.Xml.XmlDocument projectFile, System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x000d2] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:49
at Microsoft.DotNet.XHarness.iOS.Shared.AppBundleInformationParser.ParseFromProject (System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x00147] in /_/src/Microsoft.DotNet.XHarness.iOS.Shared/AppBundleInformationParser.cs:71
at Xharness.AppRunner.InitializeAsync () [0x00046] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppRunner.cs:120
at Xharness.Jenkins.TestTasks.RunSimulator.SelectSimulatorAsync () [0x002df] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulator.cs:108
at Xharness.Jenkins.TestTasks.AggregatedRunSimulatorTask.ExecuteAsync () [0x00335] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/AggregatedRunSimulatorTask.cs:63
at Xharness.Jenkins.TestTasks.TestTasks.RunInternalAsync () [0x00226] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/TestTask.cs:283
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This requires a few things:
* [runtime] Add support for generating managed delegates only for CoreCLR.
However, since our managed code is shared between CoreCLR and MonoVM, the
best we can do is to make these CoreCLR-only delegates .NET-only.
* [runtime] Make it possible to implement Mono Embedding API in the CoreCLR bridge
By making it possible to skip the automatically generated Mono Embedding
* [runtime] Add a MonoObject implementation for CoreCLR.
We need a way to represent a managed object in native code, and since most
our existing runtime code uses MonoObjects, we use the same for the
CoreCLR bridge, just our own version of it. In Mono, the MonoObjects are
tracked by the GC (which scans the stack), but we can't make CoreCLR scan
the stack, so we use a reference counted version of MonoObject instead -
we just put the GCHandle into a reference counted MonoObject, and when the
MonoObject is freed, then we free the GCHandle as well.
* Go through all uses of mono_assembly_open, and make sure they release the
returned assembly.
and that requires ensuring all (implicit/explicit) interface members are
generated...
**Example**
Removed interfaces:
```csharp
IARAnchorCopying
Foundation.INSCoding
Foundation.INSCopying
Foundation.INSSecureCoding
```