Not working Visual Studio 2012

Jun 29, 2012 at 9:05 AM
Edited Jun 29, 2012 at 9:06 AM

Library looks very cool but is not working with VS 2012 beta.

Design time support finally works when restarting VS. 

But at run time: Resources are always taken from default culture and ignoring Thread.CurrentThread.CurrentUICulture. When setting content from code behind it works without problems. So there might be a problem with your library?

Tested with 2.0.0 and 2.1.0 beta nuget packages.

Best regards from sunny Bremen



Jun 29, 2012 at 11:59 AM

Hi Björn,

I've tested design time and runtime in my Win8/VS2012 RC (Release preview) sandbox and it worked. Did you experience this behaviour only once or repeatedly?

The other question is rather philosophical - we decided not to set the culture on our own due to several reasons. We recommend binding the culture to your viewmodel and handling an unset culture there.

Best regards from boiling hot Jena,


Jun 29, 2012 at 1:28 PM

Hi Uwe,

perhaps I misunderstood the concept. Evertything works fine when setting


to the supposed culture. 

Best regards


Aug 30, 2012 at 3:49 PM

I was just testing WPFLocalizeExtension with the official release of Visual Studio 2012, and changing localization at design time does not appear to work. Changing localization during run time is just fine though.

Any thoughts, or has anyone else had issues with design time?

Sep 4, 2012 at 9:28 PM

Up to now, I do not have the VS2012 release here.

Sep 24, 2012 at 10:02 PM

I can confirm it not working in VS2012.

It doesn't show up in the Designer until you completely restart VS. Changing the DesignCulture doesn't seem to work at all.

I have no clue how I could help debugging that. Maybe you can point me to the right direction, MrCircuit? :-)

Sep 25, 2012 at 8:09 AM

I'll switch to VS2012 soon and then I'll have a look at it.

Sorry for the delay.

Sep 26, 2012 at 7:19 PM

I tried it again today... after restarting VS, it works O.ô

As it seems, the .resx files don't get reloaded after editing and/or building them, so adding strings or editing them has no effect until I close and re-open the solution or restart VS.

Also, when I edit the XAML and modify the key of a working Loc extension, the new string only shows up after changing the DesignCulture or re-opening the XAML.

I haven't tested it thoroughly, so there might be more problems or maybe I misinterpreted some observations. I hope you can find the problems and fix them. I could try and debug the extension's code, but I currently have no idea how to debug the code while it's run by the designer. Any help with that?

Sep 26, 2012 at 8:50 PM


In general, the project that contains the resx files has to be rebuilt after changing the files. The second issue may be a problem with the internal PropertyChanged notification of the LocExtension - I'll see if I can reproduce this in my current version of VS.

Debugging during design time is only possible using Logging (e.g. writing to a text file or engines like NLog) or step-by-step exception-throwing supplying the state information to the exception message :-).

Best regards,


Sep 27, 2012 at 12:11 PM
MrCircuit wrote:

Debugging during design time is only possible using Logging (e.g. writing to a text file or engines like NLog) or step-by-step exception-throwing supplying the state information to the exception message :-).

Hi Uwe, thats not completly true. In VS2010 it was possible to start a second instance of VS2010 and attach to the process of the first VS2010 while debugging. The second instance got the wpf localize extension source open with breakpoints enabled.

Its a crazy setup but was working fine. Please have a look if this is still true for VS2012.

Best regards

Oct 8, 2012 at 12:43 PM


Here comes an update:

I've digged into the key change issue that occurs in all versions of VS. Up to now, I found the following facts:

* If the key is supplied using the constructor syntax (e.g. "{lex:Loc SomeKey}"), no update of the property is fired internally or in other words, the object is not created again. This needs the particular XAML to be reloaded (close and open again, rebuild project...).

* If the key is supplied via the Key property (e.g. "{lex:Loc Key=SomeKey}"), an update is propagated to the internal property but it does not trigger an update of the value, although it *should*. Again, a reload of the XAML makes the changes to take effect.

* When changing a key, that is supplied using one of the previous two ways, and *then* changing the design culture, the value is updated correctly. I'll try to find out more on this.

Best regards,


Jan 11, 2013 at 3:46 AM

tried both way with Key no no key and it will not flip language at design time