I have an application which has several resource files for different languages depending on the machines culture/language. This works fine if i set the Culture using code, but I am wanting to specify the culture on the command line somehow.
I know in java you simply need to set the VM Args lang attributes and the application starts up in that language, but I am unsure if this is possible using Visual Studio as it doesnt have this type of option.
Can anyone provide a non code solution, I know i could set some cmd line args to read in the lang and then set it using a bit of code but I am wanting to know if there is another way.
I also dont want to keep switching my language using my machine setting.
Cultures are a .NET specific thing, picked up at run-time from the current users 'Locale'. This can be changed by a user at runtime, on a per-application basis.
The default 'Execute Process' functionality does not really support this, a Microsoft utility exists "AppLoc" which adds this functionality. There is an article available on CodeProject Running AppLoc from Batch Files explains how to better control this.
Why do you need to set this using cmd line args?
You could just use current thread CurrentUICulture property to get it.
Related
This is not a question about standard localization - I know how to localize the app, use resources, Uid's and so on - this works perfectly.
The problem is that the app comes within a bundle, therefore when the user installs the app it covers only languages that are selected in device/phone settings. But I would like to provide an option in settings that would allow choosing a language regarding the settings. For this purpose, I can use ApplicationLanguages.PrimaryLanguageOverride, which works very nice when deployed via VS, but as I've mentioned - version from the store lacks resources, as not all are installed.
Does anybody know how to bypass this bundle behavior?
The problem is also that I'm using MAT (multilingual app toolkit) and my translation comes with xliff files. I've spent quite a lot of time to find a way to convert them to resw files, without success. Is there any way to do it (or I've to write my own converter)?
You need to use ResourceContext:
var context = new ResourceContext(); // deliberately not using getForCurrentView()
context.Languages = new string() {"fr-fr"};
ResourceMap resourceMap = ResourceManager.Current.MainResourceMap.GetSubtree("Resources");
String str = resourceMap.GetValue("string1", context).ValueAsString;
More info at:
'How to load string resources' and
'ResourceContext class'ResourceContext class'.
PS. I have app in store and there is no problem with changing language without reinstall so all resources must be there
Check out this: UWP: Resource file for languages is not deployed correctly you need to get rid of bundle in order for my code from above to work. Or you could check if chosen language is installed in OS and if not you could not allow user to choose it using:
Windows.System.UserProfile.GlobalizationPreferences.Languages
I'm wondering is there any way to use the normal shortcuts form windows like %PROGRAMFILES%, %APPDATA%,.... when using System.Diagnostics.Process.Start ?
What I want to do there is using one of those shortcuts to dynamically create the path that is being used to tart the program I want to start with Process.Start.
Example:
System.Diagnostics.Process.Start("%PROGRAMFILES%\MyApp\MyApp.exe");
Edit: As a comment to the accepted answer:
As one important thing was mentioned in the comments I want to also put it here:
If the solution does not work as the file is not found, one should print out the result of the System.Environment.ExpandEnvironmentVariables command. It can be that it points unintendedly to the x86 program files location instead of the program files location (or vice versa) depending on if for the application itself (project properties) "Prefer 32-bit" or platform target is set accordingly. If that is kept in mind the solution works quite nicely.
Use System.Environment.ExpandEnvironmentVariables to perform the expansion first, then pass the result to Process.Start:
System.Diagnostics.Process.Start(
System.Environment.ExpandEnvironmentVariables(#"%PROGRAMFILES%\MyApp\MyApp.exe"));
I am almost sure this does not work, however, there is an environment class in the .NET library that can return the information you are looking for.
Probably like:
// Change the directory to %WINDIR%
Environment.CurrentDirectory = Environment.GetEnvironmentVariable("windir");
If you use 'programfiles' instead it might work (could not check here).
You can use
Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFilesX86)`
To get the path to a special folder (in this case, 32-bit program files directory). There's more in that class that would be of help as well.
Also, I expect that Process.Start with the non-expanded path will work fine if you use UseShellExecute - the shell is capable of expanding paths on its own.
However, this is still probably a bad solution. What if the user installed your target application somewhere else? Are you sure there's no better way to get path to the application?
I'm using SharpDevelop to create a WinForm-based C# application. After studying my target audience, I believe it is in my best interest to use a no-install application. While creating my HelloWorld! program to get to know SharpDevelop (I have just switched from VBExpress), I found that the file it outputs is a .exe without any setup process. However, I'm worried that some of the features I want won't be compatible with this format. I don't want to get deep into this app and find out users are going to have to keep the program in the same directory as 548 other random files.
Here are the features I'm concerned about:
+Save user data (XML) in AppData.
+Access internet feeds (XML and/or JSON).
+Minimize to tray on close.
Also, are there any common pitfalls with this type of deployment method?
EDIT: I understand the enduser will need the .NET framwork for C# programs. I am not worried about this.
It will execute with the same privileges.
The only thing you will want to look out for is making sure the end user has the correct .NET framework installed since you don't have an installer to do that for you. But now reading the end of your message it appears you already have that covered.
If you are concerned about the deployment technique you can test it on a non-dev machine, though the results should be the exact same.
I have a winform EXE running using .NET 2.0 framework, when i sent this EXE to my friend who is using a machine where ALL the settings/OS(windows) are displayed in mandarin language.
When i try to open the EXE, i straight away get exceptions in mandarin language.
Is there something i need to change if i need to run an winforms .net EXE in mandarin machines?
Thanks.
There are going to be a whole host of localization issues. My own software has only been used with European scripts, but I still have to handle different number and date formats. So even simple things like reading and writing numbers from the registry (for default settings) require localization support. .NET 2 provides localization support - use the CultureInfo class to determine which formatting method/etc is causing the problem.
You will also need to do everything in Unicode (which you probably already know).
Running your program in a debugger should give insights as to what exactly is failing.
I've got a German VisualStudio 9.0. Working with doubles and doing quite some parsing, I came into trouble because of the decimal separator.
What I'm looking for is a way to either switch the whole IDE (and therefore all the projects created with it) to "en-gb" or do it project wide. I chose en-gb because of the lack of am's and pm's which I don't need.
I tried to set it by using Thread.CurrentThread.CurrentCulture, but this regards only the one thread. Then I found the Application wide setting, which seems to be not what I'm looking for when developing console applications.
Any idea? Thank you for reading.
The culture of the application defaults to the culture of the machine it's running on, not the machine it was developed on. The IDE is irrelevant here.
If you need to parse/format values using a specific culture, I suggest you do that explicitly - changing the current culture of all threads would be incorrect in almost all settings, IMO.