Repository navigation
Localized satellite packages are not included in build output when using PackageReference #2012
Description
From @domyd on July 24, 2018 10:50
Description
Localized satellite packages do not seem to work in a Xamarin app when using the PackageReference restore method.
Likely related: Humanizr/Humanizer#380
Steps to Reproduce
Repro project: SatelliteAssemblyApp.zip. It's a git project with two additional branches: (Note: the referenced test nuget packages are included in /localpackages and restoring them should just work)
- Branch
works-single-packagereferences one single NuGet package (SatelliteAssemblyTest.1.0.0) that includes the main assembly and one localized resource DLL. - Branch
doesnt-work-multiple-packagesreferences two NuGet packages:SatelliteAssemblyTest.1.0.1(which only has the main assembly) andSatelliteAssemblyTest.de.1.0.1(which only contains the localized resource DLL).
- Build solution in Release mode
- Archive Android project to get an APK
Expected Behavior
The localized resource DLLs are included in the APK in both cases (/assemblies/de/SatelliteAssemblyTest.resources.dll exists within the APK). On a device with German culture, the label on the main page should say "Deutsch" in both cases.
Expected APK: works-single-package.zip
Actual Behavior
The localized resources are missing in the case of split nuget packages (/assemblies/de doesn't exist within the APK). On a device with German culture, the label on the main page says "English".
Actual APK: doesnt-work-multiple-packages.zip
Basic Information
- Version with issue: 3.0.0.561731
- Last known good version: not tested
- IDE: VS 2017 (v15.7.5)
- Platform Target Frameworks:
- Android: 8.1
- Android Support Library Version: 27.0.2
- Nuget Packages: none, except the test package(s)
Copied from original issue: xamarin/Xamarin.Forms#3386
Activity
cassionandi commentedon Sep 25, 2018
Any workarounds on this?
xalikoutis commentedon Nov 8, 2018
Hi Guys any progress on this?
jemunk commentedon Feb 28, 2019
This is still an issue! Any progress? Any workarounds?
smoogipoo commentedon Jul 30, 2019
Any updates or workarounds for this issue?
clairernovotny commentedon Sep 21, 2019
Ping? We're still getting reports of this:
https://twitter.com/lastexitcode/status/1175392618022408192
xalikoutis commentedon Sep 21, 2019
moved to flutter
ChaseFlorell commentedon Sep 23, 2019
Can we open a sister issue on the iOS side of things? Where would it go?
JeanRessouche commentedon Feb 21, 2020
No idea for a solution ? That's really problematic
cemrich commentedon Jun 10, 2020
This issue prevents Humanizer from being used in localized Xamarin projects (see Humanizr/Humanizer#799). This is especially problematic, as Humanizer is described as compatible to Xamarin and this issue does only starts to appear when non english translation are added later on in the development process.
It seems the iOS counterpart of this issue has been fixed in dotnet/macios#7113.
jonathanpeppers commentedon Jun 10, 2020
Sorry, I know this is an old ticket....
I don't see NuGet's
<ResolveNuGetPackageAssets/>MSBuild task returning the satellite assembly, and so the remainder of the build doesn't even know about this file.The cause of this behavior seems to be:
https://github.com/dotnet/NuGet.BuildTasks/blob/286d99efae21704989da40911380ee63c82e9c5a/src/Microsoft.NuGet.Build.Tasks/ResolveNuGetPackageAssets.cs#L318-L321
But if I set
$(NuGetRuntimeIdentifier)and$(RuntimeIdentifiers):This makes
<ResolveNuGetPackageAssets/>returns the satellite assembly. But it still doesn't make it to the.apkfile 😞 .Let me review this behavior in .NET 5/6 and see what happens there: https://github.com/xamarin/net6-samples
Test using satellite assemblies
jonathanpeppers commentedon Jun 10, 2020
It appears that this is going to "just work" in .NET 6. But keep in mind, this is under active development:
https://github.com/xamarin/net6-samples/compare/satelliteassemblies
cemrich commentedon Jun 11, 2020
Thank you very much for looking into this!
Does this mean this issue will not be resolved until .NET 6 is ready to use?
jonathanpeppers commentedon Jun 12, 2020
@cemrich I'm unsure about setting
$(NuGetRuntimeIdentifier)and$(RuntimeIdentifiers)in "legacy" MSBuild projects to workaround NuGet. It doesn't feel quite right...I will need to do more research.
cemrich commentedon Jun 16, 2020
I worked around this issue by referencing the Humanizer dlls directly from my head projects and the shared project. I placed the dlls inside a separate project directory with following structure:
I have not yet tested this solution for more than one localization package.
tranb3r commentedon Nov 24, 2022
So, is it going to be fixed or not ?
jonathanpeppers commentedon Nov 28, 2022
This issue is from 2018, I would follow the new one for updates on this: dotnet/maui#4470