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.
Related
I am new to Visual Studio Express.
I am writing an Class Library and want to debug it, but I don´t get how I do that.
The dll is for an App which itself injects into an other Software. I have direct Access to that App.
So far I have attached the Debugger to the App, but what now? Do I have now to specify something so that always when I debug it a new Version is builded in the Plugin Directory of the App? Or shall I set my Working Dir to the Apps Plugin Directory?
I have read https://msdn.microsoft.com/en-us/library/aa291243%28v=vs.71%29.aspx and various other resources, but it never happens what is expected.
Add a new project to your solution that outputs an executable assembly, such as WinForms, Console, or Web.
Set this new project to be the startup project.
Add the Class Library project to the Executable projects references.
Write your test code.
Run the executable project.
I think that you may be confused what debugging in visual studio. Debugging in Visual Studio allows you to set breakpoints and see errors more clearly by highlighting the line of code that is throwing the error.
I am writing an Class Library and want to debug it, but I don´t get how I do that. The dll is for an App which itself injects into an other Software. I have direct Access to that App.
Library classes are hard to debug, b/c they won't want to run by themselves. I actually wouldn't call your class a library. Your code is an application that "hooks" itself into another software. You can debug your application by running it with a debugger attached (simply pressing start should attach the debugger unless you explicitly ask for it not to be attached in project settings) and then using your application to inject itself into another software. Any errors that result from the application while in testing will be caught by the debugger.
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!
I have a solution which contains multiple C# projects. One of these projects is an executable, the rest are DLLs.
The problem is, some of the projects do not actually run on the same process as the executable start-up project. This is because some of the projects are really extensions to a WCF service that allow the service to play with the executable.
My question is: is it possible in any way, shape, or form to set a breakpoint in said projects? I am aware of the ability to "attach to process", but I'm not sure it is a good solution for me.
I want to:
Be able to see the source as I break
Not have two copies of Visual Studio open if possible
EDIT: the only reason I am not sure of 'attach to process' would work well for me is because I have little experience with that feature - perhaps it is what I should be using? Can I still load .pdb files?
EDIT 2: If one of the commenters would like to submit their comment as an answer, I will accept
Attaching to the WCF service seems to be the exact tool for the job:
It allows you to attach to a running process, even if you've only got the code and PDBs for a plugin/extension for that process. You can set breakpoints in your own code and they'll be hit when the 3rd-party process calls them.
You can attach to any process from an existing VS instance, even if that instance is used to debug a different executable, in this case your main EXE project. You can start debugging your app, then attach to the service before making the service call.
Make sure, though that the DLLs called by the WCF service are the same ones as you have in your VS instance - if they're called from the same location as the VS build output, you'll be fine. If not, make sure they're in sync.
So it's basically as stated in the title. I've created a WPF app in Visual Studio 2013 using some external libraries.
Application works flawlessly on my Development machine (Windows 8.1 x64 + Visual Studio 2013) but doesn't run at all on Production device (Tablet with Windows 8 (NOT 8.1)). App is developed under .NET 4.5, doesn't matter if I try to run Debug or Release version. The proccess just hangs a while and then closes without any errors or messages.
If anyone would know what to do or how to fix this I would be very happy.
Thanks in advance :).
The first thing too look up in this situation, would be the Windows event log. When a .NET application crashes badly, the .NET Runtime will log an event there.
Most of the time, these events will log the stack trace which lead to the crash. This will give you a hint as to what happened.
Such logs are found in the "Application" category, and the source name you need to look for is ".NET Runtime". Usually, there will be another entry with the source name "Application Error", but this one is much less likely to help you.
Another useful technique, is to add a Console.WriteLine call at the start of your program, in order to see if that line gets to run at all.
Depending on what you find using these techniques, you may also want to use tools such as Dependency Walker or ILSpy, as suggested by Mike Dinescu.
Most likely a binding error occurs at start-up but the production machine you're testing on is configured to silently report these errors and it doesn't display the typical dialog box that would inform you that the process crashed.
Don't fret though, that message would probably not help you too much anyway.
What you need to do is inspect the main executable with a tool that can generate a dependency tree and figure out which DLLs are missing. Most likely these will be native binaries, not managed. The usual suspects are the VC runtime, or MFC or ATL libraries but there could be others too. That's why you need to use a tool such as DependencyWalker or RedGate's Reflector to find all dependencies for the main executable.
It is because your external libraries are not compiled into final .exe file. So you either need to include them in the same folder or merge them into exe but this process can be quite tricky. Look for ILMerge. However it is way easier to just copy them with your exe file.
I have a c# class library that I am calling from Classic ASP.
Is it possible to debug this using visual studio? Break points in the class don't work, which isn't surprising.
I am running this on iis7 in the browser, rather than through Visual Studio 2010 because of the fact that I'm using a classic ASP page. Do I need to get this running in Visual Studio in order for this to work?
I also tried to use Response.writes, but they result in:
The name 'Response' does not exist in the current context
You need to attach the debugger to the process (either IIS or another debugger that you are using to debug your classic ASP application) that is loading the assembly.
Under VS2010 go to Tools -> Attach to Process (probably the same under 2008 as well).
try to add in the code of the lib: System.Diagnostics.Debugger.Break(); where you want to break. Also ensure the lib is compiled and deployed with the pdb symbols. When the code will reach the instruction, IIS will throw an exception. The system will ask you to attach a debugger, and you're on the way.
I actually wrote an article regarding this:
http://www.jameswiseman.com/blog/tag/visual-studio-2010/
From the article:
Open Visual Studio 2010
This is easy enough if you have it installed. Might be a bit tricky if you don’t ;-)
Open your website in Visual Studio
Again, easy enough.
Fire up your web site.
I.e. open your browser and navigate to the website.
In Visual Studio, click ‘Debug’ Menu -> ‘Attach to process’
You may need to tick the box labelled ‘Show processes from all users’
‘Inetinfo.exe‘ if application protection is low or ”dllhost.exe‘ if application protection is higher. You may get an ‘Attach Security Warning’ popup. If so, continue On. It’s a bit scary at first, but if it’s your own app on your own PC, then you’ll be ok.
If you’re worried about this, follow the advice on MSDN.
Add a breakpoint to your code, and navigate to a location where you will hit it.
Troubleshooting - Registering pdm.dll
This worked on the first occasion that I tried it. Subsequent attempts were not so successful, and I found a few things that I had to do.
When trying to attach to ‘Script Code’ I got the following warning in the IDE.
Warning: Cannot debug script code. The
correct version of pdm.dll is not
registered. Repair your Visual Studio
2010 installation, or run
‘regsvr32.exe
“%CommonProgramFiles%\Microsoft
Shared\VS7Debug\pdm.dll”‘.
Just follow these instructions.
Troubleshooting - Restart IIS
This also helped on one occasion. Can’t really say why.
You will make your life much easier all round if you wrap you .net classes in a web service then call the web service from the classic asp pages.
For debugging, attach the debugger to the process as described in other answers.
For tracing, I find very handy the combination between System.Diagnostics.Trace.Writeline() in the class library and an OutputDebugString listener like DebugView.