microsoft - Detectar la dependencia de.NET Framework 3.5 SP1(cmp. 3.5 w/o SP1)

net framework 3.5 windows 10 offline

Question

Estoy usando 3.5 SP1 en mi máquina, mientras que nuestros clientes actualmente usan 3.5 sin SP1. No sé de ninguna manera en VS2008 dirigir la solución o proyecto a 3.5 sin SP1, solo el 3.5 con SP1 que tengo instalado.

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 VM o en una máquina separada) para ver si la aplicación se rompe, y se rompe algunas veces cuando hemos usado partes de la API que no están 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 a 3.5 SP1 (debido al uso de API nuevas, o lo que sea), ya sea analizando el código fuente o los ensamblajes que producimos.

Mis poderes de google no han sido lo suficientemente fuertes con esta pregunta, ¿alguna pista?

Answer 1

Puede usar el código que se encuentra aquí para detectar los Frameworks .NET instalados.

Answer 2

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) lanza una nueva Excepción (se requiere ".NET Framework 3.5 SP1.");

Answer 3

Hay otra opción que no he probado. La documentación de Visual Studio 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". Esencialmente, dice que hacer lo siguiente obligará 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.
• Excluya 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.

Answer 4

Simplemente tuve 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 la publicación de Krzysztof Cwalina .

La buena noticia es que, como Marc mencionó es su respuesta , FxCop tiene una nueva regla 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 para solucionar el problema . Seguí las instrucciones y ahora FxCop detecta mis referencias a las API del paquete de servicios.

Answer 5

¿Qué tal esto ? (reglas de objetivos múltiples para FxCop)