„Nie można zaktualizować zależności projektu” po zatwierdzeniu do Subversion

87

Mam projekt instalacyjny w .NET. Kiedy zapisuję projekt i inne projekty w Subversion, projekt instalacyjny nie jest już kompilowany. Pojawia się błąd „Nie można zaktualizować zależności projektu”.

Jason N. Gaylord
źródło

Odpowiedzi:

50

W witrynie MSDN jest długi wątek dyskusyjny na ten temat. Wygląda na to, że istnieje wiele możliwych przyczyn. Dyskusja zawiera kilka linków do tego problemu z firmy Microsoft. Oto poprawka dla VS2005, a tutaj obejście dla VS2010.

msergeant
źródło
21
Podejście „usuń i ponownie dodaj projekt” działa w moim przypadku.
Mike Fuchs
1
+1 Musiałem ręcznie naprawić ścieżkę zależności w pliku .VDPROJ. Zobacz moją odpowiedź, aby ewentualnie wygrać. Poprawka w ogóle nie pomogła.
Marc
9
+1 do radbyxa. Twój prosty komentarz prawdopodobnie zaoszczędził mi godziny frustracji :)
JOpuckman,
4
Ponowne uruchomienie również naprawiło to dla mnie. Dzięki radbyx!
Josh Lowry
Zamknięcie rozwiązania, a następnie ponowne otwarcie. To zadziałało dla mnie :-)
FIV
93

Zamknięcie VS2010 i ponowne otwarcie zawsze działało dla mnie :)

Chuck Claunch
źródło
4
Pan jest niesamowity.
Panda Pyjama
3
Fakt, że wyszukałem w Google ten problem, przyszedłem tutaj i zobaczyłem, że już zagłosowałem za tą odpowiedzią, powiedział mi, że prawdopodobnie to zadziała. I tak się stało.
jcollum
1
Panie, jeszcze raz jesteście niesamowici!
Panda Pyjama
32

Miałem ten sam problem, ale żadna z wymienionych rozdzielczości nie działała dla mnie. Przebudowanie projektu konfiguracji mogłoby zadziałać, ale jest to uciążliwe, ponieważ uwzględniamy produkty z ponad 30 projektów.

To, co znalazłem, to bardzo podobne podejście do tego, co zrobił @Marc.

  1. Zauważyłem, które zależności zostały zgłoszone przez Visual Studio jako błędy
  2. Edytuj plik .vdproj w Notepad ++
  3. Wyszukaj plik .dll, który powoduje problemy. Zobaczysz sekcję „ScatterAssemblies”. Jeśli jest pusta, usuń całe odwołanie do biblioteki dll
  4. Zapisz plik

We wszystkich przypadkach miałem wiele odniesień do tej samej biblioteki DLL (nie wiem, jak to się stało)

Przykład prawidłowego odniesienia:

"{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:"
}

Przykład nieprawidłowego odniesienia:

"{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:"
}

Otrzymałem również to samo ostrzeżenie „Dwa lub więcej obiektów mają tę samą lokalizację docelową ('[katalog docelowy] \ MyAssembly.dll')”, ostrzegające, że @Marc ma ... ale projekt instalacyjny kompiluje się i działa poprawnie.

Jabezz
źródło
2
Skończyło się na usunięciu wszystkich Fileodniesień do zestawu. Działał doskonale.
MartinHN
To tyle razy. Wyrywałem sobie włosy, próbując rozwiązać te błędy, i żadna z innych sugerowanych poprawek nie zadziałała.
John Källén
To zadziałało dla mnie, gdy usunięcie całej zawartości sekcji plików nie zadziałało.
alan
10

Prawidłowy link do poprawki dla VS2010 to:

http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681

Działa dobrze po instalacji

Pranav Singh
źródło
1
To zadziałało dla mnie. Ponowne uruchomienie VS i edycja pliku .vdproj nie.
Colin Pickard,
Microsoft Connect został wycofany, a powyższy link prowadzi nas do strony, która nie zawraca sobie głowy, aby powiedzieć, gdzie znajduje się ta poprawka.
dotNET
6

Miałem podobny problem i znalazłem poprawkę w tej bardzo długiej i starej dyskusji na temat MSDN .
Jako użytkownik 'Jeff Hunsaker' w czwartek, 26 sierpnia 2010 o godzinie 17:51 odpowiedział (bezpośredni link nie jest możliwy):

Właśnie spotkałem się z tym podczas uaktualniania projektów wdrożeniowych programu Visual Studio 2008 do VS 2010. Rozwiązanie Hansa (powyżej) zadziałało dla mnie.

  1. Edytuj plik .vdproj w Notatniku.
  2. Wyszukaj „SourcePath” = „8:
  3. Dla każdego zestawu / biblioteki dll podaj pełną ścieżkę
  4. Zapisz plik

W moim pliku .vdproj miałem kilka wpisów odnoszących się po prostu do zestawu:
„SourcePath” = „8: MyAssembly.DLL”

Mimo że program Visual Studio [w jakiś sposób] znał lokalizację pliku, otrzymałem komunikat „Nie można zaktualizować zależności projektu”, dopóki nie podałem pełnej ścieżki:

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

Pozdrowienia,

Jeff ...

Zauważyłem, które zależności zostały zgłoszone przez Visual Studio i napisałem skrypt, aby je naprawić na wypadek, gdyby było to wymagane.

Zauważ, że teraz wyświetla mi się ostrzeżenie „Co najmniej dwa obiekty mają tę samą lokalizację docelową ('[katalog docelowy] \ MyAssembly.dll'). Ale mogę z tym żyć.

Marc
źródło
4

To rozwiązało ten sam problem dla mnie: dodałem zestawy, o których była mowa w komunikacie o błędzie, do GAC. Kiedy ponownie skompilowałem projekt, dll pojawiły się w obszarze „Wykryte zależności” w Eksploratorze rozwiązań i otrzymałem ten sam błąd. Następnie wykluczyłem dll (kliknij prawym przyciskiem myszy i wybierz opcję Wyklucz), a projekt ostatecznie skompilowany.

Arne
źródło
3

Przyczyną problemu mogą być osierocone pliki w sekcji „Deployable” -> „File” pliku .vdproj. Możesz to sprawdzić, usuwając wszystkie pliki z projektu instalacji w programie Visual Studio (najpierw wykonaj kopię zapasową). Jeśli otworzysz plik .vdproj za pomocą edytora tekstu i nadal widzisz wpisy w sekcji „Plik”, masz ten problem. Możesz zanotować klucze tych plików i usunąć je z oryginalnego pliku .vdproj i powinno działać ponownie.

Alternatywnie skompiluj ten program szybkiej poprawki (testowany tylko z 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());
        }
    }
}
cicho pewny siebie
źródło
3

Udało mi się obejść ten problem, usuwając projekt instalatora z rozwiązania, a następnie ponownie dodając istniejący projekt.

Apogeum
źródło
Dla mnie też zadziałał. Dzięki.
DTdev
1

Ponowne uruchomienie VS2010 nie zadziałało, ale udało mi się wszystko uruchomić, wykonując „Czyste rozwiązanie”, a następnie „Buduj rozwiązanie”. Próba „Odbuduj rozwiązanie” po wyczyszczeniu nie przyniosła jednak rezultatu. Wtedy mogłem normalnie uruchomić rozwiązanie z F5.

Panie Chops
źródło
1

Gdy otrzymuję ten błąd, stwierdzam, że mój projekt wdrożeniowy VS2010 (.vdproj) jest „uszkodzony”. W szczególności elementy w sekcji FILE pliku VDPROJ mają identyfikatory GUID, których brakuje w sekcji HIERARCHY pliku VDPROJ. Zostało to szczegółowo opisane poniżej.

1) Projekty wdrożeniowe VS2010 obejmują następujące sekcje:

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

2) Sekcja HIERARCHY zawiera identyfikatory GUID dla każdego elementu (np. Pliku) dodanego do projektu wdrożenia. Ponadto każdy plik dodany do projektu pojawia się jako element w sekcji WSTĘPNE> PLIK . Poniższy przykład przedstawia normalną konfigurację pliku msimg32.dll . Zwróć uwagę na pasujący identyfikator GUID (tj. _1C15DB39774F7E79C84F1CC87ECFD60A) w sekcjach HIERARCHY i FILE .

"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) Moje projekty wdrożeniowe VS2010 mogą zostać uszkodzone na dwa sposoby:

  • a) Element w sekcji PLIK jest zduplikowany, a zduplikowany element otrzymuje identyfikator GUID, który nie pojawia się w sekcji HIERARCHIA .

  • b) Identyfikator GUID powiązany z elementem w sekcji PLIK został usunięty z sekcji HIERARCHIA (tj. element w sekcji PLIK jest osierocony).

3a) Przykład pierwszego problemu - zduplikowana pozycja w sekcji PLIK :

W tym przykładzie plik msimg32.dll ma dwa wpisy w sekcji PLIK . Pierwszy (tj. Poprawny) wpis ma pasujący identyfikator GUID (tj. _1C15DB39774F7E79C84F1CC87ECFD60A) w sekcji HIERARCHY , ale identyfikator GUID drugiego (tj. Błędu) wpisu (tj. 2DDC4FA12BFD46DEAED0053D23331348) nie pojawia się w sekcji HIERARCHY .

"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) Przykład drugiego problemu - osierocony przedmiot w sekcji PLIK :

W tym przykładzie plik msimg32.dll ma wpis w sekcji PLIK . Ale identyfikator GUID powiązany z tym wpisem (tj. A515046ADA6244F2A260E67625E4398F) nie ma pasującego wpisu w sekcji HIERARCHY (tj. Go brakuje) .

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

4) Rozwiązanie: W przypadku obu przedstawionych powyżej problemów rozwiązaniem jest usunięcie osieroconego elementu z sekcji PLIK .

Poniższy przykład pokazuje, jak sekcja PLIK w punkcie 3a powyżej wyglądałaby po usunięciu drugiego wpisu dotyczącego 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) Odkryłem, że uszkodzone wpisy w VDPROJ wystąpiły tylko dla:

  • a) pliki zestawu (tj. DLL) z moich projektów C # i
  • b) wykryto zależności z moich projektów C ++ (np. version.dll, urlmon.dll)
Ian Bell
źródło
0

Oto kilka rozwiązań, które działają:

1) Usunięcie jednej z bibliotek DLL powodujących problemy z projektu instalacji, a następnie ponowne dodanie tylko tej jednej rozwiązało problem za mnie. Działało to nawet wtedy, gdy problem dotyczył wielu bibliotek DLL. Usunięcie i dodanie tylko jednego z nich uruchomiło VS2010, aby jakoś je wszystkie naprawić.

2) Odbuduj rozwiązanie, a następnie spróbuj ponownie zaktualizować zależności. Przebudowa pomaga Visual Studio odkryć zależności, ponieważ może mieć problemy ze znalezieniem zależności, gdy nic nie zostało zbudowane.

3) Uruchom ponownie program Visual Studio

Powyższa poprawka VS2010 nie działa dla mnie. Czasami ponowne uruchomienie VS2010 rozwiązuje problem, a jeśli to nie działa, wykonanie powyższego działa.

Leigh McCulloch
źródło
0

Może się to również zdarzyć, gdy próbujesz debugować i wybrałeś tryb wydania. Mam mnie przed chwilą :(

Richard N.
źródło
0

Chciałbym dodać, że otrzymuję ten sam błąd, kiedy edytuję projekt wdrożenia z mojego komputera zamiast z dedykowanego komputera kompilatora.

Ostatni raz, kiedy dostałem ten błąd, musiałem cofnąć ostatnie zmiany i zrobić to ponownie z dedykowanego komputera kompilatora.

Hugo
źródło