La respuesta corta es: no hay manera de dar a entender que el objeto está dispuesta en otro lugar.
Un poco de Reflector-ing (o dotPeek-ing, o lo que sea) explica por qué.
FxCop está en C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop
. (Ajuste según corresponda para su versión combo OS/VS.) Las reglas están en el subdirectorio Rules
.
En la carpeta principal FxCop
, abierta
Microsoft.VisualStudio.CodeAnalysis.dll
Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll
phx.dll
En la carpeta Rules
, abierta DataflowRules.dll
.
En DataflowRules.dll
encuentra Phoenix.CodeAnalysis.DataflowRules.DisposeObjectsBeforeLosingScope
. Esa es la clase real que hace la evaluación.
Mirando el código allí, puede ver dos cosas de interés con respecto a su pregunta.
- Utiliza un servicio compartido llamado
SharedNeedsDisposedAnalysis
.
- Es deriva de
FunctionBodyRule
.
El primer artículo es interesante porque SharedNeedsDisposedAnalysis
es lo que determina qué símbolos deben Dispose()
llamada. Es bastante completo, haciendo un "recorrido" por el código para determinar qué se debe desechar y qué se desecha realmente. Luego mantiene una tabla de esas cosas para su uso posterior.
El segundo elemento es interesante porque FunctionBodyRule
reglas evalúan el cuerpo de una sola función. Existen otros tipos de reglas, como FunctionCallRule
, que evalúan elementos como los miembros de llamada de función (por ejemplo, ProvideCorrectArgumentsToFormattingMethods
).
El punto es, entre el potencial de "miss" en ese SharedNeedsDisposedAnalysis
servicio en el que no puede ser recursiva a través de su método de ver que las cosas realmente están siendo eliminados y la limitación de FunctionBodyRule
no va más allá del cuerpo de la función, es sólo no atrapando su extensión.
Esta es la misma razón "funciones de guardia" como nunca se consiguen considerados como validar el argumento antes de usarla - FxCop todavía le dirá para comprobar el argumento a favor de nula a pesar de que eso es lo que la "función de protección" está haciendo .
Tiene básicamente dos opciones.
- Excluir problemas o desactivar la regla. No hay forma de que haga lo que usted quiere.
- Crea una regla personalizada/derivada que comprenderá los métodos de extensión. Usa tu regla personalizada en lugar de la regla predeterminada.
Después de haber escrito personalizado FxCop gobierna a mí mismo, yo lo haré saber lo encontré ... no trivial. Si avanza por ese camino, aunque la recomendación en el mundo es utilizar el nuevo estilo de regla de motor de Phoenix (eso es lo que usa el actual DisposeObjectsBeforeLosingScope
), me resultó más fácil entender las reglas FxCop SDK más antiguas/estándar (consulte FxCopSdk.dll
en la carpeta principal de FxCop). El reflector será de gran ayuda para descubrir cómo hacerlo, ya que hay prácticamente cero documentos sobre él. Consulte los otros ensambles en la carpeta Rules
para ver ejemplos de ellos.
Se muestra dice 'this.privateMember.Dispose()'. ¿Su código realmente dice 'this.privateMember.SafeDispose()'? –