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
Related
Is it possible to decompile a .NET Assembly in C# without external executables like ILSpy? Libraries, which could be used in my program would be great.
Can you give me any advice to do this?
I guess you want source code of it, and integrate to your app. You can check 2 project bellow:
Mono.cecil: https://github.com/jbevain/cecil
ILSpy: https://github.com/icsharpcode/ILSpy
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.
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.
I have a C# application which links to a few c# DLLs which in turn use bindings to call c++ functions in other Dlls.
This all works fine if I compile the c++ Dlls with /MTd but when I use /MDd I get an XMLParseException in my C# app complaining that it can't find any Dlls(it fails to find the first of my Dlls that I use). My best guess is that using this other switch causes it to change the path where it looks for its Dlls, causing it to fail. I used DependencyWalker to have a closer look and the two Dlls it actually fails to find are 'IESHIMS.DLL' and 'WER.DLL'. I can't see my c# Dlls anywhere in the tree in DependecyWalker however. Anyone have any ideas what might be wrong here?
Also, using the non-debug equivalents (/MD and /MT) make no difference. Regardless, I can't use /MT as it causes another bug.
EDIT: I've narrowed the problem down somewhat. When compiled and linked using the VS2010 command prompt, my app works fine, with the VS2008 command prompt it still fails to find the Dll. Does anyone know any differences between these two version of VS which could cause the behaviour I described above?
Thanks in advance,
Are you compiling all the modules against the same run-time libraries? From:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
"All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD)."
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%
)