Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Bug] Publishing maui rc2 app to App Store not working -- The app references non-public symbols in MyContactNetwork.MobileMaui: _proc_pidinfo #3290

Closed
baartho opened this issue Nov 5, 2021 · 5 comments · Fixed by #3339
Closed

[Bug] Publishing maui rc2 app to App Store not working -- The app references non-public symbols in MyContactNetwork.MobileMaui: _proc_pidinfo #3290

baartho opened this issue Nov 5, 2021 · 5 comments · Fixed by #3339
Labels
area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) t/bug Something isn't working
Projects
Triage

Comments

@baartho
Copy link

baartho commented Nov 5, 2021

Description

I'm running into an App Store rejection issue with .NET 6.0 RC 2 + MAUI + iOS + WebView.Maui:

ITMS-90338: Non-public API usage - The app references non-public symbols in MyContactNetwork.MobileMaui: _proc_pidinfo. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

I believe that the offending package is System.Diagnostics.Process, which I'm guessing is referenced (and so ILLink won't remove, no matter what) because of this line:

https://github.com/dotnet/runtime/blob/1c7100b0c21a2af147362c7b5c61408611743ded/src/libraries/Common/src/Interop/OSX/Interop.libproc.GetProcessInfoById.cs#L93

which is called by

https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.OSX.cs

I tried adding the System.Diagnostics.Process.dll to the trimmer exceptions but it didn't work - I believe something in your code is referencing it.

ILinker build output:

ILLink: Processing embedded substitution descriptor ILLink.Substitutions.xml from System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Assembly System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a : skipped (SDK)
         ILLink: Reduced '11' instructions in conditional branches for [System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] method System.SR.GetResourceString(String)
         ILLink: Reduced '4' instructions in conditional branches for [System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] method System.SR.Format(String,Object)
         ILLink: Reduced '236' instructions in conditional branches for [System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] method System.Diagnostics.Process.StartCore(ProcessStartInfo)
ILLink: Reduced '5' instructions in conditional branches for [System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] method System.SR.Format(String,Object,Object)
 ILLink: Reduced '1' instructions in conditional branches for [System.Diagnostics.Process, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a] method System.Diagnostics.ProcessWaitState.Holder.Finalize()

Repro: Build the base MAUI Blazor template in Release+iOS+ARM64 and publish to App Store TestFlight, using the following in csproj:

ios-arm64

Configuration
.NET 6 rc2
MAUI Single Project
Blazor + MAUI.WebView
iOS ARM64 Build

Regression?
Similar issue: dotnet/runtime#57931
@baartho baartho added the t/bug Something isn't working label Nov 5, 2021
@hartez hartez added the area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) label Nov 5, 2021
@josephatkuvio
Copy link

I can confirm this issue on a dotnet new MAUI Blazor and MAUI template, in release/ios-arm64. After release linking, System.Diagnostics.Process.dll is still part of the app bundle, and proc_pidinfo is not linked out, even when the linker is explicitly told to link this DLL. So there's gotta be a direct reference somewhere within MAUI or its libraries, I just haven't found it yet.

dotnet new maui:

admin@DXT037 Maui.New % grep -r pidinfo .
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/Maui.New matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.llvm.o matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s.opt.bc matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s.bc matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.o matches
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_threadinfo__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_threadinfo__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_ulong__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_ulong__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_taskallinfo__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_taskallinfo__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_threadinfo__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_ulong__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_taskallinfo__int

dotnet new maui-blazor:

admin@DXT037 mauiblazor.new % grep -r pidinfo .
Binary file ./obj/Release/net6.0-ios/iossimulator-x64/linked/System.Private.CoreLib.dll matches
Binary file ./obj/Release/net6.0-ios/iossimulator-x64/linked/System.Diagnostics.Process.dll matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/MauiBlazor.New matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.llvm.o matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s.opt.bc matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s.bc matches
Binary file ./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.o matches
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_threadinfo__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_threadinfo__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_ulong__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_ulong__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:	.no_dead_strip wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_taskallinfo__int
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:wrapper_managed_to_native_Interop_libproc_proc_pidinfo_int_int_ulong_Interop_libproc_proc_taskallinfo__int:
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl _proc_pidinfo
./obj/Release/net6.0-ios/ios-arm64/nativelibraries/aot-output/arm64/System.Diagnostics.Process.dll.s:bl wrapper_managed_to_native_Interop_libproc_pr

@jsuarezruiz jsuarezruiz added this to New in Triage via automation Nov 8, 2021
@josephatkuvio
Copy link

Confirmed this morning that this issue is still occurring with .NET 6.0 RTM and MAUI Preview 10.

@josephatkuvio
Copy link

It appears the linker is pinning it because of some reference to System.CodeDom.ExecWaitWithCapture. Running illinkanalyzer.exe on the compiled app and tracing dependencies for proc_pidinfo got me these two stacks:

PS C:\users\josep\source\repos\linker\artifacts\bin\analyzer\debug\net6.0> .\illinkanalyzer.exe -r proc_pidinfo .\linker-dependencies.xml.gz
Loading dependency tree from: .\linker-dependencies.xml.gz

--- Raw dependencies: 'proc_pidinfo' -----------------------------------

--- Method:System.Int32 Interop/libproc::proc_pidinfo(System.Int32,System.Int32,System.UInt64,Interop/libproc/proc_taskallinfo*,System.Int32) dependencies ---
Dependency #1
        Method:System.Int32 Interop/libproc::proc_pidinfo(System.Int32,System.Int32,System.UInt64,Interop/libproc/proc_taskallinfo*,System.Int32)
        | Method:System.Nullable`1<Interop/libproc/proc_taskallinfo> Interop/libproc::GetProcessInfoById(System.Int32) [1 deps]
        | Method:System.Diagnostics.ProcessInfo System.Diagnostics.ProcessManager::CreateProcessInfo(System.Int32) [1 deps]
        | Method:System.Diagnostics.ProcessInfo System.Diagnostics.ProcessManager::GetProcessInfo(System.Int32,System.String) [2 deps]
        | Method:System.String System.Diagnostics.Process::ToString() [1 deps]
        | TypeDef:System.Diagnostics.Process [83 deps]
        | Method:System.Int32 System.CodeDom.Compiler.Executor::ExecWaitWithCapture(System.IntPtr,System.String,System.String,System.CodeDom.Compiler.TempFileCollection,System.String&,System.String&) [4 deps]
        | TypeDef:System.CodeDom.Compiler.Executor [10 deps]
        | TypeDef:System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0:System.CodeDom.dll [5 deps]
        | Field:System.IO.StreamWriter System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0::outputWriter [3 deps]
        | Method:System.Void System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0::<ExecWaitWithCapture>b__0(System.Object,System.Diagnostics.DataReceivedEventArgs) [2 deps]
        warning: loop to Method:System.Int32 System.CodeDom.Compiler.Executor::ExecWaitWithCapture(System.IntPtr,System.String,System.String,System.CodeDom.Compiler.TempFileCollection,System.String&,System.String&)

PS C:\users\josep\source\repos\linker\artifacts\bin\analyzer\debug\net6.0> .\illinkanalyzer.exe -r ExecWaitWithCapture .\linker-dependencies.xml.gz
Loading dependency tree from: .\linker-dependencies.xml.gz

--- Raw dependencies: 'ExecWaitWithCapture' ----------------------------

--- Method:System.Void System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0::<ExecWaitWithCapture>b__0(System.Object,System.Diagnostics.DataReceivedEventArgs) dependencies ---
Dependency #1
        Method:System.Void System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0::<ExecWaitWithCapture>b__0(System.Object,System.Diagnostics.DataReceivedEventArgs)
        | TypeDef:System.CodeDom.Compiler.Executor/<>c__DisplayClass6_0:System.CodeDom.dll [5 deps]
        | TypeDef:System.CodeDom.Compiler.Executor [10 deps]
        | TypeDef:System.CodeDom.Compiler.Executor/<>c__DisplayClass6_1:System.CodeDom.dll [5 deps]
        | Field:System.IO.StreamWriter System.CodeDom.Compiler.Executor/<>c__DisplayClass6_1::errorWriter [3 deps]
        | Method:System.Void System.CodeDom.Compiler.Executor/<>c__DisplayClass6_1::<ExecWaitWithCapture>b__1(System.Object,System.Diagnostics.DataReceivedEventArgs) [2 deps]
        | Method:System.Int32 System.CodeDom.Compiler.Executor::ExecWaitWithCapture(System.IntPtr,System.String,System.String,System.CodeDom.Compiler.TempFileCollection,System.String&,System.String&) [4 deps]
        | Method:System.Int32 System.CodeDom.Compiler.Executor::ExecWaitWithCapture(System.IntPtr,System.String,System.CodeDom.Compiler.TempFileCollection,System.String&,System.String&) [1 deps]
        warning: loop to TypeDef:System.CodeDom.Compiler.Executor

That second stack loops back on itself, so it's not telling me what the actual source is, nor have I found any references to this stack in dotnet/maui or xamarin/xamarin-macios, but I haven't looked super deeply.

However, lo and behold, when I add <_ExtraTrimmerArgs>--action link "System.Diagnostics.Process" --action link "System.CodeDom"</_ExtraTrimmerArgs> to the csproj, the proc_pidinfo reference is successfully linked out, and the App Store accepts the binary.

@eerhardt
Copy link
Member

Looks to be the same issue as dotnet/runtime#61265. I will have a fix up for both shortly.

eerhardt added a commit to eerhardt/maui that referenced this issue Nov 10, 2021
@eerhardt
Fix CodeDom reference
36918d2 
I noticed that in my Maui application System.CodeDom was being referenced. This is because we don't have a `PrivateAssets="all"` on the PackageReference in Microsoft.Maui.Controls.Build.Tasks.csproj.

This causes a problem when submitting an app to the Apple App Store, because CodeDom is preventing some unnecessary System.Diagnostics.Process code from being trimmed.

Adding the PrivateAssets="all", and removing unnecessary Conditions since this project only builds for netstandard2.0.

Fix dotnet#3290
Fix dotnet/runtime#61265
@eerhardt eerhardt mentioned this issue Nov 10, 2021
Merged
@hartez hartez moved this from New to Done in Triage Dec 27, 2021
@aokocax
Copy link

aokocax commented Jan 23, 2022

I was getting the same error with 6.0.1 but with daily build (SDK 6.0.2-servicing.1.22063.8) the problem was solved.
I was able to send it without any problem.
dotnet/runtime#61265 (comment)

@ghost ghost locked as resolved and limited conversation to collaborators Feb 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-publishing Issues with the app packaging/publishing process (ipk/apk/msix/trimming) t/bug Something isn't working
Projects
No open projects
Triage
Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix CodeDom reference eerhardt/maui
5 participants
@hartez @aokocax @eerhardt @josephatkuvio @baartho