Localizing Windows Forms with .NET 3.5

Question

I have a problem to make a localizable WinForms application with target .NET 3.5 framework.

I am following the guide from MSDN: http://msdn.microsoft.com/en-us/library/y99d1cd3%28v=vs.90%29.aspx

After I am following the Walkthrough and creating localizable form and setting Thread.CurrentThread.CurrentUICulture to some culture it is working only when I set as Target Framework a ".NET Framework 4". After I am recompiling the application with ".NET Framework 3.5" as Target Framework I am not able to display different language than default, so setting CurrentUICulture doesn't affect displayed text.

I could not find any information about this issue, any information that there is a different behavior in .NET 3.5 and .NET 4.0. Had anyone similar problem, or know what is the reason of behavior I described?

More explanation:

I am setting CurrentUICulture before InitializeComponents method:

public partial class Form1 : Form 
{
    public Form1()
    {
        Thread.CurrentThread.CurrentUICulture = new CultureInfo("pl-PL");
        InitializeComponent();
    }
}

Everything working perfectly in .NET 4.0, but when I change it to .NET 3.5 it is not.
I am using Visual C# 2010 Express.

When are you setting `CurrentUICulture`? It has to be before the resources are loaded (i.e. right at the start of the program before you display any forms at all). It definitely works for .Net 3.5, we used it for all our 3.5 Windows Forms programs. — Matthew Watson, May 14 '13 at 08:33
I am setting it in main form constructor before `InitializeComponent` method as described in the Walkthrough. Just to be sure I changed it also in the beginning of `Program.Main` method as well, but it didn't help as well — bozydar.sz, May 14 '13 at 08:37

score 3 · Answer 1 · answered Mar 12 '18 at 19:37

I know I am pretty late for the party but since I spent hours to find the solution I want to share it with you. The solution is for Visual Studio 2017.

I guess the problem has to do with the issue discussed in: https://developercommunity.visualstudio.com/content/problem/5735/when-vs-2017-rc-is-installed-resourcesdll-is-gener.html

The problem is that VS 2017 compiles the resource satellite assembly dlls with .NET 4.0, wich causes them to be silently ignored by the exe compiled as .NET 2.0 executable.

The solution is to start the Visual Studio Installer, click on Modify below Visual Studio Commuity 2017. The change to the tab Individual components and select and install .NET Framework 3.5 development tools.

Thanks. After I installed the.net Framework 3.5 development tools using the Visual Studio Installer, everything worked fine! (VS 2019) — zmjack, May 29 '20 at 04:03

score 0 · Answer 2 · answered May 14 '13 at 09:10

Set the culture as follows

public MainForm()
{
    // Set default culture before initialisation.
    SetCurrentCulture();
    InitializeComponent();
}

The SetCurrentCulture is shown below and sets the default culture. This needs to be performed before the InitializeComponent call.

public static void SetCurrentCulture(CultureInfo cultureInfo)
{
    Thread.CurrentThread.CurrentCulture = cultureInfo;
    Thread.CurrentThread.CurrentUICulture = cultureInfo;
    CultureInfo.DefaultThreadCurrentCulture = cultureInfo;
    CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;
}

The CultureInfo.DefaultThreadCurrentCulture and CultureInfo.DefaultThreadCurrentUICulture were introduced in .NET4.5+ and is used to tell any subsequent threads spun off from the main UI thread that there default culture should be the specified value. This may not be relevent for you using .NET4.0.

I hope this helps.

Thank you for your answer, but in my case it won't help. I am setting the culture in correct place and it works with .NET 4.0 but stops right after I am changing target framework to .NET 3.5. I edited my post to provide more insight. — bozydar.sz, May 14 '13 at 09:39

score 0 · Answer 3 · edited May 23 '17 at 10:25

I would like to bring this topic back, as I have the same problem and the solution of bozydar.sz (uninstalling .NET 4.5) doesn't seem acceptable to me. I found the same problem with Visual Studio 2012 (Express, Desktop) when targeting my Windows Forms application to .NET 3.5 framework. I inspected the resource DLLs with ildasm and found the resource DLLs were built with 4.0 runtime even the target framework was 3.5.

The same issue using VS2012 Express has been reported at Microsoft Dev Center, however a solution is not reported. In another post on Stackoverflow, the problem was also reported for VS2012 and target framework < 4.0. The solution for the questioner was to stay with the previous version of Visual Studio, which again isn't very much of a solution.

I tried different settings for "Build Action" and other properties of the *.resx files, without success.

Next, I verified this problem as follows: I installed Windows SDK for Windows 7 and .NET 3.5 SP1. From the command prompt of that Windows SDK 7.0, I've built the Visual Studio 2012 sln file with msbuild 3.5. Inspecting the resource DLLs with ildasm gives me version 2.0.50727 this time, this is what I would expect here. When I replace the resource DLLs of the original deployment (from VS2012 publish dialog with target framework 3.5 and ToolsVersion 4.0) by the resource DLLs which I got from msbuild 3.5 in my deployment, the problem is resolved: Localization of the Windows Forms application is correct now. But still, using msbuild 3.5 is not a long term solution. If target framework 3.5 is offered in VS2012, I would expect this to behave properly.

With Visual Studio 2013 RC the same behavior was observed: the resource DLLs have version 4.0 and not 2.0. The resource DLLs cannot be loaded by the main application.

This answer by user Dan Malcom to another question on Stackoverflow led me to a registry hack that works for me:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="c:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\"
"MSBuildToolsRoot"="c:\\Windows\\Microsoft.NET\\Framework64\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0\\WinSDKNetFx35Tools@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0]
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A@InstallationFolder)"
 "SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0\\WinSDKNetFx35Tools@InstallationFolder)"
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0@InstallationFolder)"

The original keys in my registry were:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="c:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\"
"MSBuildToolsRoot"="c:\\Windows\\Microsoft.NET\\Framework64\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A@InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\4.0@MSBuildToolsPath)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0]
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A@InstallationFolder)"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx40Tools-x86@InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\WinSDK-NetFx35Tools-x86@InstallationFolder)"
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0@InstallationFolder)"

I exported the registry keys, edited them end ran the file to correct the keys. For the Wow6432Node of the registry I did the same.

The following problems existed in my original registry (must be the state after I installed VS2012 and Windows SDK 7.0):

The FrameworkSDKRoot value in the ToolsVersions\4.0 key references a key from Windows SDK 7.0A (the one that comes with VS2010), but this version was never installed on my machine.
The same holds for the SDK40ToolsPath and SDK35ToolsPath values.
The SDK35ToolsPath value in the ToolsVersions\4.0\11.0 key references a WinSDK-NetFx35Tools-x86 which did not exist.
In the Wow6432Node, all of the FrameworkSDKRoot, SDK35ToolsPath or SDK40ToolsPath were incorrect (referencing non-existing registry values).

Editing the registry resolves the problem, but at high cost: One needs to apply this change to every development computer / build server.

score -1 · Accepted Answer · answered May 14 '13 at 13:43

I've found out that the problem was caused by my installation of Visual C# Express or .NET 4.5 (not sure which one was the root of the issue).

After I checked my resources satellite DLL with ILSpy, it appeared that even when I was building my project with .NET 3.5, resource DLLs were built with 4.0 runtime and could not be loaded by the application. This was the reason why text was not changed, even after I changed CurrentUICulture.

Uninstalling .NET 4.5 and reinstalling Visual C# 2010 Express solved the issue. Now satelite DLLs with resources are built with 2.0 runtime and are correctly loaded by my application.

Localizing Windows Forms with .NET 3.5

4 Answers4