Localized satellite packages are not included in build output when using PackageReference

[jassmith]

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-package references one single NuGet package (SatelliteAssemblyTest.1.0.0) that includes the main assembly and one localized resource DLL.
• Branch doesnt-work-multiple-packages references two NuGet packages: SatelliteAssemblyTest.1.0.1 (which only has the main assembly) and SatelliteAssemblyTest.de.1.0.1 (which only contains the localized resource DLL).

1. Build solution in Release mode
2. 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

[cassionandi]

Any workarounds on this?

[xalikoutis]

Hi Guys any progress on this?

[jemunk]

This is still an issue! Any progress? Any workarounds?

[smoogipoo]

Any updates or workarounds for this issue?

[clairernovotny]

Ping? We're still getting reports of this:

https://twitter.com/lastexitcode/status/1175392618022408192

[xalikoutis]

moved to flutter

[ChaseFlorell]

Can we open a sister issue on the iOS side of things? Where would it go?

[JeanRessouche]

No idea for a solution ? That's really problematic

[cemrich]

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 xamarin/xamarin-macios#7113.

[jonathanpeppers]

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):

msbuild .\SatelliteAssemblyApp\SatelliteAssemblyApp.Android\SatelliteAssemblyApp.Android.csproj /p:Configuration=Release /t:SignAndroidPackage /bl /r /p:NuGetRuntimeIdentifier=MonoAndroid8.1 /p:RuntimeIdentifiers=MonoAndroid8.1

This makes <ResolveNuGetPackageAssets/> returns the satellite assembly. But it still doesn't make it to the .apk file 😞 .

Let me review this behavior in .NET 5/6 and see what happens there: https://github.com/xamarin/net6-samples

[jonathanpeppers]

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]

Thank you very much for looking into this!

It appears that this is going to "just work" in .NET 6.

Does this mean this issue will not be resolved until .NET 6 is ready to use?

[jonathanpeppers]

@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]

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:

Humanizer.dll
de/Humanizer.resources.dll

I have not yet tested this solution for more than one localization package.

[ghost]

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[ghost]

This issue will now be closed since it had been marked possibly-stale but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

[tranb3r]

So, is it going to be fixed or not ?

[jonathanpeppers]

This issue is from 2018, I would follow the new one for updates on this: dotnet/maui#4470