I did a custom .editorconfig file which I apllied the nameing conventions like(interfaces should begins with I and then Uppercase) and works just fine (except the fact that it doesnt fix the names automatically after i run code cleanup). and i was wondering if there were a set of rules to control the comments, for example, the line should starts with space then the comments, and it should start new line after 100 character.
I dont want to use third party softwares, I would like to use vanilla visual studio
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'm new to VS, never really used it much. Prefer other IDE's but when it's a toss up between VS and MonoDevelop, I was told VS was the better choice.
I set it as my default editor in Unity and it's giving me this message every so often
The line endings in this file are not consistent. Do you want to normalize the endings?
Then it gives me a list such as
Windows (CR LF)
Macintosh (CR)
Unix (LF)
How can I stop this from coming up?
You can turn off that check in Tools/Options/Environment/Documents
Uncheck "Check for consistent line endings on load"
If you don't want to cover up by changing the document setting, you can try and remediate by replacing the faulty line endings. See post 'how to fix inconsistent line endings for whole vs solution.
Resharper directs my attention to this line of code in Form1.Designer.cs:
private System.ComponentModel.IContainer components = null;
...with "Field can be made readonly"
Is it safe to acquiesce, or should I just chalk it up to Resharper being a little too persnickety, and ignore it?
Resharper also flags Designer.cs for many other violations, such as:
Redundant explicit delegate creation
and, several times:
Qualifier 'this.' is redundant
UPDATE
Here's how my settings look (I didn't alter them):
So...does this mean I need to manually add all those file extensions seen in Igal Tabachniks' scream shot? It seems it is set up for Windows 8 projects only; the quick-and-dirty util that "threw" these messages is a plain old Windows Forms app.
It is safe to alter the Designer.cs file, but I would not advise it. The file is automatically generated and it will be generated again whenever you change the corresponding forms file. At top of the file it should mention this in a comment: All changes will be lost.
Those warnings from Resharper are guidelines not rules. They are only there to help with code readability and help prevent accidental coding errors by making your intent more obvious.
Now the Designer.cs file is generated by a machine and is intended to be read by a machine, not a person, so those guidelines are not relevant to the designer file.
I was 90% sure that the filters in Resharper excluded the Designer.cs from it's recommendation engine, but I would have to wait till Monday to check. You may be able to just add a filter to Resharpers settings to exclude *.Designer.cs
You must have somehow modified your Generated Code setting in ReSharper, as ReSharper by default always ignores known generated files and regions, so it shouldn't flag any violations in any .Designer.cs files.
Make sure your settings look like this:
EDIT: it seems that most of your defaults are missing, for some reason. The best thing you could do is try to reset the settings to default.
The fastest would be to delete your GlobalSettingsStorage.DotSettings, located in %appdata%\JetBrains\ReSharper\vAny, but this would obviously reset all your other settings (such as custom naming conventions).
Alternatively, you could manually edit the file (it's just an XML file), and remove all lines that start with:
<s:String x:Key="/Default/CodeInspection/GeneratedCode/GeneratedFileMasks...
After deleting the entries, save the file (make a backup first!), and restart Visual Studio. Your defaults should hopefully be back.
I have a solution that uses a native .DLL library that is wrapped by a .NET .DLL with a C# GUI.
All my plumbing works just fine in Debug mode. The moment I try going to Release mode, I get a whole whack of error messages, largely to do with the .CPP files in the native library. Errors include the following:
definition of dllimport function not allowed
TRACE_DEBUG_METHOD_CALL: identifier not found
a lot of undeclared identifiers in my main .CPP file (eg: DLLAPI_Release: undeclared identifier)
I have to admit that the Properties configuration for a C/C++ project is overwhelming so I wonder if there is one or more simple settings somewhere that I simply need to modify.
ALSO, is there a book out there that is devoted to the project properties window in VS2010 specifically? I have a few books but none really spend anytime on what is obviously a very crucial component to serious app development.
I appreciate any assistance anyone can offer. Thanks!
This is not unlikely to happen when you made a bunch of setting changes but didn't also make them for the Release build. Easy to forget, the first time anyway. You can easily tell which settings were changed from the default, they are displayed in bold type. Step through the setting pages, flip back-and-forth with the Configuration combobox in the upper left corner.
About 15 minutes of your life, not counting the thinking time you need because the setting should be different for the Release build. Start another instance of Visual Studio with a dummy project to verify that.
Trying to compare the property pages can be a beating. My recommendation would be to open the property pages for your project, select the Debug configuration, and under "C/C++", select "Command Line" and copy the command line options into a text editor, then do the same for the Release configuration and see where they differ. You'll need to do the same for the "Linker" command line.
Some of the differences will be intentional (e.g. debug flags should be set for the Debug configuration), but you should be able to spot things that should be the same but are not.
Actually tracking down where the command line options are set can be a bit of a pain, especially if you are using property sheets to manage common properties between projects, but generally you should be able to track them down just by looking through the different options on the different pages.
As for a reference, the best reference is the actual compiler documentation on MSDN. There is a section containing all of the documented compiler options and one containing all of the documented linker options.
The property pages are just a GUI frontend for setting these various options. When you select one of the properties in the property pages, it should say in the help box at the bottom of the dialog which compiler options are used by that property.