"Impossible de mettre à jour les dépendances du projet" après avoir validé Subversion
J'ai un projet d'installation en .NET. Lorsque j'enregistre le projet et les autres projets dans Subversion, le projet d'installation ne se compile plus. J'obtiens l'erreur "Impossible de mettre à jour les dépendances du projet".
Il y a un long discussion fil à ce sujet sur MSDN. Il semble qu'il existe de nombreuses causes possibles. La discussion inclut quelques liens pour ce problème de Microsoft. Voici un correctif pour VS2005 et voici une solution de contournement pour VS2010.
Fermer VS2010 puis rouvrir ça a toujours fonctionné pour moi :)
J'ai eu le même problème, mais aucune des résolutions mentionnées ne semblait fonctionner pour moi. Reconstruire le projet d'installation fonctionnerait, mais c'est pénible, car nous incluons les sorties de projet de plus de 30 projets.
La chose que j'ai trouvée fonctionner est une approche très similaire à ce qu'a fait @Marc.
- J'ai noté les dépendances signalées par Visual Studio comme des erreurs
- Modifiez le fichier .vdproj dans Notepad ++
- Recherchez le fichier .dll qui pose problème. Vous verrez une section "ScatterAssemblies". S'il est vide, supprimez toute la référence de la DLL
- Enregistrer le fichier
Dans tous les cas, j'ai eu plusieurs références à la même DLL (je ne sais pas comment cela s'est produit)
Exemple de référence correcte:
"{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:"
}
Exemple de référence incorrecte:
"{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:"
}
J'ai également reçu le même message "Deux objets ou plus ont le même emplacement cible ('[targetdir]\MyAssembly.dll')", avertissant que @Marc a obtenu ... mais le projet d'installation se compile et fonctionne correctement.
Le lien correct pour le correctif pour VS2010 est:
http://connect.Microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
Fonctionne bien après l'installation
J'ai eu le même problème et j'ai trouvé un correctif dans cette très longue et très ancienne discussion sur MSDN .
En tant qu'utilisateur 'Jeff Hunsaker' le jeudi 26 août 2010 5:51 PM a répondu (lien direct impossible):
Je viens de rencontrer cela lors de la mise à niveau de Visual Studio 2008 Deployment Projects vers VS 2010. La solution de Hans (ci-dessus) a fonctionné pour moi.
- Modifiez le fichier .vdproj dans le Bloc-notes.
- Recherchez "SourcePath" = "8:
- Pour chaque assembly/dll, indiquez le chemin complet
- Enregistrer le fichier
Dans mon fichier .vdproj, j'avais plusieurs entrées faisant simplement référence à l'assembly:
"SourcePath" = "8: MyAssembly.DLL"Même si Visual Studio [en quelque sorte] connaissait l'emplacement du fichier, j'ai reçu l'erreur "Impossible de mettre à jour les dépendances du projet" jusqu'à ce que je fournisse le chemin complet:
"SourcePath" = "8: ..\..\..\build\bin\MyCompany.MyAssembly.DLL"
Cordialement,
Jeff ...
J'ai noté les dépendances signalées par Visual Studio et j'ai écrit un script pour les corriger au cas où cela serait nécessaire.
Notez que cela me donne maintenant un avertissement "Deux ou plusieurs objets ont le même emplacement cible ('[targetdir]\MyAssembly.dll'). Mais je peux vivre avec cela.
Cela a résolu le même problème pour moi: j'ai ajouté les assemblys mentionnés dans le message d'erreur au GAC. Lorsque j'ai recompilé le projet, les DLL sont apparues sous "Dépendances détectées" dans l'Explorateur de solutions et j'ai eu la même erreur. Ensuite, j'ai exclu les DLL (clic droit et sélectionnez Exclure) et le projet a finalement été compilé ok.
J'ai réussi à contourner ce problème en supprimant le projet d'installation de la solution, puis en ajoutant à nouveau le projet existant.
Le problème peut être dû à des fichiers orphelins dans la section "Deployable" -> "File" du fichier .vdproj. Vous pouvez le vérifier en supprimant tous les fichiers du projet d'installation dans Visual Studio (effectuez d'abord une sauvegarde). Si vous ouvrez le fichier .vdproj avec un éditeur de texte et voyez toujours des entrées dans la section "Fichier", vous avez ce problème. Vous pouvez noter les clés de ces fichiers et les supprimer du fichier .vdproj d'origine et cela devrait fonctionner à nouveau.
Vous pouvez également compiler ce programme de correction rapide (testé uniquement avec 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());
}
}
}
Le redémarrage de VS2010 n'a pas fonctionné pour moi mais j'ai réussi à tout faire fonctionner en faisant une 'Clean Solution', puis une 'Build Solution'. Cependant, essayer la "solution de reconstruction" après le nettoyage n'a pas fonctionné. Ensuite, je pouvais exécuter la solution avec F5 comme d'habitude.
Lorsque j'obtiens cette erreur, je trouve que mon projet de déploiement VS2010 (.vdproj) est "corrompu". Plus précisément, les éléments de la section FILE du fichier VDPROJ ont des GUID manquants dans la hiérarchie section du fichier VDPROJ. Ceci est décrit en détail ci-dessous.
1) Les projets de déploiement VS2010 comprennent les sections suivantes:
"Hierarchy"
{
}
"Deployable"
{
"File"
{
}
}
2) La section HIÉRARCHIE contient des GUID pour chaque élément (par exemple, un fichier) ajouté au projet de déploiement. De plus, chaque fichier ajouté au projet apparaît comme un élément dans la section DEPLOYABLE> FILE. L'exemple suivant montre une configuration normale pour le fichier msimg32.dll. Notez la correspondance GUID (c'est-à-dire _1C15DB39774F7E79C84F1CC87ECFD60A) dans la HIÉRARCHIE et FICHIER = sections.
"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) Mes projets de déploiement VS2010 peuvent être corrompus de deux manières:
a) Un élément de la section DU FICHIER est dupliqué et l'élément dupliqué reçoit un GUID qui n'apparaît pas dans le HIÉRARCHIE section.
b) Le GUID associé à un élément de la section FILE a été supprimé de la hiérarchie section (c'est-à-dire que l'élément dans la section FICHIER est orphelin).
3a) Exemple de premier problème - élément dupliqué dans la section :
Dans cet exemple, le fichier msimg32.dll a deux entrées dans la section FILE . La première entrée (c'est-à-dire correcte) a une correspondance GUID (c'est-à-dire _1C15DB39774F7E79C84F1CC87ECFD60A) dans la section DE LA HIÉRARCHIE , mais le GUID pour le la deuxième entrée (c.-à-d. erreur) (c.-à-d. 2DDC4FA12BFD46DEAED0053D23331348) n'apparaît pas dans la section HIÉRARCHIE .
"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) Exemple de second problème - élément orphelin dans la section FICHIER :
Dans cet exemple, le fichier msimg32.dll a une entrée dans la section FILE . Mais le GUID associé à cette entrée (c'est-à-dire A515046ADA6244F2A260E67625E4398F) n'a pas d'entrée correspondante dans (c'est-à-dire qu'il manque) dans la section HIÉRARCHIE .
"Hierarchy"
{
}
"Deployable"
{
"File"
{
"{1FB2D0AE-D3B9-43D4-B9DD-F88EC61E35DE}:_A515046ADA6244F2A260E67625E4398F"
{
"SourcePath" = "8:MSIMG32.dll"
"TargetName" = "8:MSIMG32.dll"
… more information ...
}
}
}
4) Solution: pour les deux problèmes illustrés ci-dessus, la solution consiste à supprimer l'élément orphelin dans la section FILE .
L'exemple suivant montre comment la section FICHIER au point 3a ci-dessus apparaît après la deuxième entrée pour msimg32.dll a été supprimée.
"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) J'ai trouvé que les entrées corrompues dans le VDPROJ ne se sont produites que pour:
- a) Fichiers d'assemblage (c'est-à-dire DLL) de mes projets C # et
- b) des dépendances détectées de mes projets C++ (par exemple version.dll, urlmon.dll)
Voici quelques solutions qui fonctionnent:
1) Suppression de l'une des DLL problématiques du projet d'installation, puis réajout de celle-ci uniquement a résolu le problème pour moi. Cela a fonctionné même lorsqu'il y avait de nombreuses DLL avec le problème. La suppression et l'ajout d'un seul d'entre eux ont déclenché VS2010 pour tous les réparer.
2) Reconstruisez la solution, puis essayez à nouveau de mettre à jour les dépendances. La reconstruction aide Visual Studio à découvrir quelles sont les dépendances, car il peut avoir du mal à trouver les dépendances avec rien de construit.
3) Redémarrez Visual Studio
Le correctif VS2010 lié ci-dessus n'a pas fonctionné pour moi. Parfois, le redémarrage de VS2010 résoudra le problème et lorsque cela ne fonctionne pas, la procédure ci-dessus fonctionne.
Je voudrais ajouter que j'obtiens la même erreur lorsque je modifie le projet de déploiement à partir de mon ordinateur au lieu de l'ordinateur du compilateur dédié.
La dernière fois que j'ai eu cette erreur, j'avais besoin d'annuler les derniers changements et de le refaire depuis l'ordinateur du compilateur dédié.
Cela peut également se produire lorsque vous essayez de déboguer et que vous avez sélectionné le mode Release. Je viens de me voir :(