2008-10-24 13 views
5

Estoy usando 3.5 SP1 en mi máquina, mientras que nuestros clientes actualmente usan 3.5 sin SP1. No conozco ninguna forma en VS2008 para dirigir la solución o proyecto a 3.5 sin SP1, solo el 3.5 con SP1 que tengo instalado.Detectar .NET Framework 3.5 SP1 Dependencia (cmp. 3.5 w/o SP1)

Si utilizamos funciones o constructores no disponibles en 3.5 w/o SP1, el código no funcionará correctamente.

Es decir, quiero detectar en tiempo de compilación lo que no funcionaría sin SP1.

Hasta ahora hemos realizado pruebas (en una máquina virtual o máquina separada) para ver si la aplicación se rompe, y se rompe algunas veces cuando hemos utilizado partes de la API no disponibles hasta SP1. El problema es que solo se rompe cuando el código realmente se ejecuta (en tiempo de ejecución), no cuando se carga el ensamblado.

Una solución sería tener una máquina con VS2008 sin SP1 e intentar compilar el proyecto. Sin embargo, preferiría alguna herramienta que me ayude a detectar una dependencia de 3.5 SP1 (debido al uso de la nueva API, o lo que sea), ya sea analizando el código fuente o los ensamblajes que producimos.

Mi poderes de google no ha sido lo suficientemente fuerte con esta pregunta, ¿alguna pista?

Respuesta

5

Acabo de tener el mismo problema, y ​​encontré una solución. Para nuestra aplicación, fue una llamada a System.Threading.WaitHandle.WaitOne (Int32) que nos metió en problemas. Para obtener más detalles sobre cómo las referencias a las API que se introdujeron en las versiones del paquete de servicio pueden filtrarse en su código sin que Visual Studio lo note, consulte Krzysztof Cwalina's post.

La buena noticia es que, como Marc mentioned is his answer, FxCop tiene un new rule que detecta estas fugas. La mala noticia es que la regla está quebrada en FxCop 1.36 cuando apuntas a .NET Framework 3.5. Sin embargo, David Kean describe cómo editar un par de archivos de configuración XML en fix the problem. Seguí las instrucciones y FxCop ahora detecta mis referencias a las API del paquete de servicios.

2

¿Qué tal this? (reglas de destino múltiple para FxCop)

+0

Acabo de probar FxCop 1.36 (independiente). Utilizando una versión de nuestra aplicación que se sabe que usa la API SP1, aún no pude ubicar los usos de 3.5SP1. –

1

Puede usar el código encontrado here para detectar los Frameworks .NET instalados.

+0

Gracias, pero ya sé exactamente qué versión está instalada. Este es un producto interno, y el ambiente está bien especificado. Los problemas que estamos teniendo es no utilizar accidentalmente el código del SP1 ya que las estaciones de trabajo no pueden ejecutarlo. –

0

cadena Fx35RegistryKey = @ "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ NET Framework Setup \ NDP \ v3.5"; objeto Fx35ServicePack = Registry.GetValue (Fx35RegistryKey, "SP", nulo);

if (Fx35ServicePack == null || (int) Fx35ServicePack < 1) throw new Exception (se requiere ".NET Framework 3.5 SP1.");

+0

Esto es similar a un answear anterior y también solo funciona en tiempo de ejecución. Mi pregunta es principalmente sobre algo durante el tiempo de compilación. –

0

Hay otra opción que no he probado. El Visual Studio documentation dice que puede hacer que su instalador ClickOnce se dirija específicamente al framework .NET 3.5SP1. Siga el enlace y busque "Orientación .NET Framework versión 3.5 SP1". Básicamente, indica que al hacer cualquiera de las siguientes acciones, se forzará al instalador a instalar 3.5SP1:

  • Especifique una URL de error en el cuadro de diálogo Opciones de publicación.
  • Especifique un nombre de Suite en el cuadro de diálogo Opciones de publicación.
  • Cree un acceso directo en el escritorio en el cuadro de diálogo Opciones de publicación.
  • Excluir un archivo del hash en el cuadro de diálogo Archivos de la aplicación.
  • Desactive la casilla de verificación Firmar el ClickOnce manifiesta en la página Firma.
  • Agregue una referencia al ensamblado System.Data.Entity.
Cuestiones relacionadas