We used to arrange our Files with a Tool called NArrange.
Unfortunately, this doesn't get advanced anymore and thus doesn't work with the new C#-Expressions like String-Interpolation etc.
I'd like to use ReSharper for the arrangement and also tried to work trough the instructions: https://www.jetbrains.com/help/resharper/10.0/File_and_Type_Layout.html?origin=old_help
From what I've seen in them and in the VS, there is a default Template for every Type and the "Full Cleanup" should apply it.
But just nothing happens.
I also tried to change some stuff on the Default Layout and created my own Profile as suggested, but it keeps happening nothing.
Since I can't get any information from Mr. Google, I guess I'm doing something wrong, which is pretty obvious?
Got it: ReSharper can't make use of other Regions than the ones defined in the File Layout: As soon as a to ReSharper unknown Region is in the File, it seems to stop the whole process and just does nothing.
Related
I'm using Visual Studio Code primarily to edit C# code, and it automatically detects errors in the code as I type. However because it updates this every second or so, that means that the moment I start typing something on a line and pause even for a brief moment, I've technically introduced a syntax error and it highlights it with a red underline, until finally the whole line is typed.
This is very distracting! I like having it tell me where errors are, but I'd much rather have it wait until I've finished what I'm typing, or even better when I've saved the file, since at that point I expect the code to be correct.
Is there any way to configure VS Code to do this?
I think the answer to this is that there is still no way to add a delay to the code validation. See Intellisense, Add an option to delay validation (and thus wavy lines in code).
The unsatisfactory solution provided there is to disable validation altogether until a save operation:
On second thought , this is exactly what tasks already do. Just
disable the built-in js/ts validator using javascript.validate.enable:
false + typescript.validate.enable: false and setup a task to build
your project instead. It should only update errors when the file on
disk changes (i.e. you save it). You can also configure autosave if
wish to have this happen after a delay
You would have to see if your cSharp language server provides an option to run validation onSave or onType.
I just looked through all the settings for csharp and omnisharp in vscode and found nothing similar to the validate only on save option or to disable validation altogether.
For php there is such an option built-in: PHP > Validate: Run. onSave or onType.
I have updated the extension When File v0.4.0.
Now you can change workbench colors when the file is dirty (not saved) (experimental)
This only works for files in a Workspace. The extension needs a workspace because it will not change the global workbench color customization.
Add the following to your settings (Global or Workspace)
"whenFile.change": {
"byLanguageId": {
"csharp": {
"whenDirty": {
"editorError.foreground": "#ff000020",
"editorWarning.foreground": "#ff000020",
"editorInfo.foreground": "#ff000020"
}
}
}
}
When you start typing the squiggles will be very faint red. If you save the file they will get the theme colors back. Every theme uses different squiggles colors but faint red is not a problem. Also the icons in the PROBLEMS panel become transparent.
If you have customized these colors you have to put these in a theme group of workbench.colorCustomizations. But it can be that theme groups override the colors.
I will add a timer to reset this state when you haven't typed for x seconds.
If your theme uses the other colors in the groups editorError, editorWarning, editorInfo you can add these too.
Open up the command palette (CTRL + SHIFT + P) - > c/c++: Disable Error Squiggles. This will disable all error warnings and highlighting.
I'm writing a Visual Studio editor plugin. I'd like the editor to behave similarly to other editors: if the edited file changes outside the IDE, I want the proper dialog window to be displayed and the document reloaded (if needed).
The IVsPersistDocData interface contains methods IsDocDataReloadable and ReloadDocData, but during debugging, they were never called in this scenario.
There is a combination of IVsFileChangeEx and IVsFileChangeEvents interfaces, but reaction to changing files outside the IDE seems to be so generic, that I guess I shouldn't need to manually monitor the edited file. Or should I?
It seems, that there actually is no automatic mechanism for doing that and using IVsFileChangeEx and IVsFileChangeEvents seems to be the only solution.
http://blogs.msdn.com/b/dr._ex/archive/2005/11/01/487721.aspx
http://msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.Shell.Interop.IVsFileChangeEx.aspx
Was working on new functionality in a code file... ManageTime.cs.
Had a bug fix request come in for a bug in the same file.
Used Visual Studio TFS to Suspend My Work.
Fixed bug in ManageTime.cs.
Now What?
Do I Check in ManageTime.cs, then can I resume my shelf set and will it handle merging the shelfset with the new feature code?
Afraid to try without some direction for fear of losing code.
Yes, if your team's policies say that you check in the code after your bug fix, go ahead and do that. If you aren't ready to check in or don't want to check in at this time, but are worried about losing work, you can always create another shelveset just in case (keep the Preserve Pending Changes box checked so you keep your bug fix changes).
Once you are ready, find and unshelve the shelveset. Just like getting the latest version from source control, VS will try to automerge the changes. If there's a conflict that it can't resolve, you'll get the same Resolve Conflicts window that we're used to seeing from time to time to manually resolve the conflicts.
Your assumption appears to be correct. Suspending your code essentially shelves the code along with a few Visual Studio settings such as window location, open files, and similar things. As long as you shelved (suspended) your in process work, then checked in a different bug fix, you should be able to merge with your updated source code once you resume and get latest version.
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.