RedGate Reflector to recover source code from .net assembly - c#

Quick question.
Can I recover a lost .cs file using RedGate Reflector ?
My assembly is a debug version

If you open .NET assembly in Reflector, you should be able to switch which language Reflector uses to display the code e.g. IL, VB.NET, C#. There is a dropdown list on the UI menu bar with this selection of languages.
As long as you have all the required external libraries and references, you should be able to copy the C# code form Reflector and try to rebuild it.

To make it a little more simple to get the IL code back into a file you should check out this Reflector Add-in.
More add-ins for Reflector can be found here.

Related

How can I decompiling IL code of .net framework

I want to investigate IL code of most .net framework library classes. Is it possible? I am trying to decompiling some dll (e.g.: System.Treading), and I only see signature of the functions. Then I go to mscorlib.dll and see only manifest. There is a way to see the real code?
You can use .NET Reflector (commercial but very good):
https://www.red-gate.com/products/dotnet-development/reflector/
You can open a .net assembly with it (.exe or .dll).
So you can also directly browse .NET Framework assemblies by selecting the framework version.
Select view IL or other language such as C# or VB code and it is done.
There is also for example this free tool (slow, very slow):
https://www.jetbrains.com/decompiler/
If you want to study the implementation of .Net classes. I suggest you use the reference code provided by Microsoft.
The main advantage of using the reference code, is that you can see the comments and other elements that will not be added to IL (like #define).
Reference Source
To study the effect of certain C# constructs on the generated IL, I would suggest using SharpLib.
SharpLib
Personnaly to decompile IL code i use ILspy , it's lightweight tool and easy to use .
you can found it in the link below :
https://sourceforge.net/projects/ilspyportable/
Best Regards .

dotnet dll decompile and change the code

I need to change the code of the .NET DLL. I am able to see the code by compilable the DLL with .NET reflector, but I am not able to change the code of the DLL. With .NET Reflector, I decompile the code and saved in to my hard disk, but when i am able to recompile the code its giving errors.
Few code is decompiled in binary format few code is decompiled with c#. Is there any tool to change and recompile the DLL?
Here are the tools I used for trying to decompile the DLL:
ILSpy
DisSharp
Reflector7.1 With the Reflexil plugin
Spices.Net.Suite.5.8
Deploy .NET 1.0.0
devextras.codereflect
dotPeek-1.0.0.2545
intellilock
JustDecompile_BETA_2011.1.728.1
Unfortunately, none of the tools giving perfect source code to recompile the DLL code.
The following code is working:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\ildasm.exe" original.dll /out=code.asm
echo Here changes to code.asm should be done.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe /dll code.asm
So if the change in code is to be small, it's doable by making the changes in assembly code directly. One can compile and disassemble simple methods to see how the assembly code should look like. Putting additional methods inside the assembly file should not be too hard too.
Of course code analyzis should be done using ilspy-like tools, displaying the source code rather than assembly code.
Tools employed here come from Windows SDK (ildasm) and from .net framework (ilasm).
I've had limited success in recompiling DLLs. A better way of going about it is to using Reflector and the Reflexil plugin. You need to have a bit better knowledge of the IL code that makes up .NET assemblies but Reflexil does a great job of describing the OP codes. I have a little walk through on my blog about how I used to modify the PowerShell Cmdlet Help Editor: http://csharpening.net/?p=348

Changing the code in assembly

I have a dll file is written on C #, I opened the file via the Reflector, the file is the code
if (a! = 5)
{
}
How can I change the code on
if (a == 5)
{
}
I still have the plugin Reflexil
You can do that using MSIL Disassembler
Decompile using that tool, apply changes in IL and compile back again using MSIL Assembler
This will work smoothly if compiled app is not protected.
Whilst the answer about modifying the IL is correct, you can also use Denis Bauers plugin for reflector to disassemble the code and create a new project from it. You can then recompile that project to produce a new dll.
This allows you to make the change in a more familiar environment, rather than having to deal with the IL. you can also choose the language you want to make the changes in.
If the assembly needs to be signed then you might have problems getting it to load again.
Other Alternatives are ILSpy or the Resharper 6.0 which also contains a disassembler.

How can I view MSIL / CIL generated by C# compiler? Why is it called assembly?

I'm new to .NET C# programming. I'm following few books. It is said that instead of compiling C# code directly to machine code, it is converted into an intermediate language (called MSIL aka CIL). But when I compile, I get an exe/dll file.
Is this MSIL/CIL contained in these exe/dll files?
I want to see that intermediate language code, just to get feel for its existence. How do I view it?
They are calling this exe/dll file an assembly. Are they using this "fancy word" just to differentiate these from the exe/dll files that contain native/machine code?
Yes it is, more exactly in the .text section of the PE file (portable executable = *.exe or *.dll). More information can be found here.
The best choice is to use ILSpy (Reflector is no longer free). It's a free disassembler that can dissassemble your assembly into MSIL but also C#, VB (to some extent). The .NET Framework SDK contains ILDasm, which is the official MSIL dissasembler.
Basically yes. An assembly is a file that contains MSIL code and corresponding metadata. This is not restricted to PE files per se, but all current CLR implementations use them.
If I may recommend a good book on that matter too, it's Expert .NET 2.0 IL Assembler by Serge Lidin. He's the guy who designed MSIL.
One of my favorite ways to see IL for a snippet of C# is to use the free LINQPad tool. After entering some code and choosing "C# statements" at the top (or "C# Program", whichever suits), click the "IL" button under the code entry area, and you will see the generated IL.
Using LINQPad for this is much more convenient than loading up Visual Studio or running the compiler from the command line, then loading up ILDASM and opening the .il file with a text editor.
If you want it online, .NET Fiddle is excellent. Just paste your code and click View IL option at the top right.
Another option: Use ReSharper
Source / IL synced view: left blue background line corresponds with right IL Block
In Visual Studio:
Choose ReSharper | Windows | IL Viewer
or Context Menu: Navigate | IL Code
Supports synced view of Source Code and IL - when you click on a statement in source, the corresponding block in IL is highlighted (and vice versa). Displays descriptions for IL from Microsoft Developer Network and "Common Intermediate Language (CIL) instruction set" from ECMA standard specification.
see Viewing Intermediate Language (IL) in Resharper Help. Picture above is from Resharper Help.
Free option is to use Jetbrains dotPeek
see also: "Exploring Intermediate Language (IL) with ReSharper and dotPeek", by Maarten Balliauw, January 19, 2017 - Jetbrains Blog
sharplab is an online tool, great for simple use cases. Type your code on the left, IL shows up on the right.
I believe that they are called "assemblies" because an assembly is a set of modules, assembled together by a manifest.
(source: microsoft.com)
See Assembly Contents for details.
Yes it is in assembly.
You need .NET Reflector or ILDasm.
More details on assembly check HERE.
P.S As you are following some books I will highly recommend you CLR via C#.
In many respects, .NET assemblies are similar to Java bytecode packages.
Yes. They also contain manifests and other data, but the CIL is part of the exe/dll.
Use ILDasm or Reflector - most people would say Reflector, as it is much more powerful. Both will show you what CIL was produced. Wikipedia has a list of all CIL instructions, for a better feel (it is assembly like).
I guess it is meant as an assembly of code. A good way to differentiate it from native.
I know this is an old question, and I'd prefer any of the tools above. However, in a pinch, there has been an MSIL viewer in the box with Visual Studio since at least Version 2005.
The tool is named ildasm.exe, and is located in the following folders after default Visual Studio installations:
Visual Studio 2005
"C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\ildasm.exe"
Visual Studio 2008
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\ildasm.exe"
Visual Studio 2010
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\ildasm.exe"
For more information, see: "How to: View Assembly Contents" in the MSDN Library.
I have just spent a couple of hours searching for the best tool that could let me view the IL code directly inside Visual Studio.
The only solution I found so far is Msiler https://visualstudiogallery.msdn.microsoft.com/60fc53d4-e414-461b-a27c-3d5d2a53f637
it works quite well!
Otherwise the second best solution, but without visual studio integration, is JetBrains dotPeek, which is quite awesome to be honest.
From my experience the best source of IL-related knowledge is Andrew Troelsen “Pro C# and .NET Platform”. Starting from 3rd edition he has really, really outstanding chapter (approx 50 pages) on how to understand IL and even write your own code and use ILAsm. I’ve employed that information to investigate whether multiple inheritance exists in .NET world. Also you could try to employ some very interesting features in IL (e.g. filtering of exceptions which only exists in VB but not in C#).
I highly recommend to read that chapter.
Eventually, .NET Reflector is an enterprise standard for investigating IL code of assemblies and Richter's book is definitely "must read" stuff. But from other books like mentioned above you could reveal really useful things :)
Yes, each assembly in .NET world holds some IL code (alongsite with manifest) which could be viewed thru Reflector or ILDasm. Even more, Reflector could show you C# and VB optimized code. This means that any person could view the source code of an assembly and that's why in commercial products obfuscators are used.
I you want to view the intermediate language, Try downloading JustDecompile from Telerik (Which is currently free, requires a sign up though).
Drag in your DLL and choose IL from the drop down box at the top!
There is now another option. You can do this in VS Code with this extension built with Roslyn. This is currently limited to .NET Core.

Tool to import Type Libraries as C# code

Is there a tool to import/convert COM type libraries into C# code rather than generating an assembly? The TLBIMP tool and the TypeLibaryConverter class only generate assemblies.
I've had some success ripping the C# ComImport definitions by running Reflector over the generated Interop assembly and copying a pasting the disassembled source, but this usually requires quite a bit of manual patching up before it'll compile.
Desired goal is a single EXE without satellite Interop DLLs, so perhaps the answer is to use ILMerge to effectively embed the interop DLL in the EXE.
I was sure in the past I'd come across such a tool - but maybe it dreamt it :-)
I'm not so sure it is going to be useful to you, but the source code for a managed version of Tlbimp.exe has been released on CodePlex. VS2010 will definitely solve your problem.
This won't help you out today, but there is a feature coming in the next version of C#. It's called NoPia or Type Embedding depending on which presentation you read. This feature essentially will link a PIA assembly into whatever project you reference it from. The end resulrt is a single EXE which no need to deploy an interop/PIA DLL.
Misha's post on the subject: http://blogs.msdn.com/mshneer/archive/2008/10/28/type-embedding-support-in-c.aspx
Short term though, you may have to go with ILMerge or reflector + copy code.
As I originally suspected the best solution is going with ILMerge. I can't be selective about parts of a COM API to embed, but it works well enough.
Here is the Post Build Event Command Line I'm using, which should be easy enough to reuse:
set MERGEFILES=Interop.Foo.dll Interop.Bar.dll
if "$(ConfigurationName)" == "Release" (
ren "$(TargetFileName)" "_$(TargetFileName)"
"$(ProgramFiles)\Microsoft\ILMerge\ILMerge.exe" /out:"$(TargetFileName)" "_$(TargetFileName)" %MERGEFILES%
del "_$(TargetFileName)"
del %MERGEFILES%
)

Categories

Resources