J'ai un projet d'installation dans .NET. Lorsque j'enregistre le projet et les autres projets sous subversion, le projet d'installation ne se compile plus. J'obtiens l'erreur «Impossible de mettre à jour les dépendances du projet».
J'ai un projet d'installation dans .NET. Lorsque j'enregistre le projet et les autres projets sous subversion, le projet d'installation ne se compile plus. J'obtiens l'erreur «Impossible de mettre à jour les dépendances du projet».
Réponses:
Il existe un long fil de discussion à ce sujet sur MSDN. Il semble qu'il existe de nombreuses causes possibles. La discussion comprend quelques liens pour ce problème de Microsoft. Voici un correctif pour VS2005 et voici une solution de contournement pour VS2010.
Fermer VS2010 puis le rouvrir 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 une douleur, car nous incluons les résultats du projet de plus de 30 projets.
Ce que j'ai trouvé à travailler est une approche très similaire à ce que @Marc a fait.
Dans tous les cas, j'avais plusieurs références à la même dll (je ne sais pas comment cela s'est passé)
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 avertissement "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.
Fileréférences d'assemblage. A parfaitement fonctionné.
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é une solution dans cette très longue et ancienne discussion sur MSDN .
Comme l'utilisateur 'Jeff Hunsaker' a répondu le jeudi 26 août 2010 à 17h51 (lien direct impossible):
Je viens de rencontrer cela lors de la mise à niveau des projets de déploiement de Visual Studio 2008 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 connaissait [d'une manière ou d'une autre] l'emplacement du fichier, j'ai reçu l'erreur «Impossible de mettre à jour les dépendances du projet» jusqu'à ce que j'aie fourni le chemin complet:
"SourcePath" = "8: .. \ .. \ .. \ build \ bin \ MyCompany.MyAssembly.DLL"
Cordialement,
Jeff ...
J'ai noté quelles dépendances ont été 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 objets ou plus 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é correctement.
Le problème peut être dû à des fichiers orphelins dans la section «Deployable» -> «File» du fichier .vdproj. Vous pouvez vérifier cela 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 que vous voyez toujours des entrées dans la section «Fichier», vous rencontrez 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 correctif 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 «solution propre», puis une «solution de construction». Cependant, essayer 'Rebuild Solution' après le nettoyage n'a pas fonctionné. Ensuite, je pourrais 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 HIERARCHY contient des GUID pour chaque élément (par exemple, fichier) ajouté au projet de déploiement. De plus, chaque fichier ajouté au projet apparaît comme un élément dans la section DÉPLOYABLE> FICHIER . L'exemple suivant montre une configuration normale pour le fichier msimg32.dll . Notez le GUID correspondant (c. -à -_1C15DB39774F7E79C84F1CC87ECFD60A) dans les HIÉRARCHIE et FILE 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 FILE est dupliqué et l'élément dupliqué reçoit un GUID qui n'apparaît pas dans la section HIERARCHY .
b) Le GUID associé à un élément de la section FILE a été supprimé de la section HIERARCHY (c'est-à-dire que l'élément de la section FILE est orphelin).
3a) Exemple de premier problème - élément dupliqué dans la section FILE :
Dans cet exemple, le fichier msimg32.dll a deux entrées dans la section FILE . La première entrée (ie correct) a un GUID correspondant (c. -à -_1C15DB39774F7E79C84F1CC87ECFD60A) dans la HIERARCHY section, mais le GUID pour le second ( à savoir erreur) entrée (ie 2DDC4FA12BFD46DEAED0053D23331348) ne figure pas dans la HIERARCHY section.
"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 deuxième problème - élément orphelin dans la section FILE :
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 une entrée correspondante dans (c'est-à-dire qu'il est absent de) la section HIERARCHY .
"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 FICHIER .
L'exemple suivant montre comment la section FILE au point 3a ci-dessus apparaîtrait après la suppression de la deuxième entrée pour 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) J'ai trouvé les entrées corrompues dans le VDPROJ ne se sont produites que pour:
Voici quelques solutions qui fonctionnent:
1) La suppression de l'une des DLL de problème du projet d'installation, puis la réintroduction de celle-ci a résolu le problème pour moi. Cela fonctionnait 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 les réparer tous d'une manière ou d'une autre.
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 sans 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 fonctionnera pas, effectuer les opérations ci-dessus.
Je voudrais ajouter que j'obtiens la même erreur lorsque j'édite 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'ai dû annuler les dernières modifications et le refaire à partir de l'ordinateur de compilation dédié.