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”.
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”.
Odpowiedzi:
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.
Zamknięcie VS2010 i ponowne otwarcie zawsze działało dla mnie :)
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.
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.
Fileodniesień do zestawu. Działał doskonale.
Prawidłowy link do poprawki dla VS2010 to:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
Działa dobrze po instalacji
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.
- Edytuj plik .vdproj w Notatniku.
- Wyszukaj „SourcePath” = „8:
- Dla każdego zestawu / biblioteki dll podaj pełną ścieżkę
- 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ć.
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.
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());
}
}
}
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.
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:
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.
Może się to również zdarzyć, gdy próbujesz debugować i wybrałeś tryb wydania. Mam mnie przed chwilą :(