[Bug] [Android] System.IO.FileNotFoundException when <BundleAssemblies>True</BundleAssemblies> #64
Comments
|
@RadoslawKubas Could you attach an example or review the attached one? |
|
I can reproduce it in release mode only |
|
I had/have the same problem and it is only in Release mode. Another problem with AndroidX (the stable versions) and XF 4.5 pre-release is that you cannot enable r8 (code shrinker) in release. In the end I rolled back to the old support libraries and everything works. |
|
@danardelean can you be more specific about the error you are seeing? Please open a new issue with more details. |
|
I checked with latest stable 4.5.0.356 and same problem repeats. I tried to prepare an example, but the problem is that even in my main solution, I can't reproduce it locally. When building same commit with VS2019 Community 16.4.5 it seems to be fine, but with build on Microsoft App Center and publish to Google Play, all prepunch tests fails. |
|
I am having the exact same issue. On DEBUG everything works fine. If I change the config to Release - the build passes, I can archive the app but as soon as the app starts, the app crashes with the same error. |
|
Okay, so I managed to produce a sample project and I managed to narrow down the problem, but this time I got a different exception (but at the same time it is kind of similar). It turned out that it isn't due to the BundleAssemblies config. This happens as soon as we choose to use r8 for code shrinking, the app crashes. Here is the demo project: Steps to reproduce:
If we don't have any code shrinking, everything works fine and the app launches successfully. However, if we choose to use code shrinking (and r8 specifically), then the app crashes with the following exception: Time Device Name Type PID Tag Message |
|
Here is another repro project: In debug mode, an image will be displayed on the main page. The exception is only happening with Stack trace of the exception (no crash, it's silent): |
|
I have same problem |
|
We have also observed this problem, which happens only in release mode and when Bundle Assemblies is set to true |
|
Will fix on new version ? |
This is a temporary workaround for dotnet/android-libraries#64
|
Same here 4.5.0.495 - still not working for me |
|
This bug was opened more than one month ago, and it's quite a serious regression. |
|
Your issue looks like Xamarin.Forms one (it is in Essentials, but it is Forms one): So add proguard rule: |
|
@mduchev Please report here if that helps. Thanks |
|
Hey folks! After looking at this, I think I have found out what is happening. Basically, when using the This is what is happening now. We will get a solution/workaround ASAP for you folks. Thanks for your patience and all the info/repros that helped us work this out. For the folks interested in the code of mkbundle: The logs will have something like this: |
|
Will fix in release XF or VS ? |
|
@nhdanh |
|
I only concern when my project will be fix this error :) |
|
@nhdanh most probably it will be fixed (worked around) in an AndroidX or Xamarin.Forms NuGet update. So not needing a wait for a VS update is good. |
|
@EDMIStephen We talked about docs too and that was mistake, but written long time ago. It was fine to mention and warn users not to use mkbundle for what is not intended, but what to say if you keep doing it? Being vocal and demanding something you have been advised not to use/demand and demanding it to be done ASAP is also not professional, Add to that counting man hours spent on issues. Some users are forcing OOS maintainers to simply ignore them, but I don't want to do it for other helpful users. For example did you try nugets containing fixes for this issue? Some users did. mkbundle was intended for self contained apps, but presenting it as security tool was wrong (not completelty wrong, but mostly). The same as cutting support for it, which in the end was not cut. We all make mistakes. |
|
@moljac |
This was my argument for being against cancelling support of mkbundle or changing the code of it.
The easiest part of this bug was fixing it on my side, but when this issue appeared I was working on other tasks too. We can go on and on what was right. There are users with the same arguments like yours who think that their problems (or wishes) have higher priority than yours. Now as we communicate and I call for cooperation - I do test this issue. There are nugets with this hotfix. Did you try them? If I publish them and switch to another tasks I will not come back to this issue for a while, simply because of other tasks and users that are waiting. |
|
Note: typeforwarding for some Xamarin.Forms apps might fail in some cases. Fix added in locally built nugets (link is above). |
I'm not discussing priorities here. I'm challenging your process, which is obviously bad, if it makes you kill a feature instead of fixing a regression. |
|
That is your opinion and you are completely entitled to it. The "sit and wait" process is not much better. Now you can continue with ad-hominem accusations via challenges about process or anything else, while ignoring my arguments (priorities). Note: feature was not killed and regression is fixed. And would you be so kind and propose few suggestions for improvements, please? |
|
@moljac , is the fixed only thru the link you provided above? Or will it be pushed thru the main, official channel (XF release)? |
At this moment - yes. There are ready to press the button packages on CI, but it is not public, so I simply pushed those nugets to that repo, so external users could test.
XF team is already testing those nugets. OK. There were some improvements/fixes this morning, but they will be able to use them in few minutes. I cannot promise anything for forms. Android parts will be released as soon as they confirm it. |
|
Thank you @moljac, I'm sure most of us are very appreciative of yours and others' work 👍 |
May I remind you that I've tried to help you with this issue as much and as quickly as I could, by posting a repro project. This was more than 3 months ago. |
|
@moljac , I might not agree on your attitudes on some of your replies, BUT BUT, as a technical person to another, I still like to thank you for your hard work. You are the assignee to most of the issues. It seems like you are like a sweatshop child labor in a very very 3rd world country. It's like Xamarin.Auth disappointment all over again. But, Cheer up. I'm not sure what's your position or how high up you are, but it's still better being a technical person and having these discussions than having to deal with the office/project politics. If you can't handle the workload, let your boss know. This is not a hobbyist repository (is this?) where you can ask customer/user to "take it or leave it" (you didn't explicitly, but your frustrated-attitude did). You never know which "big customer" Microsoft is trying to attract, but only to come here and get disheartened replies. |
|
For those willing to test before publishing: https://github.com/moljac/Samples.AndroidX/tree/master/nuget-local |
|
When using Xamarin.Forms 4.6.514 instead of 4.6.0.800, here is the error I get on building my android app: I'm probably doing something wrong... And by the way, I don't understand why the new version of Xamarin.AndroidX.Migration that is being published is 1.0.0.1, when I'm already using 1.0.6. |
I don't think so. With more complex samples there might be such issues with transitive dependencies. In some cases I had to manually fix some dependencies by adding explicit dependencies. Can you post your project file ( For now:
Or let nuget handle transitive dependencies: Forms will pull everything in: Was your app migrated to AndroidX before? If yes, then you don't need to migrate again. You'll need it if some library references (transitively) Android.Support then types are mapped on CIL level (Mono.Cecil). I will need more time to explain Migration. Xamarin.AndroidX.Migration 1.0.0.1 had to be published, because of the mappings in THAT moment. (There were different artifacts bound at that version) and that nuget carries mapping files. Just simple explanation: Check 1st |
|
@moljac For the rest of your explanation, sorry but I'm totally lost... |
It is OK. I feel that way too. Ping me later if you want deeper info. I would try several options:
Please provide feedback. Today after I publish 1.0.6.1 or 1.0.7 transitive dependency resolving will be easier. |
|
@tranb3r try this:
|
|
@melimion |
|
@moljac haven't tried yet, will try today |
|
Nuget setup issue and related sample: |
|
@moljac rebuilt app with new nugets- no issues |
|
@melimion Thanks a lot for the feedback. Appreciated. |
|
@moljac Thanks ! |
|
@tranb3r NP (you re welcome). |
|
Sorry, late to the party but actually Xamarin team seems to be right. Bundle into native assemblies reduces size for apk but increases for aab. Here is what i found, Let me know if you have similar experience. |
Fixes: #7764 Context: d236af5 Context: dotnet/android-libraries#64 (comment) .NET Android dropped support for `$(BundleAssemblies)`=True; see also commit d236af5 and [a comment on dotnet/android-libraries#64][0]: > After internal discussion, we are strongly considering removing > support for `$(BundleAssemblies)` in .NET 5, as it increases > on-device memory use and slows down app startup times. However, this "dropping of support" was incomplete; setting it would result in broken apps! % dotnet new android -n android-ba % cd android-ba % dotnet build -p:BundleAssemblies=true # run the app, or just look at the .apk contents % unzip -l bin/Debug/net7.0-android/*-Signed.apk | grep assem 660 02-03-2023 14:13 assemblies/rc.bin # Note: `assemblies/assemblies.blob` is not present, but is required! Fix this by *removing* most usage of the `$(BundleAssemblies)` MSBuild property as well as all the code affected by it. - Stop running bundle test apps on CI - Remove bundle unit tests - Remove the `CodeGen-MkBundle` project from the tests solution - Remove the `Xamarin.Android.MakeBundle-Tests` from the tests solution - Remove all native code (and configuration) related to mkbundle - Warn about `$(BundleAssemblies)` usage in .NET projects. A XA1035 warning will be emitted when `$(BundleAssemblies)`=True in .NET Android apps. Preserve a couple of related properties in the `<BuildApk/>` and `<GeneratePackageManagerJava/>` tasks, because they are still used by the debugger targets from `xamarin/monodroid`. [0]: dotnet/android-libraries#64 (comment)
and others
Description
After upgrade from Xamarin.Forms 4.4.0.991640 to 4.5.282-pre4 I noticed that when
<BundleAssemblies>True</BundleAssemblies>app crash on start with exception
My working setup for release in 4.4 is
in 4.5 everything works fine only if
Steps to Reproduce
Expected Behavior
App starts.
Actual Behavior
App crash with System.IO.FileNotFoundException exception.
Basic Information
The text was updated successfully, but these errors were encountered: