Not sure if this belongs here or in SO but here goes anyway...
We have a CruiseControl.NET server that performs nightly builds on or applications and then publishes the resulting output to the IIS instance on the same box - this acts as out test deployment for QA.
Everything has been running fine for months until we moved to a new server (Win2003 R2 SP1) - actually a VM.
Now, whenever the nightly build publishes to IIS we get an error in the browser stating The compiler failed with error code 128. This never happened on the old server!
Running aspnet_regiis -i will get the site back online but I'm baffled as to why IIS seems to have forgotten all about .NET as the result of a simple file copy.
I've reviewed the publish stage of the build process and moved from the good old-fashioned batch script to a 'cleaner' nAnt script but the problem remains.
If I run the above command, clear out the events logs and then access the site a new event appears:
The configuration information of the performance library "C:\WINDOWS\system32\infoctrs.dll" for the "InetInfo" service does not match the trusted performance library information stored in the registry. The functions in this library will not be treated as trusted.
But the site does still load without any problems. If I then run either of the publish scripts (.bat or .build) then access the site another identical event appears and the compilation error is displayed (running aspnet_regiis fix it though).
If I manually delete the old files and copy across the new ones then once again the Compiler Error is displayed in the browser.
Now the quick fix is to run aspnet_regiis as part of the build script but frankly that just smells to bad.
[Edit 12/11/09]: I've been kicking this around for a little while now and still don't really know why it is happening. I've reinstalled IIS and .NET 2.0 & 3.0 (3.5 is not needed!) but the problem persisted. Finally I tried deploying the application using files built via a 'Release' build (as opposed to 'Debug') and this appears to have resolved the problem - but I don't know why.
I'll find out tomorrow morning after the nightly builds have run in anger so hopefully I have some good news waiting for me. Assuming this is the problem, why should it make a difference? This process was running fine for months on the physical server - why should it be causing problems on the VM.?
Anyone have any ideas, suggestions or solutions..? Thanks in advance