It has taken us a considerable amount of time to prepare the sources for SP1, test the RSCC package, and do the deployment. During the past months we have already put a a lot of thought into this problem and we will be changing the way the RSCC process is integrated in the development of the .NET framework. For the .NET Framework 3.5 and .NET Framework 3.5 SP1 release our process was optimized to start the source preparation process after the final build of the assemblies was done. For the upcoming releases we will be making the RSCC process part of our static analysis quality gate and as such make sure that the sources are RSCC ready at all times. Here's an overview of the differences between the processes:

.NET Framework 3.5 and .NET Framework 3.5 SP1 process

1. Find the PDB that was built with the release version of the assembly. 
2. Extract the source code of each file used to build the PDB.
3. Source code cleanup for the entire source tree:
   1. Policheck scan
   2. Removal of developer names
   3. Adding of a standard copyright banner
   4. etc. 
4. Run a visual pass on all the comments
5. Remove certain comments and sections of code that we can't share 
6. Generate RSCC package
7. Commit changes to source control

RSCC as a quality gate for upcoming releases

1. Add RSCC build step to MSBuild
2. Source code analysis during build (Policheck scan, etc)
3. Remove comments and sections of code that you don't want to share for the check-in 
4. Code and comments review for the pending check-in
5. Developer commits changes to source control
6. Generate RSCC package gets done on a daily basis on the build server

What's the difference?

The biggest difference is that with the new process developers will make sure that the code they write is RSCC ready before they check their source code in. By doing this on an ongoing basis we hope to significantly reduce the overhead of releasing the .NET Framework source code.