Getting all static (interned) strings from a .NET assembly (dll)

Question

I wish to get a list of all strings that are used in a .NET assembly including the “static” values that local variables are set to, parameters passed to methods, fields at set to, etc.

I recall from something I read a long time ago that a .NET assembly contains a tables of all strings it uses (or they can be "interned")– or am I just dreaming?

Using .NET Reflector is a good ideal (thanks thijs), I will also have a look at its API if no one comes up with an already written tool.

(This is so I can write a tool to check we have not missed any strings that should be translated. I could process the C# source code, however I will then have to cope with Strings that are split over many lines, etc.)

I have just thought, I wish to exclude strings passed into CodeFlowException(), etc., so this is already getting more complex.

PS: if you can think of a better set of tags, please retag this question.

Answer 1

In the end I wrote a very simple C# parser that found the strings in the source code. This solved the problem I had and let me add “comments” to the strings to help the translators.

The comments were just read from C# comments in a “magic format”

(Sorry the parser is not good enough to allow anyone else to use it, it only just about works on my C# code base)

Answer 2

You can use SysInternals Strings tool to view the strings in executables and object files.

Answer 3

You should be able to do this using reflection, take a look at this:

http://msdn.microsoft.com/en-us/library/system.reflection.fieldinfo.isliteral.aspx

and

http://msdn.microsoft.com/en-us/library/system.reflection.fieldinfo.aspx

Answer 4

For those who want to extract all user strings from a .NET assembly (.exe or .dll) I wrote a simple utility which can do that (file ExtractExeNetStrings2.zip). The utility is written in C#.

Answer 5

Simple C# utility that extracts all user strings from a .NET assembly (.exe or .dll) by examining bits of a binary file.

The source code from vladob's answer can now be found on github here. The link from the original answer has been broken. vladob gave consent to this repost. Actually I gave consent to me.