visual studio - visual - Configuración de un servidor de símbolos público(o privado) a través de http
visual studio code html (4)
Todos los documentos que he encontrado (referencias 1 a 5) hablan sobre la configuración de un servidor de símbolos utilizando una ruta UNC compartida y luego ponen la configuración correcta a disposición de la instancia del depurador local (ya sea _NT_SYMBOL_PATH o la configuración de depuración de Visual Studio IDE) ).
Microsoft proporciona un servidor de símbolos (referencia 6) disponible a través de http para sus almacenes de símbolos públicos.
Quiero crear, para mi propio código, un servidor de símbolos accesible a través del transporte http, en lugar de compartir archivos UNC. La gente de Mozilla parece haberlo hecho (referencia 7), pero ya no es funcional.
¿Hay mejores referencias disponibles para realizar esta tarea que las que he encontrado hasta ahora?
Referencias
- https://msdn.microsoft.com/en-us/library/b8ttk8zy(v=vs.80).aspx
- http://msdn.microsoft.com/en-us/library/ms680693(v=vs.85).aspx
- http://stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx
- http://entland.homelinux.com/blog/2006/07/06/
- http://msdn.microsoft.com/en-us/windows/hardware/gg462988
- http://support.microsoft.com/kb/311503
- http://developer.mozilla.org/en/Using_the_Mozilla_symbol_server
Creo que la respuesta es muy simple: "Solo comparte el directorio a través de algún tipo de ruta http". De acuerdo con la entrada de Chad Austin sobre "Cómo crear su propio servidor de símbolos" , esto solo funcionará.
En otras palabras, el directorio que utiliza symstore.exe para almacenar los símbolos, cuando se sirve como http://symbols.example.com/public_symbols/ , se podrá utilizar como destino del servidor de símbolos para las herramientas de depuración de Windows.
Nuestro servidor de símbolos (de Mozilla) funciona bien, AFAICT. No estamos haciendo nada particularmente complicado, solo colocamos los archivos PDB en la estructura de directorio correcta (tenemos un script para eso , pero puede usar symstore.exe) y lo servimos a través de Apache. Creo que lo único especial que tenemos son algunas reglas de Reescritura para permitir el acceso a los archivos de una manera que no distingue entre mayúsculas y minúsculas, porque las herramientas de Microsoft son realmente inconsistentes con respecto al caso de GUID / nombre de archivo.
Tenga cuidado al hacer que varios usuarios utilicen Symstore.exe directamente en el mismo almacén de símbolos. Las notas de Microsoft sobre este tema hacen que parezca que simplemente creas un recurso compartido y que todos se actualicen a través del programa SYMSTORE.EXE entregado como parte de las Herramientas de depuración para Windows. Los libros blancos le aconsejaron que haga esto por cada compilación.
Y funciona muy bien con usuarios individuales o al canalizar todas las actualizaciones a través de una sola persona que está actualizando el servidor de símbolos para un equipo.
Desafortunadamente, la "letra pequeña" en la parte inferior de algunos de los documentos técnicos dice que solo un usuario que ejecuta symstore.exe puede actualizar el servidor de símbolos compartido al mismo tiempo sin romper el contenido.
(Ejemplo: en http://msdn.microsoft.com/en-us/library/ms681417(VS.85).aspx , Microsoft dice: "Nota SymStore no admite transacciones simultáneas de varios usuarios. Se recomienda que un usuario ser designado "administrador" del almacén de símbolos y ser responsable de todas las transacciones de agregar y eliminar ".
Por lo tanto, no hay un mecanismo inherente para serializar las actualizaciones en el almacén de símbolos. Parece que los intentos múltiples y simultáneos de actualizar el almacén de símbolos pueden romper el almacén de símbolos y / o su índice.
No podemos tener compilaciones para todo nuestro multimillonario, corporación internacional en todas las zonas horarias que dependen de la coordinación a través de un hombre en una ubicación.
Basándome en esos documentos técnicos, planteé estos problemas con Microsoft en marzo de 2009; Quien confirmó que esto era un posible problema. Después de esa discusión, decidimos implementar un servicio de actualización de símbolos que serialice las actualizaciones a través de las llamadas directas a la herramienta de depuración de Windows SDK DbgEng.DLL SymbolSrvStoreFile () API, por lo que nunca existe la posibilidad de dos actualizaciones simultáneas contra la misma área de símbolos al mismo tiempo . Los usuarios tienen una acción de compilación que pone en cola sus símbolos a través del servicio en lugar de actualizar directamente el almacén de símbolos. El servicio luego serializa las actualizaciones para asegurarse de que nunca se realicen verdaderos intentos de actualización simultánea.
La documentación limitada disponible sobre el uso de SymSrvStoreFile no era muy clara en ese momento. Lo conseguí trabajando. Esperemos que se haya mejorado desde entonces. de lo contrario, el problema más importante fue que la ruta de entrada debe especificarse en un formato similar a _NT_SYMBOL_PATH. Así que en lugar de, por ejemplo, usar "C: / Data / MyProject / bin" como ruta de entrada, en lugar de eso, debe especificar "srv * C: / Data / MyProject / bin".
Nuestro servicio ahora también registra las actualizaciones a través de una base de datos. La base de datos sirve como copia de seguridad del almacén de símbolos (en caso de que alguna vez se corrompa y deba ser reconstruida) y también crea un punto de informe para que los gerentes y las personas de apoyo sepan quién está guardando sus símbolos y quién no. Generamos un informe semanal de "registro de símbolos" que se envía automáticamente a las partes interesadas.
Un servidor de símbolos servido a través de HTTP tiene la misma estructura que un servidor de símbolos servido a través de una ruta de archivo UNC, por lo que lo más simple sería usar symstore.exe para almacenar los archivos en una carpeta en algún lugar y luego usar un servidor HTTP simple que expone esa carpeta a través de HTTP (incluso la ejecución de python -m SimpleHTTPServer en el directorio de símbolos funcionaría).
Un pequeño problema es que si no existe un archivo de símbolos, el servidor HTTP debe devolver un código de error 404 (probado al menos en Visual Studio 2013). Me encontré con un problema en el que un servidor HTTP que devolvía 403 archivos perdidos hacía que Visual Studio dejara de realizar solicitudes después de la primera solicitud fallida.
symstore.exe crea una serie de archivos y carpetas 000Admin/ (los 000Admin/ folder, refs.ptr y files.ptr ). Ninguno de estos son necesarios para que el servidor de símbolos funcione.
Si desea crear un almacén de símbolos sin usar symstore.exe, puede cargar los archivos con esta estructura:
BinaryName.pdb/$BUILD_ID/BinaryName.pdb BinaryName.exe/$LINK_ID/BinaryName.exe
Donde BUILD_ID es un GUID incrustado en el archivo PDB y el ejecutable, y LINK_ID es una combinación de marca de tiempo de compilación y tamaño de archivo en el ejecutable. Se pueden obtener leyendo la salida de la herramienta dump_syms.exe de la biblioteca de breakpad. Consulte http://www.chromium.org/developers/decoding-crash-dumps