I am using Visual Studio 2017 Enterprise and I have an ASP solution which uses several compiled dlls that reference one another sequentially i.e. my solution references A.dll, A.dll uses B.dll and so on. My solution uses .NET 4.0 and the dlls have each been compiled in .NET 3.5. I want to debug the entire stack until a call in the last dll (D.dll). These are the dlls:
What I did: I've unchecked Enable Just My Code and I checked Enable .NET Framework source stepping. I generated the pdb files for each dll using dotpeek and then I moved them in Symbols Cache folder and also specified modules to load these specific dlls.
When I debug (I run the solution in Debug mode with Any CPU configuration) I can see each pdb loaded in the Debug/Windows/Modules window, I can see the source code for each window, and everything works ok until I reach A.dll. When I try to step into B.dll, I get the following message:
Your app has entered a break state, but no code is currently executing
that is supported by the selected debug engine (e.g. only native
runtine code is executing).
What is weird is that if I set Function Breakpoint in the D.dll, that breakpoint is hit, but the same approach does not work with B or C. There is no warning like 'The current breakpoint will not be hit', it just does not trigger. I want to see the entire flow from my solution to the last dll.
Does anybody have any idea why this happens? Do I need to do something else to cascade through the stack call?
Any help is appreciated.
Related
I'm trying to debug my code in Visual Studio but my Breakpoint is not hit,it's giving me this message "Breakpoints set but not yet bound"
The breakpoint is in a project that is not set as StartUp Project because it is a library project, my controller calls the method by invocation, I also verified that the dll generated by the solution that contains the library is the same as the project added to my solution
I've read various other questions and tried various solutions like closing VS, deleting bin and obj folders, clean and rebuild but I can't reach those brakpoints
You may have a few options to resolve your issue. First and recommended, your dll and exe project should be in the same solution and both in debug mode. If the projects are in separate solutions, set the breakpoint on the method call on the exe project side. Then pressing F11 should let you into your dll code. If you don't own the project or solution exe, you have the option in VS to link your dll to a running process, but you will only be able to link compiled binaries with managed code. For example, your dll could probably link to windows explorer, but any code will run as far as I know.
I downloaded a package from SourceForge, PlanEph, which has 64 and 32 bit DLLs for C#. I got the 32 bit included C# demo to work by putting the DLL in my bin/Debug directory (I'm using Visual Studio 2015 Community) and adding the DLL as a reference.
Then I tried to make my own version of the demo in a separate solution, and got the System.DllNotFoundException. Various experimentation lead me to believe I can't have two identical namespace names anywhere in my Visual Studio installation, so I erased everything and started over.
I made a directory C\GJAbin, put the DLL in it, and added it to the system Path variable. I also put a helloWorld type program in that dir and executed it from the command line to verify the directory really was in the path. Then I recreated the demo solution, added the DLL as a resource, and built the solution "successfully". Then I ran it and got the System.DllNotFoundException.
So I can't understand why the DLL is being found when compiling but not at run time.
Go to project settings, go to "publish" tab and on the top most button (labeled something like "application files"). Chose "Show all files" checkbox if you don't see your DLL. Set the DLL's publish status to "Include" (NOT "Include (Auto)"!!) and publish it again.
Now the DLL should be inside the publish folder.
So I can't understand why the DLL is being found when compiling but not at run time.
Locating the assembly at compile time is done differently (by MSBuild) than at runtime (by the CLR).
At compile time, MSBuild has specific search paths that it knows about, or in most cases like this, there will be something in your project file telling MSBuild where to look for the file. Usually the <Reference> has a <HintPath>.
At runtime, the CLR will attempt to find the assembly from its own set of well-known paths. It will look in your app's config file (if applicable), then in the Global Assembly Cache (GAC), then in your app's root directory. Much more detail on this is available here.
You can tell MSBuild to copy the reference to your build output directory (usually the same as your app root directory when running). In VS, you can do this by selecting the reference and looking at the Properties tool window (or press F4 by default). Set the CopyLocal state to True. In the project file, this will add a <Private>True</Private> on the <Reference>.
You can also add the assembly to the GAC using the gacutil tool, but this does make it harder if you want to share your app with others. Usually it's preferable to keep a copy in your app root directory.
If it's still not working, you can also see the log for how the runtime is trying to find this assembly. The fuslogvw.exe tool in the Windows SDK (you can run it from the VS command prompt and it will be on the %PATH%) allows you to enable logging for assembly loads. You do need to be able to run this as an administrator to configure the setting.
As you can see in the screenshot, you can either log the results in the exception (so that you can see it while debugging), or you can log it to a file on disk (so you can see it whenenver).
The problem turned out to be an unfortunate interaction among the way the author chose names and the way Visual Studio displays information and error messages. The author created a c# dll Astronomy.PlanEph32.dll containing a namespace PlanEph32, which which was really just a wrapper for the c dll PlanEph32.dll. So all the error messages about not being able to load PlanEph32.dll were referring to not finding the c dll; the c# dll was being found just fine.
I have been working with multiple projects (3-5, 1 exe, rest dll) in a solution and have not had any problems till now. Now one of my projects (dll) won't debug in the solution. The exe and two dlls are c# and the rest are vb. The vb dlls are the ones that won't work now. We have just changed source control and I dropped and added the projects back together and that is the biggest difference. Since then I am receiving "the breakpoint will not be currently hit. No symbols have been loaded for this document", error. It is not showing in the debug->windows->modules and so far I have added it and dropped it, reset references to all solutions, rebooted and researched all over the internet. Also, I am working with Visual Studio 15.
The dlls have not been loaded to the process which you are trying to debug, under project properties check if optimize code is checked-in this will cause VS to see assembly as "not my code", it will not load symbols for it.
Ok, finally got this to work, thanks to one of my co-workers. I was referencing the dll from the bin folder in my exe. We deleted the reference and created a new reference linking it directly to the debug folder of the dll. I could then step into the dll.
I am developing a C# Console app with Visual Studio 2013 Pro targeting .NET 4.0.
Part of this project includes confidential IP so I have created a DLL which contains that IP and a dummy DLL which I use when I have to hand out the code to other folks. I use a #if to include one or the other. The stub compiles and provides testing capabilities. The DLL Actually started out as just another class of the Console app but I just compile it separately to a DLL now. .NET4.0.
I can set breakpoints either in my Main or my DLL and it works fine. I can step through both etc.
The issue is that if there is an error in the DLL, VS breaks at the call in the main program and not at the error in the DLL with a not-so-helpful error message. I then have to guess where in the DLL to set a breakpoint.
Previous posts suggest I ensure that my compile options are set to Debug (they are) and that the .pdb file for me DLL are in the references folder of the main program. I don’t know what the reference folder is but the DLL .pdb is in the bin/x64/Debug folder.
The DLL is part of my Solution. In other words, the Solution Explorer for my main Console app allows me to open the DLL source code and set a breakpoint. The only pain in the part is that I have to "rebuild" the dll each time I run or the main program won't see the changes.
Any clues would be greatly appreciated.
Thanks
-Ed
While searching for debugging c# DLLs, I came across this article.
http://msdn.microsoft.com/en-us/library/c91k1xcf%28v=VS.100%29.aspx which says
You can start debugging DLL from:
The project used to create the executable that calls the DLL.
or
The project used to create the DLL itself.
I have source code(C#) for the executable project as well as the DLL.
My DLL project is in a different solution.
I want to debug the DLL from my exe project. How do I proceed with this. I have searched goole but without any detailed steps. I also added the DLL project to the exe project solution and added the break points in the source code for library project. But the breakpoint is never hit. How does the debugger know that I have loaded the source code for the DLL. Am I missing anything?
Update:
Following Avitus and Mick's suggestions, I added the DLL project to the exe solution. Also added the reference to the DLL project and the breakpoints were hit.
I also tried to debug it through the DLL project by
project--properties--Debug and setting the exe in the Start external program. In this case the break points were not hit, it kept saying the debug symbols not loaded. I tried all the options here without any success
Configuration was set to Active(Debug).
Debug Info was set to full.
In Tools--options--debugging(Enable just my code[Managed code] was unchecked)
In Tools--options--debugging--symbols, I had all modules,unless excluded selected and the Specify excluded modules list of empty. For some reason this method did not work.
The DLL has to have a debug database, or basically you have to include the DLL's solution in the solution you would debug it in.
Also visual studio has a Create Test feature which generates a bunch of test for methods and functions.