Aspnetcore: Localization not working after changing rootnamespace

[aspnet-hello]

_From @mattiaz9 on Tuesday, March 14, 2017 6:34:33 AM_

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

_Copied from original issue: aspnet/Localization#340_

[aspnet-hello]

_From @hishamco on Tuesday, March 14, 2017 6:51:02 AM_

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

[aspnet-hello]

_From @mattiaz9 on Tuesday, March 14, 2017 7:16:33 AM_

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.

[aspnet-hello]

_From @hishamco on Tuesday, March 14, 2017 8:08:46 AM_

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

[aspnet-hello]

_From @mattiaz9 on Tuesday, March 14, 2017 8:36:30 AM_

Just to test if I could replicate the problem

[aspnet-hello]

_From @hishamco on Tuesday, March 14, 2017 8:40:35 AM_

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

[aspnet-hello]

_From @ryanbrandenburg on Tuesday, March 14, 2017 11:16:26 AM_

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.

[aspnet-hello]

_From @hishamco on Tuesday, March 14, 2017 11:18:54 AM_

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

[aspnet-hello]

_From @mattiaz9 on Wednesday, March 15, 2017 4:42:02 AM_

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

[aspnet-hello]

_From @hishamco on Wednesday, March 15, 2017 9:24:59 AM_

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?

[aspnet-hello]

_From @tmm360 on Wednesday, March 15, 2017 9:31:21 AM_

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.

[aspnet-hello]

_From @hishamco on Wednesday, March 15, 2017 9:34:10 AM_

Good point @tmm360, IMHO this absolutely a bug

[aspnet-hello]

_From @hishamco on Wednesday, March 15, 2017 9:50:51 AM_

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

[aspnet-hello]

_From @rolek on Wednesday, April 12, 2017 2:46:12 PM_

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.

[aspnet-hello]

_From @TsengSR on Sunday, August 13, 2017 9:21:43 AM_

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.

[aspnet-hello]

_From @kdaveid on Saturday, August 19, 2017 6:18:33 AM_

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...

[aspnet-hello]

_From @mkArtakMSFT on Wednesday, December 27, 2017 10:41:33 AM_

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

[aspnet-hello]

_From @ryanbrandenburg on Thursday, December 28, 2017 2:56:37 PM_

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

[aspnet-hello]

_From @TsengSR on Thursday, December 28, 2017 8:05:35 PM_

@ryanbrandenburg: Can you post an example/code?

[aspnet-hello]

_From @ryanbrandenburg on Friday, December 29, 2017 9:15:22 AM_

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

[ryanbrandenburg]

Moved this to preview1 with @mkArtakMSFT's blessing since it's relatively low risk and we wanted to get the fix in front of people sooner rather than later.

[ryanbrandenburg]

Fixed in aspnet/Localization#435. We added an Attribute RootNamespaceAttribute which you can add to your assembly to specify the RootNamespace when it's different from the AssemblyName. I'm filing a separate bug to generate that Attribute automatically because that work won't be done in time for preview1.

[tmm360]

So how can I use the RootNamespaceAttribute now? Why I can't simply use <RootNamespace>My.Custom.Namespace</RootNamespace> into the project's file? This sound me like a workaround.

Actually if I set it in project's file I receive this exception: System.Resources.MissingManifestResourceException: 'No manifests exist for the current culture.'

[TsengSR]

@tmm360 : See here

Add

[assembly: RootNamespace("Alternate.Namespace")]

to your AssemblyInfo.cs (or any other *.cs file).

[tmm360]

Thank you! I've solved

[joemey]

@ryanbrandenburg
It would be awesome if this could be added to the current localization docs
(https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization#resource-file-naming.)

Took me some hours to track this down

[hishamco]

/cc @Rick-Anderson

[ryanbrandenburg]

I created aspnet/Docs#7434 to track this work.

[chrsas]

In my Asp.Net Core sample, it still does not work. https://github.com/chrsas/LocalizationTest