Is there any issue to write the "Naming Style" rules in a file and then load them in Resharper ??
We are a team of 9 C#/.Net Developers and we are searching if it's possible ! Because it will take too much time if we have to do it manually from Resharper settings, in each computer...
I'm not sure if I understood your question correcly, but it seems you want to share your ReSharper settings among team members.
ReSharper allows saving settings per solution, which you can then check into your source control repository. That should allow all users to use the same settings.
When you edit the ReSharper settings (ReSharper > Options), at the bottom there should be a button called "Save To". There you can choose to save your settings to a solution-wide file, which can then be checked in.
Related
Recently I installed VS Code and C# plugin for it. I must say that I really like the editor. It is very lightweight and highly customizable. However I haven't found how can I redefine several colorization options such as highlighting classes inside field definitions or local variables?
I already use standard C# colorizer. I just want to customize the color of some lexemes, not everything.
Checkout the docs here:
https://code.visualstudio.com/Docs/customization/colorizer
You basically either get one from the marketplace or generate a basic editable file with yeoman.
You can also add themes even from color sublime as described here:
https://code.visualstudio.com/docs/customization/themes
Install theme from extensions from which you wish to start.
Then find where the theme got installed. On Windows it would be %USERPROFILE%\.vscode\extensions, see details in Installing extensions.
There you'll find folder with theme, inside is themes folder and <something>.tmTheme file which is actually xml file. Open it inside VSCode and start editing :)
You'll find items and colors, syntax is described elsewhere, but common sense will help you.
To test change, open desired .cs file in same editor. Changes are applied after restart, so it's also good to make key shortcut to restart the editor:
keybindings.json
...
{
"key": "ctrl+shift+alt+r",
"command": "workbench.action.reloadWindow"
}
...
Then try color, restart, see result, continue...
I have a localized WinForms application. To avoid a large number of iterations in the translation procedure, I have given our translators software to allow them to edit the .resx files directly.
This has worked great for the resource files that are not tied to UI components (Forms/Controls), but for forms and Controls the resources don't seem to be getting updated. What I mean by this, is that at design-time all resource strings are correct (Text/ToolTips et al.) and I can see the correct translations - when I run the application (debug or any other release) the translations are not being updated, why?
Thanks for your time.
Edit1. The plot thickens further. There are two buttons that are not being updated at all when I change their components (button text, tooltip or any thing governed by the underlying resource file). Lets say I change the button text from 'Lock Workbook' to 'Lock Workbook GG', then the new text shows in the designer and the .resx files (both in the .resx designer and the code behind) but when I run the code (in debug or release mode) the button text is not updated!?
If I update the button next to the button I updated above, this does change the text in the running application?? This is baking my noodle as I fail to see where the old text is being stored and why for a sub-set of buttons their component text is not getting updated!?
Any ideas are warmly welcomed!
Edit2. I have tried to delete the .suo and clean and recompile. I have also removed the troublesome form from the solution and re added it.
So that you can see this strange behavior, here is one of the problematic buttons ('Lock Workbook GG') and a normal one ('Set as Default Workbook GG').
Now at run-time I see
Maybe your build settings are wrong?
This is what I have for my dll.
I have given our translators software to allow them to edit the .resx files directly
That certainly was not a good idea. Any professional translator will know how to tackle .NET resx files. Even if they don't have any of the tooling that's traditionally used by translators, like SDL Passolo, then they would still fall back to the standard Winres.exe utility included with the SDK.
Whatever you wrote probably has a bug. Quite hard to reverse-engineer from the question what that bug might be. Other than that the .resx file for a Winforms form is quite different from the one you get from Resource File project template or the resource designer. There are lots of resource naming tricks to avoid ambiguity between the form's properties and the properties of its controls. Get a name wrong and it won't work right.
Don't write your own, at least ask them to use Winres.exe if necessary. It is free.
The bindings to the button are made in the Designer File of the related form, have you checked whether there are some issues? Try removing the code that sets the ressource and re-add it via the designer.
Probably this has something to do with the CopyLocal property. Please check if these are TRUE for these resource files. If not, set them to true, otherwise, after succesfull compilation, they are not being copied to the output directory.
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.
Is there any possible way to prevent files in a folder being removed or from over written during re installation? i have a folder where i store some templates for sending mails which user can edit.I have added the basic templates in my setup and so during re installation it removes the templates which the user might have already edited and places a new copy of the template.How can i prevent this?Should i use installer class or is there any property that i can use?Please Guide.
See:
File Versioning Rules (Windows)
Especially:
Neither File Has a Version (Windows)
You are using a tool that makes every single file a key file of it's own components. Therefore, you should already be getting this default behavior. If you set Permanent, they should not get removed. You said that the use "can" modify these files. The behavior is that if they haven't modified the files, they will get overwritten and if they have modified the files they will not.
However, IMO, a better pattern is to have an override directory that users can copy templates to and modify. You can get into undesired behaviors on upgrades resulting from the conflict of 1) My new build fixes something and 2) I can't install it because the old stuff has user data. This is especially true for things like XML files.
this can be done by selecting the file properties and setting the value of permanent to true.
For a new MVC web development project, I'm collaborating with a couple of other developers and we want to use Visual SVN to manage source control.
Following the "Getting Started" instructions at the VisualSVN website (http://www.visualsvn.com/visualsvn/getting-started/) seems to to commit everything within the Solution folder including all the settings file (.suo, user, .Publish.Xml)
However, we want to maintain separate Publish Settings within Visual Studio as we publish to our local machines for testing.
Is that possible?
P.S. Shouldn't VisualSVN Client automatically ignore the .suo and .user files?
it doesn't you'll need to either
add them to the ignore on commit lists - you can do this while committing but its a per user setting
remove them from svn - delete them from svn using tortoise as visual svn cant see them (take copies first, as I think this will actually delete them), commit the delete. Put them back into the folder and commit again, svn will show up these files as uncommited, right click on them and select ignore in the commit window, and commit them, this will apply to everyone. Its easier to not commit them in the first place :)
I use SVN as my source control as well. I also use VisualSVN (but only server side). The main thing I would suggest is to use VisualSVN to host your repositories, but use something else to commit/update/checkout your repositories to your local machine.
I would suggest TortoiseSVN for this. Use TortoiseSVN to control your workflow on local machines. You can then use it to simply right-click/ignore your *.suo files. Or any other files/folders you wish to keep out of the repository!
It may take a bit of research to get it setup. But this is what I use on an every day basis, and it is very user friendly.
I've never used VisualSVN, but I would be surprised...no shocked if what you said was true.
Does VisualSVN really by default automatically add and commit user files? You'd think a solution that's built for VisualStudio would simply know better. I would call the company and verify this.
If VisualStudio does commit local user files, I would recommend that you use AnkhSVN instead.
Not only does AnkhSVN know better than to commit user files, it's also open source and you can save yourself the $49 per user you need for VisualSVN. And, it's not just the $50 you're paying per user that you pay with VisualSVN either. It's also the fact that you have another license you need to track while users come in and leave the project. Who do you think is going to get that fun job?
However, if you must use VisualSVN, and VisualSVN does commit user local files by default, You need to get my kitchen sink pre-commit hook. One of the things it does is allow you to completely ban the addition of files such as Visual Studio's *.csuser` files and the other types of VisualStudio detritus.
Of course, you should let developers know how they can set global-ignores and autoproperties in Subversion. This will prevent them from accidentally adding them. But, there's no way you can configure that globally, or to prevent someone from purposefully adding them. Only my pre-commit hook can keep them out of your repository. After a few failed commits because your developers tried to add in these private user files, your developers will quickly fall into line and set up their global-ignores.