Problems with NotFound errors and compilation failures

We're getting errors every so often with a WCF service (consumed by Silverlight) that don't give us much to go on:

The service '/ourservice.svc' cannot be activated due to an exception during compilation.  
The exception message is: Object reference not set to an instance of an object.. ---> 
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Web.Compilation.DiskBuildResultCache.CacheBuildResult(String cacheKey, BuildResult result, Int64 hashCode, DateTime utcStart)
   at System.Web.Compilation.BuildManager.CacheBuildResultInternal(String cacheKey, BuildResult result, Int64 hashCode, DateTime utcStart)
   at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)

The service compiles/runs fine whenever I use it via the browser or using the silverlight client. The Silverlight side of the system reports this also equally un-helpful error:

System.ServiceModel.CommunicationException: 
[HttpWebRequest_WebException_RemoteServer]Arguments: NotFound

The only lead I've managed to find is possibly changing the instancing behaviour but I'm not sure why we would need to do that, and I can't tell what the default is anyway.

• It's hosted on Windows 2008 SP1
开发者_JAVA技巧
• The server is behind a load balancer
• The timeouts in the web.config for the service are 5 minutes
• The maximum object size is 50000000
• The services have AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)

Any suggestions would be great

Update

This is another symptom - the Silverlight client frequently sends this exception to our logging service (which writes to the event log + emails)

There was an error saving the report - The error object contained errors
System.ServiceModel.CommunicationException: [HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.60129.0&File=System.Windows.dll&Key=HttpWebRequest_WebException_RemoteServer ---> System.Net.WebException: [HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.60129.0&File=System.Windows.dll&Key=HttpWebRequest_WebException_RemoteServer ---> System.Net.WebException: [HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.60129.0&File=System.Windows.dll&Key=HttpWebRequest_WebException_RemoteServer
   at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
   at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
   at System.Net.Browser.AsyncHelper.<>c__DisplayClass4.<BeginOnUI>b__1(Object sendState)
   --- End of inner exception stack trace ---
   at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
   at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
   --- End of inner exception stack trace ---
   at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
   at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
   at MyNamespaceSilverlight.Core.ReportServiceReference.ReportServiceClient.ReportServiceClientChannel.EndUpdateReport(IAsyncResult result)
   at MyNamespaceSilverlight.Core.ReportServiceReference.ReportServiceClient.MyNamespaceSilverlight.Core.ReportServiceReference.IReportService.EndUpdateReport(IAsyncResult result)
   at MyNamespaceSilverlight.Core.ReportServiceReference.ReportServiceClient.OnEndUpdateReport(IAsyncResult result)
   at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)

Is anything in the service modifying the contents of the \bin directory? When hosting under ASP.NET, the ASP.NET runtime will monitor the \bin directory for any changes and, when a change is seen, it will attempt to reinitialize the application so that it picks up whatever changes there might have been.

You should not have anything writing to the \bin directory as part of your service's normal operation. Usually this is a problem with log files being configured to write to the \bin directory rather than a specific directory of their own. If you are unable to write the log files someplace outside the root of your application directory for whatever reason, just write them into a \logs sub-directory and configure ASP.NET to block all access to that directory like so:

<location path="logs">
    <system.web>
        <authorization>
            <deny users="*" />
        </authorization>
    </system.web>
</location>

A similar problem is reported here: Service activation problem that seems to be related to log files.

Looks like a bug in System.Web. Same issue is reported here: http://connect.microsoft.com/VisualStudio/feedback/details/550511/nullreferenceexception-during-service-compilation.

The jury is still out, but I think you have better chances of getting this issue resolved if you post your details on http://connect.microsoft.com.

We've received the similar error during testing of WCF services, when one of the developers started a deployment of a new version of the service.