I am creating a complex class with AssemblyBuilder that Im later creating objects from. There is however uncertainties in how this class is really contructed. So is there any way to write this dynamicly created class to a cs file for inspection?
I can get the dll file written to disk but I need the cs file.
You can decompile managed .NET dll to C# code using
DotPeek by JetBrains (free, sources are closed)
ILSpy open source project (MIT license sources are available at github)
Reflector by Red Gates (Paid tool, sources are closed)
JustDecompile by Telerik (free with open source decompilation engine available at github Apache License)
There is also a Microsoft's ildasm tool.
If you need to write custom tool you can download open-source code and give it a try.
Do you have a requirement to use AssemblyBuilder? I'm asking because AssemblyBuilder wont allow you to see the generated class without using a decompiler and if the class you´re generating is quite complicated, the decompiled code wont be of good quality.
You are almost in the same situation if you use Reflection.Emit because it generates low level IL.
If you really need to see the source code that you're generating dynamically your best option is CodeDom. Here's an example How to: Create a Class Using CodeDOM
You might be able to kill two bird with one stone with Roslyn (aka ".NET Compiler Platform"). You'll need the package Microsoft.CodeAnalysis.CSharp.
First, you can use the SyntaxFactory class to generate syntax nodes, which you can combine into larger structures (members, methods, classes, namespaces, compilation units).
You can also get a nicely formatted representation of your syntax nodes with ToString() or ToFullString() (with correct indentation and line breaks and everything), which is what you were originally looking for.
There are quite a few tutorials online on how to use this API (like 1, 2), and there's the Roslyn Quoter website that can convert a piece of C# code into SyntaxFactory calls.
Second, you can then use the resulting CSharpSyntaxNode to create a CSharpSyntaxTree, which you can compile into IL with the help of CSharpCompilation (after all, Roslyn is the reference C# compiler).
If you want, you can even emit the generates assembly into a stream, get the assembly's binary data from there, and load your newly created assembly into your currently executing assembly, and dynamically instantiate the types you just defined.
You need to use the .NET reflection.
Ildasm.exe cannot help you because it will not create the .cs file you need.
So either the ILSpy is the open-source .NET assembly browser and decompiler from the SharpDevelop team or dotPeek from Jetbrains.
Depending on the platform you may also check Mono Cecil. Cecil is a library written by Jb Evain to generate and inspect programs and libraries in the ECMA CIL format.
If you need speed JustDecompile from Telerik is a free tool for .NET assembly browsing and decompiling that claims to be 10x faster than competitors.
All these tools lets you take an existing compiled assembly (.dll or .exe) and easily browse the symbols it contains, and then just as easily decompile the assembly language back to readable C# and IL.
Related
Hey i have done a few of decompiling in .net as i am learning c# so it helps me to see codes as it helps a lot. But lately i have come acrossed few program that i know are .net but in reflector show up as non .net assemblies. Here is the example of program named: Proxy Multiply.
I am not trying to do any illegal stuff or something. Just trying to learn. I have tried to google this but i was not able to achieve any good result.
Thanks
here is the link to image.
There are many .Net code protection alternative, that obfuscate the IL codes so that they are not that much exposed to IL disassembler application.
.Net Reactor
Themida
SmartAssembly
the list is huge . . .
many of the protector modify the Exe (PE Header info), .Net exe contains some extra MetaData that helps disassembler to identify it.
Download this little application it may tell you a little more about the exe.
Download PEiD 0.95
PEiD is an intuitive application that relies on its user-friendly
interface to detect packers, cryptors and compilers found in PE
executable files – its detection rate is higher than that of other
similar tools since the app packs more than 600 different signatures
in PE files.
PEiD comes with three different scanning methods, each suitable for a
distinct purpose. The Normal one scans the user-specified PE file at
its Entry Point for all its included signatures. The so-called Deep
Mode comes with increased detection ratio since it scans the file's
Entry Point containing section, whereas the Hardcore mode scans the
entire file for all the documented signatures.
My best guess the assembly you are looking for is Protected by .Net Reactor or Themida
I have same problem with dot net reflector before,
try JetBrains dotPeek version 1.0 Decompling(this application will show code that obfuscated)
Decompiling .NET 1.0-4.5 assemblies to C#
Support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files
Quick jump to a type, assembly, symbol, or type member
Effortless navigation to symbol declarations,
implementations, derived and base symbols, and more
Accurate search for symbol usages
with advanced presentation of search results
Overview of inheritance chains
Support for downloading code from source servers
Syntax highlighting
Complete keyboard support
dotPeek is free!
Just because it is .NET doesn't mean that you can just decompile it like that. They probably used ILMerge. That's not to say it's impossible but it will require more work.
See Is it possible to “decompile” a Windows .exe? Or at least view the Assembly?
Building is the sequence composed of compiling and linking.
In .NET the source code is compiled into the assembly that contains Common Intermediate Language and type info. At run time the JIT compiler converts the CIL code into native code.
I do not understand, in .NET ,how and when the linking is occurring.
Can someone please explain the process ?
Thanks in advance
There's no linking in terms of C++.
I mean, there's no any intermediate "obj"/"lib" files, that can be distributed and linked with another "obj" files later. Reference to an assembly always has dynamic behavior (always dynamic-link library), as opposed to C++ static linking.
Something like linking is a creation of .netmodule. You can build .NET source code with compiler into .netmodule instead of assembly (look here, especially section "Differences Between C# Compiler and C++ Compiler Output"), and later you can link these modules together into a single assembly (see al.exe).
But this is uncommon practice - most of assemblies contains single module, and this work (source -> module -> assembly) has been done by compiler (e.g., csc.exe) behind the scenes. Also, I can't remember any product being redistributed as a set of .netmodule (not as a set of assemblies).
I am currently creating my own intellisense, and was slightly unsure on a point:
The VS Intellisense can look into referenced DLLs and pull out the namespaces, classes etc from it. Does it do this with reflection? What if I add a DLL made in java (if that can be done?)
for C++, does the intellisense simple scan header files you #include, and find available namespaces, classes etc from that?
I don't fully care about the exact implementation of intellisense in visual studio, but I am interested in how it obtains it's data.
Compiled .NET assemblies and Java classes contain all meta-information about classes and symbols that they define. Nothing like .h or .lib files is required to link against them. For these types of modules, significant amount information may be extracted directly from them.
I do not know if Visual Studio is using reflection to read metadata from managed assemblies, but reflection is certainly a correct mechanism to apply in this case. But also note that VS displays more information than there is contained in an assembly directly, namely, the /// doc-comments. These may come from source files in other projects in the solution, and from separate .XML files that come with assemblies.
For C and C++, the matter is different. There is little information available in a DLL alone. There are export symbols, but they do not usually signal whether a symbol is a function or just an extrn, and how many arguments and what types the function takes. C++ uses so called "mangled" names, from which some information may be gained. But most information that is available about a library is coming from header files. VS, as far as I know, parses sopurce files of projects and .h files included from code to get intellisense database. There are macros (#define's), and inline and template classes and functions that are not reflected in DLL extern symbols at all.
For both managed and unmanaged assemblies, sometimes debug information PDB files are available. Again, I am not sure, but I think VS is not using them for intellisense. This does not mean that you should not. There do contain extended information about external variables, classes, functions and methods. All in all, there is no "standard" intellisense approach, and you probably should consider using multiple sources for the symbolic source information.
Unfortunately, I do not know much about Java to give a detailed answer to that part of your question. Also, there is a popular IDE framework called Eclipse, but I have not looked under its hood. There must be some interesting parts hidden there, but do your own research.
A few useful references:
Visual Studio SDK. Even if you are not extending visual studio, you may want to read its documentation. It has a section on Intellisense. Also, look at open-source IDEs, such as Eclipse and #develop
System.Diagnostics.SymbolStore Namespace contains classes to access PDB files. In unmanaged world, use DbgHelp library, part of Windows SDK.
A utility called Depends was part of Win32 SDK, and is avalable separately now. It shows externals defined by an unmanaged DLL. This SO discussion reveals a few ways to access this information programmatically. DbgHelp contains functions to un-mangle C++ names, after you extract them from the PE export directory.
I am well aware that one can use reflector to browse the content inside an assembly, and one can use FileDisassembler to convert the content into the c# source code with cs projects. But the source code outputted by FileDisassembler may not be able to compile if it has interface with property.
Is the other similar applications that do what FileDisassembler does?
I would not trust Reflector's decompiler.
Many times I have seen it just ignore instruction it did not understand, or just optimized certain sequences away, and changing the meaning the process.
The only trusty way is to use IL.
Regarding more tools, look at the CCI. IIRC, they had a C# source emitter at some stage, but it was removed for some reason.
dotPeek from jetBrains is a good decompiler for c#. http://confluence.jetbrains.net/display/NETPEEK/dotPeek+Early+Access+Program
This questions is a follow up on an answer by Paul Alexander to the question "Should interop assemblies be signed?".
Depending on how complex your Interop assemblies are - you can generate the proxy code into a separate .CS/.VB file and compile it directly into your assembly. Then you won't have to worry about strong name issues.
How would I go about generating the interop proxy code for a COM library into C# source code?
I guess it could be done with tlbimp and then extracting the source with Reflector. Has anyone done this or is there a simpler way?
Take a look at the following MSDN article:
How to: Create Wrappers Manually (Talks about how to create your interop assembly manually.)
Once you've got the interop assembly, use a tool like Reflector to disassemble it and generate the raw C# source. Reflector.FileDisassembler makes this really easy.
Now you can include the generated C#/VB sources directly into your assembly.
I do not know simpler way, and extract interface descriptions via Reflector. However in VS 2010 Microsoft will do this for you automatically.