Pregunta sobre el formato de archivo Visual Studio * .sln

Question

Estoy usando un editor de texto para editar manualmente mi archivo * .sln. Estoy confundido acerca de las siguientes líneas:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Test2008", "Tools\Test2008\Test2008\Test2008.csproj", "{00B5EBB2-FDA5-4B23-BDC5-27E9F82E7C69}" 
    ProjectSection(ProjectDependencies) = postProject 
     {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} 
    EndProjectSection 
EndProject 

cuál es el punto de esta

{82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8}

declaración? Se ve totalmente superfluo.

Answer 1

Parece que esta sintaxis redundantes es una de las peculiaridades requeridas por MSBuild para reconocer la dependencia de un proyecto:

Parece que Visual Studio mantiene las dependencias de dos maneras, una sola de los cuales se lee por MSBuild.Veo que debido a que todavía puedo especificar las dependencias en GUI, copie la solución a otra máquina y compórtala con VS en pedido correcto. - Victor Sergienko

En cuanto a qué se requiere la "declaración ecuación superflua", parece que el asignar de GUID para su propio GUID de un proyecto es una solución para un problema con MSBuild 4.0 que causa MSBuild que no reconocer o responder a ciertas dependencias de proyecto enumeradas en un archivo de solución (.sln) o crear dependencias desordenadas.

La sintaxis jodida "{x} = {x}" sobre la que pregunta es una variación de la sintaxis estándar de MSBuild para hacer referencia a un proyecto (es decir, la respuesta del ejemplo @ Sergio).

Aparentemente, incrustando la declaración de dependencia en un bloque ProjectSection junto con un GUID de dependencia autodenominado hace que MSBuild cambie el orden de compilación del proyecto dependiente, pero en realidad no agrega otra referencia al mismo.

Hay un discussion on Microsoft Connect donde se trata esta solución. En ella, Dan de Microsoft sugiere una solución limpia para este fallo MSBuild en su segundo puesto en la página, y también menciona la solución que estás preguntando por:

que fija el ordenamiento, como ahora LibraryProject esperará en CodeGeneratingProject, pero su construcción no se verá afectada. Puedo poner en orden mediante la eliminación de la dependencia en el archivo de solución, así - la eliminación de estas líneas, que ahora son innecesarios:

ProjectSection(ProjectDependencies) = postProject 
    {B79CE0B0-565B-4BC5-8D28-8463A05F0EDC} = {B79CE0B0-565B-4BC5-8D28-8463A05F0EDC} 
EndProjectSection 

y todavía funciona bien.

Answer 2

De MSDN:

Esta declaración contiene el proyecto única GUID y el tipo de proyecto GUID. Esta información es utilizada por el entorno para encontrar el archivo de proyecto o los archivos que pertenecen a la solución, y el paquete VS necesarios para cada proyecto .

El proyecto GUID se pasa a IVsProjectFactory para cargar el VSPackage específica relacionada con el proyecto, entonces el proyecto se carga por el VSPackage. En este caso, el VSPackage que se carga para este proyecto es Visual Basic.

Por ejemplo:

Proyecto ("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1", "Project1.vbproj", "{8CDD8387-B905-44A8 -B5D5-07BB50E05BEA}" EndProject

Answer 3

la línea {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} = {82B9BEC0-C9CC-4423-B54F-61E3C4AF53D8} indica que el proyecto ha Test2008 una dependencia declarada (establecido a través del diálogo dependencias del proyecto en VStudio) en el proyecto con el identificador único 82B9BEC0-C9CC-4423- B54F-61E3C4AF53D8. Debería poder encontrar un proyecto con ese mismo identificador en el mismo archivo .sln.

En cuanto a por qué la sintaxis impar de la línea, no tengo conocimiento interno del formato de archivo .sln. Sin embargo, basado en la observación de otros extractos de ProjectSection en archivos .sln, tendría que adivinar que el analizador .sln utilizado por Visual Studio históricamente asumió que las líneas ProjectSection estarán en un formato key = value, con la exclusividad de clave impuesta dentro de cualquier sección dada. También supongo que las personas que implementaron la funcionalidad de dependencia del proyecto decidieron que, en lugar de ocultar con el analizador, sería más simple usar projectId = projectId para sus líneas de sección, ya que las claves no tienen sentido para ellos, pero se garantiza que serán únicas si solo una dependencia del proyecto A al proyecto B se aplica de otro modo.

Answer 4

Líneas después de ProjectSection(ProjectDependencies) = postProject especifica la lista de dependencias - qué proyecto depende de cuál. (Puede verse en Solución> Propiedades> Dependencias del proyecto).

Si desea "descifrar" más de lo que está sucediendo dentro, echar un vistazo a siguiente proyecto:

https://sourceforge.net/p/syncproj/code/HEAD/tree/

Aquí está analizador .sln, se puede comprobar Solution.cs, búsqueda "ProjectDependencies ".

clave es siempre el mismo valor, este es un tipo de problema de formato de archivo.