Multiple project visual studio solution won't debug one project dll - c#

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.

Related

Breakpoints set but not yet bound in library project

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.

Setting up a project for release in visual studio 2013

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.

Visual Studio 2010 Wont Load Referenced DLLs

I have been working on an ASP.NET project for months now without issue. Recently my computer crashed mid compile and now when I load and run the project I get 'Could not load file or assembly 'Ionic.Zip' or one of its dependencies.'
Thinking it was an issue with that particular DLL, I removed it as a test only to have the project say it could not load another referenced DLL, etc etc, until I had no references left...
Any ideas?
If nothing in the code has changed. "Build->Rebuild Solution" should do the trick (implicitly cleans and builds).
If this does not work, do "Build->Clean solution" and go delete all generated build folders (default bin and obj folders). And then try build and run.
And if it still does not work, the code has changed and dependencies are really missing.
Using NuGet and packages are missing perhaps?
I tried everything but NuGet, I didn't use it to get any of the references before.
In the end I had to check in all my changes to TFS, delete the project from my workspace and computer, and then reload it from TFS. Seems to have worked. Something must have been damaged in the project file.

Debugging a dll in c#

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.

How to debug a .dll?

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.

Categories