AppContext.GetData always return null for iOS #50290
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
Is there any chance that |
No, linker is disabled in my test and I confirmed the version of
Add the test above to any of the unit test we have in our repo (or create your own unit test project). |
|
It's an incorrect initialisation order, likely on Xamarin side. This is where It happens before |
|
Switching these two lines may help (but has to be tested, both on MonoVM and CoreCLR): |
|
@filipnavara thanks, that's worth a try I stopped looking after reading |
|
Yeah, that comment was not accurate: #37240 |
|
A quick local test (mono/iOS sim) seems to work |
|
Tagging subscribers to this area: @CoffeeFlux Issue DetailsDescriptionWe initialize the runtime with some keys, e.g. AFAIK those features works fine at runtime. However if you try to query the keys from managed code then the returned values are always [Test]
public void ___AppContext ()
{
Assert.IsNotNull (AppContext.GetData ("APP_PATHS"), "APP_PATHS");
Assert.IsNotNull (AppContext.GetData ("PINVOKE_OVERRIDE"), "PINVOKE_OVERRIDE");
}I have a feeling that Configuration
Regression?Not sure. We never had to query the values from managed code before. Other informationThis is blocking our work to enable ICU with iOS [1] since the runtime code calls [1] xamarin/xamarin-macios#8906
|
@spouliot Is it safe to close the issue? |
|
Given that Xamarin seems to be calling these in the wrong order, I'm closing since this isn't a runtime issue. If it later turns out to be one, we can always reopen. |
Those are called respectively inside `xamarin_vm_initialize` and `xamarin_bridge_initialize` functions. This fix the **AppContext.GetData always return null for iOS** issue dotnet/runtime#50290 Added unit tests to ensure `AppContext.GetData` can read back the values we're providing at startup.
|
local tests were fine, it's on the bots now... xamarin/xamarin-macios#11014 |
Those are called respectively inside `xamarin_vm_initialize` and `xamarin_bridge_initialize` functions. This fix the **AppContext.GetData always return null for iOS** issue dotnet/runtime#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.
|
I'll confirm in the morning (if that was an issue before the call order change) but we are now failing on device (AOT builds) with: It might also be related to the linker (it's enabled on this project). I'm not sure if |
|
It doesn't have linker attribute but it's listed in the ILLink descriptor file: |
|
Might be related to xamarin/xamarin-macios#10726 |
|
I have the crashing sample running under cc @vargaz anything I can look for since I already have the whole thing set up? |
|
The AOT compiler generates icall wrappers for all icalls registered in the cross compiler. |
|
Yeah, that's what I thought. I'll try to run the AOT process under LLDB and figure out more. |
|
Actually, on second thought there's If the answer is yes, then I guess the cache check in |
|
The removal of string literals is quite recent change: 4cbb1e6 |
Those are called respectively inside `xamarin_vm_initialize` and `xamarin_bridge_initialize` functions. This fix the **AppContext.GetData always return null for iOS** issue dotnet/runtime#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.
ghost
locked as resolved and limited conversation to collaborators
Description
We initialize the runtime with some keys, e.g.
AFAIK those features works fine at runtime.
However if you try to query the keys from managed code then the returned values are always
null. For example that test would fail on the first assertI have a feeling that
AppContext.Setupis never called on the native properties/values so nothing gets exposed to managed code.Configuration
6.0.100-preview.3.21161.23Regression?
Not sure. We never had to query the values from managed code before.
Other information
This is blocking our work to enable ICU with iOS [1] since the runtime code calls
AppContext.GetDatahttps:/dotnet/runtime/pull/49406/files#diff-4a770bb138400e296d16d4bf1e745c2f3a4eafcba26b7b602e87baa623d30fffR10[1] xamarin/xamarin-macios#8906
The text was updated successfully, but these errors were encountered: