System.InvalidOperationException: el tipo [XYZ] no se puede utilizar en este contexto. Error confirmado

Question

Estoy en mi extremo de los ingenios en este caso. Ocasionalmente recibo el error anterior de mi servicio web .Net 2.0 asmx. Tengo el XmlInclude adecuada() en su lugar, y que sólo aparece a veces - cuando uno vuelve a edificar y actualizar el sitio, puede que se muestre, no puede, sin orden ni concierto. Si muevo algunos de los XmlIncludes(), los reconstruyo y los realizo, el error por lo general desaparece.

Antes de tener el proceso de compilación en su lugar que convierte todo a una DLL, estaba usando el buen método de implementación de xcopy. El error ocurrió entonces, también, pero entonces todo lo que tenía que hacer era añadir un espacio para el archivo que define todo el XmlInclude() llama, e IIS sería recompilar y el error se iría.

Por lo que vale, hay un montón de XmlIncludes definidos, alrededor de 100 o menos.

¿Alguna idea?

He aquí un fragmento:

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

Editar: Parece que la reordenación de los XmlIncludes hace que el error desaparezca, pero puede o no volver la próxima vez que vuelva a compilar y volver a implementar.

Edit # 2: OK, algunos más detalles. Forzar un reciclaje al cambiar el archivo web.config no resuelve el problema ni reinicia completamente IIS. Por algún motivo, mi registro no se escribió correctamente, por lo que aún no tengo el seguimiento de la pila.

Esta vez, el error se estaba produciendo para 2 métodos específicos. Realicé un cambio en el archivo global.asax (para intentar corregir el registro de seguimiento de mi pila), reconstruí y actualicé, y uno de los dos métodos comenzó a funcionar. Luego dividí la clase con XmlIncludes en dos clases parciales, reconstruí, actualicé y ambos métodos comenzaron a funcionar nuevamente. No estoy seguro de si esto es una solución permanente o no en este momento, porque es muy aleatorio; Actualizaré en el próximo ciclo de compilación de nuevo.

Edit # 3: Definitivamente no es una solución permanente, y todavía no estoy enganchado en el lugar correcto para atrapar un rastro de pila completo (aunque mis otros registros están funcionando bien). Ugh. Actualizaré nuevamente la próxima ronda.

Edit # 4: Finalmente tenemos un seguimiento de pila. No captura en Visual Studio, ni en el controlador de excepción global en mi global.asax. Estos son los resultados que se muestran cuando se invoca el método directamente desde el navegador 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() 

Edición # 5:

Esto puede ser un síntoma del error anterior, así que no estoy convencido de que es relevante, pero lo publicaré de todos modos. Si hay que adjuntar a los Asistentes de depuración gestionadas y refrescar un montón, al final me sale:

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) 

No estoy seguro de que está relacionado ... podría ser sólo el flujo de error.

Edit # 6:

OK, más información. Utilicé la publicación de blog de Scott Hanselman here para entrar en el ensamblaje generado. Resulta que a pesar del XmlInclude, el ensamblaje generado NO tiene una referencia al tipo, por lo que definitivamente es un error en .NET. Estoy intentando rastrear qué lo desencadena, pero algo en lo que genere los ensamblados de salida (sgen?) Está fallando.

Edición # 7:

FYI para cualquier persona después de esto, me he presentado un informe de error a MS:

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

Answer 1

Mi mejor conjetura (y es una suposición) es que tocar el archivo es una pista falsa. Creo que es más probable que cualquier recompilación aclare esto. Por ejemplo, podría tocar el archivo web.config para forzar un reciclaje y probar o refutar mi suposición cuando esto ocurra.

La razón por la que sospecha que este es el error que está recibiendo se refiere a un problema de serialización. El Serializador XML se confunde al pensar que no puede serializar uno de sus tipos. Debido a que ha descartado muchos de los sospechosos más comunes, como matrices de objetos o la inclusión de otros tipos que no son serializables intrínsecamente, sospecho que una condición de carrera de compilación como una referencia circular entre dos de sus ensamblajes es la culpable. Este caso particular sería aclarado por una segunda compilación.

Nota: Una buena herramienta para detectar referencias circulares es NDepend.

Si no es una referencia circular, haces cualquier código gen, utilizando cualquier proveedor de construir o utilizar la reflexión para cargar los ensamblados en su aplicación o cualquier otra cosa que podría ser incluso un poco exótica?

Editar:

Basado en su comentario, usted no está haciendo nada exótico. Por lo tanto, compruebe referencias circulares y (solo se le ocurrió esto) dependencias conflictivas entre sus ensamblajes. Por ejemplo, SubSonic references a number of assemblies, y si hace referencia a uno de estos conjuntos de una versión diferente, que podría explicar cómo funciona una vez y no otra vez con el mismo código.

Answer 2

OK, tengo una solución que funciona, aunque todavía no estoy seguro de por qué. Esto es definitivamente un error en el ensamblaje proxy generado. Descubrí que el ensamblado generado algunas veces pasa por alto algunos de los tipos incluidos en los XmlIncludes. Curiosamente, parecía haber ciertos tipos específicamente, aunque no puedo encontrar un patrón de por qué esos y otros no.

La solución fue crear una definición de clase parcial (que es incluso en el mismo archivo!) Que tenía los XmlIncludes para sólo esos tipos particulares que estaban causando problemas constantemente. Desde entonces, no he visto el error en absoluto.

Definitivamente un error en algún lugar del generador, a pesar de lo que está provocando que no sé. Espero que esto ayude a alguien más en el camino.

EDITAR I belive he confirmado lo que causó el problema. Tenía una referencia a SharpZipLib, creado para .NET framework v1.1, en mi proyecto .NET 2.0. Cuando construí el app_code.dll, agregó una referencia a mscorlib 1.0.5. Aparentemente, tener esta referencia adicional fue suficiente para causar que sgen genere incorrectamente las DLL temporales utilizadas al invocar el servicio web. Entonces, si tiene el problema ... cargue todos los ensamblados a los que se hace referencia en ILDASM, haga doble clic en el manifiesto y confirme que ninguno de ellos hace referencia a .NET 1.1. Si lo hacen ... eres una manguera.

Aparentemente, esto en realidad no lo solucionó, ya que el problema persiste, solo que falla un tipo diferente.