I have decompiled C# dll and now can not compile it. It shows strange errors, for example in some switch blocks some case blocks havent their break statements, or errors like "Can not cast int to bool" are shown. But the amount of errors is not very large for dll of that size, so I think it is not the problem of decompiler.
Is there some derective for compiler (for example, smthing life unsafe) that will solve this problem? Or why is there such strange errors?
P.S. The dll is not broken - the application is using it right now. I'm using dotPeek to decompile and Visual Studio 15 to compile the result code.
For such an error like :
"Can not cast int to bool"
There is absolutely no compiler directive that will allow your compiler to go ahead, I think that your decompiler messed up something decompiling ... You could simply try with another decompiler and see if you get another results, valid alternatives are : ILSpy, JustDecompile and Dotnet IL Editor .
Be aware that some commercial DLL is obfuscated just to try to make life difficult to the decompiler and to who decompile ...
Be careful to avoid breaking some copyright .
It's quite hard to decompile IL to C# and decompiler has probably done something wrong. In my experience, decompiled and compiled code can also behave differently than original assembly, so be aware. And such compile error can be indocation that dotPeek was not sure, so think about it what it should do or look in IL.
If you are willing to make really small edits to the assembly (inject method calls, make something public) it may be safer to do it directly in IL obtained by ildasm.
Related
I'm used to being able to compile source code even if it has errors due to my Java (Eclipse) background. This is a tremendous help when developing test-first, which has become my modus operandi. Also it helps a lot with refactoring.
Is there any way to achieve something similar in C#? I have to use JetBrain's Rider, but I don't care much for the IDE.
The source code could not compiled when you violate the rules of writing syntax are known as Compile-Time errors.
Even in Java the source code could not compiled when incorrect syntax such as a missing semicolon at the end of a statement or a missing bracket, etc.
Why does ILSpy generate a source even though it was developed with C ++ Windows Application?
https://imgur.com/a/nAAnV
developing it with C ++↑
enter image description here
↑In order not to display like Noah CSGO?
Most probably you've missed the fact, that you can write in C++ and compile it into MSIL assembly and run that as .net managed code.
Go and see - in Microsoft Visual Studio for C++ there's a compiler switch /clr:pure or other flags (msdn: https://msdn.microsoft.com/library/k8d11d4s.aspx).
When you use this mode, you will be able to use special markers to define that specific classes should be compiled as CLR managed classes. If you take care and write everything properly, /clr:pure will emit a normal 100%-managed assembly. I'm tempted to say "everything as if in C#" but that's not true, generated code will be different, but nevertheless, everything will work, metadata will be there, etc. ILSpy will decompile that just like any assembly generated by C#, VB.Net or F#, but probably the code/names/etc will be a bit more mangled.
Sidenote: If you invest in some real decompiler like Reflector, they can often take a C# assembly and decompile it as-if-written-in-managed-C++ and vice versa..
Furthermore, if you don't care about "pure" msil, you can even mix native and managed code. Half of the code in native C++, other half in managed, just take some care regarding pointers and references and cleanups, and compiler will happily emit for you a mixed assembly - here I have no idea if ILSpy will manage to show you anything. Probably it will show you the managed part and show the native part as being there but as not-disassemble-able.
Finally, it's also https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-build-a-multifile-assembly which ILSpy probably also supports.
After searching the stackoverflow plus googling alot, the solutions offered for debugging code that gets emitted for DynamicMethods seems outdated and very unwieldy.
Surely in the intervening 4 years or more since LCG (light-weight code generation) was released, someone must have found a better way.
What do you find is the easiest way to verify the dynamic IL that you write and debug it?
Do you use peverify or ILDasm or something else? Those 2 tools require writing the assembly to disk but DynamicMethod doesn't offer any direct way to do that.
Apparently WinDbg aso offers a way to see the IL but that's very awkward to deal with that.
Something like a plugin to VisualStudio 2010 will be ideal.
Any ideas?
You can use ILGenerator.MarkSequencePoint to allow debugging step by step your emitted code.
I was reading about the yield keyword when I came across a sample chapter from C# in Depth: http://csharpindepth.com/Articles/Chapter6/IteratorBlockImplementation.aspx.
The first block of code utilizes the yield keyword to make a simple iterator. But, the second block of code shows this code after the compiler has had its way with it. Among other things, it has exploded the yield statement into a state machine.
Several other examples of code being modified by the compiler is evident on the page.
My question is: Was the author actually able to access the code after compilation, or did he infer what it was going to look like?
You can have a look using Reflector, that's probably your best bet:
http://reflector.red-gate.com
The author himself mentioned:
Obviously the compiler doesn't actually produce C#, but I've used Reflector to decompile the code as C#.
in the same paragraph, titled High level overview: what's the pattern?
Probably both. It's quite easy to reverse-engineer compiled assemblies using Reflector. And the C# language spec, which defines how various syntactic-sugary things are compiled, is a public document. The author could have used either approach, or a mixture of the two.
Check out ildasm to take a look at the compiled IL.
(Really, it's good fun once you get your eye in)
.NET CLR actually has a form of assembly called MSIL, along with an assembler and dissembler. So yes, you can actually compile the code, then see the exact compiled CLR instructions.
https://web.archive.org/web/20211020103545/https://www.4guysfromrolla.com/articles/080404-1.aspx
dotPeek by JetBrains
https://www.jetbrains.com/decompiler/
It's free and easy to use :)
So Jeff Atwood rightly complained about Visual Studio not performing background compilation see: http://www.codinghorror.com/blog/2007/05/c-and-the-compilation-tax.html
The solution from most sources seems to be Reshaper which will incrementally perform background compilation as you write. This leads to their great realtime re-factoring tips and error detection.
But what I don't understand is with R# continually compiling my code, why does it take so long when executing a compilation via VS (i.e. Ctrl + Shift + B or similar). What I mean by this is, if R# has already compiled my code then why would I need a recompilation?
My assumption is of course that R# is not overriding the assemblies in my bin directories but instead holding the compilation results in memory. In which case, is it possible to tell R# to simply override my assemblies when compilation is successful?
I don't know about "rightly complained" - that's an opinion I happen to disagree with:)
However, the VB.NET (and probably Resharper c#) background compilers do not actually compile full assemblies - they cannot! If you think about it, the natural state of your code while you are working is not compilable! Almost every keystroke puts your code in an invalid state. Think of this line:
var x = new Something();
As you type this, from the key "v" to the key ")", your code is "wrong". Or what if you are referencing a method you haven't defined yet? And if this code is in an assembly that another assembly requires, how would you compile that second assembly at all, background or not?
The background compilers get around this by compiling small chunks of your code into multiple transient "assemblies" that are actually just metadata holders - really, they don't care about the actual effects of the code as much as the symbols defined, used, etc. When you finally hit build, the actual full assemblies still need to be built.
So no, I don't believe it's possible because they're not built to do actual full compilation - they are built to check your code and interpret symbols on the fly.
Reshaper which will incrementally perform background compilation as you write
It doesn't, it just parses the source code. The exact same thing Visual Studio already does if you don't have Resharper, that's how it implements IntelliSense, its own refactoring features and commands like GoTo Definition and Find All References. Visual Studio also parses in the background, updating its data while you type. Resharper just implements more bells and whistles with that parsing data.
Going from parsing the code to actually generating the assembly is a pretty major step. The internal format of an assembly is too convoluted to allow this to happen in the background without affecting the responsiveness of the machine.
And the C# compiler is still a large chunk of unmanaged C++ code that is independent from the IDE. An inevitable consequence of having to have the compiler first. It is however a stated goal for the next version of C# to provide compile-on-demand services. Getting true background compilation is a possibility.
I don't really have an answer but I just wanted to say that I have been using Eclipse and Java for 4 months now and I love the automatic compilation. I have a very large java code base and compilation happens constantly as I save code changes. When I hit Run everything is ready to go! It's just awesome. It also deploys to the local web server instance (Tomcat in my case) automatically as I make code changes. All this is setup by default in Eclipse.
I hope Microsoft does something similar with .net in the near future.