I have a Visual Studio 2010 solution with a few projects, one of which compiles to a DLL and defines an interface to create a plugin. All these projects together make up a standard product.
Now, a have created another solution with a single project, that references that DLL and implements a plugin.
When debugging, I am running the standard product and load the plugin during runtime. Of course, I can debug all the code of the standard product, but how can I debug the plugin code?
It was way easier than anticipated. I just opened the .cs file I wanted to debug in the solution with the standard product and I could put a breakpoint there.
All in all, it Just Worked™ and I never tried this, because I thought it wouldn't.
Related
I'm quite new to VS Code. I have been debugging DLLs for 3rd party applications earlier in Visual Studio but it seems all the tools available there are not available in VS Code.
What I have been doing in VS earlier is:
create, develop and build my DLL to the plugins folder of that 3rd application (with references to the 3rd party application's libraries)
add the 3rd party exe as another project and set it as startup project.
when starting debugging session, VS automatically launches/attaches to my dll, i.e. I can step through my code when I start the plugin inside the app.
I am able to successfully build the DLL in VS Code to the correct folder and it works (will show me the simple msgbox i am waiting for). However, when I try to debug it by attaching the debugger to the 3rd party app process, the debugger does not stop at the breakpoints. When I hover over the breakpoint during debugging (which is not red anymore during debug), I get the message "No symbols loaded for this document". I guess I'm doing something wrong. The .pdb for the DLL is in that plugins directory. Is this because the debugger does not find it? Honestly, I'm not very well in with the launch.json contents yet (no need to work with those in full VS). What is the best way (if any) to do this kind of debugging in VS Code? In case this is something that definitely can't be done in VS Code, please let me know, so I know I need to return back to full IDE.
It turned out I just had some issues in my launch.json. I am now able to step through my code and the UX is practically the same than that with full VS. Problem solved.
#vernou Thanks for the link anyway!
I have four different solutions: two C/C++ libraries, a C++/CLI wrapper which uses those libraries and a WPF project.
How can I debug my libraries when they are called by my WPF Project?
When you want to debug anything you call that is outside your solution, you need to help Visual Studio find the debugger information. If you just link to a library it can run code but you can't do step by step debugging becuse you're only linking binaries and not source code.
For debugging external libraries, you need two things:
link the library files compiled in debug mode
tell Visual Studio where to find the .pdb files (which contain useful information for debugging).
To make sure the .pdb files are loaded correctly, you can go in your project options then Debugging->Symbols and then select the directory where the .pdb files from your library are. Visual Studio will put the .pdb files in the release directory usually (default settings).
Important note: that since you are using a wrapper over the libraries, you need to make sure that the wrapper itself is also doing this (or you will only be able to debug the wrapper).
There was already a bunch of questions like that but how do I make a stand alone .exe file in Visual Studio C# Express? There is no setup and deployment tab/bar in here.
I've pressed that "Publish projectName" but not sure if that is right. There is a bunch of other .exe files in bin\Debug and bin\Release. Which one do I need and is this actually correct? My project is WinForms C# app, nothing too fancy. Need to make sure it works on other computers.
Thanks in advance.
Take that with the same name as your project. So if your project is names MyWinFormApp, you need MyWinFormApp.exe.
If there is nothing like MyWinFormApp.exe in bin/Release than you probably did not built your application in the release mode. However, if you succeeded to build your application in a debug mode, there should be a MyWinFormApp.exe file in bin/Debug folder.
You can find MyWinFormApp.vshost.exe there as well, but that is not what you want. It is just some helper executable for a compiler.
Also, make sure that if your application uses any other libraries which are not part of the .NET framework you have to ship them along with the exe file as well in order to make it working on another computers.
I am trying to learn to write my codes in libraries and compile them into DLLs in C#.
This is what I do:
I have a main VS project in which I piece up the different parts of the application that I am writing.
I write my classes in separate VS projects. Then, I compile them into DLLs, which I will copy the DLLs to the main VS project. The main VS project will make references to these DLLs and then use them in its logic.
The problem, however, is that when there is a bug or issues with the codes compiled in the DLL, it becomes very difficult to debug. The compiler won't tell where exactly the error came from. Also, when I make changes to the classes resided in the DLLs, I have to always recompile and replace them when working on the main VS project.
My workflow becomes very obtrusive this way. What should the correct workflow be when working with DLLs?
Add the DLL project(s) to the solution file which contains the main project and you will be able to break into that code with the debugger (right click solution -> add existing project).
I'm toying with my first remoting project and I need to create a RemotableType DLL. I know I can compile it by hand with csc, but I wonder if there are some facilities in place on Visual Studio to handle the Remoting case, or, more specificly, to tell it that a specific file should be compiled as a .dll without having to add another project to a solution exclusively to compile a class or two into DLLs.
NOTE: I know I should toy with my first WCF project, but this has to run on 2.0.
You can get away with just calling csc.exe on the pre-build event if you don't want to mess with the .proj file directly and add build events.
None that I know of using VS 2008 at the moment.
But you might want to check out NAnt. It is made for this kind of work.