I have an app written in C#. It was already compiled.
There are plenty of dll files there and i could not open them , decompile them cannot see and access C# code which build them, when i add a reference to dll files in Visual Studio i only can see what methods are there, but i cannot see / access code of those methods.
Is there a tool or is there a way how to see / access that code , modify it and then recompile it ?
Please if you have an idea give me a hand !
Thanks
The easiest way to do this is through Reflector - it is not perfect, but will give you a good idea.
It lets select an assembly and display it in either IL, vb.net or C#. You can copy/paste the result into Visual Studio and compile it with your changes.
Because it works on the raw optimized IL, things like foreach loops can end up as labels and gotos and variables names can end up as invalid C#/vb.net variables names (though they are valid IL).
I have used it in the past, and the biggest issue is in reconstructing foreach loops, though the pattern becomes apparent after several of those, and the variable names can be changed with a search/replace.
Related
I will briefly tell you the situation.
I got a C# project which uses some DLL created in C++.
Now, separately, I also have a C++ project, which was used to create that DLL some time ago.
Now, I wanted to debug the C++ DLL during running the C# project.
I enabled "Enable Unmanaged Code Debugging" in my C# project.
I started debugging C# project and stepping into some functions alongside.
All seemed to be ok. When I reached a function which belonged to C++ DLL,
it asked for the source of the C++ file, I had to browse to my C++ project.
(Before I think it complained about some .pdb files).
Now, I managed to step into the C++ function also, but as I step over and over, some of the data structures in that function don't seem to be populated with the data, e.g., please see screenshot below
You can see the blob data structure is empty, and same happened with DataParser (it was showing it had 0 items inside, whereas in code above you can see there are multiple items being added to it).
I would really appreciate some help, what is going wrong here? And where I could have done mistake. How can I debug this C++ DLL so that I also see what values are assigned to its variables currently?
Maybe my way of debugging this C++ DLL is wrong? The fact that the C# project is using an already created DLL, and I have this C++ project which was used to create this DLL some time ago - the fact that they are separate, maybe that has to do something with it also?
PS Before I had to make changes like this to C++ project and lower toolset because I use VS2012 (strange if project was created using VS2013 though because I think it is old project). Also the project uses lot of manually written other C++ classes. Maybe that is the problem also and somehow the compiler can't retrieve their values and definitions?
What are the steps in general to debug a C++ DLL file in a setup like I have?
EDIT: PPS. Also some other interesting facts I have seen. If I click F11(Step into) on the DataParser.Add function for example, not necessarily I am taken to the body of that function, it shows me body of other function (which might be somehow related to it).
Also if I press F10 say after first time Request.Add is called, it jumps over multiple Request.Add lines, and moves to the fifth one for example.
EDIT2: Also before I step into C++ code it is showing me warning that "the source is different version than the one that was used to create a DLL". Is this a problem?
Module and PDB
There is a link between a module (.dll/.exe) and the debug database (.pdb). This link is established via a timestamp and a checksum that is present in both files. Visual Studio checks the correctness of those, otherwise it will complain and not stop at breakpoints at all.
While other debuggers such as WinDbg have commands to turn that feature off, Visual Studio doesn't have such a feature and requires active manipulation (such as Chkmatch) to turn off the checmsum verification. As long as you didn't use such a tool, your debugging symbols are fine.
PDB and source
There is also a link between the debug database (.pdb) and the source. This link is established by file name and line numbers. As you can guess, your source code will not modified during compilation, so the source code does not contain any checksum or timestamp that could be verified.
Therefore, the source may have changed and the line numbers may not even match roughly any more. There are several reasons for line numbers to get broken. I have answered a similar question before and listed the following reasons for line number changes although the code itself did not change:
code reformat, which e.g. sorts the methods by visibility, so complete methods are moved
code reformat, which e.g. breaks long lines at 80 characters, usually this moves things down
optimize usings (R#) which removes 30 lines of unneeded imports, so things move up
insertion of comments or newlines
How to debug
Restore the exact source code of that version, if you can.
Debug completely without source, just by PDB information. This way you can keep the binary components, if that's important (e.g. if a bug can only be reproduced with that version)
Rebuild all modules to make the code match the modules again. That way you lose the binary and the problem may not reproduce any more.
If you examine C# code in Reflector, you can notice special compiler-generated local variables that are named with the pattern CS$X$Y. These variables were (unofficially) documented in this answer.
Is there any way to view these values via the Watch window in Visual Studio, or via the VS Debugger Extensibility API?
I'm asking specifically about the regular Visual Studio debugger, please do not answer that this is possible via windbg/sos/sosex - as that's not what I'm looking for.
Unfortunately there is no way to do this with the C# EE. The names for these locals are indeed stored in the PDB and available. However the C# EE will filter out all temporary values during debugging to reduce clutter. This filtering is unconditional and cannot be overridden. C# is not alone here as this is the behavior in every language.
The good news though is that every language uses different naming patterns for their temporaries. This means a temporary name in C# will run right past the filtering of the VB EE. Even though it's an illegal identifier the VB EE still considers it a valid local (and vice versa). Hence you just need to temporarily switch the debugging engine for C# code to the VB EE and the locals will become visible
Here is how to do this
Close all instances of Visual Studio (this is really important)
Open up regedit
Navigate to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\AD7Metrics\ExpressionEvaluator\{3F5162F8-07C6-11D3-9053-00C04FA302A1}\{994B45C4-E6E9-11D2-903F-00C04FA302A1}
Change the value of CLSID from {60F5556F-7EBC-4992-8E83-E9B49187FDE3} to {59924502-559A-4BB1-B995-5D511BB218CD}
Now whenever you debug C# code it will use the VB EE and hence display temporaries as normal locals. Note that this is completely unsupported. But it should work fine. I was able to see raw closure values with this trick on my machine and poke around a bit without any issues.
Note that these instructions are specific to Visual Studio 2013. If you are using 2012, or 2010 it should work by changing the 12.0_Config in the registry key name to
2012 use 11.0_Config
2010 use 10.0_Config
It may need a few tweaks on top of that (didn't actually test older versions). If you run into any problems there let me know and I'll try and get it working locally and update the instructions
Here is a pic of the final output once you make this change
No, they are not added to the PDB file. The debugger simply has no way to discover them, nor know anything about where they are stored. This is all entirely intentional.
Having a server that other devs use, I currently log the version of the dll they use. I do that by having the client that use Reflection to retrieve its version:
Assembly.GetEntryAssembly().GetName().Version.ToString();
It's nice, but since it come from dev that uses TFS and do themself the build, I can not see if they have the latest version of the sources. Is there a trick, like a compilation tag, that would easily allow a hash of the generating source code?
Note: I have try to send the MD5 of the dll (using assembly.Location), but it is useless since the hash value changes between 2 compilations (I suppose there is some compilation timestamp inside the generated dll).
This is most collaboraton issue then a coding.
In the moment that you find out that the version is old one.notify them about it.
If the real version is not old one, that means that developers before making buold did not increment the version ID, which is mistake.
In other words, ordanize it among people, and not relly on these kind of tools (if there is any). You trying to create a complicated tool, that will help you avoid mistakes, but humans will find a way to make them again.
So it's better to create solid relation structure among you, imo.
Create a tool on pre build event to hash/last-write-time your code files.
Write the result to a cs file or a embedded resource file.
The result file must exclude in above action.
For prevent skip build (up-to-date) feature not work,Compare the file before write.
And if youre opening the file in IDE will get a prompt `changed from out side' when build.
Seem there is no easy way to do it.
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.
For business reasons, I want to create a C# application that would take a C++ file / snippet as input, compile it (probably invoking a C++ compiler under the hood) and output compilation results.
Do you know how this could be done?
Thanks in advance.
Using CL.exe
Look in to the Process class.
It provides all of the functionality required to start an external application, including a compiler.
Now, depending on the compiler you choose, you will need to specify the start arguments of the process carefully in order to compile in a predictable way.
Most compilers support command-line parameters.
You just need to build the right command and execute it through the shell like advised here.
che
If you want to not just build a single file, but a whole .vcproj file - check the command line parameters for devenv.exe. If I remember correct it is:
devenv.exe /build my.vcproj
You can shell out to any number of command-line C++ compilers (like gcc) using Process.Start.
You could do this by calling any C++ compiler on the command line. I'm sure the compilation results can be redirected so that you can grab it after the compile finished.
If you are trying to achieve something like SnippetCompiler for C++, you might want to look at one of the C/C++ scripting languages. I have always liked CInt.
Sure its possible, it is actually common practice nmake and other make-like utilities call the compiler all the time.
OTOH if you are thinking of deploying this solution to a customer you may be in for a bit of rough ride cause of all the details like settings, location where files are, how to react on the result, license, which c++ compiler to deploy etc.
Another option which is much simpler (IMHO) is instead of C++ to invoke the C# compiler directly from your C# program for compiling a C# snippet. Files can then stay in memory and you don't need to save any files before you compile. There are numerous examples on the web that show how to do that. Another advantage with this solution is that you already have the C# compiler there so there is no need to install a C++ compiler as well.