We have been asked to provide all of the possible error messages in our code for support purposes.
Unfortunately they are not all located in resource files so I figure that if we can get a list of all of the strings in the app we can then filter out the error messages from there.
Is there anything that would let me do this in a C# app?
Cheers
How about using the find function like such
You can also use regular expressions if you have pattern and be detailed in your search by changing the "Use" to "Regular Expressions"
If you have ReSharper 5 you can use their localization feature to help you do this.
Enable localization for your project, then right click the project and select Find Code Issues. It will list all instances of a string hardcoded into the application. (Unless you have Localizable(false) set)
If you can think of a consistent string that you use on each message line (eg "throw new exception(" or "MessageBox.Show(", it may be as simple as hitting Ctrl+Shift+F in Visual Studio (find in files), typing it in, then copying the results to a file.
Before you jump into Regex land, check this out: Regex to parse C# source code to find all strings
I'm sure there are some RegEx expressions or some such you could run on your code base and maybe catch all strings. Seeing as how this is a business requirement and you're likely to be repeating this in the future, I'd refactor to get all my error messages in a structured format first. Then, automate the analysis of the structured format.
Resource files might be appropriate.
Related
I use HelpNDoc for providing a chm-file for the context sensitive help in my application.
In this software you define a help-ID and a corresponding help-context.
The help-ID for example maybe "SystemSetup" and the help-context is 57.
Now my question:
I can call the help this way:
System.Windows.Forms.Help.ShowHelp(null, #"myhelp.chm", HelpNavigator.TopicId, "57");
and all works well, but can I some how call ShowHelp with the help-ID ("SystemSetup") instead?
I ask this cause the help-context can change, but the help-ID stays always the same.
There is no easy way to do that. The Topic ID is the best thing you have to directly point to a topic. The software we use to generate the CHM files allows names to be given to topics, which can be retrieved using your code.
If that doesn't work for you, and the only thing you have is the name, you might get it done by using the Topic enum value and the name of the HTML file (if it is distinct enough).
Something like this could be what you need (you can retrieve the html file name through an CHM viewer):
System.Windows.Forms.Help.ShowHelp(null, #"myhelp.chm", HelpNavigator.Topic, "SystemSetup.html");
I don't know which option is better. That is up to you and your specific scenario.
HelpNDoc uses the following pattern to name topic files: "HELP_ID.htm" where HELP_ID is the chosen unique Help Id for that topic. So you can reliably open a specific topic using the following command:
System.Windows.Forms.Help.ShowHelp(null, #"help.chm", HelpNavigator.Topic, "HELP_ID.htm");
Also, as you found out, HelpNDoc is able to generate a source file with constants. And you can automate its generation and include it in your build process by creating a new "Code" build. See the step by step guide: How to create a new documentation output to be published
Hey guys.. I am writing a Windows application in C# that minifies CSS files and packs JS files as a batch job. One hurdle for the application is, what if the user selects a JavaScript file that has already been packed? It will end up increasing the file size, defeating my purpose entirely!
Is opening the file and looking for the string eval(function(p,a,c,k,e,d) enough? My guess is no, as there are other JS packing methods out there. Help me out!
One might suggest that you compare the size of the pre and post packed JS and return/use the smaller of the two.
UPDATE based on question in comment by GPX on Sep 30 at 1:02
The following is a very simple way to tell. There may be different, or more accurate, ways of determining this, but this should get you going in the right direction:
var unpackedJs = File.ReadAllText(...)
var unpackedSize = jsContent.Length;
var packedJs = ... // Your Packaging routine
File.WriteAllText(pathToFile, unpackedSize < packedJs.Length ? unpackedJs : packedJs)
I would check file size and lines of code (e.g.: average line length). These two information should be enough to know if the code is sufficiently compact.
Try this demo.
I direct you to a post that suggests packing is bad.
http://ejohn.org/blog/library-loading-speed/
Rather use minification. Google Closure compiler can do this via a REST web service. Only use a .min.js extension for minified (not packed).
Gzip will do a better job and will be uncompressed by the browser. Its best to switch on zip compression on the server which will zip a minified file down further.
Of course this raises the question 'How can I tell if my Javascript is already minified!'
When you create/save a minified file, use the standard file name convention of "Filename.min.js". Then when they select the file, you can check for that as a reliable indicator.
I do not think it is wise to go overboard on the dummy-proofing. If a user (who is a developer, at that), is dumb enough to double-pack a file, they should experience problems. I know you should give them the benefit of the doubt, but in this case it does not seem worth the overhead.
If you're using a safe minimization routine, your output should be the same as the input. I would not recommend the routine you mention. MS's Ajax Minifier is a good tool and even provides dll's to use in your project. This would make your concern a non-issue.
I would suggest adding a '.min' prefix to the extension of the packed file, something like 'script.min.js'. Then just check the file name.
Other than that, I would suggest checking how long the lines are, and how many spaces are used. Minified/packed JS typically has almost no spaces (typically in strings) and very long lines.
I have a c# project in my Visual studio 2008 which when built, outputs a bunch of files in a temp directory for other programs to use i.e. JsTestDriver, JsCoverage, etc (all a bit Unix-related).
Trouble is, everytime when the files were generated, they seem to contain weird return carriage/line feed which upsets the programs that would use them next.
What I'm currently doing is manually create a notepad file, rename it to a different name, then copy and paste the entire content of the generated file (and save) to solve this problem. This is, of course, tedious and not something I enjoy doing (ultimately I want this whole process to be automated).
So my question is: how do I get Visual Studio to output the correct/proper CR/LF so I no longer need to go through the manual process?
If the above is too vague, I'll be happy to clarify. Thanks in advance.
Yes, it's a bit too vague at the moment - you should provide:
More details about how you're writing out the files
More details about exactly what's in the files afterwards. Use a hex editor to find this out.
The simplest way of changing what happens in terms of line endings is probably to just be explicit about it in the code. For example, instead of:
output.WriteLine(foo);
write
output.Write(foo);
// Here LineTerminator would be a constant - or you could make
// it a variable somewhere
output.Write(LineTerminator);
... possibly encapsulating this in your own class to make it easier (so you can have your own WriteLine method which does the right thing, perhaps).
EDIT: I've been assuming that it's your own code writing out the files. If that's not the case, the easiest solution is probably to find or write a tool to convert the files, and put it as a postbuild step. I'm sure such tools exist (I think there was one called dos2unix a while ago) but it may be as easy to write your own as to find one which does exactly what you want.
Does anyone know of a good tool for refactoring resources in a visual studio 2008 solution?
We have a number of resource files with translated text in an assembly used for localizing our application. But they have gotten a bit messy... I would like to rename some of the keys, and move some of them into other resource files. And I would like those changes be done in my code, and the translated versions of the resource files as well. Maybe a some analysis on what strings are missing in the translated versions, and what strings have been removed from the original as well...
Does anyone know of a good visual studio extension or ReSharper plugin that can help me with this? Right now it is kind of a pain, because I have to first rename the key in the base resource file, then in the localized versions. And then compile to get all the compile errors resulting from the key which now have a different name, and then go through and fix them all... very annoying =/
I just stumbled across this question which prompted me to blog about what I use for this problem here Moving and renaming resource keys in a .resx file.
I have two PowerShell scripts, one which renames a resource key and one which moves a resource key from one resource file to another.
Using these scripts I am able to rename a resource key:
.\RenameResource.ps1 oldKey newKey
And I can move a resource with key “keyName” from a file named “ResourceFile1.resx” to “ResourceFile2.resx”:
.\MoveResource.ps1 ResourceFile1 ResourceFile2 keyName
RGreatEx is suitable when you need to move a lot of strings in code to resources. But in this case it can't help.
There are no such plugin (*this means that I have never seen such and didn't found in google, but there are some localizators which can help to translate to new language - http://www.peoplewords.com/download/ResxEditor.aspx and http://sourceforge.net/projects/resx/ and http://www.resx-localization-studio.net/ and http://madskristensen.net/post/A-NET-resource-editor-application-for-resx-files.aspx). But you easily (may be) can do this without it.
All you need is to write some small tool which will generate common dictionary of strings for a selected language for several selected resx files and store it somewhere. Another tool you need to create is a tool which will generate new resx files (after your changes) using changed resxs as templates and using the dictionary generated by previous tool.
Of course all new and changed strings will be missing but this can be fixed manually. This will take not so much time (especially when you'll add functionality to write a log of missing strings during generation new resx) .
Were looking into Sisulizer to localize our software, and I think it accomplishes what you're asking for (a bit overkill perhaps?)
Seems to be some new features in ReSharper 5 that helps with this
Localizing your Applications with ReSharper 5
This demo shows how ReSharper 5 helps you make strings in your code localizable quickly, without breaking your regular workflow. Working with resource files is no more a developer's nightmare with ReSharper 5.
We have a resource file with lots of translated strings used various places in our application. Is there a better way for binding for example the text of a button to a certain string?
Currently we are usually just doing something like this in the constructor, in a Load event handler or in a method called by one of those:
someButton.Text = CommonTexts.SomeString;
someMenuItem.Text = CommonTexts.SomeOtherString;
Is there a better way to do it? Maybe in the designer? Or is this the recommended way of doing it?
Just to let you know how we do the actual translation: We have one Class Library project which only contains resx files. The main resx files are written in english (of course). We then open up those base resx files in an application called ResEx where we (or someone else) does the translation to other languages. When compiled Visual Studio automatically creates assemblies for each language which are used automatically depending on the current culture set. This works pretty well, so I don't really need info on how to do the translation and such (although I am always curious to improvements of course). What I am asking is if there is a better way for getting those translated strings from the resource assembly and into all the various Text properties.
I understand, it's an old question, but still, I had the same issue (VS 2010), and one of the first links in google is this topic.
In order to move all the texts to forms resource file - you need to set the winform Localizable property to True. And that's it. :)
(c) Cap. O.
You can do:
using System.Resources;
using System.Reflection;
Assembly assembly = this.GetType().Assembly;
resman = new ResourceManager("StringResources.Strings", assembly);
btnButton.Text = resman.GetString("ButtonName");
There is a good tool called LingoBit Localizer that does the job for the fraction of the time it would take to build all the reasources files.
You don't have to care about other languages while in development process, you simply code and set properties as you would if you were programming for a unilingual software. After you're done, or whenever you wish, you run LingoBit Localizer over your DLL or Windows Form application. This will get user-displayable strings out to a grid for you within its GUI. Now, perhaps a professional translator could use to translate the words if your programmers don't know the language for which the applicaiton have to be translated. Then, you simply save the project when you're done. This will create a DLL file which you simply add to your binary deployment directory, then your application will automatically set itself to the right language depending on the current culture information on which the app. is installed or so. This saves a lot of programming time and headaches.
Hope this helps even though it is not resource-based solution.
This will extract the the value of Home keyword and populate into the Text1 Box.
Text1.Text= Resource.Home.ToString();
Try this:
someButton.DataBindings.Add("Text", CommonTexts, "SomeString");
Your way is the best way to do this if you have developers who are not personally fluent in the languages you're translating your application into. I've done this before with an English application that had to be translated into Spanish, Portuguese and Chinese (I only speak one of these semi-fluently). The original forms were all created in English, and in the form's Load event the code iterated through every control and searched for each control's Text property in a translations spreadsheet, and replaced it with the appropriate translation.
The built-in way of internationalizing a form (which is basically a variant of form inheritance) assumes that the programmer is fluent in the language you need to translate to, which is pretty much of a stretch, and it requires you to manually enter all the translated text values for each form and each language. It also makes your binary larger (potentially much larger), since it adds a .resx file for each form for each language that you support.