I'm having a difficult time finding the right keywords to search on for this. I'm simply trying to figure out a way to debug an executable file that was created by my application. I just created an executable file from my application that contains some encrypted stuff which starts my application when double clicked, that my application uses for certain things. Is it possible to run that executable program that starts the application, and debug the entry into visual studio? I need to verify that the encrypted data is decrypted properly in the application, and the only way to verify this is with debug, or writing to an output file the decrypted information. I'd rather just debug, so I don't have to remember to take out the code that produces the outfile.
Thanks in advance!
Make sure that you application is installed with the .PDBs in the directory with it.
In visual studio, load the solution containing your application.
After you have started the app by double clicking on the associated icon select debug| attach to process ...
Select your process.
If you application is going right into action you may have to add a thread.sleep(10000) (or show a modal dialog) to give you time to attach to the start while you debug - remove it when done.
Related
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.
Seems like a simple question but I am facing some weird problems.
I am using Visual Studio 2015, Enterprise Edition and Install Shield to create setup of my software, this is my first time making a general purpose software. Everything goes according to plan but I get these 2 problems.
Problems are:
Shortcuts don't work
Application doesn't launch until I run from root directory as admin
Problem 1:
I create the setup and do everything asked, I put the primary output into setup, which by the way contains 2 files. the .exe file and a .config file and I choose the primary output in "add" button to create a shortcut but when I install that setup, the Desktop shortcut doesn't work, in no way.
Problem 2:When I simply double click on the software's main .exe file, it doesn't run. No response but when I run it as Admin, it responses and opens. The problem is weird cause this doesn't happen in debug or the release files of the software.
Is there something I am doing wrong? maybe the way I insert the primary output?
This doesn't appear to be an installation problem. Your statement "..when I run it as Admin, it responses and opens" means that your program requires admin privilegs to run correctly, and running it from a shortcut does not automatically run it as administrator. The usual way to say that a program needs elevation when it runs is to give it an elevation manifest as here:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
with requireAdministrator. The program will then show the standard dialog requesting elevation.
The most likely reason for your program doing nothing when it fails is that it silently crashes and goes away, and that's probably because your code isn't explicitly making sure that everything you do is actually working. For example, if you try to create/modify a file in Program Files (and you're not elevated) it will fail, and your code should check that access was denied.
I have the following issue and hope that someone might help me to get it sorted.
Every time I run my C# Win Forms application for the first time after starting up VS 2015, and stopping the application again, I cannot change any files as they are all locked.
Steps:
Open/Create new windows form application.
Run the application.
Close the application.
Try to edit anything in your project (fails with the following error: The file C:\Users***\documents\visual studio 2015\Projects\WindowsFormsApplication1\WindowsFormsApplication1\Form1.Designer.cs cannot be modified at this time.
[
I can see on the Form tab that it shows a lock.
[
At the moment the only way I can get past this is to close VS and open it again every time I want to make changes to my project.
Hope someone can help me.
NO, if this is the case then go ahead and check in Task Manager for a process called devenv.exe. there will be an already existing/running process present which is blocking/locking your project files. In other words, not all instances of that process is been ended, else you would haven't seen that red lock button in Visual Studio.
I use windowsform application using C# language, I have many forms, and when I want to traverse from one to another, I use this.Hide();
When I use this method, I receive the shown error,
I know that the solution is to end process using windows task manager, But the question is that Is there any way I can use travel between forms without leading to this error?
Error 9 Unable to copy file "obj\x86\Debug\WindowsFormsApplication1.exe" to "bin\Debug\WindowsFormsApplication1.exe". The process cannot access the file 'bin\Debug\WindowsFormsApplication1.exe' because it is being used by another process. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 2868
Easy going solution is to add some code in Project Properties..
Just go to Project tab and select project properties..
From there select Build Events tab.
And in Pre-build event Command line add the following code..
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Although you Hide() your forms, they still remain as a part of the process. If you don't close every form properly, the process will remain running and you cannot recompile your project and eventually you will have to kill your process using the taskmanager.
Visual Studio tries to rewrite your executable and if the executable runs as a process, Windows will refuse to write to your .exe.
Just delete the .exe file in the bin folder: bin\Debug\WindowsFormsApplication1.exe
Don't worry, the build will create a new one.
I believe this is happen while you compiling the application or you start debugging the application.
This may be due to.
While you stop the debug in VS, the process may not be stopped.
May be you just executed the application, by double clicking it.
Might be some issues due to permission. If you are using source control, some folders may be treated as read only while downloading the project. So you need to edit that manually.
Make sure that you used Application.Exit() to exit from all the process.
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.exit.aspx
I finally how fix it. Why we can't continue debug after the first debug because the first debug exe still running. So that, after first debug, you need to go to Task Manager -> Process Tab -> [your project name exe] end the exe process.
close visual studio
in windows 7
click Shift + Ctrl + esc
in Tab processes
find process like the name of your project and end it.
I managed to fix it by deleting the suo file (hidden solution file).
Simple method is to delete the .exe file from the project directory folder and build the project again. this will create new exe file and problem will solve.
I am having great difficulty getting a Windows program, written in VS 2008 C#, to launch another type program. I've put a main program to offer you the ability to launch some other VS 2008 C# programs. When one of them is selected the following code is intended to do the launch:
System.Diagnostics.Process.Start(#"C:\Documents and Settings\rat\My Documents\Visual Studio 2008\Projects\PV_002_082708\PV_001\PV_001\bin\Debug\PV.exe");
It works, but each user will have a different path. The path shown is for my computer. The code would have to know where each persons program was installed! In the past, I could easily call a program that was in the C:\Program Files location because that's where the MS Package & Deployment program put the programs. VS 2008/2010 doesn't put them there!
I'm sure I am not knowledgeable about Visual Studio 2008/2010 to know if there is a way around this, so any help would be greatly appreciated.
System.Diagnostics.Process.Start(System.Io.Path.Combine(System.Windows.Forms.Application.StartupPath, "PV.exe"));
assuming that the program is in the launched application's path.
or...
System.Diagnostics.Process.Start(System.Io.Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.MyDocuments), #"Visual Studio 2008\Projects\PV_002_082708\PV_001\PV_001\bin\Debug\PV.exe"));
assuming you want to open the project from it's place.
Once you create the installation package you can set the install path to some fixed path that users will not be able to change and than use that from your code (not very user friendly but it would work) or insert the user chosen path value into the registry and get it from there instead.
May want to have a look at this thread. How-to as well as lots of pro's and cons.
Embedded a *.exe into a dll
If you see the first answer to his question, I think this would work for you.
Simply he is saying, you add a resource file to your project, then when the user runes your program, it extracts your exe file that you added as a resource file to somewhere you know on the end users maching.