I need to debug some assemblies due to they throw exceptions. It's my assemblies but I don't have the source code of them. What I have is their pdb files.
Is there any way to debug that assemblies by Visual Studio?
--EDIT--
Of course, I also can disassembly them to get *.il files of them. Would it help me somehow?
Actually there are a few ways to accomplish this:
Use dnSpy - a free opensource .net debugger and assembly editor https://github.com/0xd4d/dnSpy
Setup symbol server with dotPeek (also free) https://www.jetbrains.com/help/decompiler/Using_product_as_a_Symbol_Server.html
Use Resharper decompiler to load symbols for external modules in your visual studio. I think this is the easiest way. I've described the whole process on my blog https://cezarypiatek.github.io/post/debug-without-sources-part-one/
This is exactly why I paid for Reflector. Need to debug someone else's assembly? It works perfectly.
As far as I know, the PDB files are just pointers for debugging. That is, if you don't have the source code then the PDB files will only give you the stacktrace.
I don't know if Visual Studio can handle it, you might need to hook up manually to the process.
Not exactly in visual studio, but I wrote in the past such a tool inside reflector, calle d Deblector. Is no longer mantained by me but have a look. Of course the debugging experience is not the same you can have in Visual Studio, but is sometimes enought to get you out of troubles.
Check out dotPeek:
https://www.jetbrains.com/decompiler/
You can set this up as a symbol server inside visual studio to generate PDB files which allow you to debug. It is very easy to use and just as good as many of the paid products.
You can add libraries directly from nuget, or point to the DLL.
Related
I am working on an assembly that handles various color transformations. When I load the assembly into a new project to test, if there happens to be an bug in the assembly, Visual Studio opens the offending code from the DLL. I can step through all of the code in the assembly.
I definitely don't want the code to be so easily visible/available. I would like the code to be somewhat "locked" in the assembly.
How can I set the DLL to simply throw some sort of error instead of opening?
Edit
I'm not interested in the code being "safe" and I have no need to obfuscate. This library is being used internally and the code itself is perfectly accessible to tohers. What I don't want is for someone using the library to find themselves suddenly debugging the assembly. If there is a problem, I prefer to have an error thrown instead of the assembly code opening in Visual Studio.
This is happening because you have VS installed on the machine, and because you are deploying the PDB files - you will not get this dialogue box if VS is not installed.
Additionally:
Do not deploy code that has been built in the Debug configuration. These contain additional information that helps with debugging.
Make sure you do not deploy the PDB files with the executables. Same as above, and they are not needed for running the code.
Both these will help, but any assembly would be easily decompiled with reflector, so you may also want to investigate obfuscators to stop other programmers from easily seeing your code.
There is a list of C# obfuscators here : http://www.csharp411.com/net-obfuscators/
What you need is to obfuscate your binaries.
Basically if you want your code to be safe and you dont want your classes are exposed to others, you should definitely need to Obfuscate your code.
To obfuscate your code you can use DotFuscator, it is included with Visual Studio installation.
check my article on it.
http://www.codeproject.com/KB/dotnet/code_security.aspx
how can i see source code of built in controls in visual studio offline?
You can disassemble the IL into somewhat readable source code using Lutz Roeder's Reflector. The local variable names won't be very descriptive, but you can get a good feel for what the program logic is.
You can also disassemble IL using the ILDASM utility, but this is a bit more involved.
http://referencesource.microsoft.com/netframework.aspx
Note that this is shared-source, not open-source. (You can't contribute code)
In addition to what Schabse Laks writes on downloading the sources at http://referencesource.microsoft.com/netframework.aspx:
There is more info on the sourcecode at http://referencesource.microsoft.com/
You can also configure the .NET debuggers to use http://referencesource.microsoft.com/symbols as a symbol server and step through the .NET 4.0 source code:
Steps for Visual Studio by Scott Hanselman
A small fix for the order of debug symbols in Visual Studio 2010 by Sorporbear
Steps for WinDbg by Naveen Srinivasan
Note that downloading the sources in your debugger can be really slow the first time (lots of sources need to be downloaded, the server might be a bit busy, or your internet connection might be slow).
--jeroen
I have a .exe app which I want to understand better - I can see it in reflector
Is there any way to get reflector to create a VS project with the code so I can view it properly in Visual Studio?
Nothing special is needed, it is built into Reflector, albeit not very discoverable. Right-click the assembly in the left pane and choose Export. You'll get a chance to change the output directory. Click OK and Reflector starts decompiling the code, creating a source file for each individual class. And creates a .csproj file which you can open in Visual Studio.
Check out Jason Bock's FileGenerator, it might be what you are looking for.
I've used Denis Bauer's Reflector.FileDisassembler http://www.denisbauer.com/NETTools/FileDisassembler.aspx. It works well enough to compile and step through the code.
Yea there is, but it doesn't come cheap
http://www.remotesoft.com/salamander/
I have used it to decompile assembly, but I've never used the feature to decompile it into a project so can't give you a review on that. The quality of the decompiler will match the one in reflector.
They also be some legal issues associated with decompiling exe into project - and source for recompilation, so use it with care.
I have a project which has a calling structure similar to this:
main project/application
my library code
someone else's library code
my library code
Everything's written in C#, and I have access to 'someone else's library code'. Their code is not included in my project, because it's open source and not my code. I can make debug versions of all the libraries, and I've done so.
That 'someone else's library code (SELC, I guess?) is throwing an exception in a heisen-bug kind of way, and I'm trying to track it down and maybe submit a bugfix to the project maintainer. Problem is, my debugging stack is stopping at my library code, and lists the SELC as 'external' and I can't debug into it. I've copied the pdb files as well as the debug version of the library into the debug directory of my application, and still no luck; I can't seem to debug into their code, and I can't step into it at all.
Once upon a time, back in vs6 days, I could do this-- have two different projects open at the same time in two different environments, and have the debugger trace across dll boundaries from one project into another. I'd assume that functionality remains, because it's just so dang useful.
Any suggestions?
I've looked for this answer but not found it, so if this is a dupe, just let me know where to look.
Do you have "Just My Code" turned on in Visual Studio's debugging options?
If you have the sources (as i read from you), you can make an project with their source code, and then add the project to your solution.
In visual studio the project in .csproj file , and solutions in .sln file.
I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?
If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.
Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!
There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).
Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.
One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program
As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.
.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109
I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.