By default the .dll and .pdb files will almost certainly be being generated into the bin directory under Desktopmosules\events, rather in the bin directory below the root of the website. You should be able to check this be looking at the creation date of the files there. To have them created in the Root/Bin directory, what I do is right click on the project in Visual Studio and change build output path on the compile tab. Bear in mind there are four projects in events module. It likely you will only change Events and SQLDataProvider projects, so you perhaps only need to change the build paths for those, depends whether you want to debug across all of them.

It's possible this may only change the Release build path, and not the Debug build path. This is what happened with our 4.0.0 build in VS2008. So I ended up editing the VBProj file by hand, so make the two paths the same. You should see them in there, but they will look like ../bin, or ../../bin.

Bear in mind this is what I do, only because I don't know better. It may be there is a way of having the desktopmodules/events/bin directory added to the run path, but I've never made the effort to find out how. So if someone wants to enlighten me that would be great, because it would make my life easier

Cheers
Roger

Okay, I believe I've figured it out, but not without much detective work.

It turns out that in the source package for the Events module, there is something in the DotNetNuke.Events.vbproj that keeps it from being loaded in VS 2008.  Therefore, whenever you open the DNN.Events solution in VS, which in turn loads the four subprojects, the DotNetNuke.Events subproject does not get loaded--which means that it does not get rebuilt whenever you do a clean build.  So, you're left with the DotNetNuke.Events.dll that was packaged with the module, which doesn't have debugging symbols.

What worked for me was:

1.  Edit the DotNetNuke.Events.vbproj file by hand.  I think the key is the Visual Studio block at the end of the file.  Remove that block, and save the file.

2.  Bring up the DotNetNuke.Events.sln file with VS 2008.

3.  Make sure debug mode is turned on in the compiler to generate the symbols.

4.  Build the solution, generating the 4 DLLs.

4a.  If you get a build error regarding Framework, make sure that the References point to a valid DotNetNuke.dll.

5.  Bring up your DNN web site in VS 2008, and set a breakpoint in the code.

6.  Voila, c'est parfait!

I've only been working with DNN/.NET/Windows for a couple of weeks, but I've got plenty of C++/Unix experience.  If any of you more experienced .NET folks have some advice on a better way to address this issue, please edumacate me.