Ich bin in dieser Sache mit meinem Latein am Ende. Ich bekomme gelegentlich den Fehler oben von meinem .Net 2.0 asmx Webdienst. Ich habe die richtige XmlInclude() an Ort und Stelle, und es erscheint nur manchmal - wenn ich neu erstellen und aktualisieren Sie die Website, kann es zeigen, kann es nicht, keinen Reim oder Grund. Wenn ich einige der XmlIncludes() verschiebe, neu aufbaue und die Änderungen nach oben schiebe, verschwindet der Fehler normalerweise.
Bevor ich den Build-Prozess eingerichtet habe, der alles in eine DLL umwandelt, habe ich die gute alte xcopy-Bereitstellungsmethode verwendet. Der Fehler trat auch dann auf, aber dann musste ich nur ein Leerzeichen in die Datei einfügen, die alle XmlInclude()-Aufrufe definierte, und IIS kompilierte neu und der Fehler verschwand.
Für was es Wert ist, gibt es eine Menge von XmlIncludes definiert, etwa 100 oder so.
Irgendwelche Ideen?
Hier ist ein Ausschnitt:
namespace Courses{
[Serializable]
[XmlInclude(typeof(UserToCourse)),
XmlInclude(typeof(UserToCourseCollection)),
// ...lots more....
XmlInclude(typeof(ReadOnlySearchResultsRecordset<UserToCourse, UserToCourseCollection>)),
XmlInclude(typeof(AllCoursesByTrainingProgramCollection)),
XmlInclude(typeof(StartupObject))]
public partial class ServiceCallResult{
//..snipped class def
}
}Bearbeiten: Es scheint, dass das Umordnen der XmlIncludes den Fehler verschwinden lässt, aber es kann oder kann nicht zurückkommen, wenn ich das nächste Mal neu kompilieren und erneut bereitstellen.
Bearbeiten #2: OK, einige weitere Details. Das Erzwingen eines Recyclings durch Ändern der web.config löst das Problem nicht, ebenso wenig wie ein kompletter Neustart des IIS. Aus irgendeinem Grund hat mein Protokoll nicht richtig geschrieben, so dass ich die Stapelverfolgung noch nicht habe.
Dieses Mal trat der Fehler bei 2 bestimmten Methoden auf. Ich nahm eine Änderung an der global.asax vor (um zu versuchen, meine Stack-Trace-Protokollierung zu beheben), erstellte und aktualisierte sie neu, und eine der beiden Methoden begann zu funktionieren. Dann habe ich die Klasse mit den XmlIncludes in 2 Teilklassen aufgeteilt, neu erstellt und aktualisiert, und beide Methoden funktionierten wieder. Ich bin nicht sicher, ob dies eine dauerhafte Lösung ist oder nicht in diesem Moment, weil es so zufällig ist; Ich werde auf dem nächsten Build-Zyklus wieder aktualisieren.
Bearbeiten #3: Definitiv keine dauerhafte Lösung, und ich bin immer noch nicht an der richtigen Stelle eingehängt, um einen vollständigen Stack-Trace zu erhalten (obwohl meine anderen Logs alle einwandfrei funktionieren). Igitt. Ich werde in der nächsten Runde wieder aktualisieren.
Bearbeiten #4: Endlich habe ich einen Stack-Trace. Es fängt weder in Visual Studio noch im globalen Exception Handler in meiner global.asax. Hier sind die Ergebnisse, die angezeigt werden, wenn ich die Methode direkt vom Webbrowser aus aufrufe:
System.InvalidOperationException: There was an error generating the XML document. ---> System.InvalidOperationException: The type System.String[] may not be used in this context.
at System.Xml.Serialization.XmlSerializationWriter.WriteTypedPrimitive(String name, String ns, Object o, Boolean xsiType)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriter1.Write1_Object(String n, String ns, Object o, Boolean isNullable, Boolean needType)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriter1.Write119_ServiceCallResult(String n, String ns, ServiceCallResult o, Boolean isNullable, Boolean needType)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriter1.Write397_ServiceCallResult(Object o)
at Microsoft.Xml.Serialization.GeneratedAssembly.ServiceCallResultSerializer277.Serialize(Object objectToSerialize, XmlSerializationWriter writer)
at System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id)
--- End of inner exception stack trace ---
at System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id)
at System.Xml.Serialization.XmlSerializer.Serialize(TextWriter textWriter, Object o, XmlSerializerNamespaces namespaces)
at System.Xml.Serialization.XmlSerializer.Serialize(TextWriter textWriter, Object o)
at System.Web.Services.Protocols.XmlReturnWriter.Write(HttpResponse response, Stream outputStream, Object returnValue)
at System.Web.Services.Protocols.HttpServerProtocol.WriteReturns(Object[] returnValues, Stream outputStream)
at System.Web.Services.Protocols.WebServiceHandler.WriteReturns(Object[] returnValues)
at System.Web.Services.Protocols.WebServiceHandler.Invoke()Bearbeiten #5:
Dies kann ein Symptom des obigen Fehlers sein, daher bin ich nicht überzeugt, dass es relevant ist, aber ich werde es trotzdem veröffentlichen. Wenn ich zu den verwalteten Debug-Assistenten anhängen und aktualisieren ein Bündel, bekomme ich schließlich:
Managed Debugging Assistant 'StreamWriterBufferedDataLost' has detected a problem in 'C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.EXE'.
Additional Information: A StreamWriter was not closed and all buffered data within that StreamWriter was not flushed to the underlying stream. (This was detected when the StreamWriter was finalized with data in its buffer.) A portion of the data was lost. Consider one of calling Close(), Flush(), setting the StreamWriter's AutoFlush property to true, or allocating the StreamWriter with a "using" statement. Stream type: System.Web.HttpResponseStream
File name: <unknown>
Allocated from:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.IO.StreamWriter.Init(Stream stream, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter..ctor(Stream stream, Encoding encoding)
at System.Web.Services.Protocols.XmlReturnWriter.Write(HttpResponse response, Stream outputStream, Object returnValue)
at System.Web.Services.Protocols.HttpServerProtocol.WriteReturns(Object[] returnValues, Stream outputStream)
at System.Web.Services.Protocols.WebServiceHandler.WriteReturns(Object[] returnValues)
at System.Web.Services.Protocols.WebServiceHandler.Invoke()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context)
at System.Web.Script.Services.ScriptHandlerFactory.HandlerWrapper.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
at System.Web.HttpRuntime.ProcessRequest(HttpWorkerRequest wr)
at Microsoft.VisualStudio.WebHost.Request.Process()
at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)Ich bin mir nicht sicher, ob es damit zusammenhängt... es könnte nur der Fehlerstrom sein.
Bearbeiten #6:
OK, mehr Informationen. Ich habe Scott Hanselman's Blog Post verwendet ici um die erzeugte Baugruppe zu betreten. Es stellt sich heraus, dass trotz der XmlInclude, die generierte Baugruppe NICHT einen Verweis auf den Typ in ihm haben, so dass dies definitiv ein Fehler in .NET ist. Ich versuche zu verfolgen, was es auslöst, aber etwas in was auch immer generiert die Ausgabe-Assemblies (sgen?) ist fehlgeschlagen.
Bearbeiten #7:
Zu Ihrer Information für alle, die das hier verfolgen: Ich habe einen Fehlerbericht an MS geschickt:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=523253
