Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question

It could be related to the default framework of a web site, 1.1 or 2.0. aspnet_regiis sets the framework version.

If you:

  • Install windows
  • Run all windows updates
  • Add application role


  • Install windows
  • Add application role
  • Run all windows updates

Then the default framework is not the same. It could also be that you install is setting the framework version.

share|improve this answer
Not heard of that before but then I'm a Dev not a SysAdmin ;-) I'll check when I get into work tomorrow – DilbertDave Sep 27 '09 at 18:43
Didn't get to it as quickly as I'd hoped - now the dev manager wants to demo from the test servers it's a priority, so I'm looking now. Will post updates back here if i get to the bottom of it :-\ – DilbertDave Nov 3 '09 at 13:41

The VM itself isn't being rolled back, is it?

share|improve this answer
The VM is backed up on a regular basis but not rolled back. It just seems to happen whenever I publish the build, i.e. not related to backup times etc. – DilbertDave Oct 9 '09 at 9:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.