У мене є проект налаштування в .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 (клацніть правою кнопкою миші та виберіть Виключити), і проект нарешті скомпілюється нормально.
Проблему можуть спричинити осиротілі файли у розділі "Розгортання" -> "Файл" файлу .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 в тому , що відсутні в HIERARCHY секції файлу VDPROJ. Це докладно описано нижче.
1) Проекти розгортання VS2010 включають такі розділи:
"Hierarchy"
{
}
"Deployable"
{
"File"
{
}
}
2) Розділ ІЄРАРХІЯ містить 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 можна пошкодити двома способами:
а) Елемент у розділі ФАЙЛ дублюється, а продубльованому елементу надається GUID, який не відображається в розділі ІЄРАРХІЯ .
b) GUID, пов'язаний з елементом у розділі ФАЙЛ , було видалено з розділу ІЄРАРХІЯ (тобто елемент у розділі ФАЙЛ залишився сиротою).
3a) Приклад першої проблеми - продубльований елемент у розділі ФАЙЛ :
У цьому прикладі файл msimg32.dll має два записи у розділі ФАЙЛ . Перший (тобто правильний) запис має відповідний ідентифікатор GUID (тобто _1C15DB39774F7E79C84F1CC87ECFD60A) в HIERARCHY розділі, але GUID для другого (тобто помилка) запис (тобто 2DDC4FA12BFD46DEAED0053D23331348) не з'являється в 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) Приклад другої проблеми - осиротілий предмет у розділі ФАЙЛ :
У цьому прикладі файл msimg32.dll містить запис у розділі ФАЙЛ . Але GUID , пов'язаний з цим записом (тобто A515046ADA6244F2A260E67625E4398F) не має відповідного запису в (тобто відсутня) в ієрархії секції.
"Hierarchy"
{
}
"Deployable"
{
"File"
{
"{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_A515046ADA6244F2A260E67625E4398F"
{
"SourcePath" = "8:MSIMG32.dll"
"TargetName" = "8:MSIMG32.dll"
… more information ...
}
}
}
4) Рішення: Для обох проблем, проілюстрованих вище, рішення полягає у видаленні осиротілого предмета в розділі ФАЙЛ .
Наступний приклад показує, як розділ ФАЙЛ у пункті 3а вище буде виглядати після видалення другого запису для 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 вирішить проблему, а коли це не допоможе, виконайте наведені вище дії.