I have a C# class library which I also use via COM Interop. To test the library I added a C# test app to the solution, set it to the startup project and I can test it that way. The library works fine this way but one function is not working when called via COM Interop from a Visual C++ 6 test application. How do I debug the library in this situation? I searched for a solution on Google but the only advice I can find is to add a test app to the solution which of course I can't do in this situation.
EDIT: Very sorry. I forgot to say the Visual C++ test application is Visual C++ 6.
First, open boot Visual Studio and Visual C++. Start your test application in VC++. After that, in VS, open the Debug menu and choose the Attach to process. This will show you a list of current process that are running, choose the one corresponding to your test application and click on Attach. This will enabled you to put breakpoint and debug your DLL.
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!
There is an external application that executes C# libraries(plugins - my class library).
Is it possible to attach debug to my class library project in Rider.
In a Visual Studio, this is done very easily. For example, as described in this article. But how to do it in a Rider?
Thank you
Now you can use .NET Executable for your task. Put your library as command-line arguments into a run configuration. In the future, we want to add the macro for OutputPath.
I am developing a .NET core (.NET Standard 1.6) application in VS2015. The application calls C++ code via P/Invoke. Now I need to step into the C/C++ code of my native dll project.
In regular .NET application, by enabling unmanaged code debugging in the property window of the application, we can step into the C/C++ code directly:
But I can't find such option on a .NET core project. And I know that I can attach the debugger to the application to debug native code only, but that's not suitable for my case.
Again, I want to debug from managed C# code into native C/C++ code.
Any ideas?
Maybe I should switch back to .NET Framework so I can debug the native code. It's really hard to debug by printf. :(
UPDATE
The mixed mode debugging, i.e. debugging from managed C# code into native C/C++ code, has been implemented. See Tutorial: Debug managed and native code in Visual Studio.
UPDATE
The feature may have already been implemented, see this.
Just as #cynic said, this is not yet supported now (2016-11-1).
That can be verified by following steps provided by cynic.
Put a pause in your program (e.g. a Console.ReadKey call).
Attaching to the dotnet.exe process selecting "Managed (CoreCLR)" and "Native" code types
You'll get a message box stating explicitly that "Interop debugging is not supported".
Here is a proper way to debug the native dll.
Right click on the solution, Add Existing Project
Open 'dotnet.exe'. This is normally installed to 'C:\Program Files\dotnet\dotnet.exe'.
You should now see another node in solution explorer for dotnet.exe. Right click it to bring up project properties:
Change the working directory to be what you want
Change the arguments to be the path to your built dll
Change the exe project to your startup project
RECOMENDED: Go to Tools->Options->Projects and Solutions->Build and Run, uncheck 'Only build startup projects and dependcies on Run'
I am trying to create a VS extension and I need to know the currently executing project (for example, if someone is building a Xamarin.Android app and they have deployed it, I need the Xamarin.Android project). Further, I need to know the output directory of that project (so I can get some binaries from it). Can anyone help me with this?
I've tried using IVsSolution, and DTE2 (among other related things), but haven't found anything that tells me what is currently running.
Thanks
To know the output build folder of a project using automation (EnvDTE.Project), see:
HOWTO: Get the output build folder from a Visual Studio add-in or macro
To get the solution startup projects using automation see:
DTE.Solution.SolutionBuild.StartupProjects
Native VS services are somewhat more limited in this area than automation:
IVsSolutionBuildManager.get_StartupProject
The EnvDTE.Debugger object has properties to get the active process, etc:
Debugger Interface
I have been trying to monitor video memory for a highly performance intensive program.
So I used the NVIDIA CUDA libraries in a C++ Visual Studio Application to collect the data I need.
Unfortunately I need a package that can be used with Ruby, C# and the Software Testing tools my company has.
So I decided to compile a C++ DLL and import it into a C# Visual Studio Project for testing.
I was able to compile the DLL but importing it into my Visual C# Program has been an issue.
I right Click on References -> Add Reference. Then I click on the Browse tab and browse to the location of my DLL; "TestProgram.dll" and I click "OK"
Then I get the following Error message "A reference to C:.... could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
What I have tried so far:
1. Importing the DLL from several different locations on my system.
2. Moving the DLL into my Solution Explorer and importing it
3. Using the "Invoke" method: [DllImport("PathToMyDll")]
4. Using the "Invoke" method with just my dll name.
5. Typing 'using' path to my DLL
6. Exporting the dll as a .lib file instead
What am I doing wrong? I thought that if I exported a DLL using Visual Studio 2010 then surely that same DLL could be Added into a Visual Studio 2010 project.
Well, is it a valid Assembly or COM component? Just because it's a C++ DLL doesn't mean it can be used with just a reference, in fact, most can't. It needs to be a managed DLL or a COM object. If it's none of those, then you have to invoke unmanaged code from a managed assembly. That means defining each function in a stub.
More info here: how to call a C++ dll exported function from c#
Be aware, you also have to deal with 64/32 bit issues, since if the DLL is compiled for 32 bit, you can't use it in a 64 bit application.
I found the solution to this problem. CUDA creates a Windows Console Application project. So the solution was to just use that instead of a DLL.
This worked well because Ruby, Test Complete and Visual C# can read the output from a basic .exe console program (with some work).
The compiled exe is simple. All I need to do is pass in an integer as an argument when I launch the program and the program will get the data I need from my NVIDIA card.
The challenge now will be finding a good way to interface with the .exe.