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.
Related
I have a problem with parsing steps in .feature file with implementation which is defined in steps.cs file. Beside that, the same step was parsed successfully just a few lines upper in same scenario in .feature file. All steps bind successfully, with exception of last 2 steps, which fail to bind, although these steps appear for 2nd time.
I tried to delete .cache files in %TEMP%, but it is not that. Besides that, step definition is like:
From steps.cs file, when I do Ctrl+Alt+Shift+S, I get 2 steps recognized, which is ok.
We use VS 2015, specflow for VS2015, and SpecFlowSingleFileGenerator as generator. Same happens with VS 2019, with specflow for VS2019 and SpecFlowSingleFileGenerator as generator.
I must say that we have a plenty of scenarios and features which behave nice (with very very basic regex).
Anybody got any clue for this?
Also, when I enable tracing (Tools->Options->SpecFlow) in Output window of VS, I get the messaages:
[08:51:21.6011171] EditorParser: Start full parsing
[08:51:21.6041087] EditorParser: Finished full parsing in 2 ms, 6 errors
Edit: when I open .feature file for first time on opening solution, it parses everything well at first glance. But after 30 seconds, some of steps transit to unrecognized state, as mentioned above.
Edit 1: seems like this part of regex makes problems - \s*(for remote point ""(.*)"")?.
When I put space before open brace (, I get good parsing. But my steps then aren't functioning anymore.
Edit 2: images removed.
Edit 3: I've got mail from Andreas about this topic:
When the regex of a binding is getting to complex the Visual Studio Extension has problems to match them correctly. I fear your regex is already to complex for it.
The runtime should handle it just fine.
From my experience having these kind of checks in the regex make it hard to see then the error at runtime.
I think you only get an exception that the step can't be matched.
If I have such a restricted range of possible values as in your binding, I always have a runtime check that throws an exception if it doesn't pass.
I have this VisualStudio solution with a project inside of it. I have added several strongly typed config settings, that are found in the Settings section of the app. However, when I try to add a char setting with special character as the actual value I get error similar to:
'\n' cannot be converted to an instance of type 'char'.
See attached screenshot below.
I have tried editting the underlying App.config xml file, but setting the value there to a special character such as \n or \t, simply resets the field to an empty character.
I need the said setting to be a configurable delimiter for one of my data parsers.
Is it possible to have strongly typed setting setting that is a special character? What is the workaround for the above error message?
Used Visual Studio version: VisualStudio Professional 2015 (.NET 4.7)
Edit: The suggested duplicate question does not talk about app.settings or the limitaion imposed by Visual Studio at all. It is entirely different question
As a quick & dirty workaround, you can store special characters in settings as integers. Then where you load the settings, you can typecast that int to a char. On saving the settings, you dont even need the typecast.
I hit this odd behavour yesterday in Visual Studio 2015 where I was making a string that started and ended with double quotes. In stepping through the code I hovered over the result to see the contents and there were back slashes in the string - what! (see image below). Cutting a long story short, I figured out the debug view of the variable is displaying with the escaping backslashes - which in my opinion is misleading.
Does any one know if there is a way to disable this in Visual Studio so that it just displays the value as either ""bob*"" or without indication of the string type "bob*" ?
P.S. Yes I know, it seems a bit newbie to be using VS for years before noticing this behavour. Also the image is not showing our production code :)
This is expected. Because you are under debug mode you are given the dev version of the string.
To get a user friendly version of the string (actual value without slash) you just have to click on the magnify glass icon on the left
While trying to compile and debug C# code in Visual Studio I'm hitting this error - "no logical space left to create more user strings". Actually, the code compiles properly, but it crashes with this error while trying to create the executable.
I've looked at C# compile error: "No logical space left to create more user strings" and EF 4.3.1 IMigrationMetadata.Target strings are causing "No logical space left to create more user strings." compile errors but these don't help here, since they talk about C# code that was generated by some other script/process.
In my case, it's normal C# code that's being compiled/linked and hitting this error.
Can someone please help me figure out how I can debug this issue? What may be causing this problem?
There are a total of about 10 string declarations in my code.
Use Strings application to dump out all the strings in your application,from which you will be able to find ,what string is being created multiple times.
Alternatively you may also use Windbg
I use a *.resx file for the localization purpose. The Name - it's a phrase or word in English. The Value - the translation to another language of that phrase. I choose this approach to have a one localization file for the whole application. And anyone who have this file can make translation by themselves.
But in the Visual Studio 2010 resx editor, each record with name which have spaces in it, have a warning: "The resource name is not a valid identifier."
Though it compiles and works, but please tell me if I am doing something wrong here.
First of all, the idea of the resx files is to have a separate resource file for each culture. You can provide the new translation by creating a new file with different values for the same keys.
For example, you can create Forms.en-GB.resx, Forms.pl-PL.resx, Forms.de-DE.resx and the appropriate file will be picked up based on the current UI culture without you having to do anything (except ensuring relevant culture is set).
Visual Studio will generate a resource class that contains all your key/value pairs from resource file as properties - that makes it easier to use in code. The warning you get means that the keys you've provided in resource file are not a valid identifiers (they contain spaces). You might want to use _ instead of space in the keys.
If you don't want to use the generated class you can ignore this warning - your resx files are fine and can be used directly. You can remove ResXFileCodeGenerator from 'Custom Tool' property of your resx file (properties windows) or set 'Access Modifier' to 'No code generation' in resx file editor if you do not need to generate a class, but you will still get the warning.
The strength of localization with resx files is that the culture on your computer decides what language your application should be in. If you keep to one resx file, according to me, you ignore it's power. Instead, try making a resx file for each language you want to integrate. for example: the default language is english, then you have a default page localization.resx where you only keep english sentences. Say you need a French translation, make another resx file called localization.fr-FR.resx. So users who have the fr-FR culture enabled on there computer will have that language on the program without any code specific work. If someone with a culture not integrated in your application starts the program, it will look for it, and if it doesn't find it, it chooses the default, ie english, one.
So to my opinion, don't use 1 resx file for different languages, but use the powers given in the framework.
I suppose it works, but it's not really the strategy you are supposed to follow.
Take a look here; the basic idea is that you take advantage of the controls in .NET to automatically get the correct localisation themselves, so you kind of don't need to worry about doing the translating.
Though, I don't use this all the time, and I do somewhat do as you do, but I tend to use an identifier, so I may have:
UserWelcome Hey, {name}, thanks for dropping by ...
And then I'll translate that. It's helpful because it allows generality in the languages (say, for example, some languages should be greeted formally, and others not, you don't want to be contrained by a direct translation of, "You", say).
Hope this is clear.
If what you've got works, then I suppose that's something, but it's not the "general" way of doing it.