We are migrating a gigantic solution to .NET Core. It builds and works in Windows and we can debug using Visual Studio without problems.
In macOS, however, we can run it, but still not build it due to some issues.
In the meantime I was trying to think of a way to debug code on Mac. Why doesn't this work?
Add this to one of my DLL files
// Start of my application
System.Diagnostics.Debugger.Launch()
// The rest of my application
Compile that DLL file and use it, alongside the PDB file, to generate my new application.
Navigate to that part of the code in Mac
Nothing happens. Unlike in Windows where that code allows me to attach a debugger.
How can I properly debug a part of my .NET Core code?
Yes, you can!
Install Visual Studio Code and then, instead of running "dotnet run" in the Terminal as always, you can start your API by pressing F5 (make sure you are not running in the terminal at the same time!)
Make sure you put a breakpoint in a place where you are going to use, and then hit an endpoint (for example, Postman).
I have installed the plugin "C#" from Microsoft, but I don't know if that helps...
Alternatively, you can try Visual Studio for Mac, but I found that this works in Visual Studio Code and I prefer it!
On Windows, you have an opportunity to hook up a debugger when the process hits a 'first chance exception'. The default debugger is specified in the registry, and you can find more information in - Configuring Automatic Debugging.
I don’t think that is possible in Mac OS X. Have a look at How does one automatically attach a debugger to a process at process start on OS X?
Also, I tried your code on macOS:
using System;
namespace DebugConsole
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Calling Debugger.Launch");
Console.ReadKey();
System.Diagnostics.Debugger.Launch();
Console.WriteLine("Continuing...");
Console.ReadKey();
Console.WriteLine("Hello, World!");
}
}
}
This builds successfully, but when System.Diagnostics.Debugger.Launch() is hit, on macOS the process does not hit the debugger. On a Windows machine it does. In short, this code should not be the reason why your code does not build on macOS.
Update:
Use Visual Studio Code to open your code. Visual Studio Code asks you to add file launch.json for the debugging configuration.
It will also download the .NET debugging extension which is required for obvious reasons.
You can launch your console application from here, but if you want to launch the process for some reason in the background and then hook up to it then you can do that as well. On the top you will see the menu next to the 'RUN' menu - this has two options. 'Dotnet core launch' will launch the process through Visual Studio Code and attach to it. 'Dotnet core attach' will attach to already running process.
If you select the 'attach' option, it asks you for the process to be attached. Refer to the screenshot below -
Please note that you will have to put a breakpoint in the IDE. As mentioned above, the debugger does not enter debug mode based on the Debugger.Launch() function call.
Related
An architecture which I have to deal with is quite complicated:
a native C++ Windows Service creates an out-of-process COM object (native C++, CoCreateInstance with context = CLSCTX_LOCAL_SERVER) which dynamically loads (AfxLoadLibrary) my C# DLL.
I would like to debug my DLL when I click Debug -> Start Debugging.
I know that I can debug it when I attach to COM object process using Debug -> Attach to process and I can use System.Diagnostics.Debugger.Launch() in my DLL code if I need to debug startup but none of this options work automatically.
I also tried this technique: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/a329t4ed(v=vs.100) but the COM process runs as a SYSTEM user so that I cannot select my existing Visual Studio Solution with my C# project to use as a debugger, I can only start a new instance with only EXE loaded.
I tried "Start external program" too but what I need to start is a service which is not the process I want to debug, because my DLL runs in another process (the COM-one). So, debugging stops as soon as service is started (because I run it with a script, maybe this is a problem).
I don't see an option to automate it entirely with standard Visual Studio features. So I would propose you to write a simple Visual Studio extension. Just use the template and add a button to the menu or to some custom window, which on click will:
iterate through the running processes and wait until an instance of the dllhost.exe with your COM class guid on the command line, appears
when you find the process, attach to it using the Process2 interface (code in VB is available)
I'm not sure if it will help, but you may check my simple VS extension. I wrote it some time ago to configure symbols in the debugger.
I am trying to debug my DLL Class Library on Windows, but I am not able to get the debugger to stop in the source code.
Environment: Windows 10 Pro x64, Visual Studio Premium 2013 Update 5. Project is a .NET 4.5 Class Library. The executable is actually instantiated by another .exe before it calls my .dll. (I don't have source access to either of these .exes.) The .dll is in the same dir as its calling .exe, but that is not the Class Library project directory. I know my .dll code is executing, as I create new windows in my code, which are opening.
I have tried Debug->Attach to Process... in VS2013, and I connect to the calling .exe process, but the breakpoint I have set in my code never is hit, despite that code definitely being called. What am I missing here?
EDIT: This is not a duplicate of another question:
Not getting any error message
Not intermittently working
The assembly is confirmed as being loaded and executed
Your assembly might be compiled for release or compiled without any debug info. If you do things correctly, you should be able to debug by attaching to process. Another thing that can be, your code executes before you can attach to it. sometimes, especially in services, you put thread.Sleep into code, so this buys you some time to attach.
The issue turned out to be VS was not correctly figuring out what type of code to debug. In the Attach to Process window, I had to switch from Automatic to manually specify debugging Managed (v4.5, v4.0) code type in the Attach to: option, before attaching to the parent .exe process. I could then step through my source. (As it turns out, copying the .pdb file was not required - VS still uses the version of that file in the original project Debug directory.)
I'm having an odd issue with Visual Studio Community 2015. My program runs correctly inside the Visual Studio Editor, and it also runs correctly when the Application .exe is double clicked in the bin/debug/ directory. However, when the Application is run anywhere else on the computer (including the Release directory) the program does not run correctly. I am definitely copying all of the Debug folder to the location of attempted execution so it's not because of that.
When I run the executable, a loading icon appears on the mouse, in Task Manager it appears as a process using about < 500K RAM and stays there until reboot. No window appears at all, and it is impossible to end the process once it has started, meaning it cannot be deleted.
I'm using .NET 4.5.2 primarily however I've tried 4.5 and 4.6 and neither fixed the issue (I've checked and I have all 3 of them installed). I also tried copying the System DLLs locally and that didn't fix the issue either. I also tried creating a minimalist solution (below) containing a project that only printed "Hello World" and quit.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
}
This program experienced the same issues except it couldn't even be run within the Debug folder, only within Visual Studio. I then changed the project so it opened, then closed again straight away without printing anything so that it didn't use the System libraries at all, and it did the same thing. I then tried running the program in both 64 and 32 bit forced, (on a 64 bit laptop) and that didn't make a difference either.
I'm using Windows 7 Home Premium - Visual Studio Community 2015
Thanks for any help :)
Another possibility for such a rare issue could be your Anti-Virus program. Some of them like to inject an DLL into each created process to better protect you. But this can also lead to such awkward problems.
The only other way that comes to my mind would be to check the Event Viewer or run Process Monitor to get an idea where the error comes from.
Try using the release configuration and enable Break on all exceptions (Check Managing Exceptions with the Debugger for help on enabling the VS exception handling).
Hopefully this will break visual studio and show you enough information on the exception.
You can also try using Process Monitor to find the issue.
I would highly recommend using a simple hello world program to find out the root cause. My suspicion is on some corrupt .NET framework installation
That's because it's not the proper exe...
In order to get a proper working .exe for you App Right Click on your project in Solution Explorer > Go to "publish" tab > select Publish Now
(Now go to debug folder and find exe)
It will automatically open the "publish" folder which has files for install, but NOW go to your "debug" folder and you will find the working exe there and some other Visual Studio generated files releated to publish that you don't really need
~ ChenChi
I have an application that occasionally requires you to restart it after changing preferences. I do this by calling:
System.Diagnostics.Process.Start(Application.ResourceAssembly.Location);
That's great for the released version, but it's really annoying when I'm debugging and it relaunches the program outside the debugger whenever I need to change the preferences.
After some research, I've tried attaching to the debugger from code, but the very code I'm trying to run is running in the debugger already, and the application will be killed shortly. So I wrote an external program that can be called after relaunching the application (and freeing up the debugger) that supposedly attaches it to the debugger. Unfortunately this doesn't really do the job either. It appears to get attached to the debugger, but it doesn't actually let me do any debugging. It just craps out with an error if I try to pause execution.
Any ideas?
After more research, I realized all I wanted to do was programmatically hit the Restart button. I found this:
EnvDTE.DTE dte = (EnvDTE.DTE)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.10.0");
dte.ExecuteCommand("Debug.Restart");
Works great!
You may not be able to debug with your code if you are using a Process object and its Attach method from the EnvDTE namespace rather than the Process2 object and its Attach2 method from the EnvDTE80 namespace. The following snippet should work:
foreach (Process2 process in Dte.Debugger.LocalProcesses) {
if (process.ProcessID == processId) {
process.Attach2();
Dte.Debugger.CurrentProcess = process;
}
}
May also be of interest here: the Visual Studio team has released a Visual Studio extension that allows automatically attaching child processes to the current debugger: Introducing the Child Process Debugging Power Tool.
It is available on the Gallery for Visual Studio 2013 and above.
I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.