Nupkg size has blown up recently
The size of the Mapsui nupkg file built by AppVeyor used to be around 800kB, but recently is has grown strongly to about 15MB. I investigated a bit and found ...
- Mapsui.3.0.0-build.1430.nupkg to be the last small one (built from 65ef14ddad3576420ad00f4802795715cb9ebc44)
- Mapsui.3.0.0-build.1433.nupkg to be the first large one (built from b4109abc892fe3890122170ed27630d443cde12e)
However, @charlenni's commit b4109abc892fe3890122170ed27630d443cde12e looks absolutely innocent to me. I have no idea why it would change the size of the nupkg so drastically. So I suspect something with the AppVeyor build setup may have changed around that time. @pauldendulk, do you have an idea what's going on there?
* [Mapsui.3.0.0-build.1430.nupkg](https://ci.appveyor.com/project/pauldendulk/mapsui/builds/38191756/artifacts) to be the last small one (built from [65ef14d](https://github.com/Mapsui/Mapsui/commit/65ef14ddad3576420ad00f4802795715cb9ebc44)) * [Mapsui.3.0.0-build.1433.nupkg](https://ci.appveyor.com/project/pauldendulk/mapsui/builds/38257237/artifacts) to be the first large one (built from [b4109ab](https://github.com/Mapsui/Mapsui/commit/b4109abc892fe3890122170ed27630d443cde12e))
This assessment was actually based on the order of commits to master, but checking the order of builds shows that the change happened between these two:
- Mapsui.3.0.0-build.1431.nupkg is still small (from March 14)
- Mapsui.3.0.0-build.1432.nupkg is the first large one (from March 15)
I suspect this is either related to a change of the AppVeyor build configuration, or an update of tooling/libraries on the AppVeyor build server ...
It also looks like the size of any app package built from the latest versions is blown up by almost 15 MB (but interestingly only on Android, not on iOS). Still, this is pretty bad :/
* [Mapsui.3.0.0-build.1431.nupkg](https://ci.appveyor.com/project/pauldendulk/mapsui/builds/38216429/artifacts) is still small (from March 14) * [Mapsui.3.0.0-build.1432.nupkg](https://ci.appveyor.com/project/pauldendulk/mapsui/builds/38233743/artifacts) is the first large one (from March 15)
Looking at the build logs, with the additional hint that this might be Android-related, I found that there was indeed a change of the Xamarin.Android version from 11.1.0.26 to 11.2.0.21. I'm pretty sure this is the culprit.
The new build also contains warnings like:
warning XA0113: Google Play requires that new applications and updates must use a TargetFrameworkVersion of v10.0 (API level 29) or above. You are currently targeting v9.0 (API level 28). [C:\projects\mapsui\Samples\Mapsui.Samples.Droid\Mapsui.Samples.Droid.csproj]
and
warning XA0125: 'Mapsui.pdb' is using a deprecated debug information level. [C:\projects\mapsui\Samples\Mapsui.Samples.Droid\Mapsui.Samples.Droid.csproj]
warning XA0125: Set the debugging information to Portable in the Visual Studio project property pages or edit the project
warning XA0125: If this file comes from a NuGet package, update to a newer version of the NuGet package or notify the library author. [C:\projects\mapsui\Samples\Mapsui.Samples.Droid\Mapsui.Samples.Droid.csproj]
Thanks for your detective work! Perhaps this could be fixed by not supporting some older Android versions?
Thanks for your detective work! Perhaps this could be fixed by not supporting some older Android versions?
I'm not sure. There must be some reason for the drastic change in size. I'd suspect that it is related to a different handling of debugging information rather than a specific Android version ...
The "'Mapsui.pdb' is using a deprecated debug information level." message you mentioned above led me to this site: https://docs.microsoft.com/en-us/xamarin/android/release-notes/11/11.2#deprecation-of-debugtype-full-and-pdbonly
I assume that the Visual Studio update (which is probably updated on AppVeyor) caused the size increase and we should now switch to DebugType portable.
I will push these changes. Perhaps you can check if this helps.
The "'Mapsui.pdb' is using a deprecated debug information level." message you mentioned above led me to this site: https://docs.microsoft.com/en-us/xamarin/android/release-notes/11/11.2#deprecation-of-debugtype-full-and-pdbonly
I assume that the Visual Studio update (which is probably updated on AppVeyor) caused the size increase and we should now switch to DebugType portable.
I agree, sounds reasonable. I hope that this will fix the problem.
I will push these changes. Perhaps you can check if this helps.
Thanks for taking care of it! I will check once you are done.
Pushed it #1116
Pushed it #1116
Thanks, Paul.
However, looking at the latest AppVeyor build on master (https://ci.appveyor.com/project/pauldendulk/mapsui/builds/38754759), I see that:
- the nupkg is still large (15 MB)
- some of the warnings are still present
warning XA0125: 'Mapsui.UI.Android.pdb' is using a deprecated debug information level.
warning XA0125: 'Mapsui.Samples.Droid.pdb' is using a deprecated debug information level.
Maybe the size will go down once those are fixed as well (in particular the first one), or maybe or our assumption was wrong after all? In any case, it does hot hurt to fix the warnings, I guess ...
@janusw Try to change the DebugType in all csproj files to ‚portable‘ as made in #1113 second commit.
Does this change the size?
I downloaded the .nupkg file, unzipped it, decompiled the Mapsui.UI.Android.dll file and saw that the zip resource named __AndroidNativeLibraries__.zip has a size about 14.59 MB. It contains 4 android architectures and for every architecture the libSkiaSharp takes up lot of space. So the sizes comes from the skiasharp library. It may be so big because it contains debug information and maybe setting all DebugType to portable fixes this, but it could also be an upstream issue, maybe updating skiasharp helps too? I attached the zip file so you can have a look.
I downloaded the .nupkg file, unzipped it, decompiled the
Mapsui.UI.Android.dllfile and saw that the zip resource named__AndroidNativeLibraries__.ziphas a size about 14.59 MB. It contains 4 android architectures and for every architecture the libSkiaSharp takes up lot of space. So the sizes comes from the skiasharp library.
Thanks for the insights, @JBou. I don't quite understand how the problem can be caused by SkiaSharp, though, since both builds mentioned above (1431 and 1432) use the exact same SkiaSharp version ...
It may be so big because it contains debug information and maybe setting all DebugType to
portablefixes this,
I hope so. (Will try this tonight, unless somebody beats me to it ...)
but it could also be an upstream issue, maybe updating skiasharp helps too?
I don't think so (but I might be wrong).
I missed the csprojs that were in the old format. Pushed them now https://github.com/Mapsui/Mapsui/pull/1117
I missed the csprojs that were in the old format. Pushed them now #1117
Thanks, Paul. Unfortunately the nupkg size is still as large as before :(
I think this issue is the same as https://github.com/xamarin/xamarin-android/issues/5776
How is this is you build an older version of Mapsui? You could create a nuget package with the 'pack' command on a project (right mouse button menu).
hmm, reading the thread on the xamarin issue suggests that it's the tooling.
How is this is you build an older version of Mapsui?
All older versions I have seen were 'small' (below 1MB).
You could create a nuget package with the 'pack' command on a project (right mouse button menu).
I don't think that works properly. The nuget built by AppVeyor mixes files from several VS projects AFAICS.
hmm, reading the thread on the xamarin issue suggests that it's the tooling.
Well, I pointed to where exactly the change happens (see above). It seems that a version change in Xamarin.Android is what triggered the problem. Is that what you mean by 'tooling'?
So you say this is the problem:
Looking at the build logs, with the additional hint that this might be Android-related, I found that there was indeed a change of the Xamarin.Android version from 11.1.0.26 to 11.2.0.21. I'm pretty sure this is the culprit.
And now the question is what triggered it? From what I understand appveyor uses the appveyor.yml that is included in git and should have related commits. There may also be things changing in appveyor not controlled by the yml, perhaps some changes in the UI made by my, or updates in appveyor. I have no recollection of changing anything (but it is possible). If it is an appveyor update it is hard to control.
Perhaps we should focus on the warnings. What could be happening? Which files have grown in size or are now included?
So you say this is the problem:
Looking at the build logs, with the additional hint that this might be Android-related, I found that there was indeed a change of the Xamarin.Android version from 11.1.0.26 to 11.2.0.21. I'm pretty sure this is the culprit.
I assume so. It's the only thing that really changed. Plus, the same thing was reported for xamarin-android already in another context.
And now the question is what triggered it? From what I understand appveyor uses the appveyor.yml that is included in git and should have related commits. There may also be things changing in appveyor not controlled by the yml, perhaps some changes in the UI made by my, or updates in appveyor. I have no recollection of changing anything (but it is possible). If it is an appveyor update it is hard to control.
I assume that the versions of some of the tools and libraries may be updated in AppVeyor from time to time. In appveyor.yml it seems that you only specify Visual Studio 2019, so I guess you get the minor updates of VS (plus its tools+libs) automatically?
Maybe there is a way to request a specific version explicitly? I think in GitHub Actions this is possible, but I don't have much experience with AppVeyor.
Also I don't understand what environment version 3.0.0 means.
Perhaps we should focus on the warnings.
Huh, looking at the latest build, there are not many warnings left which could be related to this, I think.
What could be happening? Which files have grown in size or are now included?
As mentioned by @JBou above, libSkiaSharp seems to have grown, in particular.
@janusw Can this be closed now your PR was merged?
No, nothing that I did actually fixed the root issue. I haven't checked yet (I'm currently travelling), but I assume the nuget packages built via CI are still huge.
I haven't checked yet (I'm currently travelling), but I assume the nuget packages built via CI are still huge.
Looking at the current master build (https://ci.appveyor.com/project/pauldendulk/mapsui/builds/40020900), one can see that the packages generated as artifacts are still 'large' (15 MB for the Mapsui base package). The build is using Xamarin.Android version 11.3.0.4, which apparently still carries the bug.
Since AppVeyor does not seem to have a way to specify a particular Xamarin.Android version to use in the build (or does it?), I think the most reasonable workaround would be to build with GitHub Actions, which has this feature: https://docs.github.com/en/actions/guides/building-and-testing-xamarin-applications#building-xamarinandroid-apps
Instead of the current version 11.3.x of Xamarin.Android, one should use version 11.1, which does not exhibit the package-size problem.
A proper fix (or workaround) for this issue is the only thing that really blocks a final Mapsui 3.0 release from my point of view.
Notes:
- An upstream fix in Xamarin.Android may possibly take some time. There has not been much activity in the upstream issue lately (xamarin/xamarin-android#5776), so I don't think we should wait for that.
- In principle there is a workaround: Downgrading Xamarin.Android to version 11.1.x. The only problem is that it is not used in the CI builds (yet), therefore a final 3.0 package may need to be built manually.
A limited workaround for this issues is provided by #1175, which splits off the Mapsui.UI.* parts (Android, iOS, Uwp, Wpf) into a separate package ("Mapsui.Native"). Since this issue only affects Mapsui.UI.Android, the Mapsui core package (as well as Mapsui.Forms) is not affected by it any more. Only the Mapsui.Native package is affected now (and is still 15MB large).
This has been fixed since 4.0.0-beta.2 (via #1513).