Skip to content

Incremental builds don't work correctly when changing the UseInterpreter value #21061

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rolfbjarne opened this issue Aug 19, 2024 · 2 comments · Fixed by #22906
Closed

Incremental builds don't work correctly when changing the UseInterpreter value #21061

rolfbjarne opened this issue Aug 19, 2024 · 2 comments · Fixed by #22906
Assignees
Labels
bug If an issue is a bug or a pull request a bug fix
Milestone

Comments

@rolfbjarne
Copy link
Member

From @DominicGenetec on Thu, 15 Aug 2024 12:37:19 GMT

Describe the bug

Net 9 Preview 7, On iOS trying to use in release on a real ios device will prevent the app from launching.

To Reproduce

I'm running everything on a M1 mac.
Install net 9 preview 7
Create an iOS sample using the maui template. (or use the one i've included, see below)
Connect a real phone (not a simulator)
Compile in release and make sure the app is working.

Add this line in the csproj

    <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
          <UseInterpreter>true</UseInterpreter>
    </PropertyGroup>

Notice the app will crash on launch.

Exceptions (if any)

There are no crash log available in the mac Console, the app start and immediately exit.

Further technical details

It work fine on Net 8.
In dot net 9 preview 5, launching in debug on a iphone would also crash the application, but that seems to be fixed in preview 7.

I've made a sample app with the UseInterpreter already added. Open the MauiApp1.sln and launch it in release on a real iOS device.
MauiApp1.zip

Copied from original issue dotnet/sdk#42752

@rolfbjarne

This comment was marked as outdated.

@rolfbjarne
Copy link
Member Author

rolfbjarne commented Aug 20, 2024

I can reproduce a crash with something like this:

cd MauiApp1/MauiApp1/MauiApp1.iOS
git clean -xfd
dotnet build /p:RuntimeIdentifier=ios-arm64 /p:Configuration=Release
touch *.csproj
dotnet build /p:RuntimeIdentifier=ios-arm64 /p:Configuration=Release /p:UseInterpreter=true
# launch

This means that cleaning the project after changing the UseInterpreter condition is a workaround.

@rolfbjarne rolfbjarne added the bug If an issue is a bug or a pull request a bug fix label Aug 20, 2024
@rolfbjarne rolfbjarne added this to the .NET 9 milestone Aug 20, 2024
@github-project-automation github-project-automation bot moved this to Bugs in .NET 9 Aug 27, 2024
@rolfbjarne rolfbjarne modified the milestones: .NET 9, .NET 10 Sep 27, 2024
@rolfbjarne rolfbjarne removed this from .NET 9 Sep 27, 2024
@rolfbjarne rolfbjarne changed the title [iOS] Net 9 Preview 7, iOS app in Release will crash when UseInterpreter is set to true Incremental builds don't work correctly when changing the UseInterpreter value Sep 27, 2024
rolfbjarne added a commit that referenced this issue May 26, 2025
Store the non-file inputs to the AOT compiler in a cache file, and if these inputs
change, then clean the entire cache of AOT-compiled output. This is implemented by
computing a hash of all these inputs (properties), store the hash to a file, and
overwrite the file if the hash changes. Then in a subsequent target, we wipe the
AOT compiler cache if the file with the hash value changed.

This is a similar implementation of how the csc task (C# compiler) creates a hash
of the compiler input in order to know when to re-execute the C# compiler.

Fixes #21061.
@rolfbjarne rolfbjarne self-assigned this May 26, 2025
rolfbjarne added a commit that referenced this issue May 28, 2025
…22906)

Store the non-file inputs to the AOT compiler in a cache file, and if these inputs
change, then clean the entire cache of AOT-compiled output. This is implemented by
computing a hash of all these inputs (properties), store the hash to a file, and
overwrite the file if the hash changes. Then in a subsequent target, we wipe the
AOT compiler cache if the file with the hash value changed.

This is a similar implementation of how the csc task (C# compiler) creates a hash
of the compiler input in order to know when to re-execute the C# compiler.

Fixes #21061.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug If an issue is a bug or a pull request a bug fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant