System.InvalidOperationException：類型[XYZ]可能不在此上下文中使用。 BUG確認

Question

在這個問題上，我的斗智斗勇。 我偶爾會從我的.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：

好的，更多信息。 我用斯科特Hanselman的博客文章在這里步入生成的程序集。 事實證明，盡管有XmlInclude，生成的程序集也沒有對其中的類型的引用，所以這絕對是.NET中的一個錯誤。 我試圖追蹤觸發它的是什么，但是產生輸出組件（sgen？）的東西都失敗了。

編輯＃7：

對於此后的任何人，我都向MS提交了一份錯誤報告：

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

Answer 1

我最好的猜測（這是一個猜測）是觸摸文件是一個紅色的鯡魚。 我認為任何重新編譯都更有可能清除這一點。 例如，您可以觸摸web.config以強制循環來證明或反駁我的假設。

我懷疑這是因為您收到的錯誤與序列化問題有關。 XML Serializer很困惑，認為它無法序列化您的某個類型。 因為你已經排除了許多常見的嫌疑，例如對象數組或包含其他本質上不可序列化的類型，我懷疑一個稱贊競爭條件，例如你的兩個程序集之間的循環引用是罪魁禍首。 這種特殊情況將通過第二次匯編清除。

注意：檢測循環引用的一個好工具是NDepend 。

如果它不是循環引用，您是在使用任何代碼生成器，使用任何構建提供程序還是使用反射來加載應用程序中的任何程序集或其他任何可能有點異國情調的程序集？

編輯：

根據你的評論，你沒有做任何異國情調。 因此，請檢查循環引用和（只是想到這一點）程序集之間存在沖突的依賴關系。 例如， SubSonic引用了許多程序集 ，如果您引用其中一個不同版本的程序集，它可以解釋它是如何工作一次的，並使用相同的代碼再次失敗。

Answer 2

好的，我有一個有效的解決方案，雖然我還不確定為什么。 這絕對是生成的代理程序集中的錯誤。 我發現生成的程序集有時會錯過XmlIncludes中包含的某些類型。 奇怪的是，它似乎是特定的類型，雖然我找不到一個模式為什么那些而不是其他人。

解決方案是創建一個部分類定義（它甚至在同一個文件中！）， 它只包含那些一直導致問題的特定類型的XmlIncludes。 從那以后，我根本沒有看到錯誤。

絕對是發電機某處的一個錯誤，雖然觸發它的是什么，我不知道。 希望這會幫助其他人在路上。

編輯 我相信我已經確認是什么導致了這個問題。 我在.NET 2.0項目中引用了為.NET框架v1.1構建的SharpZipLib。 當我構建app_code.dll時，它添加了對mscorlib 1.0.5的引用。 顯然，有這個額外的引用足以導致sgen不正確地生成調用Web服務時使用的臨時DLL。 因此，如果您遇到問題...在ILDASM中加載所有引用的程序集，請雙擊清單，並確認它們都不引用.NET 1.1。 如果他們這樣做......你就被軟管了。

顯然，這實際上沒有解決它，因為問題仍然存在，只是一個不同的類型失敗。