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.
Related
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.
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
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.
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.
After running ReSharper on our project we receive the following error multiple times in various resx files;
"Duplicate Resource"
Is there a way we can easily clean each forms resx file. For example, is there a way we can safely regenerate the resx file within VS2010?
This is a C# project.
I'm the author of a commercial localization product (see http://www.hexadigm.com). If your ".resx" files are code-behind files for a windows form or user control (created and managed by the VS forms designer), then you can normally fix the problem by setting the form's "Localizable" property to false and then immediately back to true again (in the VS forms designer). That will regenerate the ".resx" file and normally eliminate any duplicates (backup your files first however, just in case). For other ".resx" files however (non-code-behind files you manage yourself), I'm not aware of any tool that will fix this for you. Note that my own product however will trap this problem (and others) but doesn't fix it. It's too risky IMO. If you have a duplicate resource that is, then the entire ".resx" file is suspect so attempting to automate a fix could make things worse (since the file could potentially have more serious problems than just duplicates). In reality it normally is just a case of duplicates (nothing more serious) but IMO it's safer for the programmer to diagnose the situation so my app will report each duplicate and then abandon processing of the affected ".resx" file (which I report to the user accordingly, as well as record to the VS Output window).