Application parts, MissingManifestResourceException: The manifest 'Xxx.Yyy.Zzz.en.resources' was not found

[DmitrySikorsky]

I'm working on modular application and trying to add application part (assembly 'Module') to the main application (assembly 'Application'). Also I have direct link to that project in Application's project.json.

Module contains localized views (using IViewLocalizer) and resx files in the Resources folder. Values from the resx not shown. If I try to call IViewLocalizer's GetAllStrings method in the View I will get next exception:

MissingManifestResourceException: The manifest 'Application.Resources.Views.Cultures.Index.en.resources' was not found.

Why does it look for Application.Resources but not for Module.Resource? I have checked and there is Module.Resources.Views.Cultures.Index.en.resources available inside the Module assembly.

Could you please help me with that? Thanks!

[hishamco]

I think it's a duplicate for issue #257

[DmitrySikorsky]

Maybe. GetManifestResourceNames() returns nothing (except views) for me too. But I know that resource is added because if I add resx like A.B.C.resx in addition to A/B/C.resx I get compilation error that resource id is already exists.

Problem is that I'm not sure that I'm doing this in the right way. Localization works if I have localized views and resx in the Application project, but it doesn't work in the views from separate assembly. (Just does nothing or throughs exception if I call GetAllStrings). Is it enough just to add localized views and resx in the Module project and then use AddApplicationPart to add that assembly?

[hishamco]

Localization works if I have localized views and resx in the Application project, but it doesn't work in the views from separate assembly.

This is seems a bug in 1.1.0-alpha1-21873, please have a look to this issue #275

[DmitrySikorsky]

Problem is that I'm using 1.0.0. I will try to create simple demo for you.

[Eilon]

We think we have a way of making this fairly easily doable in an app:

1. We'll define a new assembly-level attribute [assembly: LocalizerResourcePath(string resourcePath)]
2. Assemblies such as those containing application parts would use this new attribute to specify their root resource path.
3. The default localization system would check the type of the resource being used, see if its containing assembly has this attribute, and if so, use that as the resource root path for lookups. If the attribute isn't there, then the current behavior will be used, which is that the localization Options class has its own resource path.

[kevinchalet]

@Eilon great approach (similar to the one I had in mind).

In a perfect world, one should also be able to override the resources used by a "class library", but it's probably too much to ask, right? 😄

[Eilon]

@PinpointTownes that's certainly debatable. Usually resources are an implementation detail of a class library and so it doesn't make sense to allow someone to modify it from outside.

But in the case where the author of the "app" and the "class library" is the same person, it certainly gets more interesting. But no plans to support that at this time 😄

[kevinchalet]

But in the case where the author of the "app" and the "class library" is the same person, it certainly gets more interesting.

Nah, actually, that's not what I had in mind.

Here's a concrete use case: in ASOS/OpenIddict, we use a bunch of OpenID error messages that are returned to OIDC apps or directly to users. Currently, these messages are hardcoded but a few people said they were interested in localizing/customizing them (e.g aspnet-contrib/AspNet.Security.OpenIdConnect.Server#240 (comment)).

Allowing one to override the [assembly: LocalizerResourcePath(string resourcePath)] directive would enable a few interesting scenarios like adding languages that are not supported by the library author or customizing strings.

I suppose it would be as simple as adding a property to LocalizerResourcePathAttribute:

// Specify Overridable = true to allow the app writer to override the resource strings used by this assembly. 
[assembly: LocalizerResourcePath("path", Overridable = true)]

[DmitrySikorsky]

To be able to use static resources (like images) from other assemblies I create CompositeFileProvider like this: https://github.com/ExtCore/ExtCore/blob/master/src/ExtCore.Mvc/MvcExtension.cs#L122

Maybe we could have something like that for localization too? To unify the approaches. Like to define assemblies to look for localizations in?

[joeaudette]

this is the same problem I was trying to tackle in this project
https://github.com/joeaudette/cloudscribe.Web.Localization

it would be nice if the framework provided a way to solve this problem without so much workaround

for me the main web app is like the assembly point where composition root and configuration live, but most functionality is going to be in separate class library projects, whether using class libraries I wrote myself or written by others I want to be able to affect the localization from the main web app and to be able to customize in addition to localize. otherwise the difficulty of localizing those separate projects kind of pushes one towards baking most things directly in the main web app where it is easier to localize and customize (at least for the code by a single author)