У меня есть проект установки в .NET. Когда я сохраняю проект и другие проекты для подрывной работы, проект установки больше не компилируется. Я получаю сообщение об ошибке «Невозможно обновить зависимости проекта».
У меня есть проект установки в .NET. Когда я сохраняю проект и другие проекты для подрывной работы, проект установки больше не компилируется. Я получаю сообщение об ошибке «Невозможно обновить зависимости проекта».
Ответы:
На MSDN есть длинная ветка обсуждения . Похоже, есть много возможных причин. Обсуждение включает несколько ссылок на эту проблему от Microsoft. Вот исправление для VS2005 и обходной путь для VS2010.
Закрытие VS2010, а затем повторное открытие всегда помогало мне :)
У меня была такая же проблема, но ни одно из упомянутых решений, похоже, не помогло мне. Перестройка проекта установки подойдет, но это неприятно, поскольку мы включаем результаты более 30 проектов.
Я обнаружил, что работает очень похоже на то, что сделал @Marc.
Во всех случаях у меня было несколько ссылок на одну и ту же 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 ... но проект установки компилируется и работает нормально.
Fileссылки на сборку. Работает отлично.
Правильная ссылка на исправление для VS2010:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
Прекрасно работает после установки
У меня была аналогичная проблема, и я нашел решение в этом очень долгом и старом обсуждении на MSDN .
Как ответил пользователь Jeff Hunsaker в четверг, 26 августа 2010 г., 17:51 (прямая ссылка невозможна):
Я только что столкнулся с этим при обновлении проектов развертывания Visual Studio 2008 до VS 2010. Решение Ханса (см. Выше) сработало для меня.
- Отредактируйте файл .vdproj в Блокноте.
- Найдите "SourcePath" = "8:
- Для каждой сборки / dll укажите полный путь
- Сохранить файл
В моем файле .vdproj у меня было несколько записей, просто ссылающихся на сборку:
"SourcePath" = "8: MyAssembly.DLL"Несмотря на то, что Visual Studio каким-то образом знала расположение файла, я получал ошибку «Невозможно обновить зависимости проекта», пока не указал полный путь:
"SourcePath" = "8: .. \ .. \ .. \ build \ bin \ MyCompany.MyAssembly.DLL"
С Уважением,
Джефф...
Я отметил, о каких зависимостях сообщила Visual Studio, и написал сценарий, чтобы исправить их, если это потребуется.
Обратите внимание, что теперь это дает мне предупреждение: «Два или более объекта имеют одно и то же целевое местоположение ('[targetdir] \ MyAssembly.dll'). Но я могу с этим жить.
Это решило ту же проблему для меня: я добавил сборки, упомянутые в сообщении об ошибке, в GAC. Когда я перекомпилировал проект, DLL появилась в разделе «Обнаруженные зависимости» в обозревателе решений, и я получил ту же ошибку. Затем я исключил библиотеки DLL (щелкните правой кнопкой мыши и выберите «Исключить»), и проект, наконец, скомпилирован нормально.
Проблема может быть вызвана потерянными файлами в разделе «Deployable» -> «File» файла .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) Раздел HIERARCHY содержит GUID для каждого элемента (например, файла), добавленного в проект развертывания. Кроме того, каждый файл, добавленный в проект, отображается как элемент в разделе РАЗВЕРГАЕМЫЙ> ФАЙЛ . В следующем примере показана обычная конфигурация файла msimg32.dll . Обратите внимание на соответствующий идентификатор GUID (т.е. _1C15DB39774F7E79C84F1CC87ECFD60A) в ИЕРАРХИИ и ФАЙЛОВЫХ секциях.
"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, который не отображается в разделе HIERARCHY .
б) GUID, связанный с элементом в разделе FILE , был удален из раздела HIERARCHY (т. е. элемент в разделе FILE потерян).
3а) Пример первой проблемы - дублированный элемент в разделе ФАЙЛ :
В этом примере файл 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 ...
}
}
}
3б) Пример второй проблемы - потерянный элемент в разделе ФАЙЛ :
В этом примере файл 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 в пункте 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 произошли только для:
Вот несколько эффективных решений:
1) Удаление одной из проблемных DLL из проекта установки, а затем повторное добавление только этой, решило проблему для меня. Это работало даже тогда, когда проблема была в большом количестве DLL. Удаление и добавление только одного из них запустило VS2010, чтобы как-то их все исправить.
2) Восстановите решение, затем попробуйте снова обновить зависимости. Перестройка помогает визуальной студии обнаружить зависимости, потому что ей может быть сложно найти зависимости, но ничего не построено.
3) Перезапустите Visual Studio
Исправление VS2010, указанное выше, у меня не сработало. Иногда перезапуск VS2010 решает проблему, а если это не помогает, выполните указанные выше действия.
Я хотел бы добавить, что я получаю ту же ошибку, когда редактирую проект развертывания со своего компьютера, а не с выделенного компьютера-компилятора.
В последний раз, когда я получил эту ошибку, мне нужно было откатить последние изменения и повторить это с выделенного компьютера-компилятора.