[ios] Modifying code in library referenced by application results in AOT module loading failure #17708
Comments
|
I can reproduce this. Helper script to reproduce: git clean -xfd
git checkout iOSLibrary/Class1.cs
dotnet build /bl:build1.binlog MissingAOTModule/MissingAOTModule.csproj /p:RuntimeIdentifier=ios-arm64
sed -i '' s/\"test.*\"/\"test2\"/ iOSLibrary/Class1.cs
dotnet build /bl:build2.binlog MissingAOTModule/MissingAOTModule.csproj /p:RuntimeIdentifier=ios-arm64
launch-on-devicebinlogs: |
|
The problem is that when |
|
@kotlarmilos @ivanpovazan does the dedup feature (#17766) mean that if any assembly has changed, then every assembly needs to be AOT-compiled again? |
|
The dedup assembly contains methods which have been removed from other assemblies. The compilation of the dedup assembly has two phases: in the first phase, methods are collected but not emitted, and in the second phase, the collected methods are emitted. If any assembly has changed and AOT compiled with the |
|
@kotlarmilos so basically from the example above:
The rebuild should also reAOT the |
|
Correct. |
If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. Fixes xamarin#17708.
If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. This is a port of the [original fix for main][1] to .NET 8, where we have to take the dedup assembly into account too: if any assembly has changed, then we must re-aot the dedup assembly as well. Fixes xamarin#17708. [1]: xamarin#18509
If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. This is a port of the [original fix for main][1] to .NET 8, where we have to take the dedup assembly into account too: if any assembly has changed, then we must re-aot the dedup assembly as well. Fixes #17708. [1]: #18509 --------- Co-authored-by: Alex Soto <[email protected]>
If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. Note that this PR has a custom port to .NET 8: #18518. Fixes #17708. --------- Co-authored-by: Alex Soto <[email protected]>
If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. Fixes xamarin#17708.
…. (#18654) If an assembly changes, then we must AOT compile that assembly again (which we already did), in addition to any assembly that references the modified assembly (which we didn't do). So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency tracking is too complicated for MSBuild to resolve), and instead move the logic to detect if an assembly must be AOT-compiled again into the AOTCompile task. Fixes #17708. Backport of #18509 --------- Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
|
Is this bug still present in .NET 9 RC2? Because I'm experiencing the same issue. |
|
@marcojak no, this particular bug is fixed in .NET 9. If you're still experiencing it, it's probably a different bug that looks the same, so please file a new issue and we'll have a look. |
Steps to Reproduce
MissingAOTModuleon physical deviceClass1.Something()to anything elseExpected Behavior
Application runs again successfully after performing all steps above.
Actual Behavior
Application fails to run with the following error message:
Environment
Version information
Build Logs
msbuild-binlogs.zip
Example Project (If Possible)
MissingAOTModule.zip
The text was updated successfully, but these errors were encountered: