Localization not working after changing rootnamespace

[mattiaz9]

If you specify a default namespace different from the assembly name the localization doesn't work anymore.

[hishamco]

@mattiaz9 is it the same of issue #296? if not please clarify your scenario, because localization relay on assembly name, specially ResourceStringLocalizer

[mattiaz9]

I'm not sure. It worked before updating the project format to the new one in VS 2017.
The same problem occurs with the sample project in this repository. If I change the default namespace with VS 2017 the localization doesn't work.
I can't verify with the old VS though.

[hishamco]

I'm still surprising why you changed the default namespace for sample repo?

[mattiaz9]

Just to test if I could replicate the problem

[hishamco]

IMHO changing this absolutely will affect the generated resource files, so that's why you should care about the namespaces. I saw many issues in the past raised by namespace conflict, so that's why I mentioned the issue #296 in my first comment

[ryanbrandenburg]

When having trouble with resource discovery make sure you've read the localization docs, especially https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization#resource-file-naming.

To sum up, there are two things you must know before naming a resource, first is the name of the assembly for your project. This is decided by a lot of different factors (name of .csproj file, name of containing folder, properties within the .csproj file etc), which are different between project.json and MSBuild, so the most correct way to find it is to look at the result of typeof(Startup).GetTypeInfo().Assembly.FullName at runtime.
The second thing to know is the full name of the class the resource is for. If you're looking up a resource for the class Startup in the namespace Localization.Project then it's Localization.Project.Startup.

Once you know both of these things you can create your resource. You must name your resource the full name of the class, but trim the assembly name from the front if it's there. So in the project Localization.Project a class with full name Localization.Project.Startup would have the resource file Startup.resx, but a class with full name ExternalNamespace.Startup would have a resource file ExternalNamespace.Startup.resx

If you're still having trouble after double checking these things please upload a sample which reproduces your problem to GitHub for us to review and debug against.

[hishamco]

I'm able to reproduce the issue after modifying the default namespace

This will let all the resource files to use the newly RootNamespace in the LocalizationSample.csproj.FileListAbsolute.txt, so if I change the default namespace to MyLocalizationSample the French resource for instance will be MyLocalizationSample.My.Resources.Startup.fr-FR.resources instead of LocalizationSample.My.Resources.Startup.fr-FR.resources

[mattiaz9]

Maybe I'm doing something wrong..
I made this repo https://github.com/mattiaz9/LocalizationSample
I used two different naming convention to test it out, but none of them works with a custom default namespace.
I hope it can help

[hishamco]

Changing the RootNamspace absolutely will cause the bug, but still wondering we need change it?!!
Anyhow I will look to your sample

@Eilon can we consider this as bug?

[tmm360]

We need to change it for example when a company has a structured enterprise path on namespace, for example Contoso.MyService.Solution.InternalPath.
In this example Contoso.MyService.Solution will be the root namespace, but it will not also the assembly's name, that could be "ServiceSolution", for example.

An other example is when you have a complex solution with modules, where you want to put modules on other sub namespaces of the original project.

[hishamco]

Good point @tmm360, IMHO this absolutely a bug

[hishamco]

https://github.com/mattiaz9/LocalizationSample/blob/master/LocalizationSample/Startup.cs#L13 @ryanbrandenburg this is the same behavior of the issue #296 that @dougbu mentioned long time back, expect that caused by using invalid as a C# identifier, while this cause by changing the Default Namespace

[rolek]

For the sake of reproducing the issue, I created the sample too:
https://github.com/rolek/netCoreLocalization

Actually, localization is working, but not based on RESX files in this case. If you localize like: *.EN.cshtml, this still works.

[TsengSR]

This issue should really be addressed before 2.0 goes life imho or another year may pass. It's an absolutely common practice in n-layer architecture that assembly name do not equal the default namespace.

[kdaveid]

I have a very localized netcoreapp2.0 (web) but now my executing assembly has a name like: bar.foo.Product.Web.exe which is not only ugly but makes installation- and configuration-instructions horrible to read.

I'd be ready to add an attribute to my classes with a property pointing to the right namespace for localization. But this would not work for razor views...

[mkArtakMSFT]

@ryanbrandenburg, let's meet to discuss the solution.

[ryanbrandenburg]

@mattiaz9 we are discussing possible permanent solutions to your issue, but I wanted to let you know that one possible temporary solution to your problem is to add the correct LogicalName metadata to your EmbeddedResource items. This is less than ideal as it requires explicit understanding of how we look up resources and how they are normally stored, but we thought you might like to know about the option while we investigate further.

[TsengSR]

@ryanbrandenburg: Can you post an example/code?

[ryanbrandenburg]

I updated one of the resources in @mattiaz9's example with the correct LogicalName here.

[aspnet-hello]

This issue was moved to dotnet/aspnetcore#2645