Comments
Sort by recent activity
Thats a good idea ... could run the Close All Windows command, then the reorder command. That would take you back to the starting place. Or could take account of the current item open in the disassembler windows (if any), close all windows, reorder, then open the previously saved current item. If the navigation history is kept, then could just use that. / comments
Thats a good idea ... could run the Close All Windows command, then the reorder command. That would take you back to the starting place. Or could take account of the current item open in the disa...
Here are some answers to you numbered questions:
1. [CompilerGenerated] and [DebuggerHidden] attributes are typically on things that a either generated (and you never see in Visual Studio) or in generated code (you can sometimes see the code by in other partial classes like with Forms).
The easiest way for C# to make sure you don't use these compiler generated members and objects is to name them in some illegal syntax for C# (though the names are still legal in IL - the languages have different syntax naming rules). So that is why you get those generated names that won't compile. Problem is - you won't have the information in your assembly to reverse back to things like LINQ expressions that will cause some of these objects to be created. For simple things like automatic properties (IE. public string Name { get; set; } ) you can figure those out (the underlying field name will have a generated name).
Short story is: C# provides a lot of syntatic sugar for you ... but under the coveres the compiler and visual studio work together to hide complicated generated stuff needed to make that work.
2. Local variables names are typically not stored in IL. If you have the pdb, you might be able to get them back.
3. Label_xxx: statements are examples of how the final compiled IL is not the same as the higher level language you wrote it in. Conditions and loops translate into jump or goto statements ... things you don't worry about in C#. Again this is part of the work that the C# compiler takes care of for you.
All of those items do make it harder to reverse IL into C#. #1 being the hardest (especially with LINQ and things like the yield statement). / comments
Here are some answers to you numbered questions:
1. [CompilerGenerated] and [DebuggerHidden] attributes are typically on things that a either generated (and you never see in Visual Studio) or in g...
I forgot to mention, if you think it might be Reflector and not the assembly - then you can open it in ILDasm and look at the heaps - which will show you the names that were included at compile time (with no chance of any error in a disassembling or decompiling tool). Just do the following:
1. Open ILDasm
2. File -> Open then find your dll/exe
3. On the View menu, select the MetaInfo submenu at the bottom and check the RawHeaps item
4. On the View menu, select the MetaInfo submenu again and select Show!
Scroll down and look for the String Heap and you'll see all the type names and member names that were originally compiled in the assembly (probably by an obfuscator in your case).
This will only help you figure out if the names are in fact showing correctly in Reflector or not. / comments
I forgot to mention, if you think it might be Reflector and not the assembly - then you can open it in ILDasm and look at the heaps - which will show you the names that were included at compile tim...
That sounds obfuscated to me. One of the simpliest ways to make an assembly difficult for someone else to read is to make at least the non public member names and/or type names meaningless. I doesn't make it impossible to follow the logic and doesn't seem to be too hard to reverse until you really start trying to understand it ... then it gets pretty annoying pretty quick.
There really is no fast way to rename members or type names. The way those tools work will put the name mappings in an external file. That means the information you need to get to the original name is not in the assembly and therefore impossible to get without that mapping file.
As long as it is in a character set you can read (some aren't) you could save to text files and use find/replace ... but then the question is - how bad do you really want it... / comments
That sounds obfuscated to me. One of the simpliest ways to make an assembly difficult for someone else to read is to make at least the non public member names and/or type names meaningless. I doe...
Reflector wasn't really designed to create a vs.net project from an assembly ... all the saving logic has been added on over the years and is just a nice addition - not really what it was designed to do. Viewing the code in an easy to navigate format is what it is REALLY good at.
Most of the creating of a vs.net project logic is old and not working so well as you found out. There are at least 2 addins that do it to different degrees of success. Not much you can do except fix the errors or write your own addin that will do it better ... then please let us all know about it so we can use it too [image] / comments
Reflector wasn't really designed to create a vs.net project from an assembly ... all the saving logic has been added on over the years and is just a nice addition - not really what it was designed ...
Easiest way I've found to do that sort of thing is to use ILDasm to extract all the IL into a file and extract all the resources. Just take the resource you want to edit, edit it, put it back in the same folder you extracted all the il to and then use ILAsm to put it back together.
A simple example of the round tripping of a .net assembly (what the process I described above is called) can be found here: http://jasonhaley.com/blog/post/2004/06 ... t-exe.aspx though it doesn't cover taking the resources file and converting it to an resx file so you can edit it in VS.
You can use ther Resgen.exe tool to convert the resources file to an resx file - and vice versa. http://msdn.microsoft.com/en-us/library/ccec7sz1(VS.71).aspx / comments
Easiest way I've found to do that sort of thing is to use ILDasm to extract all the IL into a file and extract all the resources. Just take the resource you want to edit, edit it, put it back in t...
You use to be able to ... and i'm pretty sure you still can - but when I did it back in 2007 Lutz said that it wasn't really a supported scenario.
I posted a blog entry and some code about wrapping it with your own UI here: http://jasonhaley.com/blog/post/2007/10/26/Ways-to-use-Net-Reflector-3-Wrap-it.aspx / comments
You use to be able to ... and i'm pretty sure you still can - but when I did it back in 2007 Lutz said that it wasn't really a supported scenario.
I posted a blog entry and some code about wrapping...
Getting the fully qualified names written out is not an easy thing to do ... as far as I know.
The problem is due to Reflector's translator providing the language translation for you ... which means you would need to write your own language addin to then have Reflector use it to translate ... not a simple task.
I agree and think it would make a great addition if they would expose a flag to say use fully qualified names or not ... but right now it isn't that easy. / comments
Getting the fully qualified names written out is not an easy thing to do ... as far as I know.
The problem is due to Reflector's translator providing the language translation for you ... which mean...
It looks like the non public interface has been obfuscated. There isn't much you can do about that with Reflector. / comments
It looks like the non public interface has been obfuscated. There isn't much you can do about that with Reflector.
If there are alot of unreadable characters for the names then you may be looking at an assembly that has been obfuscated.
Not much you can do about that with Reflector ... which is why people obfuscate their assemblies.
Do you know if the code is obfuscated? Did you write it? / comments
If there are alot of unreadable characters for the names then you may be looking at an assembly that has been obfuscated.
Not much you can do about that with Reflector ... which is why people obfus...