c# - new - Referencias del proyecto VS roto en la sensibilidad de la caja de GUID

system guid newguid c#

Question

Desde la actualización a VS 2015, mi equipo ha experimentado cosas extrañas y aleatorias que estoy trabajando en Microsoft en este momento. Uno bastante molesto es que parece que perdemos referencias de proyectos, especialmente después de la ramificación. Ayer comencé a trabajar en una nueva rama de nuestra solución solo para descubrir que no se reconocían los tipos y que los usos del espacio de nombres se citaban como innecesarios (porque eran para los tipos que de repente no se reconocían).

Las referencias en el proyecto no mostraban ningún ícono que indicara un problema con la referencia, pero solo para ver si funcionaba, eliminé y volví a agregar una referencia al proyecto, lo que hizo que sus tipos se reconocieran una vez más.

Esto, por supuesto, actualizó el archivo del proyecto, así que miré para ver qué cambios se habían hecho. La única diferencia entre el proyecto que no pudo detectar la referencia y la que ahora puede es que los caracteres alfa en el GUID se cambiaron de minúsculas a mayúsculas. Por ejemplo:

Referencia vieja, rota:

<ProjectReference Include="path/redacted">
<Project>{95d34b2e-2ceb-499e-ab9e-b644b0af710d}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>

Nueva referencia fija:

<ProjectReference Include="path/redacted">
<Project>{95D34B2E-2CEB-499E-AB9E-B644B0AF710D}</Project>
<Name>Project.Name.Redacted</Name>
</ProjectReference>

Estoy buscando la razón por la que esto está sucediendo y cómo podría solucionarlo sin tener que eliminar manualmente y volver a agregar referencias en todo el lugar (y sin tener que convertir todos los GUID del archivo de proyecto a mayúsculas).

Debo tener en cuenta que estas referencias "rotas" no están rompiendo la compilación, y que solo aparecen en la Lista de errores como error de IntelliSense, no como errores de compilación. Por lo tanto, las referencias no están realmente rotas, simplemente han roto IntelliSense (¡¿lo que es posiblemente peor ?!).

Answer 1

Hay un error en el sistema de proyectos que parece. Este powershell recorrerá los proyectos y hará que todas las referencias sean mayúsculas:

#FixGuids
get-childitem -recurse | ?{ @(''.sln'', ''.csproj'', ''.vbproj'') -contains $_.Extension } | %{
[regex]::Replace((gc $_.FullName), ''[{(]?[0-9A-Fa-f]{8}[-]?([0-9A-Fa-f]{4}[-]?){3}[0-9A-Fa-f]{12}[)}]?'', { return ([string]$args[0]).ToUpperInvariant() }) |
Out-File $_.FullName
}

Es bastante simplista. Si confía en las guías de sus proyectos para algo más que referencias, puede convertirlo en algo más inteligente.

Answer 2

Para usar la respuesta en un gancho de git, tuve que convertirla a la sintaxis de expresiones regulares de sed:

sed -r "s/(<Project>/{?)([0-9A-F-]+)(/}?<//Project>)//1/L/2/E/3/g" sample.csproj

Tal vez alguien encuentre esto útil.

Answer 3

Sufrí un problema similar al actualizar VS2017 v15.7 a v15.9.

La respuesta para mí fue cerrar VS, borrar la carpeta oculta .vs en el directorio raíz de mi solución y reiniciar VS.

Answer 4

TL; DR

Visual Studio no es totalmente coherente sobre cómo asigna GUID a los proyectos o cómo especifica esos GUID en las referencias del proyecto. Pude resolver el problema mediante el uso de GUID en mayúsculas con llaves para los elementos de ProjectGuid y en minúsculas con llaves para los elementos del Project (en las referencias).

Fondo

Tenemos una gran solución (más de 60 proyectos en C #), y tuvimos problemas con la Reconstrucción de la solución, ya que un orden de compilación incorrecto causaría un error al resolver los proyectos de referencia que aún no se habían construido (pero deberían haber sido). Las dependencias de compilación y la orden de compilación parecían correctas. La construcción por lotes de MSBuild funcionó bien, solo fue un problema al reconstruir desde Visual Studio.

Forzar todos los GUID del proyecto a mayúsculas con llaves y todos los GUID de referencia del proyecto a minúsculas con llaves corrigieron el problema. Por lo general, así es como Visual Studio genera estos GUID, pero no siempre.

Haciendo un poco de investigación en una nueva solución de prueba, resulta que:

1. Los GUID generados para proyectos de aplicaciones de consola están en mayúsculas con llaves.
2. Los GUID generados para los proyectos de biblioteca de clases son inicialmente en minúsculas sin llaves.
3. Si se agrega una nueva referencia de proyecto a un proyecto de biblioteca de clases con un GUID en minúsculas, no solo se agrega el GUID de referencia, sino que el GUID del proyecto se convierte en mayúsculas con llaves.
4. Si se crea una copia de un proyecto de biblioteca de clases y luego se agrega a la solución, su GUID se reemplaza por uno nuevo que usa mayúsculas y llaves. (Pero si se realiza una copia y su GUID se elimina manualmente, Visual Studio no inserta un GUID de reemplazo en el archivo .csproj).
5. Las GUID de las referencias del proyecto generalmente se usan en minúsculas y con llaves, pero de alguna manera nuestro proyecto ha acumulado un montón de referencias de GUID en mayúsculas.
6. Los GUID en .sln siempre usan mayúsculas y llaves.

Pude arreglar nuestra reconstrucción rota al reemplazar los GUID de referencia con mayúsculas o minúsculas; es algo sobre la combinación de mayúsculas y minúsculas que daba problemas a Visual Studio (quizás claves de cadena sensibles a mayúsculas y minúsculas en un diccionario) ¿En algún lugar?) Ya que Visual Studio normalmente agrega referencias con GUID en minúsculas, esa es la opción que elegí.

Regex búsqueda y reemplazo

Para solucionar este problema, utilicé la búsqueda basada en expresiones regulares de Notepad ++ y la sustitución en los archivos para forzar que todas las ProjectGuids en los archivos .csproj estén en mayúsculas con llaves (el valor predeterminado para las aplicaciones de consola, y el estilo de Visual Studio se aplicará después de agregar cualquier referencia del proyecto a la proyecto):

Find what: (<ProjectGuid>)/{?([0-9a-f-]+)/}?(</ProjectGuid>)
Replace with: /1{/U/2}/E/3
Search in: *.csproj

Asegúrese de activar la búsqueda de expresiones regulares y desactivar el caso de coincidencia. Y no busque en todos los archivos, o puede hacer los cambios que no desea, por ejemplo en los archivos * .xproj, como lo indica @AspNyc. (Vea esta respuesta para obtener información adicional sobre el uso de expresiones regulares para cambiar de caso).

Luego reemplacé todas las referencias a proyectos para usar minúsculas con llaves (que es lo que normalmente hace Visual Studio):

Find what: (<Project>)/{?([0-9a-f-]+)/}?(</Project>)
Replace with: /1{/L/2}/E/3
Search in: *.csproj

Una vez realizados estos cambios, la reconstrucción de la solución de Visual Studio ahora funciona de manera confiable. (Al menos hasta la próxima vez, los GUID de referencia en mayúsculas no autorizados se infiltran en nuestro proyecto)