"No se pueden actualizar las dependencias del proyecto" después de comprometerse con Subversion


87

Tengo un proyecto de instalación en .NET. Cuando guardo el proyecto y los otros proyectos en subversion, el proyecto de instalación ya no se compila. Aparece el error "No se pueden actualizar las dependencias del proyecto".

Respuestas:


50

Hay un largo hilo de discusión sobre esto en MSDN. Parece que hay muchas causas posibles. La discusión incluye algunos enlaces de Microsoft para este problema. Aquí hay una revisión para VS2005 y aquí hay una solución para VS2010.


21
El enfoque de "eliminar y luego agregar el proyecto nuevamente" funciona para mí.
Mike Fuchs

1
+1 Tuve que arreglar la ruta de dependencia manualmente en el archivo .VDPROJ. Vea mi respuesta para posiblemente ganar algo de tiempo. La revisión no ayudó en absoluto.
Marc

9
+1 a radbyx. Tu simple comentario probablemente me salvó una hora de frustración :)
JOpuckman

4
Reiniciar también lo solucionó para mí. ¡Gracias Radbyx!
Josh Lowry

Cerrar la solución y luego volver a abrirla. Esto funcionó para mí :-)
FIV

93

Cerrar VS2010 y luego volver a abrirlo siempre me ha funcionado :)


4
Usted señor, es impresionante.
Panda Pyjama

3
El hecho de que busqué en Google este problema, vine aquí y vi que ya había votado a favor de esta respuesta me dijo que probablemente esto funcionaría para mí. Y lo hizo.
jcollum

1
¡Señor, es increíble una vez más!
Panda Pyjama

32

Tuve el mismo problema, pero ninguna de las resoluciones mencionadas pareció funcionar para mí. Reconstruir el proyecto de configuración funcionaría, pero es una molestia, ya que incluimos los resultados del proyecto de más de 30 proyectos.

Lo que encontré que funciona es un enfoque muy similar al que hizo @Marc.

  1. Noté qué dependencias reportadas por Visual Studio como errores
  2. Edite el archivo .vdproj en Notepad ++
  3. Busque el .dll que genera problemas. Verá una sección "ScatterAssemblies". Si está vacío, elimine toda la referencia dll
  4. Guardar el archivo

En todos los casos, tuve varias referencias al mismo dll (no estoy seguro de cómo sucedió esto)

Ejemplo de referencia correcta:

"{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_11EC89A306FFB83A269ACC2BF8D8462B"
{
"AssemblyRegister" = "3:1"
"AssemblyIsInGAC" = "11:FALSE"
"AssemblyAsmDisplayName" = "8:Some.OrOther.Lib, Version=1.601.4042.16978, Culture=neutral, processorArchitecture=MSIL"
                "ScatterAssemblies"
                {
                                "_11EC89A306FFB83A269ACC2BF8D8462B"
                                {
                                "Name" = "8:Some.OrOther.Lib.dll"
                                "Attributes" = "3:512"
                                }
                }
"SourcePath" = "8:Some.OrOther.Lib.dll"
"TargetName" = "8:"
"Tag" = "8:"
"Folder" = "8:_79891234C744498C83755DDEA682F0BF"
"Condition" = "8:"
"Transitive" = "11:FALSE"
"Vital" = "11:TRUE"
"ReadOnly" = "11:FALSE"
"Hidden" = "11:FALSE"
"System" = "11:FALSE"
"Permanent" = "11:FALSE"
"SharedLegacy" = "11:FALSE"
"PackageAs" = "3:1"
"Register" = "3:1"
"Exclude" = "11:FALSE"
"IsDependency" = "11:TRUE"
"IsolateTo" = "8:"
}

Ejemplo de referencia incorrecta:

"{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_11EC89A306FFB83A269ACC2BF8D8462B"
{
"AssemblyRegister" = "3:1"
"AssemblyIsInGAC" = "11:FALSE"
"AssemblyAsmDisplayName" = "8:Some.OrOther.Lib, Version=1.601.4042.16978, Culture=neutral, processorArchitecture=MSIL"
                "ScatterAssemblies"
                {
                }
"SourcePath" = "8:Some.OrOther.Lib.dll"
"TargetName" = "8:"
"Tag" = "8:"
"Folder" = "8:_79891234C744498C83755DDEA682F0BF"
"Condition" = "8:"
"Transitive" = "11:FALSE"
"Vital" = "11:TRUE"
"ReadOnly" = "11:FALSE"
"Hidden" = "11:FALSE"
"System" = "11:FALSE"
"Permanent" = "11:FALSE"
"SharedLegacy" = "11:FALSE"
"PackageAs" = "3:1"
"Register" = "3:1"
"Exclude" = "11:FALSE"
"IsDependency" = "11:TRUE"
"IsolateTo" = "8:"
}

También recibí la misma advertencia "Dos o más objetos tienen la misma ubicación de destino ('[targetdir] \ MyAssembly.dll')" que advierte que @Marc obtuvo ... pero el proyecto de instalación se compila y funciona bien.


2
Terminé borrando todas las Filereferencias de ensamblado. Funcionó perfectamente.
MartinHN

Esto, tantas veces. Me he estado rompiendo los pelos tratando de resolver estos errores, y ninguna de las otras correcciones sugeridas ha funcionado.
John Källén

Esto funcionó para mí cuando eliminar todo el contenido de la sección Archivo no lo hizo.
Alan


6

Tuve un problema similar y encontré una solución en esta larga y antigua discusión sobre MSDN .
Como respondió el usuario 'Jeff Hunsaker' el jueves 26 de agosto de 2010 a las 17:51 (no es posible el enlace directo):

Me encontré con esto al actualizar Visual Studio 2008 Deployment Projects a VS 2010. La solución de Hans (arriba) funcionó para mí.

  1. Edite el archivo .vdproj en el Bloc de notas.
  2. Busque "SourcePath" = "8:
  3. Para cada ensamblado / dll, proporcione la ruta completa
  4. Guardar el archivo

Dentro de mi archivo .vdproj, tenía varias entradas que simplemente
hacían referencia al ensamblado: "SourcePath" = "8: MyAssembly.DLL"

Aunque Visual Studio [de alguna manera] conocía la ubicación del archivo, recibí el error "No se pueden actualizar las dependencias del proyecto" hasta que proporcioné la ruta completa:

"SourcePath" = "8: .. \ .. \ .. \ build \ bin \ MyCompany.MyAssembly.DLL"

Saludos,

Jeff ...

Observé qué dependencias informó Visual Studio y escribí un script para corregirlas en caso de que sea necesario.

Tenga en cuenta que esto ahora me da una advertencia "Dos o más objetos tienen la misma ubicación de destino ('[targetdir] \ MyAssembly.dll'). Pero puedo vivir con eso.


4

Esto me resolvió el mismo problema: agregué los ensamblados que se mencionaron en el mensaje de error al GAC. Cuando volví a compilar el proyecto, los dll aparecieron en "Dependencias detectadas" en el Explorador de soluciones y obtuve el mismo error. Luego excluí los dll (haga clic con el botón derecho y seleccione Excluir) y el proyecto finalmente se compiló correctamente.


3

El problema puede ser causado por archivos huérfanos en la sección "Implementable" -> "Archivo" del archivo .vdproj. Puede verificar esto eliminando todos los archivos del proyecto de instalación en Visual Studio (primero haga una copia de seguridad). Si abre el archivo .vdproj con un editor de texto y aún ve entradas en la sección "Archivo", tiene este problema. Puede anotar las claves de estos archivos y eliminarlos del archivo .vdproj original y debería funcionar de nuevo.

Como alternativa, compile este programa de solución rápida (probado solo con Visual Studio 2010):

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;

class Program {
    static void Main(string[] args) {
        try {
            if (args.Length == 0) {
                Console.WriteLine("FixVDProj <path to .vdproj file>");
                return;
            }

            if (!File.Exists(args[0])) {
                throw new Exception("File " + args[0] + " does not exist!");
            }

            string[] strarSource = File.ReadAllLines(args[0]);
            List<string> listDest = new List<string>();
            List<string> listKnownKeys = new List<string>();

            int iSection = 0;
            bool bAccept = true;
            bool bNeedFix = false;

            foreach (string strLine in strarSource) {
                switch (iSection) {
                    case 0:
                        if (strLine.Trim() == "\"DeployProject\"") {
                            listDest.Add(strLine);
                            iSection++;
                        } else {
                            throw new Exception("\"DeployProject\" not found");
                        }
                        break;

                    case 1:
                        if (strLine.Trim() == "\"Hierarchy\"") {
                            iSection++;
                        }
                        listDest.Add(strLine);
                        break;

                    case 2:
                        if (strLine.Trim().StartsWith("\"MsmKey\" = ")) {
                            int p = strLine.IndexOf('=');
                            string strMsm = strLine.Substring(p + 1).Trim();
                            if (strMsm.StartsWith("\"8:") && strMsm.EndsWith("\"")) {
                                listKnownKeys.Add(strMsm.Substring(3, strMsm.Length - 4));
                            } else {
                                throw new Exception("Invalid MsmKey " + strMsm);
                            }
                        } else if (strLine.Trim() == "\"Deployable\"") {
                            iSection++;
                        }
                        listDest.Add(strLine);
                        break;

                    case 3:
                        if (strLine.Trim() == "\"File\"") {
                            iSection++;
                        }
                        listDest.Add(strLine);
                        break;

                    case 4:
                        if (strLine.Trim() == "{") {
                            iSection++;
                        }
                        listDest.Add(strLine);
                        break;

                    case 5:
                        if (strLine.Trim() == "}") {
                            listDest.Add(strLine);
                            iSection = -1;  // finished
                        } else if (strLine.Trim().StartsWith("\"") && strLine.Contains(':')) {
                            int p = strLine.IndexOf(':');
                            string strKey = strLine.Substring(p + 1, strLine.Length - p - 2);
                            if (listKnownKeys.Contains(strKey)) {
                                Console.WriteLine("Accepted key " + strKey);
                                bAccept = true;
                                listDest.Add(strLine);
                            } else {
                                Console.WriteLine("Invalid key " + strKey + " removed");
                                bAccept = false;
                                bNeedFix = true;
                            }
                        } else if (strLine.Trim() == "{") {
                            if (bAccept) {
                                listDest.Add(strLine);
                            }
                            iSection++;
                        } else {
                            listDest.Add(strLine);
                        }
                        break;

                    case 6:
                    case 7:
                    case 8:
                    case 9:
                        if (strLine.Trim() == "{") {
                            iSection++;
                        } else if (strLine.Trim() == "}") {
                            iSection--;
                        }
                        if (bAccept) {
                            listDest.Add(strLine);
                        }
                        break;

                    case 10:
                        throw new Exception("File structure depth exceeded!");

                    default:
                        listDest.Add(strLine);
                        break;
                }
            }

            if (bNeedFix) {
                File.Copy(args[0], args[0] + ".bak", true);
                File.WriteAllLines(args[0], listDest);
                Console.WriteLine("File " + args[0] + " has been fixed!");
            } else {
                Console.WriteLine("File " + args[0] + " did not need fix!");
            }

        } catch (Exception e) {
            Console.WriteLine(e.ToString());
        }
    }
}

3

Logré solucionar este problema eliminando el proyecto del instalador de la solución y luego volviendo a agregar el proyecto existente.


También funcionó para mí. Gracias.
DTdev

1

Reiniciar VS2010 no funcionó para mí, pero logré que todo funcionara haciendo una 'Solución limpia', luego una 'Solución de compilación'. Sin embargo, probar 'Reconstruir solución' después de la limpieza no funcionó. Entonces podría ejecutar la Solución con F5 como de costumbre.


1

Cuando recibo este error, encuentro que mi proyecto de implementación de VS2010 (.vdproj) está 'dañado'. Específicamente, los elementos de la sección FILE del archivo VDPROJ tienen GUID que faltan en la sección HIERARCHY del archivo VDPROJ. Esto se describe en detalle a continuación.

1) Los proyectos de implementación de VS2010 incluyen las siguientes secciones:

"Hierarchy"
{
}
"Deployable"
{
    "File"
    {
    }
} 

2) La sección JERARQUÍA contiene GUID para cada elemento (por ejemplo, archivo) agregado al proyecto de implementación. Además, cada archivo agregado al proyecto aparece como un elemento en la sección DESPLEGABLE> ARCHIVO . El siguiente ejemplo muestra una configuración normal para el archivo msimg32.dll . Tenga en cuenta el GUID de adaptación (es decir _1C15DB39774F7E79C84F1CC87ECFD60A) en los JERARQUÍA y FILE secciones.

"Hierarchy"
{
  "Entry"
    {
    "MsmKey" = "8:_1C15DB39774F7E79C84F1CC87ECFD60A"
    "OwnerKey" = "8:_0C67A6B6004040DC93A0113E1100615D"
    "MsmSig" = "8:_UNDEFINED"
    }
  }
"Deployable"
{
  "File"
  {
    "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_1C15DB39774F7E79C84F1CC87ECFD60A"
    {
        "SourcePath" = "8:MSIMG32.dll"
        "TargetName" = "8:MSIMG32.dll"
        … more information ...
    }
  }
}

3) Mis proyectos de implementación de VS2010 pueden corromperse de dos maneras:

  • a) Un elemento de la sección ARCHIVO se duplica y el elemento duplicado recibe un GUID que no aparece en la JERARQUÍA sección .

  • b) El GUID asociado con un elemento en la sección ARCHIVO se ha eliminado de la sección JERARQUÍA (es decir, el elemento en la sección ARCHIVO es huérfano).

3a) Ejemplo del primer problema: elemento duplicado en sección ARCHIVO :

En este ejemplo, el archivo msimg32.dll tiene dos entradas en la sección FILE . La primera entrada (es decir, correcto) tiene un GUID coincidente (es decir _1C15DB39774F7E79C84F1CC87ECFD60A) en el JERARQUIA sección, pero el GUID para el segundo (es decir, error) entrada (es decir 2DDC4FA12BFD46DEAED0053D23331348) no aparece en la JERARQUIA sección.

"Hierarchy"
{
    "Entry"
    {
    "MsmKey" = "8:_1C15DB39774F7E79C84F1CC87ECFD60A"
    "OwnerKey" = "8:_0C67A6B6004040DC93A0113E1100615D"
    "MsmSig" = "8:_UNDEFINED"
    }
}
"Deployable"
{
  "File"
  {
    "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_1C15DB39774F7E79C84F1CC87ECFD60A"
    {
        "SourcePath" = "8:MSIMG32.dll"
        "TargetName" = "8:MSIMG32.dll"
        … more information ...
    }
    "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_2DDC4FA12BFD46DEAED0053D23331348"
    {
        "SourcePath" = "8:MSIMG32.dll"
        "TargetName" = "8:MSIMG32.dll"
        … more information ...
    }
  }
}

3b) Ejemplo de segundo problema: artículo huérfano en el sección ARCHIVO :

En este ejemplo, el archivo msimg32.dll tiene una entrada en la sección FILE . Pero el GUID asociado con esta entrada (es decir, A515046ADA6244F2A260E67625E4398F) no tiene una entrada coincidente en (es decir, falta en) la sección JERARQUÍA .

"Hierarchy"
{
}
"Deployable"
{
  "File"
  {
    "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_A515046ADA6244F2A260E67625E4398F"
    {
        "SourcePath" = "8:MSIMG32.dll"
        "TargetName" = "8:MSIMG32.dll"
        … more information ...
    }
  }
}

4) Solución: Para los dos problemas ilustrados anteriormente, la solución es eliminar el elemento huérfano en la sección ARCHIVO .

El siguiente ejemplo muestra cómo aparecería la sección ARCHIVO en el punto 3a anterior después de que se haya eliminado la segunda entrada para msimg32.dll .

"Hierarchy"
{
    "Entry"
    {
    "MsmKey" = "8:_1C15DB39774F7E79C84F1CC87ECFD60A"
    "OwnerKey" = "8:_0C67A6B6004040DC93A0113E1100615D"
    "MsmSig" = "8:_UNDEFINED"
    }
}
"Deployable"
{
  "File"
  {
    "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_1C15DB39774F7E79C84F1CC87ECFD60A"
    {
        "SourcePath" = "8:MSIMG32.dll"
        "TargetName" = "8:MSIMG32.dll"
        … more information ...
    }
  }
}

5) Encontré que las entradas dañadas en VDPROJ solo ocurrieron para:

  • a) archivos de ensamblaje (es decir, DLL) de mis proyectos C # y
  • b) detecté dependencias de mis proyectos C ++ (por ejemplo, version.dll, urlmon.dll)

0

Aquí hay un par de soluciones que funcionan:

1) Eliminar uno de los archivos DLL problemáticos del proyecto de instalación y luego volver a agregar solo ese resolvió el problema por mí. Esto funcionó incluso cuando había muchas DLL con el problema. Eliminar y agregar solo uno de ellos activó VS2010 para arreglarlos todos de alguna manera.

2) Reconstruya la solución, luego intente actualizar las dependencias nuevamente. La reconstrucción ayuda a Visual Studio a descubrir cuáles son las dependencias, porque puede tener dificultades para encontrar las dependencias sin nada construido.

3) Reinicie Visual Studio

La revisión VS2010 vinculada anteriormente no funcionó para mí. A veces, reiniciar VS2010 solucionará el problema y cuando eso no funcione, hacer lo anterior funciona.


0

Esto también puede suceder cuando está intentando depurar y ha seleccionado el modo de lanzamiento. Me tienes ahora :(


0

Me gustaría agregar que obtengo el mismo error cuando edito el proyecto de implementación desde mi computadora en lugar de la computadora compiladora dedicada.

La última vez que recibí ese error, necesitaba revertir los últimos cambios y volver a hacerlo desde la computadora compiladora dedicada.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.