ResourceManager/Localization not working after changing rootnamespace

@azchohfi commented on [Fri Jan 11 2019](https://github.com/dotnet/corefx/issues/34562)

This issue had already been fixed by Asp.Net Core, but we need the same solution for WPF/WinForms:
https://github.com/aspnet/AspNetCore/issues/2645

---

@jkotas commented on [Fri Jan 11 2019](https://github.com/dotnet/corefx/issues/34562#issuecomment-453724628)

cc @sdmaclea

---

@sdmaclea commented on [Tue Jan 15 2019](https://github.com/dotnet/corefx/issues/34562#issuecomment-454453886)

> we need the same solution for WPF/WinForms: aspnet/AspNetCore#2645

AspNetCore added the `Microsoft.Extensions.Localization.RootNamespaceAttribute` and used it in its calculation of the absolute resource name. This was all done in high level libraries.

For WPF to use the **same** solution, it would seem this would need to be done in WPF.

If the runtime was to implement a **similar** solution, it would need to introduce a new (similar) attribute to the NetCoreApp API surface.

---

@azchohfi commented on [Tue Jan 15 2019](https://github.com/dotnet/corefx/issues/34562#issuecomment-454466469)

Exactly. As long as we have a plausible solution for desktop apps with .Net Core 3.0, I'm happy.

---

@tarekgh commented on [Thu Jan 17 2019](https://github.com/dotnet/corefx/issues/34562#issuecomment-455317775)

@sdmaclea what is the direction now? should this be moved to wpf? or you think it should be the core?

---

@sdmaclea commented on [Thu Jan 17 2019](https://github.com/dotnet/corefx/issues/34562#issuecomment-455329732)

@tarekgh It is not clear to me yet what the right answer is.

@azchohfi I read through aspnet/AspNetCore#2645 again.

How was this handled in .NET Framework? Why wasn't it a problem? Why is .NET Core different?