1. дома
  2. Вопрос и ответ
  3. Локализация Windows Forms с .NET 3.5

Локализация Windows Forms с .NET 3.5

2013-05-14 2 views
1

У меня возникла проблема с созданием локализованного приложения WinForms с целевой платформой .NET 3.5.Локализация Windows Forms с .NET 3.5

Я следуя руководству от MSDN: http://msdn.microsoft.com/en-us/library/y99d1cd3%28v=vs.90%29.aspx

После того как я слежу за Пошаговое руководство и создание локализуемых формы и установки Thread.CurrentThread.CurrentUICulture в какой культуре он работает только тогда, когда я установил, как Target Framework».NET Framework 4 ». После того, как я перекомпилирую приложение с «.NET Framework 3.5» в качестве целевой структуры, я не могу отображать разные языки, чем по умолчанию, поэтому установка CurrentUICulture не влияет на отображаемый текст.

Я не мог найти информацию об этой проблеме, любую информацию о том, что в .NET 3.5 и .NET 4.0 существует другое поведение. У кого-нибудь схожая проблема, или знаете, в чем причина поведения, которую я описал?

Больше объяснения:

  1. Я устанавливаю CurrentUICulture перед тем InitializeComponents способом:

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

  2. Все отлично работает в .NET 4.0, но когда я изменить его на .NET 3.5 это не. enter image description here

  3. Я использую Visual C# 2010 Express.

источник

2013-05-14 bozydar.sz

+1

Когда вы устанавливаете 'CurrentUICulture'? Это должно быть до загрузки ресурсов (то есть прямо в начале программы, прежде чем вы будете отображать какие-либо формы вообще). Это определенно работает для .Net 3.5, мы использовали его для всех наших 3.5 программ Windows Forms. –

+0

Я устанавливаю его в конструкторе основной формы перед методом InitializeComponent, как описано в Пошаговом руководстве. Просто чтобы убедиться, что я изменил его и в начале метода «Program.Main», но он тоже не помог. –

ответ

-1

Я выяснил, что проблема была вызвана моей установкой Visual C# Express или .NET 4.5 (не уверен, какой из них был причиной проблемы).

После того, как я проверил свои спутниковые DLL-ресурсы с помощью ILSpy, оказалось, что даже когда я строил свой проект с .NET 3.5, библиотеки ресурсов были созданы с 4.0-м временем выполнения и не могли быть загружены приложением. Вот почему текст не был изменен, даже после того, как я изменил CurrentUICulture.

Удаление .NET 4.5 и переустановка Visual C# 2010 Express решила проблему. Теперь спутниковые DLL-ресурсы с ресурсами построены с 2.0-м временем выполнения и правильно загружены моим приложением.

источник

2013-05-14 13:43:07

0

Установите культуру следующим

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

SetCurrentCulture показано ниже, и устанавливает культуру по умолчанию. Это необходимо выполнить перед вызовом InitializeComponent.

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

CultureInfo.DefaultThreadCurrentCulture и CultureInfo.DefaultThreadCurrentUICulture были введены в .NET4.5 + и используется, чтобы сообщить любые последующие темам отделились от основного потока пользовательского интерфейса, что по умолчанию культура должна быть заданным значением. Это может быть неприемлемо для вас с помощью .NET4.0.

Надеюсь, это поможет.

источник

2013-05-14 09:10:36 MoonKnight

+0

Спасибо за ваш ответ, но в моем случае это не поможет. Я устанавливаю культуру в правильном месте и работает с .NET 4.0, но останавливается сразу после того, как меняю целевую структуру на .NET 3.5. Я отредактировал свой пост, чтобы получить больше информации. –

0

Я хотел бы вернуть эту тему, так как у меня есть та же проблема, и решение bozydar.sz (удаление .NET 4.5) мне не кажется приемлемым. Я нашел ту же проблему с Visual Studio 2012 (Express, Desktop), когда таргетинг на приложение Windows Forms на платформу .NET 3.5.Я проверил DLL ресурсов с ildasm и обнаружил, что библиотеки ресурсов были созданы с 4.0 runtime, даже целевая структура была 3.5.

Эта же проблема с использованием VS2012 Express указана в Microsoft Dev Center, однако решение не сообщается. В another post на Stackoverflow проблема была также указана для VS2012 и целевой среды < 4.0. Решение для вопросителя состояло в том, чтобы остаться с предыдущей версией Visual Studio, что опять же не является решением.

Я пробовал разные настройки для «Build Action» и других свойств файлов * .resx без успеха.

Далее, я проверил эту проблему следующим образом: Я установил Windows SDK for Windows 7 and .NET 3.5 SP1. Из командной строки этого Windows SDK 7.0 я построил sln-файл Visual Studio 2012 с помощью msbuild 3.5. Проверка ресурсов DLL с ildasm дает мне версию 2.0.50727 на этот раз, вот что я ожидаю отсюда. Когда я заменяю DLL ресурсов исходного развертывания (из VS2012 публиковать диалог с целевой структурой 3.5 и ToolsVersion 4.0) библиотеками ресурсов, которые я получил из msbuild 3.5 в моем развертывании, проблема решена: Локализация приложения Windows Forms верна Теперь. Но все же использование msbuild 3.5 не является долгосрочным решением. Если целевая структура 3.5 предлагается в VS2012, я бы ожидал, что она будет вести себя правильно.

С Visual Studio 2013 RC наблюдалось то же поведение: библиотеки ресурсов имеют версию 4.0, а не 2.0. Библиотеки ресурсов не могут быть загружены основным приложением.

This answer пользователем Dan Malcom на другой вопрос о Stackoverflow привел меня к хак реестра, который работает для меня:

[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\\[email protected])" 
"MSBuildRuntimeVersion"="4.0.30319" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0\\[email protected])" 
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\[email protected])" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0] 
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0\\[email protected])" 
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])"

Оригинальные ключи в моем реестре были:

[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\\[email protected])" 
"MSBuildRuntimeVersion"="4.0.30319" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.0A\\[email protected])" 
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\MSBuild\\ToolsVersions\\[email protected])" 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0] 
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])" 
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\[email protected])" 
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v8.0A\\[email protected])" 
"WindowsSDK80Path"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft SDKs\\Windows\\[email protected])"

Я экспортировал реестр ключи, отредактированные в конце, запустили файл для исправления ключей. Для Wow6432Node реестра я сделал то же самое.

следующие проблемы существовали в моем первоначальном реестре (должно быть состояние после установки VS2012 и Windows SDK 7.0):

  • Значение FrameworkSDKRoot в ToolsVersions\4.0 ключевых ссылок ключ от Windows SDK 7.0a (тот, который поставляется с VS2010), но эта версия никогда не была установлена ​​на моей машине.
  • То же самое относится к значениям SDK40ToolsPath и SDK35ToolsPath.
  • Значение SDK35ToolsPath в справочнике ToolsVersions\4.0\11.0WinSDK-NetFx35Tools-x86, которого не было.
  • В Wow6432Node все FrameworkSDKRoot, SDK35ToolsPath или SDK40ToolsPath были неверными (ссылка на несуществующие значения реестра).

Редактирование реестра решает проблему, но с высокой стоимостью: необходимо применить это изменение к каждому серверу разработки/сборки.

источник

2013-10-09 09:44:52 biquaternion

Смежные вопросы

 Смежные вопросы