One error you may see when packaging solutions with VSEWSS is:  Microsoft.SharePoint.Tools.Utilities.VSeWSSServiceException VSeWSS Service Error: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.  Like most error messages from VSEWSS, there is not enough information provided to resolve the issue, so I hope to save you some time by providing a workaround that will permanently fix this problem. 

When VSEWSS packages your solution, it uses reflection to enumerate the packaged assemblies.  It works fine until it encounters an assembly that implements an interface that is defined in another assembly as is often the case in the Microsoft.Practices.* assemblies.  I am unsure of exactly why, but the extensions are unable to resolve the dependent assemblies.  To work around the issue, you can copy the dependent assemblies to the GAC, but I don’t think this is the optimal solution and doing so will cause pain during development and debugging.  Another option is to copy the dependent assemblies to the VSEWSS service bin directory post build.  After trying this for awhile, and maintaining the script, I decided it would be much simpler to just copy all assemblies in my solution to the VSEWSS service bin directory on post build.  Here is the script:

@rem    This script copies assemblies to the VSEWSS bin directory
@rem    to eliminate the packaging type load exception that occurs
@rem    when an interface is defined in a separate assembly.
@rem    usage call $(ProjectDir)Scripts/CopyAssembliesToVSEWSSBin.bat $(TargetDir)

@echo off

@echo ========== Locating VSEWSS bin directory ==========
@set vsewssbin=%programfiles%\Microsoft SharePoint Developer Tools 9.0\svc\bin
if not exist "%vsewssbin%" set vsewssbin=%ProgramW6432%\Microsoft SharePoint Developer Tools 9.0\svc\bin
@echo VSEWSS bin: %vsewssbin%

@echo ========== Copying assemblies to VSEWSS bin directory ==========
@xcopy "%1*.dll" "%vsewssbin%" /R /Y

To use the script, create a bat file in your project and call it from a post build event. It does take 64-bit installations into account, and it will also work on your Team Build server.