We Keep Coding

How to debug an exe with multiple dlls using breakpoints

I have a myapp.exe that after some complicated logic is run by another program. I wanted to debug the issues with myapp.exe just like visual studio preferably using breakpoints. What is the way to achieve this? The exe is a console application and is run on the spot. It's not a running process so I cant attach a debugger.
The expected behavior I would want is:
Do magic and set breakpoints for that exe and dlls
Call the exe from the other program
Visual studio hits the breakpoint and I can debug what is going on

Just use System.Diagnostics.Debugger.Launch() where you want to attach the debugger. You can place it just before your desired breakpoint location. Windows will ask you what debugger do you want to attach.
Another way is to check the System.Diagnostics.Debugger.IsAttached property and wait for the debugger like this (polling):
while (!Debugger.IsAttached)
{
Thread.Sleep(500);
}
The application will loop until you attach the debugger (in visual studio via attach to process command, Ctrl+alt+P ).
Again, just place a break point after or even in the loop and you're done.
This is a well know way used to debug a windows service application and can be useful also for your intent.

Debugging .NET Core in macOS

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.

C# program won't start outside visual studio as a .EXE

I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping

Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).

I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps

I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments

exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.

For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.

Cannot Run .NET C# Application Outside Debug Folder

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

WPF Application deployment - Problem with Application starting in another PC

All,
I have a WPF application built upon SQLite database and user/application Configuration settings. The application builds and runs fine in development environment. I created a Setup and Deployment project, added the "Project output" of above said application and then proceeded to create a setup. The pre-requisites and the .NET Framework versions are same in the Application and in the setup project:
.NET Framework 3.5 Client Profile
MS Visual Basic Powerpacks 10.0.0
Windows Installer 3.1
But when I move it onto another PC with identical .NET Framework installed (but without the development environment), the application does not start. It gives a "has encountered a problem and needs to close" Error. I found that this would mean a uncaught exception in the application. So, I tried to comment out parts of the application that did not have them handled and left all but a single window to display (the Main window that does nothing) but yet the application fails. I begin to suspect that the problem could be that the dependancies are not handled for the app start. Here is what I did with them:
SQLite needed a DLL that is automatically added to the "Detected Dependencies" It gets copied to the Application Directory
SQLite databases are added manually to the project and they are copied to the Application Directory
The Application.exe.config files are NOT copied. I am not sure where to put them
At this point, I would like to know how I can find out the root-cause for the problem. I tried running another simple app with a single window (and no functionality) and it works on the target machine. TIA

If you think the problem lies in the dependencies then it might be worth having a look at the "Assembly Binding Log Viewer" (i.e. fuslogvw.exe). This tool should be able to tell you exactly which assemblies were requested and how the requests were satisfied, or not satisfied. The catch is that this only works for managed assemblies.
If however you want to find out what the unhandled exception is then you could wrap a try .. catch around the application entry point. The catch in WPF is that this is generated by the compiler / Visual Studio so you can't normally change it. If you do want to change it, say to put a try .. catch around it then you need to (example taken from http://www.infosysblogs.com/microsoft/2008/09/how_to_write_custom_main_metho.html):
Find the App.xaml and App.xaml.cs files
Open the property page for App.xaml and change the build action to 'Page'
In App.xaml.cs add a Main() method which should look like:
[STAThread]
public static void Main()
{
var app = new App();
app.InitializeComponent();
app.Run();
}
If you wrap a try .. catch around the entire method body then you could write what ever the error information is to a text file. Hopefully that will help you find out what is wrong.
===== EDIT =====
If the unhandled exception is not being caught by the try .. catch construct then it can be a binder problem. Because the JIT compiler compiles methods on a as-needed basis it may help to move nearly all code out of the entry method. For example:
<!-- language: lang-cs -->
[STAThread]
public static void Main()
{
try
{
MyMethod();
}
catch(Exception e)
{
// ... Write to file here
}
}
private static void MyMethod()
{
// .. Do actual work here
}
By doing this you make sure that you are inside the try .. catch construct before the run-time tries to locate the right assemblies etc. However note that there are some exceptions that can't be caught (OutOfMemoryException, StackOverflowException and some others).

Have you considered using the ClickOnce deployment option for your application?
As you can see from this SO question it should be possible to bundle your SQLite DB with a ClickOnce application. You would get other benefits (if you are interested) such as automatic updates.

The problem also occurs if you changed the namespace of App.xaml.cs, but not of App.xaml. The moment you add the code above, you will know, since the InitializeComponent() call will not compile.