Develop Reference

debugging with monodevelop from client

I have been used to use visual studio to create web apps and other application. Visual studio makes it possible to place a breake point on a method, and activate that breakpoint from the client side. And as soon as that method gets called, the debugging will begin, and you can press next etc to see the different values of the variables.
Circumstances for the past 6 months, have required me to use monodevelop, since I am working on ubuntu. I am using nginx as webserver. Many times I have searced for documentation on how to debug from monodevelop. I have not been able to find any solution, and mono's documentation hasn't helped me so far, unfortunately. So to debug my code, I write to a log, which is killing me.
Has anyone successfully found a way to debug code using monodevelop, and activate that breakpoint from the client? Similar to the way in visual studio, that I just described?

Yes, you can set breakpoints in Mono the same way you do in VS. Verify you have installed all the relevant packages before.
http://www.mono-project.com/archived/guidedebugger/

How to debug startup exceptions with service hosted in IIS?

I have my service running in IIS. I have a non fatal exception occurring and being logged on startup.
How do I attach Visual Studio to IIS so that it also debugs the startup?
I know I can attached visual studio to the w3wp.exe to debug while its running.

Add the following to your application's start up code:
System.Diagnostics.Debugger.Break();
When this line is hit, you will be prompted to attach a debugger to the process. See Debugger.Break for more details.

If you want to live debug you must have the Remote Debugging tools installed on the web server. Make sure to use the correct version for the version of Visual Studio you are running.
Compile your project in debug mode, make sure "Emit debug information" is checked in the Advanced Precompile Settings.
Deploy your project to the server. It is critical that the code in visual studio matches exactly what you deployed. Do not try to debug against even minor differences in code (web.config setting differences are ok).
Run the remote debugging tools on the server with an administrator account. You should see it say "... Waiting for new connections".
In visual studio, use Attach to Process from the Debug menu to attach to the w3wp process on the server. Make sure the Qualifier is the server name:port number that the remote tools is listening on.
In some cases, you may need to click the "Select..." button in the Attach to Process window and select only "Managed (v4.5, v4.0)" code types instead of letting it automatically determine code type. If your break points never get hit because no symbols were loaded, this could be why.
Tip: assign a specific app pool to your IIS application so it is easier to identify in the Attach to Process window. You may have a bunch of w3wp.exe processes and you may not know which one you want to attach to.
As an alternative to live debugging, you could run an intellitrace on the server, bring the trace file back into visual studio and step through the code like it is a recorded session. This is a whole other set of instructions involving powershell. I prefer live debugging if it is an option.
UPDATE:
To step into Application_Start(), recycle the App Pool and then attach Visual Studio before any requests come in to be sure you are debugging when you (or anyone) makes the first request.

You can also use below code snippet. It is equally handy -
System.Diagnostics.Debugger.Launch();
Wheneever you place it in code, it launches Visual Studio's JIT debugger at that very spot as shown below. As already suggested in the accepted answer you can place this code in application's start-up code at the very first line:
You can then choose and attach to any new or already running instance of Visual Studio across all versions installed on your machine. Hope this helps someone!

vshost.exe not terminating properly in Visual Studio 2015

I am in charge of testing VS 2015 and how it works with our current applications for my employer. We currently use VS 2013 for everything we have, so I know there are no issues there. The problem I am having is that it appears the vshost.exe isn't terminating correctly or something. I have not narrowed down the exact issue but so far that is what I believe.
Here is how I get my error:
Run my app in debug
Open a few windows
Hit the "Stop Debug" button (the little red square)
Clean Solution
Rebuild Solution
After my rebuild I get the following errors in the EXE:
Error Could not copy "obj\Debug\APP.exe" to "..\..\bin\APP.exe". Exceeded retry count of 10. Failed.
Error Unable to copy file "obj\Debug\APP.exe" to "..\..\bin\CRM.exe". The process cannot access the file '..\..\bin\APP.exe' because it is being used by another process.
If I open the Task Manager and manually end the vshost.exe process I can successfully rebuild again, no issues. If I take the same steps, however, I am no longer able to build.
I tested these steps in 2013 and did not have an issue.
Also note that disabling the "Enable the Visual Studio hosting process" does alleviate the issue, however I do not want to disable this option.
Has anyone else had this issue? I know we are still early in release. Any suggestions/solutions to try? Is it possible there is something wrong in our code (which I highly doubt since I would then get the error in 2013, most likely).
Thanks for any help I receive!
EDIT: This is a WPF application written in .Net 4.0 using C#. Also, I have verified that the issue also occurs if I exit the application normally (IE I open a window then close it with the shutdown mode on LastWindowClosed)
SECOND EDIT: This is a new issue that presented itself in Visual Studio 2015 with the addition of the new live diagnostic tools.

I have found that if I have the "Enable Diagnostic Tools while debugging" option enabled in the debug settings I get this error. If I disable this option, the error goes away. I am not sure if this is a bug in Visual Studio but I would assume so, unless I need to do something else to shut them down properly. If anyone has comments or concerns, feel free to leave a note.

Probably late for the original question (and I see that he had a workaround), but as per MSDN, VSHOST.exe is only an enabler for improving Debug performance or facilitates scenarios such as partial trust debugging. If you do not need that support or can bear the cost of starting a process and attaching the debugger on each debug session, go ahead and disable the hosting process from project designer -> Debug -> Clear the box "Enable Visual Studio hosting process"

VS Debug DLL invoked from system service

I am developing a DLL (in Visual C# Express) with some plugin logic for an application.
Is there any way to debug this DLL, once it get's used by the application? The application is running as a service on Windows, and it's a COTS application, meaning that it's not a C# project I can start debugging from.
I am aware that there are limitations regarding debugging in Visual C# Express. Is this task possible in Visual Studio Pro?
What I want to acheive is to be able to step through the logic, set break points to see what happends when the call comes. Any clues?

I am not sure about VS Express but, normally,
Open Visual Studio
Open your Solution (Windows Service Project)
Debug -> Attach To Process
Select your Service from Available Process List
You may use breakpoints and other stuff.
Hope it helps.

While I'm not entirely sure how this works with services specifically, you can set an arbitrary debug target.
In the debug panel (in project properties), you can set any executable or other command as the debug target. The process spawned by this command will have the debugger attached, regardless of whether where the executable came from. There are no requirements that the target be a C# project, or any Visual Studio project. This should be available in both Express and Pro. It's possible to attach to a later process (if you have a launcher), but that's probably beyond your current scope.
You then set breakpoints in your code as usual, and when the code is hit (regardless of whether your code calls it or the host executable), the breakpoint will be triggered. Depending on how much information you have about the host, you may be able to effectively debug it as well; even if you have no information, you'll be able to step through the assembly.
The only requirement here is that the target load and run your code. Depending on the context (plugin to a program, injected dependency, whatnot) this is of varying difficulty. The technique is used in a number of places, particularly plugin systems where you may not be able to debug the actual host, but still want to do so with your plugin.
Another, slightly uglier variation, is to force the host to break and self-identify. This is only useful for debugging, as it's very disruptive. The typical method is to show a message box (modal) with the process ID. The process will then be suspended until the message is dismissed, and a debugger can be attached. This becomes more difficult with services, although there are still ways to publish your information in a blocking fashion.

You could use the System.Diagnostics.Debugger.Break() method.

Debugging feature activation in SharePoint 2007

I have a SharePoint feature that is activated under 'Site Collection Features' that is having some issues being activated. I've activated it through the stsadm as well as the SharePoint UI, both unsuccessful. The feature toggles from deactivated to activated, but the result that should be there is not. The result is some pages that should be created. So my question is does anyone know of a way to step through the activation of features process? I'd like to be able to attach Visual Studio 2008 to the browser and step through a few breakpoints that I've set.
I've narrowed the error down to the FeatureReceiver's FeatureActivated(SPFeatureReceivrProperties properties)
Pages that I've been referencing:
http://msdn.microsoft.com/en-us/library/ee231550.aspx
Link
EDIT: The solution was resolved by looking at the errors created in Logs folder under 12 hive, starting with the first error of importaning a web-part, and referencing http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/10/06/troubleshooting-cannot-import-web-part-error.aspx
The issue was resolved by adding two missing binaries. I was unable to attach to SharePoint feature activation by attaching to w3wp and SP Timer Service process.
Thank you all for your tips!

One thing you could try is this (assuming Visual Studio is installed on the same computer as the SharePoint server itself).
Put a breakpoint on the FeatureActivated(SPFeatureReceivrProperties properties) method.
Attach Visual Studio (Debug menu-> Attach To Process) and look for the SharePoint Timer Service (the name of which escapes me right now)
Immediately, try to activate your feature.
If I recall, the timer process is responsible for firing off various tasks, such as feature activation, so hopefully attaching to that process will be correct.
Hopefully the above might work, assuming you're using a DEBUG build of your code, you should be able to debug your code.
Hope this helps.

You will find it much easier to do this using SPVisuaDev it is a VS add in and you can select Activate(with debug) in a menu,you don't even need to use stsadm to deploy or activate your features in your dev environment. It also integrates with WSPBuilder which makes building and deploying your WSP packages much easier.

I'm pretty sure feature activation would happen in w3wp if you're doing it from the browser and stsadm if you're doing it from stsadm. Powershell in the case of powershell with 2010. The timer service isn't involved in these sorts of provisioning tasks. They're all synchronous.