Develop Reference

Debugging a Project Assembly Which is Part of Another Process

I have a solution which contains multiple C# projects. One of these projects is an executable, the rest are DLLs.
The problem is, some of the projects do not actually run on the same process as the executable start-up project. This is because some of the projects are really extensions to a WCF service that allow the service to play with the executable.
My question is: is it possible in any way, shape, or form to set a breakpoint in said projects? I am aware of the ability to "attach to process", but I'm not sure it is a good solution for me.
I want to:
Be able to see the source as I break
Not have two copies of Visual Studio open if possible
EDIT: the only reason I am not sure of 'attach to process' would work well for me is because I have little experience with that feature - perhaps it is what I should be using? Can I still load .pdb files?
EDIT 2: If one of the commenters would like to submit their comment as an answer, I will accept

Attaching to the WCF service seems to be the exact tool for the job:
It allows you to attach to a running process, even if you've only got the code and PDBs for a plugin/extension for that process. You can set breakpoints in your own code and they'll be hit when the 3rd-party process calls them.
You can attach to any process from an existing VS instance, even if that instance is used to debug a different executable, in this case your main EXE project. You can start debugging your app, then attach to the service before making the service call.
Make sure, though that the DLLs called by the WCF service are the same ones as you have in your VS instance - if they're called from the same location as the VS build output, you'll be fine. If not, make sure they're in sync.

Setting up VS 2013 to debug a DLL

I have a C# solution with about 10 projects in it. It is a standard Windows Form application.
I have DLL in a separate directory that compiles fine and work so long as I move the DLL file into the executable directory of the main program.
Now I would like to add some functions to the DLL and debug it.
I have attempted to follow the MS help for How to debug from a DLL project but it is full of errors and cannot be used (3. where or what is the 'Project Property Pages window in the Configuration drop-down' for example).
http://msdn.microsoft.com/en-us/library/605a12zt.aspx
Is there a better reference for a first time user attempting to set breakpoints in a DLL?

I found the answer.
Ignore MS help (it is not)
Start a project with only the DLL in it
Add a project to that solution that calls the DLL
Make that new project the one that starts when you hit run
Its that simple.

Debugging VB6 project that calls a .Net(C#) dll

I have been stump in this problem for a few hours now. I hope someone has had a similar problem to this.
We have developed a prototype .Net(C#) dll using VS2010, and would like to be able to call this dll in a both C# applications and VB6 application.
My question is:
Is it possible to debug a VB6 application that is calling a .Net dll? I get an error message "Automation Error The system cannot find the file specified"
The error message suggests that there is something missing for my VB6 app to find the .Net dll.
I am aware that if the VB6 application has been compiled, and the .exe has been created, the VB6 will successfully call the .Net dll functionality when using the .exe
However it is important that we can debug through our VB6 application. Unfortunately debugging does not allow you to step over the line of code instantiating the .Net DLL's class object. I can't seem to do this.
NOTE: I have looked around forums and MSDN documentation and I mostly find solution for calling a VB6 dll in .NET; which is unfortunately the opposite of what we need to do.
NOTE: I have already registered the compiled .Net(C#) assembly, and referenced it in the VB6 project.
I have however found these two pages, which seemed to be what we need, but its a solution for calling a .NET(c#) dll generated using VS2005. This doesnt seem to work when the .NET(C#) dll was generated using VS2010.
site1
site2
If someone could give any suggestions or direct me somewhere I can get one, that would be great.
Thanks
SOLUTION
Thanks to #HansPassant, I have found the solution.
To debug a VB6 project that contains a C# .NET assembly, you need to register the .NET dll through both "regasm" and "gacutil", then make sure to close and reopen the VB6 application before you start debugging.

This is not a problem, VB6 uses its own debugger that doesn't get in the way of any other debugger, including the managed one for C# code.
You start from your C# class library project, ensure it is selected as the start project. Project + Properties, Debug tab. Select the "Start external program" option and enter the path to the VB6 IDE. Typically c:\program files\microsoft visual studio\vb98\vb6.exe. Set a breakpoint on the method you want to debug.
Press F5 and the VB6 ide will start running. Load or create your vb6 project. Note how you can add the path to the .vbp project in the previous step so it will automatically load your project.
Start debugging your vb6 project as usual. As soon as it starts using your [ComVisible] C# class then your C# assembly gets loaded. And the breakpoint will hit when your vb6 code calls the method. Switch back and forth as needed. Note that you cannot single-step from vb6 to C# code, you have to set breakpoints to get the debugger to stop.

Ah, the wonders of using .NET from VB6 in a debuggable manner.
in the VB6 project compile options (reached using the Options button on the Make Project dialog window), choose the Compile to Native Code, No Optimization, and Create Symbolic Debug Info options. Then compile your VB6 project. These options allow proper VB6 binary-to-source mapping.
Go to the Configuration Properties...Debugging property page of your solution and change the Start Action to launch your VB6 executable.
In VS Solution Explorer, go to File...Add Existing Item and navigate to the folder containing the VB6 source code you want to debug. Double-click on the VB6 source code file you want to debug, and a source window should open in VS that allows you to set breakpoints in the VB6 source code.
Make sure that your .NET library has a public default constructor. This is essential.
Now also set any C# breakpoints that you need. Do not step into the .NET code - this doesn't work.
When you start debugging with VS, your VB6 and C# breakpoints should be hit normally.

One approach is to debug each individually:
Debugging the VB6 code can be done in the IDE after compiling the C# DLL and adding it as a reference to the VB6 project.
Debugging the DLL with the VB6 host is possible in Visual Studio by compiling the VB6 project and using it in the project properties as the executable to run.
In some cases this is simpler/quicker than setting up the environment to debug both simultaneously.
This approach will require having at least the framework of each working beforehand.

How to debug the c++ dll from c# project?

I have created a visual c++ 6.0 dll project and using it from my c# code. Now i want to debug the dll but i am not able to do it.
I choose the following option to do it:
put the breaking point in my visual c++ project code.
build the dll and copy it into the directory of my c# project.
Now i build my c# project and dll works fine (method are calling perfectly).
Now i want to debug the dll.
I follow a blog and open the c++ project and choose the Attach to process from vc++.
but i am not able to find the running process of visual c# project, whereas it available at task manager process.
In my c# project solution i have two project i.e.
web service (i called the dll method at the time of accessing a url)
Another one is webform application which starts the web services.
Now please help me how should i debug my dll. I have followed so many blogs but all of them are focusing on Attaching process method which is not working in my condition. What should i do?

You'll need to enable unmanaged debugging, it is not turned on by default in either scenario because your main program is managed.
You do it in your C# project with Project > Properties > Debug tab > tick the "Enable unmanaged code debugging" checkbox.
You do it with Tools > Attach to Process by clicking the Select button. Choose the "Debug these code types" radio button and tick both Managed and Native. You may have to resort to only native if your process is 64-bit.
Set a breakpoint in the DLL's source code and be sure to write C# code that exercises the DLL function. If you still have trouble getting a breakpoint then use Debug > Windows > Modules and verify that you see the DLL in the module list. Get additional troubleshooting info by right-clicking it, select Symbol Load Information. Which shows a trace of where the debugger looked for the PDB file.

You can add C++ project to the your C# solution and add reference directly to the project (not dll), then you will not be needing to copy DLL. After that just start normal debugging (F5) of your C# project, and breakpoints will be working for C++ project too. This way will be very comfortable for debugging. I have tried such debugging and did not change any other settings.

VS Debug DLL invoked from system service

I am developing a DLL (in Visual C# Express) with some plugin logic for an application.
Is there any way to debug this DLL, once it get's used by the application? The application is running as a service on Windows, and it's a COTS application, meaning that it's not a C# project I can start debugging from.
I am aware that there are limitations regarding debugging in Visual C# Express. Is this task possible in Visual Studio Pro?
What I want to acheive is to be able to step through the logic, set break points to see what happends when the call comes. Any clues?

I am not sure about VS Express but, normally,
Open Visual Studio
Open your Solution (Windows Service Project)
Debug -> Attach To Process
Select your Service from Available Process List
You may use breakpoints and other stuff.
Hope it helps.

While I'm not entirely sure how this works with services specifically, you can set an arbitrary debug target.
In the debug panel (in project properties), you can set any executable or other command as the debug target. The process spawned by this command will have the debugger attached, regardless of whether where the executable came from. There are no requirements that the target be a C# project, or any Visual Studio project. This should be available in both Express and Pro. It's possible to attach to a later process (if you have a launcher), but that's probably beyond your current scope.
You then set breakpoints in your code as usual, and when the code is hit (regardless of whether your code calls it or the host executable), the breakpoint will be triggered. Depending on how much information you have about the host, you may be able to effectively debug it as well; even if you have no information, you'll be able to step through the assembly.
The only requirement here is that the target load and run your code. Depending on the context (plugin to a program, injected dependency, whatnot) this is of varying difficulty. The technique is used in a number of places, particularly plugin systems where you may not be able to debug the actual host, but still want to do so with your plugin.
Another, slightly uglier variation, is to force the host to break and self-identify. This is only useful for debugging, as it's very disruptive. The typical method is to show a message box (modal) with the process ID. The process will then be suspended until the message is dismissed, and a debugger can be attached. This becomes more difficult with services, although there are still ways to publish your information in a blocking fashion.

You could use the System.Diagnostics.Debugger.Break() method.