7

我在这件事上束手无策。我偶尔会从我的 .Net 2.0 asmx Web 服务中收到上述错误。我已经安装了正确的 XmlInclude(),它只是有时出现——当我重建和更新站点时,它可能会出现,也可能不会出现,没有押韵或原因。如果我移动一些 XmlIncludes()、重建并向上推送更改,错误通常会消失。

在将所有内容转换为 DLL 的构建过程到位之前,我使用的是良好的 ol xcopy 部署方法。然后错误也发生了,但我所要做的就是在定义所有 XmlInclude() 调用的文件中添加一个空格,然后 IIS 将重新编译,错误就会消失。

对于它的价值,定义了很多 XmlIncludes,大约 100 个左右。

有任何想法吗?

这是一个片段:

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
    }
}

编辑:似乎重新排列 XmlIncludes 会使错误消失,但它可能会或可能不会在我下次重新编译和重新部署时再次出现。

编辑#2:好的,更多细节。通过更改 web.config 强制回收不能解决问题,也不能完全重新启动 IIS。由于某种原因,我的日志没有正确写出,所以我还没有堆栈跟踪。

这一次,错误发生在 2 个特定方法上。我对 global.asax 进行了更改(以尝试修复我的堆栈跟踪日志记录),重新构建和更新,两种方法之一开始工作。然后,我将带有 XmlIncludes 的类拆分为 2 个部分类,重新构建、更新,这两种方法都重新开始工作。我现在不确定这是否是永久修复,因为它是如此随机;我将再次更新下一个构建周期。

编辑#3:绝对不是永久修复,我仍然没有找到正确的位置来捕获完整的堆栈跟踪(尽管我的其他日志都工作正常)。啊。下一轮我会再更新。

编辑#4:最后有一个堆栈跟踪。它不会在 Visual Studio 中捕获,也不会在我的 global.asax 中的全局异常处理程序中捕获。以下是直接从 Web 浏览器调用该方法时显示的结果:

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()

编辑#5:

这可能是上述错误的症状,所以我不相信它是相关的,但我还是会发布它。如果我附加到托管调试助手并刷新一堆,我最终会得到:

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)

我不确定它是否相关......可能只是错误流。

编辑#6:

好的,更多信息。我在这里使用了 Scott Hanselman 的博客文章进入生成的程序集。事实证明,尽管有 XmlInclude,但生成的程序集没有对其中类型的引用,所以这绝对是 .NET 中的一个错误。我试图追查是什么触发了它,但是任何生成输出程序集(sgen?)的东西都失败了。

编辑#7:

仅供参考,我已向 MS 提交了错误报告:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=523253

4

2 回答 2

1

我最好的猜测(这是一个猜测)是触摸文件是一个红鲱鱼。我认为任何重新编译都更有可能解决这个问题。例如,当发生这种情况时,您可以触摸 web.config 以强制回收以证明或反驳我的假设。

我怀疑这是因为您收到的错误与序列化问题有关。XML Serializer 误以为它不能序列化您的一种类型。因为您已经排除了许多常见的嫌疑人,例如对象数组或包含其他本质上不可序列化的类型,所以我怀疑编译竞争条件(例如两个程序集之间的循环引用)是罪魁祸首。这种特殊情况将通过第二次编译来清除。

注意:检测循环引用的好工具是NDepend

如果它不是循环引用,您是否正在执行任何代码生成、使用任何构建提供程序或使用反射在您的应用程序中加载任何程序集或其他任何可能有点异国情调的东西?

编辑:

根据您的评论,您没有做任何异国情调的事情。因此,请检查您的程序集之间的循环引用和(只是想到这一点)冲突的依赖关系。例如,SubSonic 引用了许多程序集,如果您引用其中一个不同版本的程序集,它可以解释它是如何工作的,而另一次使用相同的代码会失败。

于 2009-10-25T17:22:33.127 回答
0

好的,我有一个可行的解决方案,尽管我仍然不确定为什么。这绝对是生成的代理程序集中的一个错误。我发现生成的程序集有时只是遗漏了 XmlIncludes 中包含的一些类型。奇怪的是,它似乎是特定的类型,尽管我找不到为什么这些类型而不是其他类型的模式。

解决方案是创建一个部分类定义(它甚至在同一个文件中!),它只包含那些始终导致问题的特定类型的 XmlIncludes。从那以后,我根本没有看到错误。

绝对是生成器某处的错误,尽管我不知道是什么触发了它。希望这会帮助其他人。

编辑 我相信我已经确认了导致问题的原因。在我的 .NET 2.0 项目中,我引用了为 .NET 框架 v1.1 构建的 SharpZipLib。当我构建 app_code.dll 时,它添加了对 mscorlib 1.0.5 的引用。显然,拥有这个额外的引用足以导致 sgen 不正确地生成调用 Web 服务时使用的临时 DLL。因此,如果您有问题...在 ILDASM 中加载所有引用的程序集,双击清单,并确认它们都没有引用 .NET 1.1。如果他们这样做......你会被冲洗掉。

显然,这实际上并没有解决它,因为问题仍然存在,只是不同类型的失败。

于 2009-12-03T17:06:40.803 回答