Debugging Timer Jobs in MOSS 2007

In the Execute method of the job (the method you override to write your job execution logic) place the following code (Thanks Joe!): System.Diagnostics.Debugger.Break();
Assuming you have already added your solution to the site and deployed it using Central Admin, simply uninstall the job assembly from the GAC and add the newly built one back in again
What I did here is to stop the OWSTIMER service (to prevent my job from running a million times while I do these steps)
Remove and copy the job assembly to the GAC
Map the GAC folder so you can actually see the files to place the .pdb file in for debugging using subst Z C:\Windows\Assembly (this command run from the command prompt maps the file structure of the windows assembly folder to the z:\ drive so you can copy your assembly into the Z:\GAC_MSIL\MyAssembly\10000___StrongNameKey\ folder
Reset IIS and restart the OWSTIMER service
Quickly attach your VS.NET debugger to the OWSTIMER process and wait for your job to kick off inside OWSTIMER. The debugger will break on the System.Diagnostics.Debugger.Break(); allowing you to step through your job

UnauthorizedAccessException and SPSecurity.RunWithElevatedPrivileges to the rescue

This issue occured when a user with read-only access would access a page with a web part that did some Excel parsing.

The code would throw an UnauthorizedAccessException error when attempting to instantiate the Microsoft.Office.Interop.Excel.Application() COM object, . To get around this in MOSS we can elevate the permissions to that of the SharePoint system account by wrapping that code as follows:

SPSecurity.RunWithElevatedPrivileges(
delegate()
{
// Put the code that needs to run with elevated permissions here
BashExcelSpreadsheet();
}
);

We love you SPSecurity

Office application does not quit after automation from Visual Studio .NET client

This is the result of a known Microsoft issue -- if you directly reference any members of the Microsoft.Office.Interop.Excel COM objects, the objects will not terminate in spite of garbage collection and as a result, the EXCEL.EXE process will not terminate.

The workaround is to instantiate new objects as references to the same members, then forcibly release the COM object using System.Runtime.InteropServices.Marshal.ReleaseComObject, the objects will then terminate correctly by garbage collection, and the process now terminates as expected.

Here is the Microsoft kb identifying this issue and the workaround:

Office application does not quit after automation from Visual Studio .NET client
http://support.microsoft.com/default.aspx?scid=kb;en-us;317109

Workaround for Installing Extensions for VS2005 on x64

1. Download Visual Studio 2005 Extensions, Version 1.1 for Windows Server 2003 Enterprise Edition 64-bit
A. http://www.microsoft.com/downloads/details.aspx?familyid=3E1DCCCD-1CCA-433A-BB4D-97B96BF7AB63&displaylang=en
2. Save the install file: C:\Temp\VSeWSSv11.exe

3. Extract the MSI using this command: C:\Temp\> VSeWSSv11.exe /Extract

4. Output MSI file: C:\Temp\VSeWSSv11.msi

5. Downloaded Windows® Server 2003 SP1 Platform SDK
A. Installed just Orca

6. Edit MSI using Orca
A. In the Tables column
1. Select: InstallExecuteSequence
2. In the right pane, drop these two rows.
a. X64System
b. WSSNotInstalled
3. Select: InstallUISequence
4. In the right pane, drop these two rows.
a. X64System
b. WSSNotInstalled
B. Save MSI

7. Run edited MSI and follow the prompts.