Using System.Reflection, I can get all methods from a specific class
I need know what are the references to these methods. For example: in Visual Studio, if you want the references of specific object
right click on the object and select "Find All References"
Visual Studio show the references of this selected object
I want make the same, but from code with reflection or another way.
Can I do this?
This cannot be done with reflection. Reflection is a tool for inspecting metadata and assemblies. In order to find all references to a given method / type, you'd need to inspect the underlying IL of an assembly. Reflection only has very limited IL capabilities (simply returns it as a byte array). You'll need to custom inspect that byte stream in order to gather any context about what it's referencing.
That's not something that's directly accessible via runtime reflection on a specific class. You will have to introspect the entire source code tree or resulting IL to determine if any references to a particular method with the same name are the right overload and signature for the method you're trying to find references to.
Furthermore, without additional work, you're never going to find references to a specific method that are themselves invoked via reflection. (This is one reason why obfuscating that kind of code is challenging and error-prone.)
If you're just looking to find the references for informational purposes, Reflector has that feature.
http://www.red-gate.com/products/reflector/
Microsoft released the Common Compiler Infrastructure projects under an open source license. These projects aim to support many compiler-related features, including assembly analysis like you're referring to. The documentation is limited, so you'll need to have a thorough understanding of ECMA-335 (Common Language Infrastructure) to effectively use it for your purposes.
There are no magic code samples here. This is a large and quite complicated task where you'll be on your own most of the way.
Related
I have a reference to the type and class from certain assembly.
var type = typeof(SomeNamespace.SomeClass);
Is there a way to get meta about what programming language were used to write this class? C# or VB or F#?
So in result i want something like this
var programmingLanguage = getLanguage(type); // C#
UPD:
Can I analyze what Assemblies or Namespaces where used for this class? Maybe this can be a clue to finding out a language?
UPD2:
So far I could use this ( it's just an example for VB detection )
var referenced = type.Assembly.GetReferencedAssemblies()
.Where((r) => r.Name.Contains("VisualBasic"));
VB adds Microsoft.VisualBasic. F# also adds it's own assemblies and C++ declares a lot of 'self use' types which I can detect. So this is "a way". I know it's not error prone. And there will be some false cases. So is there anything better?
.NET does not make this distinction, there's not really a good reason for you to either.
The only way would be to analyse the types and code patterns used. For example, VB projects often reference a different set of assemblies to C#.
If you need to do this for your own assemblies, I would suggest creating a custom Attribute class and decorating your assemblies with it.
Take a read of Decompiled assembly, which programming language was used. There is no facility in .NET assemblies to record the source language. In addition, not only are there C#, F# and VB.NET compilers for .NET, but there are many other compilers too (see http://en.wikipedia.org/wiki/List_of_CLI_languages for a taste of the number). Finally, the IL might have been written directly, rather than via a compiler.
You could try to search for patterns in the IL to try and work out the source language, but if would be highly error-prone. I'm not sure what benefit it would offer either.
See Kieren's answer. An alternative is to compare the assembly files, with some id in the name or metadata to define its language.
See How to get the assembly (System.Reflection.Assembly) for a given type in .Net?
This would only be helpful if you're compiling yourself, or the different language'd binaries are named differently or you can manually name them differently.
If you're compiling yourself, you can add metadata to the binary as a post-build event. See Read/Write 'Extended' file properties (C#) for details on how to add. In the build event, you'll be able to access information about the project - such as it's compilation language.
I'm basically know about metadata in c#.net and I recently heard about .net Obfuscating.
I want to know if I use any obfuscator to make my assemblies from being understood it will obfuscate the IL, but will it also change metadata? Then can I add it as a reference to my project and see the real name for classes and its members?
These days most obfuscators can basically rewrite your assembly for you. The majority of the features include:
Renaming (tool vendors often will provide an option to create a map so you can manually map a renamed member to the original member name with a tool like Reflector)
String encryption - this encrypts string constants in the code (stored in the string heap area of the meatadata) so if you open the file in Reflector it will usually show encrypted. The encrypted values still get decrypted right before using them.
IL obfuscation - control flow rewriting of the IL to make spaghetti code and difficult to follow
There are also other tools that go way beyond this but they all just raise the bar of what it takes to reverse something.
If you set a reference to an obfuscated dll/exe you'll see the obfuscated/renamed members, but if the vendor provides a map (most will) you can figure out which is which. You can also typically use interfaces that are not obfuscated if you need a readable api to use. An example would be Reflector - the addin apis are all interfaces that are not obfuscated but all implementations of the concrete classes are obfuscated.
Try using Confuser, as there's still no Deobfuscator for this one.
http://confuser.codeplex.com/
You won't see normal names of classes and methods as it hashes them and also many more. It is basically impossible to get anything out of code afterwards.
The Assembly class has a GetReferencedAssemblies method that returns the
referenced assemblies. Is there a way to find what Types are referenced?
The CLR wont be able to tell you at runtime. You would have to do some serious static analysis of the source files - similar to the static analysis done by resharper or visual studio.
Static analysis is fairly major undertaking. You basically need a c# parser, a symbol table and plenty of time to work through all the cases that come up in abstract syntax trees.
Why can't the CLR tell you at run time? It is just in time compiled, this means that CLR bytcode is converted into machine code just before execution. Reflection only tells you stuff known statically at runtime about your types, and the CLR would only know if a type is referenced when the code is run. The CLR only knows when a type is loaded at execution time - at the point of just in time compilation.
Use System.Reflection.Assembly.GetTypes().
Types are not referenced separately from assemblies. If an assembly references another assembly, it automatically references (at least in the technical context) all the types within that assembly, as well. In order to get all the types defined (not referenced) in an assembly, you can use the Assembly.GetTypes method.
It may be possible, but sounds like a rather arduous task, to scan an assembly for which actual types it references (i.e. which types it actually invokes or otherwise mentions). This will probably involve working with IL. Something like this is best to be avoided.
Edit: Actually, when I think about it, this is not possible at all. Whatsoever. On a quite basic level. The thing is, types can be instantiated and referenced willy-nilly. It's not even uncommon for this to happen. Not to mention late binding. All this means trying to analyze an assembly for all the types it references is something like predicting the future.
Edit 2: Comments
While the question, as stated, isn't possible due to all sorts of dynamic references, it is possible greatly shrink all sorts of binary files using difference encoding. This basically allows you to get a file containing the differences between two binary files, which in the case of executables/libraries, tends to be vastly smaller than either of the actual files. Here are some applications that perform this operation. Note that bsdiff doesn't run on Windows, but there is a link to a port there, and you can find many more ports (including to .NET) with the aid of Google.
XDelta
bsdiff
If you'd look, you'll find many more such applications. One of the best parts is, they are totally self-contained and involve very little work on your part.
I have a generated file with around 10,000 public static properties and methods. I suspect that a nontrivial number of them are entirely unused, but there are around 50 assemblies and millions of lines of code to check to be sure.
What I would like to do is run some kind of utility that can look into all of the compiled assemblies we have and tell me exactly which members of this class are being called, and give me counts for each one.
Is such a thing possible with reflection, or do I need to revert to actual code analysis tools? Are there any libraries that can analyze assemblies to find their dependencies within another assembly?
The ReSharper "Find Usages Advanced" feature has an option to find references in Libraries as well as in the current Solution. I haven't used this particular feature, so I'm not sure how well it works (the Find Usages within a solution works quite nicely), but you can get a trial version of ReSharper and try it. My guess is that you'll need to run it from a Solution that has a Project with references to the various Libraries you're interested in.
I don't think this can be done with "regular" reflection, since usages cannot be detected by looking only at the structure of the classes. I guess you'll need to disassemble the IL and analyze it, looking for call, calli, and callvirt instructions (property lookups are also method calls). You can get the IL for a method with typeof(SomeType).GetMethod("Method").GetMethodBody().GetILAsByteArray(), but it might be hard to analyze it when it's in the form of a byte array. You might want to look into Cecil, which might help you analyze the bytecode.
Of course, there might well exist tools for this already.
I've recently inherited C# console application that is in need of some pruning and clean up. Long story short, the app consists of a single class containing over 110,000 lines of code. Yup, over 110,000 lines in a single class. And, of course, the app is core to our business, running 'round the clock updating data used on a dynamic website. Although I'm told my predecessor was "a really good programmer", it obvious he was not at all into OOP (or version control).
Anyway... while familiarizing myself with the code I've found plenty of methods that are declared, but never referenced. It looks as if copy/paste was used to version the code, for example say I have a method called getSomethingImportant(), chances are there is another method called getSomethingImortant_July2007() (the pattern is functionName_[datestamp] in most cases). It looks like when the programmer was asked to make a change to getSomethingImportant() he would copy/paste then rename to getSomethingImortant_Date, make changes to getSomethingImortant_Date, then change any method calls in the code to the new method name, leaving the old method in the code but never referenced.
I'd like to write a simple console app that crawls through the one huge class and returns a list of all methods with the number of times each method was referenced. By my estimates there are well over 1000 methods, so doing this by hand would take a while.
Are there classes within the .NET framework that I can use to examine this code? Or any other usefull tools that may help identify methods that are declared but never referenced?
(Side question: Has anyone else ever seen a C# app like this, one reeeealy big class? It's more or less one huge procedural process, I know this is the first I've seen, at least of this size.)
You could try to use NDepend if you just need to extract some stats about your class. Note that this tool relies on Mono.Cecil internally to inspect assemblies.
To complete the Romain Verdier answer, lets dig a bit into what NDepend can bring to you here. (Disclaimer: I am a developer of the NDepend team)
NDepend lets query your .NET code with some LINQ queries. Knowing which methods call and is called by which others, is as simple as writing the following LINQ query:
from m in Application.Methods
select new { m, m.MethodsCalled, m.MethodsCallingMe }
The result of this query is presented in a way that makes easy to browse callers and callees (and its 100% integrated into Visual Studio).
There are many other NDepend capabilities that can help you. For example you can right click a method in Visual Studio > NDepend > Select methods... > that are using me (directly or indirectly) ...
The following code query is generated...
from m in Methods
let depth0 = m.DepthOfIsUsing("NUnit.Framework.Constraints.ConstraintExpression.Property(String)")
where depth0 >= 0 orderby depth0
select new { m, depth0 }
... which matches direct and indirect callers, with the depth of calls (1 means direct caller, 2 means caller of direct callers and so on).
And then by clicking the button Export to Graph, you get a call graph of your pivot method (of course it could be the other way around, i.e method called directly or indirectly by a particular pivot method).
Download the free trial of Resharper. Use the Resharper->Search->Find Usages in File (Ctrl-Shift-F7) to have all usages highlighted. Also, a count will appear in the status bar. If you want to search across multiple files, you can do that too using Ctrl-Alt-F7.
If you don't like that, do text search for the function name in Visual Studio (Ctrl-Shift-F), this should tell you how many occurrences were found in the solution, and where they are.
I don't think you want to write this yourself - just buy NDepend and use its Code Query Language
There is no easy tool to do that in .NET framework itself. However I don't think you really need a list of unused methods at once. As I see it, you'll just go through the code and for each method you'll check if it's unused and then delete it if so. I'd use Visual Studio "Find References" command to do that. Alternatively you can use Resharper with its "Analize" window. Or you can just use Visual Studio code analysis tool to find all unused private methods.
FXCop has a rule that will identify unused private methods. So you could mark all the methods private and have it generate a list.
FXCop also has a language if you wanted to get fancier
http://www.binarycoder.net/fxcop/
If you don't want to shell out for NDepend, since it sounds like there is just a single class in a single assembly - comment out the methods and compile. If it compiles, delete them - you aren't going to have any inheritance issues, virtual methods or anything like that. I know it sounds primitive, but sometimes refactoring is just grunt work like this. This is kind of assuming you have unit tests you run after each build until you've got the code cleaned up (Red/Green/Refactor).
The Analyzer window in Reflector can show you where a method is called (Used By).
Sounds like it would take a very long time to get the information that way though.
You might look at the API that Reflector provides for writing add-ins and see if you can get the grunt work of the analysis that way. I would expect that the source code for the code metrics add-in could tell you a bit about how to get information about methods from the reflector API.
Edit: Also the code model viewer add-in for Reflector could help too. It's a good way to explore the Reflector API.
I don't know of anything that's built to handle this specific case, but you could use Mono.Cecil. Reflect the assemblies and then count references in the IL. Shouldn't be too tough.
Try having the compiler emit assembler files, as in x86 instructions, not .NET assemblies.
Why? Because it's much easier to parse assembler code than it is C# code or .NET assemblies.
For instance, a function/method declaration looks something like this:
.string "w+"
.text
.type create_secure_tmpfile, #function
create_secure_tmpfile:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl $-1, -8(%ebp)
subl $4, %esp
and function/method references will look something like this:
subl $12, %esp
pushl 24(%ebp)
call create_secure_tmpfile
addl $16, %esp
movl 20(%ebp), %edx
movl %eax, (%edx)
When you see "create_secure_tmpfile:" you know you have a function/method declaration, and when you see "call create_secure_tmpfile" you know you have a function/method reference. This may be good enough for your purposes, but if not it's just a few more steps before you can generate a very cute call-tree for your entire application.