I am trying to debug a unit test. When I step into the code of the class I want to test VS2008 show the disassembly rather than the source. I have checked in the modules window and the status for the module in question reads "symbols loaded" so everything looks OK
The project is c#, I am using Visual Studio 2008 SP1, anyone got any ideas, it is driving me nuts!
Symbols and source code is not the same thing. You need either have the source code for your module in the same place on disk it was on the build machine, or set up the source server: http://msdn.microsoft.com/en-us/magazine/cc163563.aspx
If you right click in the source window, there will be a context menu option "Go To disassembly". That will show you what your looking for. Though, typically most people tend to ask how to get to source code from disassembly, not how to get to disassembly from source code! :)
#Grzenio is correct in that if you have the source and symbols and are still seeing dissassembly, something is out of whack.
Try checking for versions of the dll in the global assembly cache (GAC). You might also find other clues by checking the properties of any custom dlls that have been referenced. Specifically the properties "Specific Version" and "Copy Local". If either of these values are true, it could be a clue that the project references a GAC'd copy of a dependency dll.
Old post, but had this issue recently...
Delete the reference to the project for which you want to step through from the project calling the reference. Clean the solution, rebuild everything (which I like to do one project at a time when I have this issue). Add the reference again - ensuring you are adding the reference as a project reference and not directly referencing the .dll.
You can also try going to the debug settings and uncheck "Enable address-level debugging" under Debugging | General.
Related
I have a C# project which contains references to assemblies in DLL format. I have the PDB information for these DLL files, contained in the same folder. When I press F12 on a referenced member, I want to go to the definition of the member. Instead, it gives me the metadata, which of course I don't want.
When VS is debugging, it does go to the source code if I single step into that method. But if I press F12 on that method, it still brings me to the metadata.
There is a similar question here, but it only applies to project references, and the accepted solution has nothing to do with my issue.
"Go To Definition" in Visual Studio only brings up the Metadata
To summarize:
Referenced project is a DLL
I have the PDB information
Single-stepping in debug-mode brings me to the source code
F12 brings me to metadata
I want F12 to bring me to the source code as debug does.
EDIT: Adding as a "Project" is not an option as it creates additional complexity as our solution file references about five other projects which are all under separate source control repositories.
In Visual Studio expand the References section, select the reference to your related project (the one that contains the source code you want to F12 into) right click on it and select "Remove".
Then add the reference back to the project by right clicking on References and selecting Add Reference, under the Projects tab (if your using VS 2012) select (or browse for) the project you want to add a reference to and then click the OK button.
This will rebuild the reference and you will be able to F12 into the referenced projects source code. You will need to do this with all the projects in your solutions that are having this issue.
I don't know why this happens but at least the solution to the problem is rather simple
If you have ReSharper installed, you should bring up ReSharper options, and look for External Sources. There you can specify the relevant options:
It appears that this issue has been solved in Visual Studio 2013. Having the PDB information in the same folder as the DLL is showing me the source code when I use Go To Definition. I do not have the Reflector extension installed.
Is the referenced DLL a project in your solution? I find that when I have the source code for the project, and it's in my solution, Visual Studio is able to link to this code much more easily. (without showing me meta data).
Also, be sure to add the reference by "Project" in the References popup.
This is generally what I do anyways when I have this problem
Hope this helps!
PS. PDB files are usually just for debugging (both locally and remote) and are not used for source code reading in the way you are attempting to use it. ("Go To Definition")
One solution to this issue is to use .NET Reflector, VS or VSPro edition. This program will modify Visual Studio to provide the required functionality.
http://www.reflector.net/
Unfortunately, it costs $135 to $195, which isn't an option for everybody.
Add the reference as a project instead of ..\bin\Debug\referenceFile.dll
That solved my issue
I also used add reference as a project and my problem has been resolved and it's working great. Actually I was stuck at this point from very long time and finally i resolved this issue.
References -> Add References -> Solution -> Projects -> Select reference
I'm trying to re-jig the layout of a very large solution which has become impossibly hard (and s l o w) to work with. My plan is to create a number of solutions containing related projects, and then use binary references where necessary to link to libraries produced by the other solutions.
The thing we rely on to make this usable is Resharper's Navigate to External Sources functionality, so we can easily browse the source of the projects we are referencing from other solutions. Quite why VS can't do this out of the box is beyond me.
This is all working very nicely for classes with implementation. However, for C# interfaces and classes containing only auto-implemented properties, Resharper isn't able to browse to the sources, and falls back to cruddy metadata viewer.
I used srctool.exe, which comes with the Symbol Server tools in MS Debugging Tools For Windows, to browse the sources listed in the .pdb file, and it's clear that the sources for these interfaces and empty(ish) classes are not referenced in the pdb file. If I switch the auto-implemented properties to those with backing fields, then the source link appears in the pdb.
I'm guessing the sources are excluded because there are no places you could set breakpoints on interfaces and auto-implemented properties.
I'm wondering, though, if there is some exotic compiler option or workaround we can employ to force the PDB file to include references to the source of C# interfaces.
Thanks,
Mark
The question doesn't have enough detail. Shooting off the hip, I'd guess that you tackled the problems with the slow massive solution by converting project references to assembly references. And used the Release build of those projects as the reference.
And yes, that stumps any tool that tries to find source code files from the PDB. The release build of a .NET project uses a stripped version of the PDB, all the source code file and line number info has been removed from it. That's a pretty normal thing to do with real release builds. Release built code normally is optimized. That causes code to be re-ordered, no longer matching the logical position of the code in the source file. Any info you get from the source+line PDB info now tends to get between harmful and useless, you start looking in the wrong place for a problem.
That is however not a concern for IDE tooling or while debugging your app. The optimizer is automatically disabled in a case like this. Actually a configuration item in VS: Tools + Options, Debugging, General, "Suppress JIT optimization on module load" option. Turned on by default.
Clearly any tooling that uses the PDB is going to catatonic when they don't have a chance to find source files. The fix is to go back to the original project, select the Release configuration again and change a setting: Project + Properties, Build tab, scroll down, Advanced button. Change the "Debug info" combo from "pdb-only" to "full". Rebuild the project.
Should fix your problem. Also revives the debugger, you can step into the source code again.
Don't move files around too much btw, you might stump the chumps again. At least keep the PDB with the DLL in the same directory. If the source code is no longer present in the same directory but you checked it out again in another one then you have to tell the IDE about it. Right-click the solution, Properties, Debug Source Files setting.
what do I have to do to jump to the right class not the metadata?
in visual studio 2010 while working on c# code I right click on some code to jump to "Go To Definition"
sometimes shows the right class where my object is define and sometimes show me the Metadata not the right class...
why is this ?
thanks for your help
It only shows you the source code of a class if that class is available in your solution. If you're referencing a project whose source you have, you can add it to the solution as a project reference, and "Go To Definition" should behave as you'd expect. If you're referencing a compiled DLL, "Go To Definition" will only display metadata.
if you added references to other project than F12 will go to the actual source code but for the DLL it will go to the meta data if defind
Visual Studio will go to the metadata when the reference is a DLL or an EXE - it doesn't "know" about the source code.
It will go to the source code when you have references a project.
As others have said, Visual Studio cannot show you the actual source code for an assembly that you only have in compiled form (i.e. .exe or .dll). If you really need to see how something was implemented, then you can use Reflector to decompile it for you, though the resulting code will probably be less intelligible than the original (no comments, variable names will be lost, etc.).
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
My C# debugger is not working properly. It skips break points and line of codes sometimes. I have checked the configuration manager. I have even tried adding my projects to new solution files. Can someone please help me?
My debugging checklist:
Make sure your attaching to the process using the correct code type - if your process has both unmanaged and managed code then dont rely on "auto" to work for you, explicitly state what sort of code your trying to debug
Goto the modules window (Debug -> Windows -> Modules, you may need to enable it in the "Customize..." menu
Check to make sure that the assembly your trying to debug has been loaded, and that symbols have been loaded - if they haven't been loaded then right click on that module and select "load symbols"
Open your code file and place your breakpoint - if it appears with the little warning symbol then look and see what it says,
You might need to goto "tools -> options - > debugging -> general" and untick "Enable Just My Code (Managed Only)"
You might also want to uncheck "Require source files to exactly match the original version", if you think your sources might be slightly out (beware however, as this can lead to you debugging with completely the wrong sources, which can be very confusing)
On certain cases you might find that your module doesn't get loaded at the point where you attach your debugger (for example if you have some sort of plug in archetecutre, and plugin assemblies are only loaded when you first use them). In these cases all you can do is try and make sure everything is prepared ready for when the module is loaded.
Make sure optimizations are disabled (this is the defaut for the Debug configuration, but they are enabled in Release configuration). Compiler optimizations can mess with the debugger...
Are you sure that it compiled correctly? It sounds to me like you're debugging against a previous version, which can happen if the build fails (perhaps a code bug, perhaps the files are readonly).
If entire methods are being skipped, look at the source and see if the System.Diagnostics.DebuggerStepThroughAttribute attribute is present.
Despite the name, it PREVENTS the debugger from stepping through the method.
This worked for me in VS 2017, Go to Tools > Options then under the Options Window go to the Debugging section. Enable - "Enable .NET Framework source stepping"
This sounds like your source code is out of sync with the PDB files. The easiest solution is to clean the solution (which deletes all your dlls from the bin folder). Recompile, and then try stepping through again.
If it still fails, try closing the solution and deleting the "obj" folders. And then try again.
And also check you are compiling in debug mode - something I've done often ("why isn't it stepping through?!")
not getting break point
If at least sometimes the break point is hit it means that all the settings are most probably OK.
The missing hits may be caused by some side-effects, for example: property evaluation by the debugger (at least VS skips the breakpoints during the property evaluation for debugger) or some spying tools (but these are usually catch by debugger).
If you think this may be the case, turn off the spying tools and disable the property evaluation by the debugger.
This may be sometimes not enough, for example: If your property returns a collection, displaying e.g. a Count() will evaluate the property - so remove also all references of property from the watch windows, etc.
Disabling "Project Properties/Build/Optimize code" worked for me.
#Justin's answer above was super helpful. I would add one thing to the list.
Check to make sure you're running in debug and that your debug preferences have "Optimize code" unchecked. See below:
Also make sure that the code you're trying to debug is running in the same process as the main executable. I just wasted a half hour figuring that one out - the breakpoint wasn't hitting because the code of interest had been spun up in a child process instead of being called directly (the program in question has two different modes of operation).
If you're getting this kind of error:
The current .NET SDK does not support targeting .NET Core 2.1. Either target .NET Core 2.0 or lower, or use a version of the .NET SDK that supports .NET Core 2.1. DCR_Parser
Right click on the project in solution explorer and click on Properties. Under the Application tab go to Target framework .NET Core 2.0. And save.