SN.EXE and Empty Temp Files in %TEMP%
If you have a build server and are doing delay signing this is probably of interest to you. When delay signing the final step is to post build run the following command:
sn -R myAssembly.dll sgKey.snk
I have seen build setups that basically output all binaries to one folder and then run a loop across all the DLLs executing this command. That way everything is fixed up and ready for the devs to run. This way you do not have to worry about adding a post build step to each project or you can add one common script to each project. The release builds of course get fully signed but for daily/rolling builds this works just fine. Until you check out your temp directory.
It turns out for each call to SN.EXE a TMP file is generated. These TMP files look like this:
Volume in drive C has no label.
Volume Serial Number is 1450-ABCF
Directory of C:\temp
12/11/2007 12:39 PM <DIR> .
12/11/2007 12:39 PM <DIR> ..
12/11/2007 11:17 AM 0 Tmp917.tmp
12/11/2007 11:17 AM 0 Tmp91C.tmp
12/11/2007 11:17 AM 0 Tmp921.tmp
You probably noticed that these are 0 byte files which means space is not an issue but if you have a ton of these it can slow your hard drive down. Also, the actual SN.EXE process can start slowing down.
If you have 100 DLLs and are doing 30 builds a day that is 3,000 temp files. Now, let’s say you build debug x86, debug x64, release x86 and release x64 that is now up to 12,000. After a couple of days you could imagine how many files.
I was working on this and we found out that SN.EXE is not actually the problem here (Thanks to Scot Brennecke). The issue is in the Crypto APIs that SN.EXE uses. These APIs are the ones that create and do not clean up the TMP files. It turns out that there is a hotfix for this if you are using Windows Server 2003:
On a Windows Server 2003-based client computer, the system does not delete a temporary file that is created when an application calls the "CryptQueryObject" function
After applying this hotfix the temp files are no longer created and life was happy. I just thought I would share because the connection between this hotfix and the problem was not immediately obvious.
Have a great day!