He escrito un código que hace uso de una biblioteca de código abierto para hacer algo de trabajo pesado. Este trabajo se realizó en Linux, con pruebas unitarias y cmake para ayudar a portarlo a Windows. Hay un requisito para ejecutarlo en ambas plataformas.Trabajando con Visual Studios C++ manifest files
Me gusta Linux y me gusta cmake y me gusta que pueda obtener archivos de estudios visuales generados automáticamente. Como está ahora, en Windows todo se compilará y se vinculará y generará los ejecutables de prueba.
Sin embargo, para llegar a este punto tuve que luchar con Windows durante varios días, aprendiendo todo sobre archivos manifiestos y paquetes redistribuibles.
En lo que a mi entender va:
Con VS 2005, Microsoft creó lado a dlls secundarios. La motivación para esto es que antes, múltiples aplicaciones instalarían diferentes versiones del mismo dll, causando que las aplicaciones previamente instaladas y en funcionamiento colapsen (es decir, "Dll Hell"). Dobles de lado a lado corrigen esto, ya que ahora hay un "archivo de manifiesto" adjunto a cada ejecutable/dll que especifica qué versión se debe ejecutar.
Esto está muy bien. Las aplicaciones ya no deberían fallar misteriosamente. Sin embargo ...
Microsoft parece lanzar un nuevo conjunto de dlls de sistema con cada versión de Visual Studios. Además, como mencioné anteriormente, soy un desarrollador que intenta vincular a una biblioteca de terceros. A menudo, estas cosas se distribuyen como un "dll precompilado". Ahora, ¿qué sucede cuando un dll precompilado compilado con una versión de estudios visuales está vinculado a una aplicación que utiliza otra versión de estudios visuales?
Por lo que he leído en Internet, sucede algo malo. Afortunadamente, nunca llegué tan lejos: me encontré con el problema "MSVCR80.dll no encontrado" al ejecutar el ejecutable y así comencé mi incursión en todo este problema de manifiesto.
Finalmente llegué a la conclusión de que la única forma de hacer que esto funcione (además de vincular estáticamente todo) es que todas las bibliotecas de terceros deben compilarse utilizando la misma versión de Visual Studios, es decir, no usar dll precompilados. descarga la fuente, construye una nueva dll y úsalo en su lugar.
¿Es esto verdad? ¿Me he perdido algo?
Además, si este parece ser el caso, entonces no puedo evitar pensar que Microsoft lo hizo a propósito por nefastos motivos.
No solo rompe todos los binarios precompilados, por lo que es innecesariamente difícil usar binarios precompilados, si trabaja para una empresa de software que hace uso de bibliotecas propietarias de terceros, y siempre que actualicen a la última versión de estudios visuales - su empresa ahora debe hacer lo mismo o el código ya no se ejecutará.
Como un lado, ¿cómo lo evita Linux? Aunque dije que prefería desarrollar y entiendo la mecánica de los enlaces, no he mantenido ninguna aplicación lo suficiente como para encontrarme con este tipo de problema de versiones de bibliotecas compartidas de bajo nivel.
Finalmente, para resumir: ¿es posible usar binarios precompilados con este nuevo esquema de manifiesto? Si es así, ¿cuál fue mi error? Si no es así, ¿piensa honestamente Microsoft que esto facilita el desarrollo de aplicaciones?
Actualización - Una pregunta más concisa: ¿Cómo evita Linux el uso de los archivos Manifest?
No entiendo por qué esta pregunta ha sido rechazada ... parece estar pensada ... y mientras, Microsoft está un poco cansada de la frustración, bien atemperada y dispuesta a razonar. – Beska
¡Supongo que es mucho texto para leer! Si la pregunta fuera más concisa, podría tener más suerte. –
Cuando el título de una pregunta pregunta "¿x intenta ser malo?" no se sorprenda cuando la gente lo rechaza. :) – bk1e