We Keep Coding

mySolutionName.exe file deleted from /debug directory. How to restore or rebuild?

I'm new to c#. Antivirus deleted the mySolutionName.exe file out of the /debug directory and now I cannot execute my code. I'm concerned that anything I do may make the issue worse.
When I press F5 I get an error of:
CS2012 C# Cannot open for writing --> C:\Users\me\source\repos\MyApp\MyApp\obj\Debug\MyApp.exe''
Can someone please tell me how to rebuild the file so that I can continue developing?

after your edit:
Your program is probably still running outside of the debugger.
You need to use the task-manageer to kill all instances of MyApp.exe if this doesnt solve your issue a reboot should do the trick as well
So why is this happening?
Most liky your application is somewhere stuck on a blocking function or in a never ending loop. maybe there is even a seperate thread still operating that you forgot to close. We lack some information to tell yout that for sure. But to find out what is happening you can close your window while running in debugger mode and see if the application properly closes. if it doesnt you can hit pause and see where the program is stuck and resolve this issue by ending the task/loop/whatever in your OnClosing function of your window.

A good way to solve this issue is looking which process currently accesses the file.
A tool to do that is Microsoft SysInternals Process Explorer. It has a feature called "Find handle or DLL ..." which can be accessed by Ctrl+F.
The result will show the process which accesses the file. You can then judge whether it's Antivirus or something else that prevents you from writing to the file. If possible, you can then take an action in that program to release the file.
Example: a program is accessing my powerpoint presentation, which has the term "Schulungen" in its file name.
Process Explorer figures out: it's open in Powerpoint.exe, so I can simply close the file in Powerpoint - problem fixed.

breakpoints and processes

I have a bit of a strange scenario that I can't figure out. I have some c# code that will start another process using 'process.start()' The process in question is a custom tool I have written so I have full access to the code. Is there a way that I can use breakpoints in this 'custom tool' process? I know how to do it with 'attach debugger', but that is a manual approach as opposed to an automatic one. Is this sort of thing possible?
EDIT:
I suppose I could just launch the remote debugger process instead of my 'custom tool' ?

What exactly do you mean when you say "use breakpoints"? Do you want to attach debugger automatically on process startup?
Have you looked at ImageFileExecutionOptions registry key? It allows you to set a debugger that can be automatically attached to a proces when it starts up.

VS 2010 - Error when opening User Control / Form with Designer

C#, VS2010, WinForm application:
Sometimes I do have the problem that I get an error message when opening some of my controls / forms. All code compiles and the application runs properly. Opening the control in the designer gives me:
The designer loader did not provide a root component but has not indicated why.
From my experience I can tell, it is usually something in my code which does not get properly initialized, e.g. a property is not set which is somehow available at runtime, but not when opened with the designer. The only issue is, that the root cause is hard to find.
Q: Is there a chance to somehow use the debugger when the designer opens my component in Visual Studio 2010? That would help a lot and the problem tackling is most likely a matter of minutes then.
Remark: Just to make this clear, I know how to use the debugger ;-), I only have no idea how I could tell VS2010's designer to open my control in Debug mode.
As of 2nd SEP 2010 added:
Thanks for your help. Basically it is the MSDN Library article describing how to do it.
I have managed to set it up and run the second instance
(there was not much to understand how to do it).
It only fails in my case, because the 2nd VS2010 instance (debugging Design Time) fails to find the
symbols for my custom control. I have added the symbols manually under Debugging / symbols. No
result, still "Breakpoint won't be hit because of missing symbols"
BTW, using this approach it is helpful to exclude some stuff from the symbol loading (via modules window), because this will safe a lot of time.
Now if have to figure out how to get the symbols resolved and then I can tackle the issue.....

The vast majority of design time problems with custom controls are caused by code in the event handlers or method overrides in your control running at design time as well as run time. That's normally desirable, you get instant feedback when you change a property in the Properties window for example.
But not desirable when the code depends on something that's available at runtime but not design time. Like a dbase connection or a file that's stored in the build folder. That can generate exceptions and Visual Studio isn't very robust against handling exceptions at design time. Worst case, you can crash VS to the desktop without any diagnostic. But anything is possible.
Review the code in your control and make sure that the bits of code that should only run at runtime are wrapped like this:
if (!DesignMode) {
// etc..
}
Hard cases can be diagnosed with the debugging tips in this MSDN Library article.

To debug your control in design mode, you need two instances of Visual Studio. In the first instance, open the project which contains this control source code. In the Project Properties, Debugger, set command line which calls another Visual Studio instance (msdev? don't know exactly for VS2010 - take it from the shortcut), Then execute "Start Debugging" command. Another Visual Studio instance starts. In this instance open client project which uses your control on the form.

How to debug a C# command-line program

I'm trying to build a command-line tool in C# with VS2010.
My question is: how do I debug this, like I would a winforms.
With winforms, I can step through the code, see the values at each individual step, etc...
Here however, the program only responds when I talk to it from the command line. I can't start a debug session, since that will first fully start the program. And due to the nature of the program, it will shut itself because there were no command-line arguments.
So no debugging can occur.
What do I need to do here?
EDIT: an example, since someone made a comment that makes me feel this explanation is needed.
C:\Path\To\File\file.exe -help
That is an example of how this program is adressed. The command, -help, is given in the same line that the program is started. In other words, I cannot first start the program, and then give it a command while it's running... because it won't be running anymore. It'll start, see that it had no arguments on startup, and because of that, shut down. That's how a command-line tool works.
Activate
Process possible arguments
Output results
Shut down automatically
It is not something that keeps running till you click the little x in the top right corner.

In the Project properties, under Debug, you can enter any Command Line Arguments you would like, and then run the app with F5, the debugger will be attached automatically.

You could add a call to Debugger.Launch to your startup code. Then you can compile, and start your app from the command line. You'll get a prompt asking you which debugger you want to attach (typically this will be a list of the different versions of Visual Studio you have installed), and away you go.
(But really, setting command-line parameters in Project properties > Debug tab is the better way to go most of the time. If that's not working for you, you should figure out why.)

You can use Visual Studio to attach a debugger to the command line application, once it is under way with the correct arguments. I'm not sure if your application will terminate quickly or give you any opportunity to attach the debugger, but if it will, this should work.
I'm using VS2008 but I'll bet the process is similar in 2010:
In VS, go to Tools and click Attach to Process
Choose your application from the list and press Attach
Now VS should be able to finagle its way into your application and break on an error.

You just need to add a breakpoint to the first line of the main function (you can do this by clicking on the line in the Visual Studio editor and hitting F9) and hit F5 to start a debug session.

Either add a breakpoint to the opening { of Main, or step into the program (Debug menu). At that point set a watch on the parameter for main (the command line arguments) by selecting it and either right-click/Add Watch or drag the parameter to to watch window if it is already open. Double-click the Value column in the Watch window and set it to whatever you want it to be.
Note: the value added must be valid code -- that is, to add a -help to the string[] you would have to type new string[] {"-help"} or new [] {"-help"} depending on the version you are using.
This has the advantage over setting the parameter in the Debug tab of the Properties window by allowing different parameters for each run without having to return to the Properties window.

When you have command line arguments then you need to follow different route to debug. Go to project and then select properties. There you will see debug section and then give required parameters. So that it will take care of passing parameters to the program. If you have multiple parameters then separate them with space. After that if you debug it will hit the break point directly. For more info check here how to debug c# through command line arguments in visual studio

Is there a way to *completely* disable Edit and Continue?

I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike

Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".

Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam

Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.