Does your project rely on a number of externals--things in the GAC, COM+ packages, registry keys and the like?  Do your unit tests need these?

What tricks do you use to set up your environment for unit testing?

I've resorted to a number of dirty tricks:

1)  pre- and post-build events.  I've resorted in some cases to running VBScripts from these to do things like configure MSMQ's and install things in the GAC. 

2)  installer classes.  Sometimes I instantiate and run these from NUnit Setup or TestFixtureSetup methods.  I like this because it continuously tests the installer classes, a typically neglected area

3)  direct code in Setup and TestFixtureSetup methods.  Not the best, since they're one-offs and I figure, if the code needs these things they should be in the Installers, too. 

What I'm trying to achieve with all this automation of the environment setup is two things.  First, I want the NUnits to run in an environment that's as close to production as I can make it.  Second, Continuous Integration.  The source should include--somewhere--absolutely everything required to set up the application and all its dependencies.  When the build server builds my application, I want it to either run the Installers, or an NUnit for those installers, and set up the environment on the build server to prepare for the actual code tests to run correctly.  Furthermore, I want the NUnits to run the uninstall parts of the Installer test after the main unit tests have run, and be sure it has torn down the build server to a pre-install state.

How does everyone else approach this?  Are you still relying on 10-page setup documentation to hand off to he operations folks when your app is done?  If so, are you having deployment problems?

This is one reason I'm so rabidly anticipating MSBuild...and a big reason I wrote BusyBeeBuilder.