We Keep Coding

Resources used for translations suddenly not gets translated

I use resources to translate my ASP.NET Web Forms application. I use the plugin resx-Manager. This works fine to translate to four languages. But suddenly, it refuse to translate new strings added to the resource file, even when they have a translation. Only new string always use English no matter which culture is used. This is really confusing. The old strings works perfect.
Rebooted IIS
Rebuilt the project
Compared generated code but it looks identical to other strings.
When getting translation for string "X" it returns "X-sv". But when adding string Y it returns "Y-en" but I expect "Y-sv."

I found the solution. I have accidently added a language specific x.resources.dll in the bin folder. Instead they are stored in separated folder with the culture name. The file in the bin-folder was a few days old which explains why I didn't get the new strings.

Strange name and value appearing in Watch window

Does anyone have any idea what this means in the Watch window, how it was caused and how I could fix it?
I can't seem to find a specific line of code which is breaking it, it appears before the constructor of a class. I don't know what is causing it. I am programming in C# using Visual Studio 2015.
Has anyone else had an issue of this before?
A non-image version of the output is:
此᫈暔熚攺ᙋᲰ耀㼴͹픑㨊攼ᙉᵬ耀 error CS0726: '᫈暔熚攺ᙋᲰ耀㼴͹픑㨊攼ᙉᵬ耀' is not a valid format specifier
I'm not great at languages, but it appears to be a mixture of Chinese, Korean and various unicode characters. All of my code is written in English.
EDIT After further investigation, changing the text value or deleting it will make it not reaper when stepping through the code (Until it hits an exception in my code), or relaunching the debugger.

This is the Watch window - it contains a list of variables you specifically want to watch while debugging. It is not related in any way to a line of code. When you hit a break point, you can enter any value at all in the Name column - if it matches a variable that is currently in scope the value column will show its current value otherwise an error saying it is not in scope.
The names are saved somewhere so they persist when VS is restarted, so it is possible it is due to corruption of that file or if you cut & paste from somewhere using an unexpected character set.
The Name column must be a valid variable name (no spaces) or an expression (spaces allowed but it must be a valid expression) - anything after the valid portion of input may be considered as a format specifier (for example to limit number of array elements) - this error is related to that.
You can simply delete this entry & it will be gone permanently. There is no problem with your code.

Compiler Error CS0726
Visual Studio 2008 Other Versions
'format specifier' is not a valid format specifier
This error occurs in the debugger. When you type a variable name into one of the debugger windows, you can follow it with a comma, and then a format specifier. Examples are: myInt, h or myString,nq. This error arises when the compiler does not recognize the Format Specifiers in C#.
Check your VS language :
On the Tools menu, click Options.
In the Options dialog box, expand Environment and then click International Settings.
In the Language list, choose the language in which the UI text should appear in the development environment.

String appended to File converted to special charecters

I am trying to write a some string to a file.
string lines = "server.1=1.1.1.1:9999\nserver.2=2.2.2.2:8888\n";
File.AppendAllText(directory_path + "zoo.cfg", lines);
The string printed in the file is
"敳癲牥ㄮㄽㄮㄮㄮ㤺㤹ਹ敳癲牥㈮㈽㈮㈮㈮㠺㠸ਸ"
.
I tried with encoding ASCII,UTF-8,DEFAULT in the File.AppendAllText. But the output is the same.
Environment:
Visual studio 2015, Windows server 2012, .net v4.5
Please let me know what Iam doing wrong?

Appending doesn't rewrite the entire file. So, you have to use the same encoding as the existing content.
In general, if you don't know the encoding of text, you might as well not have that text. If someone gave it to you, "send it back." When they send it to you, it has to be accompanied by a mutual understanding of the encoding used. (BTW-It's very unlikely that it would be ASCII. And Encoding.Default is useless from machine to machine or user to user.)
Given the result, it makes complete sense that the file encoding was UTF-16 (Encoding.Unicode). Writing using any other encoding is garbage code.

Ok now this is weird. The code given above works perfect on my other machine. But for some reason which i don't know it's not working in my new dev env.
I solved the issue by adding the Encoding.Unicode parameter.
File.AppendAllText(windows_directory_path + "zoo.cfg", lines, Encoding.Unicode);
No idea why Encoding.UTF8/Encoding.ASCII didn't change the format for the resulting string.
Still wondering how same code could behave so differently.
I'm not sure if this is fix or a work around.

C#: Dealing with format exception for Convert.ToDouble('Infinity') on Windows 10

I have a C# forms application. As a part of its functionality, it writes double values to a file in string format, some of which are double.Infinity.
There is another part of application that reads these values from file and converts them back to double.
When writing values part is performed on windows 7 and reading the same file is performed on Windows 10, then there is format exception while converting 'infinity'. It appears the symbol used by the default (us-en) culture changed between Windows 8 and 10.
There are many instances of Convert.ToDouble() in application and handling each of these instances through try-catch or by using double.tryParse() isn't a feasible solution as it will require changes in many projects.
Is there any workaround for this to avoid this format exception problem?
Thanks in advance,
Kapil

This is an even bigger issue when dealing with databases and storing data in other cultures too. We initially had a problem in that the Spanish version of our software wouldn't read infinity properly, and would store infinity as the symbol, instead of the word. Even when trying to force it onto the english culture, it appeared broken.
We then saw this issue crop up on Windows 10 in the english culture, where the infinity symbol would now be saved in the database. This issue has the potential to cause problems across Windows versions and across cultures.
The safest thing to do is store and retrieve data, whether in a file or a database, using CultureInfo.InvariantCulture. This way it will always be as you expect it.
If you already have a problem in files/database, then you could run a fairly simple script to seek out the 'Double|∞' and replace it with 'Double|Infinity' which is the invariant type.
This will save you from future problems

File.Exist returning true when path has multiple backslashes

I have an application that accepts user input and does stuff to files. The users select a file and it might move it, delete it, rename it, ftp it etc. The application uses a hash table to store recently used files and their paths.
The main problem I am looking into now is one of the add-ins is saving the path incorrectly, it is saving it as such: C:\David\\File.txt
The part of the application that deals with file io tries to ensure the file exists prior to doing stuff with a File.Exists(path) call. This call is returning true even for the above example. Can anyone explain why this might be?
The issue I am facing is, beyond one module saving the path incorrectly, certain modules that interact with the file are accepting that incorrect path and working fine while others see it and crash. Although currently I am going to fix this by getting the path saved correctly, I'd like to understand what is going on here.

You have a false premise: that C:\David\\File.txt is an invalid path. Multiple backslashes are accepted fine in Windows. Try notepad C:\David\\File.txt in a command prompt as an experiment--it should work.
For more info, see this other SO q/a that reaffirms this. Any number of backslashes are fine, and this can be used as a "easy" way to combine paths without worrying about the number of backslashes. For example, the user can provide C:\David or C:\David\ and you can add \test.txt without worrying which input the user provided. However, Path.Combine is the real way to do this in C#.
Edit: To remove your extra \'s easily before passing the path into the other program, try splitting the path into the drive and folder names and combining it back together into a path. Like this:
string path = Path.Combine(pathWithManyBackslashes.Split('\\'));
Because Split doesn't create new entries when the delimiter repeats, you get rid of them. For example, C:\David\\File.txt => [C:, David, File.txt].