`dotnet run` immediately crashes while `dotnet build /t:Run` works

[jfversluis]

Android framework version

net10.0-android (Preview)

Affected platform version

SDK 10.0.100-rc.1.25451.107

Description

I am trying to use the dotnet run functionality which should now work instead of dotnet build /t:Run, but while the app seems to deploy it crashes on startup, so there seems to be a difference in behavior between these 2 commands.

This is tested on Windows 11, with .NET 10 RC 1 SDK with an opened Android emulator with API 34 & 36. Testing the same for iOS on macOS works as intended. Update: Running on macOS the results when deploying to Android are the same. That is: dotnet run and the Android app crashes, dotnet build /t:Run and it works.

I added the part that I think is relevant for the log output, I can provide a full log if needed.

Additionally I tried to add -p:AdbTarget=-e as indicated here, but that has no different effect.

Steps to Reproduce

1. dotnet new android (same for dotnet new maui, when executing the run command make sure to include -f net10.0-android)
2. Make sure you have a running Android emulator
3. dotnet run, observe that the app will show the splash screen but then crash
4. dotnet build /t:Run the app will deploy and run

Did you find any workaround?

Just keep using dotnet build /t:Run works!

Relevant log output

09-18 16:59:31.584 12419 12419 E AndroidRuntime: FATAL EXCEPTION: main
09-18 16:59:31.584 12419 12419 E AndroidRuntime: Process: com.companyname.aspirewithmaui.mauiclient, PID: 12419
09-18 16:59:31.584 12419 12419 E AndroidRuntime: android.runtime.JavaProxyThrowable: [System.NotSupportedException]: Unable to find Invoker for type 'Microsoft.Maui.MauiApplication'. Was it linked away?
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Interop.TypeManager.CreateInstance + 0xeb(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Android.Runtime.AndroidValueManager.CreatePeer + 0xa(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Interop.JniRuntime+JniValueManager.GetPeer + 0x48(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Lang.Object.GetObject + 0xa(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Lang.Object._GetObject + 0x12(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Lang.Object.GetObject + 0x0(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Java.Lang.Object.GetObject + 0x6(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at Android.App.Application.n_OnCreate + 0xe(Unknown Source)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at crc6488302ad6e9e4df1a.MauiApplication.n_onCreate(Native Method)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at crc6488302ad6e9e4df1a.MauiApplication.onCreate(MauiApplication.java:27)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1381)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7830)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2546)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:110)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:248)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:338)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:9067)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:593)
09-18 16:59:31.584 12419 12419 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:932)
09-18 16:59:31.589 12419 12419 W monodroid-assembly: Shared library 'liblog' not loaded, p/invoke '__android_log_print' may fail
09-18 16:59:31.591 12419 12419 I MonoDroid: UNHANDLED EXCEPTION:
09-18 16:59:31.591 12419 12419 I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception of type 'Android.Runtime.JavaProxyThrowable' was thrown.
09-18 16:59:31.591 12419 12419 I MonoDroid: 
09-18 16:59:31.591 12419 12419 I MonoDroid:   --- End of managed Android.Runtime.JavaProxyThrowable stack trace ---
09-18 16:59:31.591 12419 12419 I MonoDroid: android.runtime.JavaProxyThrowable
09-18 16:59:31.591 12419 12419 I MonoDroid: 
09-18 16:59:31.604   697 12440 I DropBoxManagerService: add tag=data_app_crash isTagEnabled=true flags=0x2
09-18 16:59:31.610 12419 12419 I Process : Sending signal. PID: 12419 SIG: 9
09-18 16:59:31.619   697  1851 I ActivityManager: Process com.companyname.aspirewithmaui.mauiclient (pid 12419) has died: fg  TOP 
09-18 16:59:31.620  1424  1424 I adbd    : Remote process closed the socket (on MSG_PEEK)
09-18 16:59:31.622   697  1851 W ActivityTaskManager: ProcessRecord{24b4d3 12419:com.companyname.aspirewithmaui.mauiclient/u0a215} is removed with pending start ActivityRecord{252862968 u0 com.companyname.aspirewithmaui.mauiclient/crc648892e5f7d658ef63.MainActivity t21}
09-18 16:59:31.622   697   736 I libprocessgroup: Removed cgroup /sys/fs/cgroup/apps/uid_10215/pid_12419
09-18 16:59:31.628   478   478 I Zygote  : Process 12419 exited due to signal 9 (Killed)

[jonathanpeppers]

This one is weird, because if I run dotnet build -t:ComputeRunArguments -bl and get the command that runs, it works on its own:

> & 'C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe' shell am start -S -n "com.companyname.hellomaui/crc640655b0e0c20d93c7.MainActivity"
Stopping: com.companyname.hellomaui
Starting: Intent { cmp=com.companyname.hellomaui/crc640655b0e0c20d93c7.MainActivity }
> dotnet run
Stopping: com.companyname.hellomaui
Starting: Intent { cmp=com.companyname.hellomaui/crc640655b0e0c20d93c7.MainActivity }

But the dotnet run command, that runs the same command seems to fail and the app crashes.

I wonder if this works on Mac, because we have this test running there:

android/tests/MSBuildDeviceIntegration/Tests/InstallAndRunTests.cs

Line 49 in 4a09dd4

Assert.IsTrue (dotnet.Run (), "`dotnet run --no-build` should succeed");

[jfversluis]

Just tested on macOS, same results.

dotnet run: the Android app crashes on the splash screen
dotnet build /t:Run: works as expected

[jonathanpeppers]

So, I am seeing a major WTF right now, if I open obj\Debug\net10.0-android\android\assets\arm64-v8a\hellomaui.dll:

This is a dotnet new android project named hellomaui, but it has no code inside! There should be a MainActivity.cs.

Then it crashes with:

09-19 16:05:54.240  7765  7765 E AndroidRuntime: android.runtime.JavaProxyThrowable: [System.TypeLoadException]: Could not load type 'hellomaui.MainActivity' from assembly 'hellomaui'.

This is not happening with dotnet build -t:Run.

I suspect I will have to debug the dotnet cli to understand what's going on....

[jonathanpeppers]

Ok, dotnet run -bl produces two .binlog files now:

• msbuild.binlog
• msbuild-dotnet-run.binlog

But both of these run <Csc/> and one of them doesn't pass in MainActivity.cs!

So really two issues:

• Something is running the C# compiler/roslyn twice
• One of them is missing *.cs files

[jonathanpeppers]

I don't know why, but the broken build has -p:EnableDefaultItems=false passed in:

• https://github.com/dotnet/sdk/blob/008f3c933379d2f8cc79c0e5435f6280bf20b1b8/src/Cli/dotnet/Commands/Run/RunCommand.cs#L838

Which looks like it was introduced in ~RC 1:

• dotnet/sdk@480b58f#diff-ec69b538fa112e99ddfa3397f61b9ddc4612d4c2c5a3ba19bfbe6e9439c47167R357

[baronfel]

run has set EnableDefaultItems to false for a very long time (I don't want to say forever) as an optimization - one of the pitfalls of doing evaluations is file globbing. In this case, I think it's valid to skip for Restore Target, but not the Build/Compute Targets. I think run should change this to be more compatible.

[Youssef1313]

@baronfel @jonathanpeppers From what I'm reading, I get that dotnet/sdk#50942 would potentially fix the issue.

But the fact that Csc task is running when all we need is ComputeRunArguments is very suspicious. Do we understand why Csc task is running in this case?

[Youssef1313]

Maybe build is caused by

android/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets

Lines 2800 to 2801 in 5fe71c5

	<SignAndroidPackageDependsOn Condition=" '$(BuildingInsideVisualStudio)' != 'True' ">
	Build;

?

I don't know what other scenarios can lead to needing to sign. But at least when done via ComputeRunArguments, build shouldn't be needed in the first place IMO. ComputeRunArguments should really assume that build already happened and shouldn't attempt to build again.

[jonathanpeppers]

Android needs to deploy the app during dotnet run, so it needs to be rethought a bit for mobile. I want to work on this in a future .NET release.

[jfversluis]

Confirmed this is fixed with .NET 10 RC2, I'll let it to your discretion if anything more needs to be done here or if this can be closed