I have two VS solutions. Solution A_sol is C++/C# projects. Solution B_sol has project B_proj that is C# wrapper around C++ *.dll generated by B_proj project in A_sol.
How do I debug A_proj from B_proj ?
UPDATE: one of the projects in B_sol is an executable.
How do I debug A_proj from B_proj ?
If I understood you correctly, A_proj is a C++ project. Below I will give my advice based on this assumption.
Note that it doesn't really matter from which project/solution you start debugging as long as you have the debug info (in other words, for C++ projects - if Visual Studio is able to pick up PDB's).
So you may either run your executable from the solution, or, as suggested by #hoodaticus in his answer, attach to the process which is already running. Whether your project is executable or not, you will be able to attach to it as long as:
DLL is loaded into that process
You have the PDB file that matches the DLL (generated during the build)
So I'll just repeat the same advice
In the other project, do Debug > Attach to Process > pick your process
from the list.
but I'll add that you have to pay attention to select "Debug these code types -> Native" for the process that contains your C++ dll. This part is often missed and confuses people, taking some time to discover (personally, I often get into it)
Hope that helps.
Run the process you want to debug outside the debugger.
In the other project, do Debug > Attach to Process > pick your process from the list.
To be able to debug by pressing F5 (rather than having to pick your process each time),
Right-click the startup project (the EXE) and choose Properties
In the Debug tab, select Enable native code debugging
The above steps are from this tutorial: https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-managed-and-native-code?view=vs-2019
Related
after compiling a simple console application project for release I get a lot of output:
The .exe => thats fine, I need this for sure :)
MyApp.exe.config => Im using and changing this, thats fine
Some .dll files => these are the extern libraries Im using, I think thats fine too
Unknown:
MyApp.pdb
MyApp.vshost.exe
MyApp.vshost.exe.config
MyApp.vshost.exe.manifest
log4net.xml => huh, the config for log4net is already in MyApp.exe.config, why is another log4net config xml here?
Can I delete some of them without getting later trouble? Can I add the .dll´s somehow into the .exe (so that I dont have to copy always all the .dll with the .exe)?
This is expected, and all have purposes - but you are right: you don't need any of the "unknown" files, and can delete them (and certainly don't need to distribute them). For info:
MyApp.pdb is the debug symbols; useful for stacktrace, and for debugging later if problematic; you can disable this via the Debug Info option in the Advanced Build Settings dialog (Project Properties, Build, Advanced...) but I don't recommend it
MyApp.vshost.* is the debugger host process; you can disable this by disabling the "Enable the Visual Studio hosting process" option (Project Properties, Debug)
log4net.xml is the intellisense comments - useful for IDE usage when adding references
Those files aren't meant to be distributed to client pcs nor are useful for app to work properly: they're there (also) for debugging purpose.
If you want to "merge" dlls to your project, try using Microsoft utility ILMerge.
When you build your solution in release configuration there will be no *.vshost.*., this is an executable for debug hosting process.
log4net.xml you can remove, I believe.
You should be fine deleting/not deploying most of them.
If the dll's are managed assemblies you can use IlMerge which will add the dll's into the exe for you.
I'm using VS2008 to compile my C# Console App. When I release my app, I have to delete lots of what appear to me to be superfluous files. For example,
MyApp.vshost.exe.manifest
MyApp.vshost.exe.config
MyApp.vshost.exe
MyApp.pdb
How do I prevent these files being copied into my Release directory? Oh, I'm using Reshaper also - if that makes any difference.
To remove the PDB file, just turn off PDB generation in the project settings. (Go to the Build tab, Advanced, and set "debug info" to "none" - if you're really sure you don't want the debug info...)
The VSHOST files are to allow Visual Studio to host the executable in a reusable process - basically this is a way of restarting the app quickly within Visual Studio. To stop them from being produced, again go into the project properties, this time in the "Debug" tab, untick "Enable the Visual Studio Hosting Process" option.
I suggest not to remove those files from your Release directory. Instead, create a separate folder (let's call it Deploy) for the files you really want to deploy, and make a script fillDeploy.bat which copies exactly the needed files from Release to Deploy. This script can do some additional things for your deployment (for example, put the documentation files there, provide a different config file etc). If you want this script to be called every time you make a Release build, add a postbuild event to your project like this one:
if $(ConfigurationName)==Release call $(ProjectDir)fillDeploy.bat
Inside the Properties of the project you are building you can configure these things. The exact place of the options varies from version to version of Visual Studio. Start in the "Build" tab and then look in the "Advanced" area.
I have a project in c# which uses bindings to use some c++ code. The c++ code consists of multiple DLL's which are compiled using a makefile. Currently I'm trying to run the makefile using a pre build event which calls nmake. However to get it to find nmake I need to have a line in it like the following:
"$(DevEnvDir)..\..\VC\vcvarsall.bat"
Also, even with that line present, nmake doesn't produce any output at all in the output window. Neither does it throw any errors. I tried redirecting the output to a file and it doesn't write anything. I have reproduced all steps in my pre build event in a normal shell and it works fine. I figure I must be missing something. Why doesn't Visual Studio give me a Visual Studio shell for my pre build event? Is there a better way to run this makefile? If not, has anyone got any ideas as to why nmake isn't producing any output?
EDIT: D'oh! nmake wasn't running as I forgot to add 'call' to the start of the line, i.e:
call "$(DevEnvDir)..\..\VC\vcvarsall.bat"
I often build non VS-project (sometimes with nmake, sometimes with other build tools) as a part of a larger solution build.
I tend to make a simple batch file, which sets up the environment and then runs the make.
I call the batch file from a build event (often post-build on my stuff) - usually with a CD on the front:
cd ..\.. && armbuild
Never (that I can remember, anyway) had any problem with the output appearing in the console window.
I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.
Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct
In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.
There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.
I have a Visual Studio solution with four C# projects in it. I want to step into the code of a supporting project in the solution from my main project, but when I use the "Step into" key, it just skips over the call into that other project. I've set breakpoints in the supporting project, and they're ignored, and I can't for the life of me get it to step into any references to that project.
Everything is set to compile as "Debug", and I've seen Visual Studio warn me that my breakpoints won't be hit before - it doesn't do that in this case. It's as though it looks as though my code will debug, but then at run-time, there's a setting somewhere that tells Visual Studio not to step through the code in that project. All the other projects in my solutions debug without problems.
What box have I checked to cause this behavior?
UPDATE FOR CLARITY: The "Just my code" option is currently disabled. Also, since the code belongs to a project in my same solution, I don't think the "Just my code" option applies here. I thought it only applied to pre-compiled code that I didn't have the source for, but since I have the source in my project, I don't think this option has any effect.
Not sure if this is it, but "Tools>Options>Debugging>General:Enable Just My Code" is a possibility. (I prefer to always leave this unchecked.)
It turns out that the assembly needed to be copied into the GAC before it could be debugged. Under the debugging option "Just my code", there's an option to suppress an error if you don't have any user code, and it was suppressing the following error:
The Following mobile was built either
with optimizations enabled or without
debug information. (Module name and
path) To debug this module, change its
build configuration to Debug mode.
Since I was building it in Debug configuration, I searched on that error message and got this:
http://claytonj.wordpress.com/2008/01/04/the-following-module-was-built-either-with-optimizations-enabled-or-without-debug-information/
Problem solved. I don't know why it needs to be in the GAC in order for me to step into the project, but it does. I don't ask why, I just ask how, and then I do it...
One thing to check for is that your supporting project assembly has not been installed in the GAC. Open a command prompt and run the following to make sure...
gacutil /l assemblyName
You need to ensure the supporting projects have pdb files or else Visual Studio will not have the necessary information to step through the code.
If you have the source code for the dll's into which you are trying to step into, do the following:
Click on the project in which these dll's are added as reference and remove them.
Add the Project(s) corresponding to the dll(s) to the solution
Right click on the project -> Add Reference -> Choose the newly added Project(s).
Now set the break point and debug the code.. You will be able to step into the code.
The reason for the issue is because you program is still referencing the old dll (without the source code) as it has been added to your project as a reference. Once you remove that dll and add the Project (Source code of the dll) of the dll, Visual studio will be able to step into your code.
A couple of possibilities:
There is a check box to step into "just my code". Its intent is to make it so you can't step into Microsoft's Framework code (unless you choose to by unchecking the box).
You might try recompiling the supporting code to make sure the code you're debugging exactly matches the code file you're looking at. VS does care about this and will disable a breakpoint if you put it in the code file whose version doesn't match. Also, make sure the PDB file is in the same directory as the DLL.
In Visual Studio 2013 one way to cause this behaviour is to set build configuration to Release.
Put it back to Debug and see if that helps.