System.InvalidOperationException: il tipo [XYZ] non può essere utilizzato in questo contesto. ERRORE Confermato

Question

Sono alle prese con questo spirito. Di tanto in tanto ricevo l'errore sopra dal mio servizio web asmx 2.0 .Net. Ho il giusto XmlInclude() sul posto, e appare solo a volte - quando ricostruisco e aggiorno il sito, può apparire, non può, nessuna rima o motivo. Se sposto alcune parti di XmlInclude(), ricostruisco e spingo le modifiche, l'errore di solito scompare.

Prima di eseguire il processo di generazione che converte tutto in una DLL, stavo utilizzando il buon vecchio metodo di distribuzione xcopy. L'errore è avvenuto anche allora, ma tutto quello che dovevo fare era aggiungere uno spazio al file che definiva tutte le chiamate XmlInclude() e IIS ricompilava e l'errore andava via.

Per quanto vale, ci sono un sacco di XmlIncludes definito, circa 100 o giù di lì.

Qualche idea?

Ecco un frammento:

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

Edit: Sembra che riordinando le XmlIncludes fa l'errore di andare via, ma può o non può tornare la prossima volta che ricompilare e ridistribuire.

Modifica # 2: OK, alcuni dettagli in più. Forzare un riciclo cambiando il web.config non risolve il problema, né riavvia completamente IIS. Per qualche ragione, il mio log non è stato scritto correttamente, quindi non ho ancora la traccia dello stack.

Questa volta, si è verificato l'errore per 2 metodi specifici. Ho apportato una modifica a global.asax (per tentare di correggere la registrazione dello stack trace), ricostruito e aggiornato e uno dei due metodi ha iniziato a funzionare. Ho quindi diviso la classe con XmlInclude su 2 classi parziali, ricostruita, aggiornata, ed entrambi i metodi hanno iniziato a funzionare di nuovo. Non sono sicuro che questa sia una correzione permanente o no in questo momento, perché è così casuale; Aggiornerò di nuovo il prossimo ciclo di costruzione.

Modifica # 3: Sicuramente non una correzione permanente, e non sto ancora agganciati al posto giusto per prendere una traccia stack completo (anche se i miei altri registri sono tutti lavorando bene). Ugh. Aggiornerò di nuovo il prossimo round.

Modifica n. 4: Infine disporre di una traccia dello stack. Non cattura in Visual Studio, né nel gestore di eccezioni globale nel mio global.asax. Ecco i risultati come visualizzati quando si richiama il metodo direttamente dal browser 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() 

Modifica # 5:

questo può essere un sintomo di errore di cui sopra, quindi non sono convinto che sia rilevante, ma lo pubblicherò comunque. Se io attribuisco agli Assistenti debug Managed e aggiornare un gruppo, alla fine ho capito:

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) 

io non sono sicuro che è legato ... potrebbe essere solo il flusso di errore.

Modifica # 6:

OK, maggiori informazioni. Ho usato il post sul blog di Scott Hanselman here per passare all'assemblaggio generato. Si scopre che nonostante XmlInclude, l'assembly generato NON ha un riferimento al tipo in esso, quindi questo è sicuramente un bug in .NET. Sto cercando di rintracciare ciò che lo innesca, ma qualcosa in ciò che genera gli assembly di output (sgen?) Sta fallendo.

Modifica # 7:

FYI per chiunque seguendo questo, ho presentato un bug report a MS:

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

Answer 1

La mia ipotesi migliore (ed è una supposizione) è che toccare il file è un'aringa rossa. Penso che sia più probabile che la ricompilazione di compaia con lo . Ad esempio, è possibile toccare web.config per forzare un riciclo a provare o confutare la mia ipotesi quando ciò accade.

La ragione per cui sospetto che questo sia l'errore che si riceve riguarda un problema di serializzazione. Il Serializer XML è confuso nel pensare di non poter serializzare uno dei tuoi tipi. Poiché hai escluso molti dei sospetti comuni come gli array di oggetti o l'inclusione di altri tipi che non sono serializzabili intrinsecamente, sospetto che una condizione di competizione come un riferimento circolare tra due dei tuoi assemblaggi sia da biasimare. Questo caso particolare verrebbe chiarito da una seconda compilation.

Nota: un buon strumento per rilevare i riferimenti circolari è NDepend.

Se non si tratta di un riferimento circolare, stai facendo codice gen, utilizzando qualsiasi provider di build o utilizzando reflection per caricare qualsiasi assembly nella tua app o qualsiasi altra cosa che potrebbe essere anche leggermente esotica?

Edit:

Sulla base di un commento, non si sta facendo nulla di esotico. Quindi, controllare i riferimenti circolari e (basti pensare a ciò) le dipendenze in conflitto tra tra i vostri assiemi. Ad esempio, SubSonic references a number of assemblies e se si fa riferimento a uno di questi assembly di una versione diversa, potrebbe spiegare come funziona una volta e non riesce un'altra volta con lo stesso codice.

Answer 2

OK, ho una soluzione che funziona, anche se non sono ancora sicuro del perché. Questo è sicuramente un bug nell'assembly proxy generato. Ho trovato che l'assembly generato a volte manca solo alcuni dei tipi inclusi in XmlInclude. Stranamente, sembra che alcuni tipi siano specifici, anche se non riesco a trovare un modello sul perché quelli e non altri.

La soluzione era di creare una definizione di classe parziale (è anche nello stesso file!) Che aveva XmlInclude per solo quei tipi particolari che causavano costantemente problemi. Da allora, non ho visto l'errore.

Sicuramente un bug da qualche parte nel generatore, anche se ciò che lo sta attivando non lo so. Spero che questo possa aiutare qualcun'altro in fondo alla strada.

EDIT Credo di aver confermato cosa ha causato il problema. Ho avuto un riferimento a SharpZipLib, creato per .NET framework v1.1, nel mio progetto .NET 2.0. Quando ho creato l'app_code.dll, ha aggiunto un riferimento a mscorlib 1.0.5. Apparentemente, avere questo riferimento aggiuntivo è stato sufficiente per indurre sgen a generare in modo errato le DLL temporanee utilizzate durante il richiamo del servizio web. Quindi, se hai il problema ... carica tutti gli assembly di riferimento in ILDASM, fai doppio clic sul manifest e conferma che nessuno di loro fa riferimento a .NET 1.1. Se lo fanno ... tu sei protetto.

Apparentemente, questo in realtà non lo ha risolto, poiché il problema è ancora in vigore, solo con un diverso tipo in errore.