2011-01-20 18 views
21

Ocasionalmente, veo que typeof(Foo) devuelve nulo. ¿Por qué sucedería esto?¿Por qué typeof (Foo) alguna vez devolvería nulo?

Esto está en C#, .NET 3.5.

Pensé que podría tener algo que ver con el ensamblaje que contiene el tipo que aún no se está cargando, pero una aplicación de prueba muestra que el ensamblaje se carga al inicio del método donde se usa typeof.

¿Alguna idea?


Actualización 1

  • no puedo proporcionar una muestra reproducible ya que esto sucede en una aplicación enorme
  • Cuando digo 'ocasionalmente' Quiero decir con el mismo método en mi solicitud pero durante varias instancias. Además, cuando falla una vez cuando se ejecuta, fallará cada vez para esa instancia de la aplicación.

Actualización 2

La aplicación en cuestión utiliza una cantidad enoooooooormes de la memoria y se ejecuta en 32 bits de XP. Estoy pensando que tal vez sea una excepción TypeLoadException o OutOfMemoryException que de alguna manera se está tragando (pero no puedo ver cómo, como he intentado esto con excepciones de primera oportunidad activadas en el depurador).


Actualización 3

se encontró con el mismo problema hace un momento. Aquí está el seguimiento de la pila: enter image description here El código hasta este punto es, literalmente, sólo:

Type tradeType = typeof(MyTradeType) 
TradeFactory.CreateTrade(tradeType) 

(antes, era ..CreateTrade(typeof(MyTradeType)) por lo no podía decir realmente si el typeof devuelve null)

Parece que typeof() no devuelve nulo pero se establece en nulo para cuando termina en el método CreateTrade.

La excepción (NullReferenceException) tiene una propiedad HResult de 0x80004003 (Invalid pointer). Una llamada al System.Runtime.InteropServices.Marshal.GetLastWin32Error() (en la ventana Inmediato) devuelve 127 (The specified procedure could not be found). He buscado en la ventana Módulos y el módulo que contiene este tipo y método se ha cargado y no parece haber ningún error de cargador.


+1

Interesante. ¿Puedes proporcionar una muestra de código que demuestre el problema? – Amy

+1

¿"Ocasionalmente" significa esporádicamente en la misma llamada o en ciertos lugares pero no en otros? – BoltClock

+4

Yo, por mi parte, no puedo imaginar ninguna manera de que esto pueda suceder. – leppie

Respuesta

2

Desde typeof(T) es un operador de tiempo de compilación no será involucrado el tiempo de carga del montaje.

Sería interesante ver algún código que así lo demuestre.

Aún más interesante para ver que sucede a veces y, a veces no.

Una primera respuesta podría ser: use GetType() en una instancia.

+1

La resolución es el tiempo de compilación, pero el cargador carga el módulo que contiene IFoo al comienzo del método. –

4

¿Ha fallado la carga del dll por algún motivo? Ha marcado el fusion logs.

Supongo que esto causaría más problemas que solo esto, pero si está haciendo esta comprobación antes de usar cualquier cosa del conjunto, puede estar ocultando cualquier otro problema.

1

typeof determina el tipo durante el tiempo de compilación. Entonces, incluso si devuelve nulo, entonces debería devolver nulo siempre. Porque el comportamiento no cambia durante el tiempo de ejecución. Dar un fragmento de código, algunas otras cosas están rotas.

+0

Pero no puedo ver cómo puede devolver nulo. Estoy tratando de reproducir una aplicación de prueba que usa mucha memoria ya que creo que es una excepción de carga de tipo que se está tragando. –

+1

@Steve No quise decir que typeof devolverá null. Pero dado que el tipo se deduce durante el tiempo de compilación, el comportamiento debe permanecer igual durante el tiempo de ejecución. No puede comportarse de manera diferente en diferentes momentos. Hasta donde sé, typeof nunca ha regresado nulo. – ferosekhanj

1

Esto es bastante posible y muy fácil de reproducir. typeof(T) devolverá nulo si el tipo se ha creado en la memoria. A través de System.Reflection.Emit por ejemplo.

1

Estaba teniendo este problema en mi proyecto VSPackage al usar typeof (MyClass) en el constructor del paquete. Moví mi código al método Initialize() anulado y luego funcionó bien, por lo que parece que el ensamblado no se está cargando aún puede ser un factor en este error algunas veces. Notaré también que mi VSPackage se carga en tiempo de ejecución en Visual Studio a través de MEF, por lo que probablemente este no sea el escenario habitual, pero aún así pensé que lo mencionaría.

Cuestiones relacionadas