I using dotPeek v1.2 with VS2013 Update 3 to attempt to debug a referenced C# .dll's code. I've followed all the directions from the following tutorial: Using dotPeek as a Symbol Server (http://localhost:33417/ is set as symbol location, etc.) To be honest I've read a bunch of articles like this and this, combed through all the required settings, and really haven't seen 1 working solution of debugging a 3rd party non-framework .dll so I'm not convinced this is a fully working product from this aspect.
Regardelss, dotPeek should allow once the symbol server is started to step into and debug code from 3rd party assemblies from VSNET according to their documentation. I know which .dlls to select for dotPeek because I inspected their path from Debug -> Windows -> Modules.
I happen to have ReSharper also installed which allows me to decompile when I right click a line of code and select 'Go to Declaration'. The problem is it appears the symbol server isn't doing anything to assist in serving up the code at debug time. Rather the decompiled source provided by ReSharper seems to be what VS.NET wants to jump into. The problem is I always get the following error:
Source file:
C:\Users\username\AppData\Local\JetBrains\ReSharper\v8.2\SolutionCaches_ReSharper.Meijer.Ecommerce.Nav.WebAppServices.-382002776\Decompiler\decompiler\53\66e7ccc2\MyClass.cs
Module: C:\Projects\MyProject\bin\Debug
Process: [24808] vstest.executionengine.x86.exe
The source file is different from when the module was built. Would you
like the debugger to use it anyway?
If I say, 'yes' and step in the debugger appears to be on lines that don't exist in the file and is out of sync. This makes sense as it is showing the .cs class from the 'Source File' location but has the .dll loaded from the /bin/Debug
However, I don't understand why this is happening anyway as dotPeek should be serving up the loaded symbols from the /bin/Debug and not be trying to step into any decompiled source ReSharper had presented.
How do I configure this so VS2103 will actually debug the symbols and code served up from dotPeek?
One big gotcha is that you need to make sure you have a valid path set for the cache directory in the Tools -> Options -> Debugging -> Symbols page.
Also, on the main Debugging options page (Tools -> Options -> Debugging -> General) make sure you:
Uncheck the "Enable Just My Code" option
Uncheck the "Enable .NET Framework source stepping" option
Check the "Enable source server support" option
Uncheck the "Require source files to exactly match the original version
It's also worth checking the "Print source server diagnostic messages to the Output window" option, and checking the output window when trying to step into 3rd party code. It should hopefully point to any issues.
This is how I've got things set up, and I can debug 3rd party dlls (obviously, dotPeek needs to have the .dll loaded in the assembly explorer before you start debugging, too).
Related
I am attempting to debug NuGet source code (Project Foo is referencing Project Bar through a NuGet package in MyGet) and I'm stuck with "The breakpoint will not be currently hit, the current source code is different" error and I'm out of ideas.
What I did:
Added MyGet symbol server in VS.
Assembly built non-optimized with a full PDB.
Unix-style .editorconfig for correct encoding and LF line endings (source code is in Git).
The symbols are in MyGet:
The modules appear to load correctly:
R# seems to be using the wrong hash and gives errors:
PdbNavigator: Downloader: https://private-symbol-server/symbols::Phx.Security.Web.NETCore.dll::02da18bf9fbf42e1bd6263e56ca57af8FFFFFFFF -> Ok (cached)
PdbNavigator: No debugging information found on symbol servers for Phx.Security.Web.NETCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
VS complains about the source code being different when I manually add breakpoints to the source file:
I'm open to all suggestions and ideas at this point!
The breakpoint will not be currently hit, the current source code is
different error
It complains that the xx.cs file found by VS is bit different from the version used to build the xx.dll. I assume maybe you have some changes made to the xx.cs file after you built the xx.dll and publish it to your nuget server.
You can try rebuilding the Nuget project, and push its source files, pdb and assembly to your Symbol Server the second time. (Clean the existing versions)
After that create a new project in new solution to consume that package and check if the issue persists. (Not sure if the original Bar project would affect the debugging while they're in same solution, so please create a new solution to check)
Also, you can work around this error by Go Debug menu => Options => General => Disable the Require source files to exactly match the original version option.
Most of the time we should select this option to make sure what we are seeing is what we are running during debug process, but since this is your personal project, if you can make sure the xx.cs and assembly in your symbol server is the right version you want, you can try to disable it when debugging your nuget project. See the recommended configuration.
I am trying to debug a small application that deliberately throws an exception in a dependent library. I built the code for both, but I am debugging on a workstation that I did not use to build the dependent library. I have a step in my small build process to Index Sources and Publish Symbols (using the vNext build system) for the dependent library.
I want to be able to debug and step into the code of the dependent library. My expectation is that the indexing information stamped into the pdb file will allow the acquisition of the source code files "on the fly".
The pdb file successfully uploads to the source server during the vNext build, and the pdb file is successfully loaded from the symbol cache directory I've specified in visual studio according to Debug -> Windows -> Modules.
My application throws an exception deliberately so the debugger will have something to break into. When it does, I see the code that is throwing in the stack trace, so I know the symbols are loading correctly. When I double click on that entry in the stack trace, I am not taken to the source.
Due to the indexing information, I would have expected Visual Studio to get the source, but I am shown a file browse dialog. Note, I am using Visual Studio 2017.
Here is the indexing information in the pdb file (which shows the pdb was indexed correctly):
------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Thu Mar 08 15:58:40 2018
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(%var2%) /console > %SRCSRVTRG%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=REDACTED
SRCSRVTRG=%TFS_EXTRACT_TARGET%
SRCSRVCMD=%TFS_EXTRACT_CMD%
SRCSRV: source files ---------------------------------------
C:\Resources\agent\_work\6\s\REDACTED\AppDomainLogger.cs*VSTFSSERVER*/REDACTED/AppDomainLogger.cs*77776*AppDomainLogger.cs
C:\Resources\agent\_work\6\s\REDACTED\CustomLogger.cs*VSTFSSERVER*/REDACTED/CustomLogger.cs*77776*CustomLogger.cs
SRCSRV: end ------------------------------------------------
Note, I have REDACTED some information, it is just pathing information I don't want to reveal, and a server name, but they are correct. If the VSTSSERVER value and source code values are correct, why isn't the source code pulled up when I try to debug. I'm not sure what those numbers are in the source code paths, and I didn't see any login credentials to log into the tfs server. However, since I'm already connected to TFS by virture of using visual studio, I thought perhaps credentials aren't needed? My build process curently does not label source .... could that be part of the problem?
I am a bit new at this (trying to use source information during debugging). Let me know if I'm missing something, and if I am, how I can remedy the situation.
I DO have the Debug -> Options -> General -> Enable Source Server Support checked (and it's two sub-checkboxes) prior to attaching visual studio to the application.
Ever since I started using ReSharper it's never been clear to me how I can step into my own external sources. Sometimes it's working, but most of the times it is not.
As my frustrations are at its peak I would like to figure out how this works once and for all.
I have two C# solution files (one for my Framework and one for my Platform). I am using code from my Framework in my Platform solution through Nugets.
Both solutions are located on my disk (C:\<project>\framework and C:\<project>\platform). The Framework solution contains several projects (e.g. Framework.Core and Framework.Logging).
When I am debugging my Platform solution I cannot navigate into a method (F11) that is called on one of my Framework components.
As said, this has been working fine for me in the past but now it's not working anymore and I cannot find the solution.
Thanks for your help!
ReSharper doesn't control anything about stepping into external source while debugging. The options in your screenshot control navigating into external source from standard ReSharper navigation commands (go to type, find usages, etc).
In order to debug external sources, you'll need to make sure you have access to the .pdb files for your external code. This must either be side-by-side with the assembly, or available in the symbol cache, or downloaded from a symbol server.
Each time I build my Visual C++ solution in Visual Studio 2010, the entire project (not the entire solution) recompiles.
There must be a flag or configuration somewhere to make VS compile only the changed files + depending files. Where is it?
UPDATES:
I set "Yes (/Gm)" to My project's configuration properties\C/C++\Code Generation\Enable Minimal Rebuild. It still compiles all the project's files upon F7.
If in addition you get the a message similar to:
Creating ".\Release\SomeLib.unsuccessfulbuild" because "AlwaysCreate" was specified.
when building, the reason might be that one of your projects refers to a header file which does not exist on disk (see here and here).
The first link also includes a small C# script to check for this situation. To fix, simply remove the reference to the non-existing header files from your project.
Update
It might be possible that you have your precompiled-headers setting on 'Create'. To fix, right-click your project in the solution browser and select: properties -> C/C++ -> Precompiled Headers -> Precompiled Header. Change the setting from Create to Use or Not Using Precompiled Headers.
VS should behave like you want it to by default; it sounds like something is flaky going on. Clean the project, and delete your settings files (e.g. .suo / vcproj..user / etc). There are several reasons for this, some of which I've seen are:
corrupt settings files
system date/time / time zone changes confusing vc
permissions issues on the source files
The post of tul was push forward for us, because we also have had some projects, which always did re-compile. As result I have found that:
yes, option 'Minimal Rebuild' somehow was corrupted in our visual 2010 projects. I guess, this could happens when they was transformed from visual 2005.
sign of "corruption" in a particular project is that this option is assigned, i.e. it is in bold. This could be only for some configurations, e.g. Release, or for some architectures, e.g. x64. It could be in bold "NO", but still recompiles.
FIX is as easy as the next steps:
select one or even few projects in solution
right click on project -> Properties
choose Configurations: "All Configurations"
choose Platform: "All Platforms" (if you have both x32/x64)
Expand C++ group
Goto "Code Generation"
note option "Enable Minimal Rebuild" -- most probably it will be empty, because different projects/configurations have different values
set this option to NO
click button Apply
again set this option to "inherited from parent"
click button Apply. NO you should see that this option becomes "NO" but in plain text.
DONE. No need even to recompile. The next build will be much faster.
So, I was having the same problem with one of our projects. First, I was able to debug the compiler output by selecting:
-> Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity -> Detailed.
It turned out that someone had set the project to always create precompiled headers for all files (/Yc). I changed the option as listed below.
-> Configuration Properties -> Precompiled Header -> Use (/Yu)
Then I set the same option for stdafx.cpp to (/Yc). So compilation of the stdafx.cpp creates the precompiled header, and all the other .cpp files use the precompiled header. This is the default scenario, and I'm not sure how it had changed for out project.
Additionally, I have changed all our compiler settings to be consistent across all projects, including:
1) Setting: C/C++ -> Precompiled Headers -> Precompiled Header -> Use (/Yu)
Switch: /Yu
Reason: Faster build time.
2) Setting: C/C++ -> General -> Debug Information Format -> Program Database for Edit and Continue
Switch: /ZI
Reason: Enables edit-and-continue, thereby improving debugging capability.
3) Setting: C/C++ -> Code Generation -> Enable Minimal Rebuild -> Yes
Switch: /Gm
Reason: Allow and speed up incremental builds and this is required for /ZI.
Hope that helps. I spent a lot of time messing with our project build settings and reading posts to Stack Overflow, and in the end, I miss C#.
I had the same issue, except mine started without reason, without me making any project configuration changes.
I would edit one file, hit build, and it would rebuild the entire project.
After much painstaking experimentation, I found that turning OFF 'Minimal Rebuild' made the problem go away. With that off, I could once more change a file and it would only compile that one file.
The weird thing was, once I had successfully made a build with minimal rebuild disabled, I could turn it back on, and everything was back to normal.
Makes me think that some cache file somewhere had become corrupted perhaps? I had tried deleting all my intermediary directories without joy, so if it was a corrupt file I don't think it was anywhere within my project directories.
Hope this helps.
We have a DLL which provides the data layer for several of our projects. Typically when debugging or adding a new feature to this library, I could run one of the projects and Step Into the function call and continue debugging code in the DLL project. For some reason, that is no longer working since we switched to Visual Studio 2008... It just treats the code from the other project as a DLL it has no visibility into, and reports an exception from whatever line it crashes on.
I can work around that by just testing in the DLL's project itself, but I'd really like to be able to step in and see how things are working with the "real" code like I used to be able to do.
Any thoughts on what might have happened?
Is the pdb file for the dll in the same directory as the dll? This should all work -- I do just this on a regular basis. Look in the Modules window which will show you whether it's managed to load symbols for the dll. If it hasn't then you won't be able to step into functions in that dll.
It sounds like you have "Just My Code" enabled and VS is considering the other projects to not be your code. Try the following
Tools -> Options -> Debugger
Uncheck "Just my Code"
Try again
I've gotten around this issue by opening a class that will be called in the project you need, placing a breakpoint, keep the file open, and run the debugger. The debugger will hit the breakpoint and the relative path that VS uses will be updated so that future classes will be opened automagically.