¿Almacena SDK de Windows en el control de código fuente?

La pregunta está al final: permítanme comenzar presentando el context:

Uno de los problemas que enfrentamos cuando trabajamos con Visual Studio es asegurarnos de que todos en el equipo usen la misma versión de los SDK.

Un problema típico sería pedirle a alguien que use una versión diferente de Direct X SDK que resulte en un comportamiento diferente del código, o alguien que actualice a una Plataforma / SDK de Windows más reciente para usar alguna API nueva y hacer que el código falle en otros progtwigdores. máquinas si todavía usan la versión anterior.

Una forma en que solíamos resolver el problema para otro middleware ha sido colocar todo el set de bibliotecas, incluidos files, cadenas de herramientas, etc. en nuestro sistema de control de fuente, y tener nuestros proyectos para usarlas, de modo que nadie tenga que instalar nada . También logramos hacer eso con la versión anterior de Direct X SDK, pero siempre tuvimos problemas con Windows / Platform SDK debido a los vínculos cercanos entre el SDK y la cadena de herramientas.

Como ahora debemos admitir VS2010 y VS2012, y tenemos que admitir desde Windows XP a los objectives de Windows 8, debemos admitir los sets de herramientas v100 , v110 y v110_xp .

Esto significa que necesitamos todos los comstackdores asociados y los SDK correspondientes, tanto en nuestras máquinas de desarrollo como en los sistemas de compilation: Esto se vuelve ridículamente costoso de mantener, especialmente teniendo en count que las actualizaciones aleatorias de Windows y las versiones de .NET Framework tienden a romper msbuild.

Entonces la pregunta es:

  • ¿Es posible tener Visual Studio para usar juegos de herramientas y SDK no instalados y en su lugar hacer que use lo que está disponible en alguna carpeta fuera de las ubicaciones normales de installation de VS?

  • Pregunta de bonificación: si es factible, es posible hacerlo sin tener que cambiar ningún file de configuration instalado localmente en la máquina, es decir: tener todo eso en la solución / proyecto o en las hojas de properties, así que si cambiamos la estructura en la fuente sistema de control no tenemos que actualizar cada máquina individualmente?

Gracias 🙂

Esto parece demasiado complicado, dado lo complejas que son algunas de estas instalaciones de herramientas. Resolvería este problema invirtiendo en algunos scripts de PowerShell que analicen las herramientas instaladas y las routes de herramientas y "controle" las instalaciones. Sería relativamente fácil verificar las versiones instaladas de todo, incluidos los parches y las actualizaciones. Puede ejecutarlas todas las noches o como parte de una compilation. Además, puede comparar aspectos de diferentes instalaciones, como las versiones de herramientas instaladas en una caja de desarrollador con su server de compilation.

Esto le daría el 90% del valor del 10% del dolor.

Los problemas que describes no se resuelven con tu enfoque. Lo que realmente necesita es un server de compilation y una definición de hecho que incluya el uso de binarys creados con el server de compilation. También necesita un banco de testings como parte de la definición de compilation con algunas invariantes relacionadas con el entorno de compilation utilizado.