locked
debugging Event Receiver - No symbols have been loaded

    Question

  •  Hi,
    I have not been able to debug my Event Receiver.  When I attach a w3wp process, it says "The breakpoint will not currently be hit. No symbols have been loaded for this document."

    I am running a Win 2003 Server, with WSS 3.0, and MOSS 2007.  As well, I have a Visual Studio 2008 (.NET 3.5).
    I am using the Event Receiver as a Feature, and I have packaged it into a Solution.  It was compiled in DEBUG mode.  I have followed all standard steps (by the book) of implementing an Event Receiver (using Feature.xml, Elements.xml, as well as Manifest.xml and wsp.ddf file for CABbing it.)

    The DLL is deployed to the GAC, as specified in my Manifest.xml file (<Assembly DeploymentTarget="GlobalAssemblyCache"...         ) at the time of "stsadm -o deploysolution...". 
    Note that I also explicitely deploy a .PDB file associated with the DLL, into the GAC_MSIL folder where the DLL resides.  (see below)
    The solution deployment script is a batch file (command line), with the following commands:

    @set STSADM="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe"
    @set GACUTIL="c:\program files\Microsoft sdks\windows\v6.0a\bin\gacutil.exe"

    %STSADM% -o retractsolution -name CustomFeatures.wsp -immediate
    REM Check within SharePoint that Solution has been Retracted by this Asynch call, then proceed!
    PAUSE

    %STSADM% -o  deletesolution -name CustomFeatures.wsp
    echo "Uninstalled solution and GAC."

    makecab.exe /f wsp.ddf

    %STSADM% -o     addsolution -filename c:\wsp\CustomFeatures.wsp 
    %STSADM% -o  deploysolution -name CustomFeatures.wsp -immediate -allowGacDeployment

    REM Check within SharePoint that Solution has been Deployed by this Asynch call, then proceed!
    PAUSE
    xcopy bin\Debug\CustomFeatures.pdb "Z:\GAC_MSIL\CustomFeatures\1.0.0.0__a79cdb7862d7c364\" /y

    REM Restarting IIS...
    iisreset.exe

    I think I am doing all the proper steps, the script runs successfully, and every step is confirmed.

    Once the Solution is deployed, I do the following steps to Debug:
    - IIS was just reset
    - attach process of w3wp.exe to debugger.  Of course, there are a few (4) w3wp processes on my machine.  I tried all of them individually, but the symbols are not loaded. I have confirmed that one of those "w3wp (MACHINE\spmysitesapppool)" is the one that comsumes the CPU in task manager, when I navigate to my SharePoint page.

    Note that I had successfully debugged SharePoint web parts in the past, using very similar steps (excwept they were deployed to a local /BIN folder), allbeit this successful process was done on a different machine.

    Is there anything I am missing?  My hands are really tied without the debugger, as any SharePoint developer would imagine.  I would appreciate some input.
    Regards, Zoran

    Wednesday, September 03, 2008 4:52 PM

Answers

  • I have managed to resolve my issue now.  Had a couple of discoveries that allowed me to debug at the end.

    1. Deploying a SharePoint Solution (using STSADM addsolution and deploysolution) onto the server is not enough to get your feature to work.  I made a mistake of assuming the feature would be activated automatically with the Solution deployment.  its' not.  You have to follow it up with a Feature activation command (STSADM -o activatefeature).

    2. When a Solution is installed, a Feature is only activated for the Root site, not any subsites.  You explicitely have to specify which sub-site the feature should be activated on, in order for it to work. 
    Once this is set, you can hit your sub-site, and your event receiver should catch your particular events.  Once it is loaded into memory first time, then you can use the debugger in Visual Studio to Attach your w3wp process (find the proper one if you have multiple ones like I do.  Do this by watching the Task Manager when you hit your site, see which w3wp Process spikes the CPU useage), and your break points will come alive, all symbols loaded.

    My mistake was:  I was trying to debug my Event Receiver, but because my Feature was not activated for my subsite, the Event Receiver was never firing (not even loaded into memory), so the debugger had nothing to hook onto.  It was a catch 22.

    Hope this helps others in a similar situation. 
    What I found helpful was another post on here, to get me thinking on the right track.  Link and excerpt included below.
    Zoran

    According to Martin Hatch post (http://forums.msdn.microsoft.com/en-US/sharepointdevelopment/thread/3e407bb7-0351-4351-bfea-6e47334bd0e0)

    Hey .. you get the "No Symbols Loaded" message because the assembly hasn't been loaded by the Web Application yet.

     I do SharePoint development every single day and I almost always put my DLLs into the GAC for debugging, you don't need to copy any PDB files .. that is rubbish!

     When the SharePoint application starts then it goes and loads all of the relevant assemblies into memory. The important word here is relevant assemblies.

     If you are building a Site Provisioning assembly, then that assembly will ONLY be loaded into memory when you create a new site using that Web Template.

    It is at that point that SharePoint goes to the GAC and fetches the assembly to load it into memory.

     Once the assembly is into memory you should find that Visual Studio suddenly jumps into life .. and the "No Symbols Loaded" message disappears!

     The same goes for Event Handlers. The event handler assembly will only be loaded into memory when the event trigger fires, and SharePoint goes and fetches the code that handles the event (i.e. your assembly).

     So .. until the event gets fired for the first time, Visual Studio will be displaying "No Symbols Loaded" (because it can't find your code anywhere in the running process). When the event actually gets fired then the process gets updated with your assembly, and Visual Studio recognises the code in your project and your breakpoints will suddenly start working.

     NOTE - due to this loading of assemblies into memory you must make sure that you reset the application pool (or IISRESET) each time you upload a new version into the GAC. Otherwise the process will still be using the old version .. and that means that your project will not match the version of the assembly that is in memory and you won't be able to debug.

    Thursday, September 04, 2008 5:51 PM

All replies

  • The symbol would not be loaded until you execute the event for the first time.

    Have you tried adding the list item(If its ItemAdded) and see if the event reciever is called. Symbols and any breakpoints would be subsequently automatically then.

    --
    Madhur

    http://blogs.msdn.com/mahuja | Please mark the replies as answers if they help
    Wednesday, September 03, 2008 5:07 PM
  • Ensure that the source matches up to your solution.. If you deploy the binary/pdb then you change any of your source files most of the time it won't load.

    Also, don't forget to enable debugging in the web.config. 

    Find:   <SafeMode CallStack="false" />

     Replace with: <SafeMode CallStack="true" />

     Find:   <customErrors mode="On" />

     Replace with: <customErrors mode="Off" />

     Find:   <compilation debug="false" />

     Replace with: <compilation debug="true" />




    Posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, September 03, 2008 6:57 PM
  • Hi Madhur, thanks for a quick reply.
    I have tried executing the event before linking the debugger, with no luck.
    When adding my list item, the event receiver is not being called either; thus the need to debug.

    No luck debugging yet.  Symbols still not loaded.

    Further to that, I have loaded an old VS Solution, which had a different event receiver for a diffrent list, and within there I AM able to debug, and load symbols properly.

    That is, I now have 2 Visual Studio solutions going in paralel.  The one that's giving me trouble debugging is based on the old one.  Both are very much identical in setup, only differ in the events captured, and receive on different lists.  Deployments are the same, they both use Features and Solutions.  Both show up on Central Administration | Solution Management page.
    I can debug the old one, loading the symbols, but I can't debug the one I need.  What can be different between the two very similar solutions, to make a difference in not loading the symbols?

    Note 1: no PDB file needed
    The old Solution does NOT even need a PDB file sitting in the GAC_MSIL.  It can debug without!  This is contrary to the on-line documentation I followed at http://blog.ray1.net/2008/04/debugging-sharepoint-gac-dlls.html .

    Note 2:  Scope of Event Receiver
    My old solution has an Event Receiver of the Web scope (<Feature Scope="Web"...), which is the only scope the receiver can be applied to according to MSDN (does not apply to Scope of: Site, Web Application, or Farm). 
    As such, the only events captured are the ones triggered from a high-level site, like
    http://vm:8020/sites/ImportedSites , and not captured from any subsite like
    http://vm:8020/sites/ImportedSites/MySubSite .

    Using Solution deployments (STSADM -o  deploysolution), there is no way to specify which (sub)site the Receiver will apply to, as far as I know.  Correct?  so, how do I make it fire on the subsite?
    Using explicit Feature deployments without using Solutions (stsadm -o   activatefeature -name CustomCode -url http://vm:8020/sites/ImportedSites) allows you to specify a subsite, looks like.  However, I don't want to explicitely deploy features, without bundling into a solution.
    I also would rather not wanna go OBject Model for deployments.  thus, the above question remains.

    thanks,
    Zoran
    Wednesday, September 03, 2008 7:03 PM
  • Hi Michael,
    thanks for your input.
    if you take a look at my response to Madhur just above, you'll understand the 2 Visual Solutions (implementing  I'm refering to in my paragraph below.

    Both of my solutions consist of 1 Project, a Class Library.  It's pretty simply.  Neither of them have a web.config.  So, they are inheriting the settings from web.config from the IIS root, or even the machine.config from (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG).

    I have modified the glabal web.config in the proper IIS folder, to adjust to your settings of:
      <SafeMode CallStack="true" />
      <customErrors mode="Off" />
      <compilation debug="true" />

    I had reset IIS.
    The problem still remains:  I can debug the old solution, but I can't debug the one I need to.
    hmm.
    Zoran
    Wednesday, September 03, 2008 7:31 PM
  • I have managed to resolve my issue now.  Had a couple of discoveries that allowed me to debug at the end.

    1. Deploying a SharePoint Solution (using STSADM addsolution and deploysolution) onto the server is not enough to get your feature to work.  I made a mistake of assuming the feature would be activated automatically with the Solution deployment.  its' not.  You have to follow it up with a Feature activation command (STSADM -o activatefeature).

    2. When a Solution is installed, a Feature is only activated for the Root site, not any subsites.  You explicitely have to specify which sub-site the feature should be activated on, in order for it to work. 
    Once this is set, you can hit your sub-site, and your event receiver should catch your particular events.  Once it is loaded into memory first time, then you can use the debugger in Visual Studio to Attach your w3wp process (find the proper one if you have multiple ones like I do.  Do this by watching the Task Manager when you hit your site, see which w3wp Process spikes the CPU useage), and your break points will come alive, all symbols loaded.

    My mistake was:  I was trying to debug my Event Receiver, but because my Feature was not activated for my subsite, the Event Receiver was never firing (not even loaded into memory), so the debugger had nothing to hook onto.  It was a catch 22.

    Hope this helps others in a similar situation. 
    What I found helpful was another post on here, to get me thinking on the right track.  Link and excerpt included below.
    Zoran

    According to Martin Hatch post (http://forums.msdn.microsoft.com/en-US/sharepointdevelopment/thread/3e407bb7-0351-4351-bfea-6e47334bd0e0)

    Hey .. you get the "No Symbols Loaded" message because the assembly hasn't been loaded by the Web Application yet.

     I do SharePoint development every single day and I almost always put my DLLs into the GAC for debugging, you don't need to copy any PDB files .. that is rubbish!

     When the SharePoint application starts then it goes and loads all of the relevant assemblies into memory. The important word here is relevant assemblies.

     If you are building a Site Provisioning assembly, then that assembly will ONLY be loaded into memory when you create a new site using that Web Template.

    It is at that point that SharePoint goes to the GAC and fetches the assembly to load it into memory.

     Once the assembly is into memory you should find that Visual Studio suddenly jumps into life .. and the "No Symbols Loaded" message disappears!

     The same goes for Event Handlers. The event handler assembly will only be loaded into memory when the event trigger fires, and SharePoint goes and fetches the code that handles the event (i.e. your assembly).

     So .. until the event gets fired for the first time, Visual Studio will be displaying "No Symbols Loaded" (because it can't find your code anywhere in the running process). When the event actually gets fired then the process gets updated with your assembly, and Visual Studio recognises the code in your project and your breakpoints will suddenly start working.

     NOTE - due to this loading of assemblies into memory you must make sure that you reset the application pool (or IISRESET) each time you upload a new version into the GAC. Otherwise the process will still be using the old version .. and that means that your project will not match the version of the assembly that is in memory and you won't be able to debug.

    Thursday, September 04, 2008 5:51 PM