Problème: Vient de commencer aujourd'hui, toutes les références à un assemblage en dehors de la solution ne sont pas résolues, avec The referenced component 'SomeComponent' could not be found.
lors de la tentative de génération. Cela se produit à la fois pour les composants tiers (environ 15) et pour tous les assemblys .NET Framework, en gros pour tout ce qui ne fait pas partie de la même solution.
Essayer de charger d'autres solutions a produit le même problème. Créer un nouveau projet WinForms a cependant fonctionné sans problème. (Cela a fonctionné avant la réinstallation de VS, cela ne fonctionne plus non plus. J'ai créé une nouvelle application WinForms ainsi qu'une application WPF, et le concepteur ne peut pas charger les assemblys non plus. J'ai essayé de cibler les versions 3.5 et 2.0 et non. la chance.)
Ce que j'ai essayé:
Quelqu'un at-il une expérience avec cela et sait-il un moyen de le faire fonctionner à nouveau? Mon plus puissant Google-fu m'a échoué, alors je demande ici. Peut marquer le wiki de la communauté si demandé.
Mise à jour: J'ai essayé de "mettre à niveau" Windows (vers la même version) car je ne voyais pas d'option de réparation pour Vista et c'est toujours impossible. J'ai réinstallé tout ce qui semblait pertinent. Jusqu'ici, il semble que je devrais simplement sauvegarder et reformater, à moins qu'une solution ne soit trouvée avant demain.
Update2: Je viens de sauvegarder les données et de les reformater. Je ne suis donc plus en mesure de vérifier les idées que je n'ai pas encore essayées. Je vais donc laisser la prime expirer d'elle-même jusqu'au dernier vote référence à quelqu'un d'autre qui pourrait avoir ce problème plus tard.
Etape de débogage suggérée suivante: review Project Designer: Références -> Chemins de référence pour vérifier que les chemins de votre système et des composants tiers apparaissent correctement. (Méfiez-vous des objets qui risquent de glisser devant l'ancienne Mark I Eyeball, comme des lettres de motivation.)
J'ai eu le même problème. Il s'avère que quelque chose n'allait pas avec NuGet. J'ai supprimé la partie suivante du *.csproj
- File (ouvert dans un éditeur de texte). Cela a résolu le problème pour moi:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.Microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
Dans mon cas, la solution était complètement différente. Il semblait que c'était un problème avec les chemins NuGet (causé par le déplacement du projet vers une solution différente, puis de nouveau.
J'ai modifié le fichier .csproj et supprimé toutes les références à NuGet et aux packages associés. J'ai également supprimé le dossier packages du dossier solution.
Les composants du système ont ensuite réapparu comme par magie.
J'ai eu ce problème similaire il n'y a pas si longtemps.
J'ai trouvé que le problème était dû au fait que git ne créait pas correctement les fichiers .exe lorsque l'on sautait de branche en branche (nous avons nuget.exe dans un chemin et il était supprimé/ajouté lors du saut de branche). Lorsque vous essayez d’exécuter une pépite, Windows pose un problème sur l’exécutable.
Après avoir réinitialisé la branche plusieurs fois, j'ai finalement réussi à faire fonctionner l'exe. Ensuite, j'ai remarqué que la sécurité de tous les répertoires du référentiel avait été réinitialisée. J'ai donc dû m'en occuper.
Après tout cela, Visual Studio a ensuite commencé à jouer à Nice.
Espéré que cela aide quelqu'un!
Essayez d’exécuter VS après la journalisation de la charge de l’assemblage avec fuslogvw. Vous pourrez voir des erreurs supplémentaires capturées par le moteur d'exécution lorsqu'il tente de localiser et de charger les assemblys.
Dans Vista, vous devez exécuter fuslogvw en tant qu'administrateur et spécifier parfois un chemin explicite pour enregistrer les journaux.
Vous pouvez également essayer de déboguer Visual Studio en y attachant une autre instance ou avec le débogueur de base fourni avec le Kit de développement logiciel (SDK) .NET.
Je sais que c'est une vieille question, mais cela se produit toujours dans la dernière version de Visual Studio (2015). Je l'ai corrigé d'une manière différente qui n'était peut-être pas disponible lorsque la question a été posée. Fondamentalement, cela est lié au fait que VS ne peut pas trouver le package .Net Library. Pour corriger dans la dernière version de Visual Studio (2015):
J'espère que cela aide quelqu'un!
Eh bien, si vous cliquez sur l'erreur dans VS 2012 RC et que vous la corrigez, l'erreur disparaît ...
Je déteste le dire, mais on dirait que le système est plutôt bouleversé. Il doit y avoir un moment où il est plus rapide de réinstaller le système d'exploitation que de continuer à essayer de réparer l'installation actuelle.
J'espère juste que vous prenez cela dans le bon esprit ... désolé.
Vérifiez votre sortie avec ILDASM pour vous assurer que les références s'affichent correctement. Comparez-les à un assemblage qui fonctionne et voyez si quelque chose vous échappe.
Tourné dans le noir ici, mais j'ai rencontré le même problème (similaire). Le problème que j'ai rencontré concernait le fait d'avoir une machine 64 bits et de gérer un projet qui comportait un mélange de dll tierces 64 bits et 32 bits. La solution consistait à vérifier que j'avais les bons bits (32v64), puis à faire en sorte que le projet soit construit en mode 32 bits: propriétés du projet> construire> plate-forme cible: x86.
Une autre fois, cela a eu lieu, j'ai dû supprimer toutes les DLL 64 bits et réinstaller avec les DLL 32 bits
HTH
Cela peut également être un problème avec les références d’autres projets dans la même solution. Je voulais seulement construire un projet, mais j'ai reçu ce message sur les références dans un autre projet. Bien que le problème de l’autre projet soit correct, je pense que le message n’était pas correct: