I am trying debug a workflow code and it always shows that the breakpoint cannot be hit. I have made sure that I deploy the recent code.
Also I have tried to load the PDB symbols using windows->debug->modules but I don't see the dll of my project there.
I am not not understanding how to proceed further. I am using vs2010 and sharepoint 2010
In order to debug workflows you have to attach to owstimer.exe and w3wp.exe (try all of them if there a several). And of course you have to have the same code both in studio and deployed.
Related
I noticed that since the latest update (Version 6.10.0755) a new critical bug may have been introduced. I'm asking here about it before reporting it just in case they introduced an option that would fix my issue.
My issue is that any time I edit a back end .cs file for a page, when I attach the program to the website instance and attempt to debug, I get the error message "This source file has changed. It no longer matches the version of the file used to build the application being debugged." It feels as though the Just-In-Time compiling feature has been "turned off." Can anyone give me any feedback if it was and how to fix it, or is anyone else experiencing this and should this be reported as a bug in the system?
Edit: I am using an instance which I updated from a previous 6.1 version (6.10.0269). The error is occurring on a graph extension of the SOOrder page. Fully customized pages seem to be fine. Here is a screen shot of the error:
I don't know why the files are detected as changed but you should be able to re-attach to a fresh compiled instance with the following steps.
When attaching in visual studio, the Debug output window will list the compiled runtime code of the ASP application instance. It's in the file 'RuntimeCode_GUID.dll'
Stop IIS and the debugger, this will release the handle to the runtime code dll file
Delete the runtime code dll file
Restart IIS and open the web site in the browser, this will recompile the runtime code
Re-attach the debugger to the website
I built the WSP file manually (using CAB utility) and uploaded them to the sharepoint 2010 server. I want to debug the dll that was packaged in that WSP file to test if the events are caught by the listener. I attached to w3wp.exe (all instances that appears). however I find that the symbols are not loaded for any break point to be hit and the thread is getting exited with some run time exception.
what Am I missing here ? Do I have to copy my PDB files at any particular location ?
thanks
you have the answer in your question. yes you have to upload your pdb file to GAC using command prompt and copy statement
which would be available under
C:\WINDOWS\assembly\GAC_MSIL> in directory form open it and copy your pdb thier
or easier option is compile your wsp in debug format
You don't need to copy the PDB symbols file into the GAC if Visual Studio is configured correctly :-
Fortunately, it's just as easy to
debug in the GAC as it is in BIN if
you configure the development
environment correctly.
Unfortunately,
few know how to do this because the
internet is polluted with pages full
of bad information that is a held over
from previous versions of .Net.
You
can spot these easily because they
will say you need to copy the debug
symbols (.pdb file) to the GAC. In and
of itself, that will not work. These
days it is also completely
unnecessary.
To configure VS ... to debug the
assemblies properly, do the following:
You mention the Sandbox tag in your question, so you have to attach to SPUCWorkerProcess.exe and not w3wp.exe, the sandbox code runs in an isolated worker.
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I am following the below steps to do it. I have selected the application's bin folder in App path and clicked on the build button. Then I have run the application from visual studio 2005. However, i don't see the reset counter or take snapshot buttons enabled. Please help.
You'll find a nice step-by-step instruction and explanation in this thread.
I may also have an explanation of what's going wrong for you:
You compile your asp.net app in VS2005 - fine
You then instrument and overwrite your app using Build in the profiler - also fine
But then you run your app from VS2005 and that may re-compile your app again so you're running an un-instrumented version. Instead of running it from VS2005 you should simply have IIS "launch" the code by navigating to the corresponding webpage.
If this is not the problem then take a look at the log-file generated by the running, profiled app. By default the log-file is located in C:\Windows\Temp\EQATECProfilerLogs\profiler.log.
is it impossible to debug? I am running 64-bit Windows Server Enterprise, and trying to debug my solution on Sharepoint which includes a dll that has baselayoutpage pages. When I try to atttach the process to the Visual Studio debugger (VS2008) it says break points will not be hit. I have been pulling my hair out on this one, I have tried manually locating the module in debug and specifying the pdb file, but that doesn't work. i have even tried redeploying several times. There is the VSeWSS DebugReDeploy configuration I use to reploy the assembly onto the Sharepoint site.But always ends up that I am unable to debug, I have tried many things! If anyone would know why please let me know?
I have found the answer, I had to goto the project properties in solution explorer and goto the build options and click advanced from there select all configurations and select debug info as All... I hope I told it correctly, I am saying it from my memory
I have written an SharePoint EventReceiver (Windows SharePoint Services 3.0) and want to debug it with Visual Studio 2008 SP1, which runs on a different computer. I have tried the following steps:
Installing the event receiver (I know that this works because a log file proves that the code is executed).
Registering my event receiver class library in the GAC of the SharePoint server (built in Debug mode).
Starting Visual Studio Remote Debugging Monitor on SharePoint server.
Attaching to process w3wp.exe on SharePoint server from local machine.
Unfortunately Visual Studio tells me that the breakpoint I set will not be hit. I guess that when installing the assembly to the GAC the debug symbols (or whatever is needed for debugging) are lost.
What can I do to debug my event receiver? As far as I know the only way to extend SharePoint by custom assemblies is to deploy them to GAC - am I missing here something?
Best Regards
Oliver Hanappi
you could try manually copying your assembly's debug (.pdb) file to the c:\windows\assembly\MSIL\ASSEMBLYNAME\VERSION folder on the target machine and restart IIS.
I just ran into this issue this morning. I was getting the same error about breakpoints not being hit. In my case, it was because I attached to the wrong w3wp.exe process. If you have multiple w3wp.exe processes running on the server - make sure you're attaching to the correct process for debugging.
As an aside - you don't mention running iisreset anywhere in your steps. After you copy your custom event received assembly to the GAC - make sure you run an iisreset so that the web server is picking up your changes.
Hope that helps!!
This question is very old but I just want to share the following command that will assist in picking the right w3wp.exe process.
Assuming you have deployed and enabled your event receiver.
Execute this command on the commandline
%windir%\system32\inetsrv\appcmd.exe list wp
This will print the PID and an indication of which site it is for eg.
C:\Windows\system32>%windir%\system32\inetsrv\appcmd.exe list wp
WP "11632" (applicationPool:4a8cbf60637942ff9a2486d0e682ac54)
WP "16800" (applicationPool:SharePoint Central Administration v4)
WP "23648" (applicationPool:teams)
Now you can attach you Visual Studio debugger to the right process easily.
For example for the SP site teams I will attach to PID 23648