I have a .dll attached to my project(I made the .dll). I have in the .dll project configuration set to "Active (Debug)".
I even deleted the .dll then added break points to the .dll code and rebuilt it and added back to my project and I still can't go inside the .dll and debug it.
I not sure what I am missing?
Place a breakpoint on the consuming code that calls into the .dll. When your project breaks there, step into the call (F11, by default).
Otherwise, I'd strongly suggest importing the project from which the .dll is built into the solution of the project that is attempting to consume it. This is the arrangement that makes VS happiest and causes the least headaches from versioning, switching between solutions, etc.
You'll have no difficulty debugging then.
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 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'm working on a C# project that is nearing release. As part of this, I have started building the project and testing it on another machine. This has revealed some odd problems. My biggest concern, though, is that my project is failing to run. I can do some basic things, but when I try to use my projects primary functionality it crashes. Using Visual Studio, I was able to determine the exception that was causing the crash.
Essentially, I'm getting a FileNotFoundException on the dll that contains most of my project's functional code. I'm not sure if I've made an error in adding the dll to my project, or if there's a problem in one of the files in the dll.
The dll was added as a reference using the Project -> Add Reerences feature of the user interface.
The dll contains three files which contain absolute file paths (these are for #import statements). Example follows.
#import "C:\Users\Me\Documents\Projects\MyProject\Delegates\bin\MyDelegate.tlb" raw_interfaces_only
My hang up is I'm not exactly sure what I'm doing wrong here. I suspect that those import statements are causing problems, but I'm not exactly sure how to fix them if they in fact are the problem. This is my first c#/c++ project so any help would be appreciated.
Adding the dll as a reference DOES NOT include the dll with your project--you are simply telling your project to use the library for your code. The dll will need to be installed on all computers that run your application, for your application to use the dll.
If the dll also uses three files (as you specified), then those files must also be included, and be installed in the expected path.
Presuming you have redistribution rights on the dll you mention, you can include the dll in your project. Be sure to set the "copy" property as "copy always" or "copy if newer" and change the reference to use the copy that ends up in you bin folder. Then you only need to be sure to include that dll and install it in the same folder as your application.
I have a VS2012 solution with a VS2010 C++/CLI project that depends on a VS2012 C# project. When I build the C++/CLI project it ALWAYS builds the C# project even when no changes have been made to it.
Looking at the DbgView output using the method here I see the following message:
Project 'H:\Workspaces\xxxx\ProjectA\ProjectA.vcxproj' not up to date
because 'H:\WORKSPACES\xxxx\ProjectB\BIN\X86\DEBUG\ProjectB.DLL' was
modified at 06/02/2014 13:05:30, which is newer than
'H:\Workspaces\xxxx\ProjectA\bin\Debug\ProjectA.lib' which was
modified at 06/02/2014 13:05:29.
Where:
ProjectA is the VS2010 C++/CLI project
ProjectB is the VS2012 C# project
Under Common Properties >Framework and References I have the following settings:
Copy Local False
Copy Local Satellite Assemblies False
Reference Assembly Output True
Link Library Dependencies True
Use Library Dependency Inputs False
What's causing the the DLL and the LIB file to have different timestamps? Is there anything I can change in my settings to prevent this?
Project 'H:\Workspaces\xxxx\ProjectA\ProjectA.vcxproj' not up to date
That explains why your C++/CLI project gets rebuilt. Doesn't have anything to do with your C# project. And of course it is getting rebuilt, its dependencies changed.
You haven't yet found the trigger for your C# project getting rebuilt. Look backwards.
Do avoid these outdated C++ build logging hacks. It is not your C++ project that is the problem anyway. Favor changing the MSBuild verbosity to Detailed. Tools + Options, Projects and Solutions, Build and Run. And focus at the output that shows you why the C# project needs rebuilding, that's the one you care about.
Not a direct solution, but a close second. Try installing .NET Demon from Redgate.
Do you have pre-build events set in the ProjectB? This also could be causing this error.
If you know you will not be changing ProjectB or you know that changes will be rare, you can just try and remove it from build in the properties of the solution.
Does this help at all?
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.