Pourquoi le message d'erreur suivant s'affiche-t-il lors de la construction d'un projet d'installation?
Une erreur s'est produite lors de la validation. HRESULT = '80004005'
Cette erreur est liée à une erreur de dépendance. J'ai supprimé toutes les références à mon projet de sortie principal et les ai ajoutées à nouveau. Il compile maintenant OK!
Un projet de la solution avait ToolsVersion="4.0"
(dans le fichier .csproj), il a été remplacé par ToolsVersion="3.5"
et le projet d’installation est bien construit.
Les deux raisons que j'ai trouvées se trouvent déjà dans d'autres réponses, mais elles le sont dans des réponses séparées et ne sont pas expliquées complètement. Donc, espérons que cela combinera les possibilités et donnera un bon moyen de déboguer chacun. :)
Raison commune
Mon problème n'était pas une erreur de dépendance. Cependant, cela semble être la raison commune. Donc, en gros, vous devez vérifier votre fichier MSI et vous assurer que toutes les dépendances sont toujours valides. La meilleure réponse du blog sur la façon dont vous pouvez facilement résoudre ce problème s'il s'agit d'un problème de dépendance est Une erreur s'est produite lors de la validation. HRESULT = '80004005'.
Extrait du blog:
Suivez les étapes ci-dessous pour résoudre le problème.
- Si votre solution contient plusieurs sorties de projet, identifiez le projet à l'origine du problème. Vous pouvez le faire en supprimant un projet à la fois du projet d'installation (S) jusqu'à ce que l'erreur disparaisse.
Une fois le projet identifié, identifiez la référence qui pourrait donner le problème.
- Vérifiez si le projet (A) fait référence à un projet qui a été retiré de la solution. - Supprimez ces références, le cas échéant.
- Vérifiez si le projet (A) fait référence à un projet qui a été déplacé vers un autre emplacement physique après son ajout en tant que référence. - Supprimer et ajouter de telles références.
Reconstruisez le projet d'installation après avoir corrigé la référence en conséquence pour voir si l'erreur disparaît.
Raison alternative
Cependant, mon problème était lié à la gestion des versions de Visual Studio. Donc, si vos dépendances sont valides et que vous rencontrez toujours ce problème, vous devez le résoudre s'il s'agit d'un problème avec VS2010 .
En gros, si vous exécutez MSBuild et que vous voyez cet avertissement:
Le fichier de projet contient ToolsVersion = "4.0", qui n'est pas pris en charge par Cette version de MSBuild. Traiter le projet comme s'il avait ToolsVersion = "3.5"
Ensuite, le problème est le contrôle de version Visual Studio. Cela signifie qu'un projet a été ouvert ou créé dans Visual Studio 2010, puis enregistré ou ajouté à une solution 3.5 existante. J'ai simplement recherché ToolsVersion="4.0"
dans tous les fichiers de mon projet et trouvé le fichier .csproj
incriminé, je l'ai ouvert dans un éditeur de texte et modifié manuellement le 4.0
en 3.5
.
Je me suis heurté à ce problème aujourd'hui. La solution dans mon cas? Redémarrez Visual Studio 2008.
Dans mon cas, ma solution (VS2008) comportait un projet référencé dans une autre solution (VS2010). Dans la solution VS2010, j'avais mis à niveau le projet vers .NET 4.0. Lorsque j'ai réalisé par la suite que le projet était également utilisé dans une autre solution, je l'ai rétrogradé en .NET 3.5. Pour une raison quelconque, tout semblait avoir été modifié correctement dans le fichier csproj sauf un emplacement mentionné ici: Erreur dans le projet d'installation HRESULT = '80004005'
Je sais que cela est déjà résolu ailleurs, mais je voulais éclairer la question sous un autre angle.
J'ai passé énormément de temps sur celui-ci, même si rien de ce qui précède n'a fonctionné. Mais j'ai trouvé une autre solution avec un hack de registre, vous devez ajouter une nouvelle valeur DWORD (EnableOutOfProcBuild
) de (0
) à HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild\EnableOutOfProcBuild
Note : ceci concerne Visual Studio 2015
Bien que le simple fait de supprimer et d'ajouter de nouveau les dépendances de projet fonctionne dans de nombreux cas, il est important de noter que:
Le message d'erreur "Une erreur s'est produite lors de la validation. HRESULT = 80004005." Se produit généralement lorsque le projet est référencé vers l'autre projet qui n'est Pas ajouté à la solution actuelle. Le projet d'installation prend en charge uniquement les projets de dépendance Au sein de la même solution. 1
Dans mon cas, j'avais installé Visual Studio 2010 en même temps que Visual Studio 2008. Mon projet d'installation, lors de son ouverture dans Visual Studio 2008, donnait la même erreur, mais était OK dans Visual Studio 2010.
Si copié sur un autre ordinateur qui ne possédait pas Visual Studio 2010, mais qui en possédait déjà, il serait compilé.
J'ai lu cette réponse dans un autre billet sur Stack Overflow, et cela a fonctionné pour moi.
Ouvrez votre fichier de projet d'installation (.vdproj) dans Notepad (ou tout autre éditeur de texte). Supprimez ces lignes au début du fichier .vdproj:
"SccProjectName" = "8:"
"SccLocalPath" = "8:"
"SccAuxPath" = "8:"
"SccProvider" = "8:"
Construire à nouveau - l'erreur est parti. Cette erreur ne m'a pas empêché de déployer, de construire, de déboguer (ou quoi que ce soit) mon projet; ça m'a juste agacé. Et cela s’est fait même si je définissais tous les projets comme étant intégrés à une configuration actuelle et que le projet de configuration ne le soit pas.
Je sais que cela est un peu vieux, mais mon problème et ma solution ne sont pas spécifiquement décrits ici (pour autant que je sache, si je l’ai manqué, je m'en excuse).
J'ai eu le même problème. Cela ne compilerait pas mon projet, mais ne comporterait aucune erreur. Tout ce que je pouvais voir était "Build Failed". J'ai ouvert le fichier "Sortie" (Cliquez sur Affichage -> Sortie dans le menu), et il m'a dit exactement quelle référence (dans mon cas, un fichier .dll) était à l'origine du problème.
J'ai supprimé et recréé la référence et il a changé le nom de référence de Microsoft.Office.Core (qui n'était apparemment qu'une version 32 bits) en "OFFICE". Ensuite, tout a bien fonctionné. - Assurez-vous de noter le chemin d'accès au fichier que vous référencez dans la fenêtre des propriétés ... Mon nouveau chemin d'accès était exactement le même, mais le nom de la référence a quand même changé ... tout en me grattant la tête. ..
La morale de l’histoire est donc ... Lorsque vous n’obtenez aucune erreur et que votre construction échoue, cochez la case "Sortie" et cela pourrait aider.
J'ai installé Visual Studio 2010 et converti les solutions dans cette version. En raison de problèmes de performances, j'ai modifié mes solutions pour revenir à Visual Studio 2008. Tout allait mieux maintenant, mais une erreur s'est produite lorsque j'ai essayé de compiler le projet d'installation. Je me suis rendu compte que j'avais un projet de test Visual Studio 2010 dans ma solution; il ne me restait donc plus qu'à décharger le projet de test et à générer à nouveau le projet de configuration.
Résumé: déchargez tout projet Visual Studio 2010 dans la solution.
J'espère que ça aide.