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.

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

[ios] Non-public API usage when submitting app #14290

Closed
spouliot opened this issue Apr 30, 2019 · 2 comments · Fixed by #14316 or xamarin/xamarin-android#3105

Comments

@spouliot
Copy link
Member

@spouliot spouliot commented Apr 30, 2019

Steps to Reproduce

  1. Submit an iOS app to Apple App Store
  2. Wait for an email confirmation

Current Behavior

Non-public API usage:

The app references non-public symbols in iTravel: _FSEventStreamCreate, _FSEventStreamInvalidate, _FSEventStreamRelease, _FSEventStreamScheduleWithRunLoop, _FSEventStreamStart, _FSEventStreamStop, _FSEventStreamUnscheduleFromRunLoop

Expected Behavior

Success

On which platforms did you notice this

[x] iOS
[ ] macOS
[ ] Linux
[ ] Windows

Version Used:

Latest XI using mono from 2019-02

@spouliot

This comment has been minimized.

Copy link
Member Author

@spouliot spouliot commented Apr 30, 2019

@spouliot

This comment has been minimized.

Copy link
Member Author

@spouliot spouliot commented Apr 30, 2019

mono poupou$ grep -r FSEventStreamInvalidate .
./external/corefx/src/Common/src/Microsoft/Win32/SafeHandles/SafeEventStreamHandle.OSX.cs:            Interop.EventStream.FSEventStreamInvalidate(handle);
./external/corefx/src/Common/src/Interop/OSX/Interop.EventStream.cs:        internal static extern void FSEventStreamInvalidate(IntPtr streamRef);
Binary file ./mcs/class/lib/monotouch_watch_runtime/System.dll matches
Binary file ./mcs/class/lib/monotouch_runtime/System.dll matches
Binary file ./mcs/class/lib/monotouch_watch/System.dll matches
Binary file ./mcs/class/lib/xammac_net_4_5/System.dll matches
Binary file ./mcs/class/lib/monotouch_tv/System.dll matches
Binary file ./mcs/class/lib/monotouch_tv_runtime/System.dll matches
Binary file ./mcs/class/lib/monotouch/System.dll matches

The mentioned symbols are officially only available for macOS (not iOS, tvOS or watchOS)

alexischr added a commit to alexischr/mono that referenced this issue May 2, 2019
…file"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is used unofficially-available  symbols and cannot publish apps using those.

Fixes mono#14290
@spouliot spouliot referenced this issue May 9, 2019
4 of 5 tasks complete
monojenkins added a commit to monojenkins/mono that referenced this issue May 10, 2019
…file"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is used unofficially-available  symbols and cannot publish apps using those.

Fixes mono#14290
monojenkins added a commit to monojenkins/mono that referenced this issue May 10, 2019
…file"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is used unofficially-available  symbols and cannot publish apps using those.

Fixes mono#14290
alexischr added a commit that referenced this issue May 10, 2019
#14316)

* Revert "[System] Add FSEvent FileSystemWatcher to 'monotouch' BCL profile"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is using unofficially-available  symbols and cannot publish apps using those.

Fixes #14290

* [csproj] Update project files
akoeplinger added a commit that referenced this issue May 12, 2019
… BCL profile" (#14448)

* Revert "[System] Add FSEvent FileSystemWatcher to 'monotouch' BCL profile"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is used unofficially-available  symbols and cannot publish apps using those.

Fixes #14290

* [csproj] Update project files
akoeplinger added a commit that referenced this issue May 12, 2019
… BCL profile" (#14447)

* Revert "[System] Add FSEvent FileSystemWatcher to 'monotouch' BCL profile"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is used unofficially-available  symbols and cannot publish apps using those.

Fixes #14290

* [csproj] Update project files
baulig added a commit to baulig/mono that referenced this issue May 15, 2019
mono#14316)

* Revert "[System] Add FSEvent FileSystemWatcher to 'monotouch' BCL profile"

This reverts commit 46fc535.

While iOS FileSystemWatcher works, we now find that it is using unofficially-available  symbols and cannot publish apps using those.

Fixes mono#14290

* [csproj] Update project files
grendello added a commit to grendello/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: xamarin@1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.