"Невозможно обновить зависимости проекта" после совершения Subversion
У меня есть проект установки в .NET. когда я сохраняю проект и другие проекты в subversion, проект установки больше не компилируется. Я получаю сообщение об ошибке " невозможно обновить зависимости проекта."
13 ответов:
есть длинный обсуждение поток об этом на MSDN. Кажется, что есть много возможных причин. Обсуждение включает в себя несколько ссылок на эту проблему от Microsoft. вот исправление для VS2005 и вот решение для VS2010.
у меня была та же проблема, но ни одна из упомянутых резолюций, казалось, не работает для меня. Восстановление проекта установки будет работать, но это боль, так как мы включаем результаты проекта 30+ проектов.
то, что я нашел для работы, очень похоже на то, что сделал @Marc.
- я отметил, какие зависимости были сообщены Visual Studio как ошибки
- редактировать .файл vdproj в Notepad++
- Поиск .dll, которая дает проблемы. Вы увидите раздел "ScatterAssemblies". Если он пуст, удалите всю ссылку dll
- "сохранить файл"
во всех случаях у меня было несколько ссылок на одну и ту же dll (не уверен, как это произошло)
пример правильной ссылки:
"{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:" }
пример некорректной ссылки:
"{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:" }
Я также получил то же самое "два или более объектов имеют одинаковое целевое местоположение ('[targetdir]\MyAssembly.dll') " предупреждение, что @Marc получил ... а проект установки компилируется и работает нормально.
правильная ссылка для hot-fix для VS2010:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
отлично работает после установки
У меня была аналогичная проблема, и я нашел исправление в этом очень долгом и Старом обсуждении MSDN.
Как пользователь 'Jeff Hunsaker' в четверг, 26 августа 2010 5: 51 вечера ответил (прямая ссылка не представляется возможным):Я только что столкнулся с этим при обновлении проектов развертывания Visual Studio 2008 до VS 2010. Решение Ганса (выше) сработало для меня.
- редактировать .vdproj файл в блокноте.
- Поиск "SourcePath" = " 8:
- для каждой сборки/dll укажите полный путь
- "сохранить файл"
внутри меня .файл vdproj, у меня было несколько записей просто ссылка на сборку:
"SourcePath" = " 8: MyAssembly.DLL"несмотря на то, что Visual Studio [каким-то образом] знал расположение файла, я получил ошибку "не удалось обновить зависимости проекта", пока я не предоставил полный путь:
"SourcePath" = "8:..\..\..\строить\бин\Название_компании.Моя сборка.DLL"
с уважением,
Джефф...
Я отметил, какие зависимости были сообщены Visual Studio и написал сценарий, чтобы исправить их в случае, если это требуется.
обратите внимание, что теперь это дает мне предупреждение "два или более объектов имеют одинаковое целевое местоположение ('[targetdir]\MyAssembly.dll'). Но я могу жить с этим.
Это решило такую же проблему для меня: Я добавил сборки, которые были упомянуты в сообщении об ошибке в GAC. Когда я перекомпилировал проект, dll появилась в разделе "обнаруженные зависимости" в обозревателе решений, и я получил ту же ошибку. Затем я исключил dll (щелкните правой кнопкой мыши и выберите исключить), и проект, наконец, скомпилирован ОК.
проблема может быть вызвана потерянными файлами в разделе" развертываемый "- > "файл".файл vdproj. Это можно проверить, удалив все файлы из проекта установки в Visual Studio (сначала создайте резервную копию). Если вы откроете .vdproj файл с текстовым редактором и по-прежнему видеть записи в разделе "файл" у вас есть эта проблема. Вы можете отметить ключи этих файлов и удалить их из оригинала .vdproj файл и он должен работать снова.
альтернативно скомпилировать это быстрое исправление программа (протестирована только с 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()); } } }
мне удалось обойти эту проблему, удалив проект установщика из решения, а затем снова добавив существующий проект.
перезапуск VS2010 не сработал для меня, но мне удалось заставить все работать, сделав "чистое решение", а затем "решение для сборки". Однако попытка "перестроить решение" после очистки не сработала. Тогда я мог бы запустить решение с F5 как обычно.
когда я получаю эту ошибку, я нахожу свой проект развертывания VS2010 (.vdproj) "поврежден". В частности, элементы FILE в разделе файла VDPROJ есть GUID, которые отсутствуют в иерархия раздел файла VDPROJ. Это подробно описано ниже.
1) проекты развертывания VS2010 включают следующие разделы:
"Hierarchy" { } "Deployable" { "File" { } }
2) The иерархия раздел содержит GUID для каждого элемента (например, файла), добавленного в проект развертывания. Кроме того, каждый файл, добавленный в проект, отображается как элемент под РАЗВЕРТЫВАЕМЫЙ > ФАЙЛ. В следующем примере показана обычная конфигурация для файл msimg32.dll. Обратите внимание на соответствующий GUID (т. е. _1C15DB39774F7E79C84F1CC87ECFD60A) в иерархия и 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) мои проекты развертывания VS2010 могут быть повреждены в двух случаях способы:
a) элемент в FILE раздел дублируется, и дублированный элемент получает идентификатор GUID, который не отображается в иерархия.
b) идентификатор GUID, связанный с элементом в FILE раздел был удален из иерархия раздел (т. е. элемент в FILE потерянными).
3a) пример первого проблема-дублированный элемент в FILE:
в этом примере файл msimg32.dll имеет две записи в FILE. Первая (т. е. правильная) запись имеет соответствующий GUID (т. е. _1C15DB39774F7E79C84F1CC87ECFD60A) в иерархия раздел, но GUID для второй (т. е. ошибка) записи (т. е. 2DDC4FA12BFD46DEAED0053D23331348) не отображается в иерархия.
"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) Пример второй проблемы-потерянный элемент в FILE:
в этом примере файл msimg32.dll есть запись в FILE. Но GUID, связанный с этой записью (т. е. A515046ADA6244F2A260E67625E4398F), не имеет соответствующей записи в (т. е. она отсутствует)иерархия.
"Hierarchy" { } "Deployable" { "File" { "{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_A515046ADA6244F2A260E67625E4398F" { "SourcePath" = "8:MSIMG32.dll" "TargetName" = "8:MSIMG32.dll" … more information ... } } }
4) решение: для обеих проблем, показанных выше, решение заключается в удалении осиротевших пункт в FILE.
в следующем примере показано, как FILE раздел в пункте 3a выше появится после второй записи для 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) я обнаружил, что поврежденные записи в VDPROJ произошли только для:
- a) файлы сборки (т. е. DLL) из моих проектов C# и
- b) обнаружены зависимости от моих проектов на C++ (например, версия.файл DLL, urlmon.dll)
вот несколько решений, которые работают:
1) удаление одной из проблемных библиотек DLL из проекта установки, а затем повторное добавление только что решило проблему для меня. Это работало даже тогда, когда было много DLL с проблемой. Удаление и добавление только одного из них вызвало VS2010, чтобы как-то исправить их все.
2) перестроить решение, а затем попробуйте обновить зависимости еще раз. Перестроение помогает visual studio обнаружить, что такое зависимости, потому что это может быть, изо всех сил пытается найти зависимости с ничего не построено.
3) Перезапустите Visual Studio
исправление VS2010, связанное выше, не сработало для меня. Иногда перезапуск VS2010 устранит проблему, и когда это не сработает, выполните вышеуказанные работы.