Le type ou l'espace de noms <blah> n'existe pas
Ok, j'ai eu celui-ci un million de fois avant et il a été répondu à 1 million +1 fois auparavant.
Et pourtant, encore une fois. J'ai 3 projets, A, B et C, chacun une DLL. Chaque projet est .Net 4.0 (pas la version du client, version 4.0 complète). Les projets C font référence à A et à B. Ils sont référencés en tant que projets et la sortie est configurée pour être copiée localement.
En C, j'ai deux déclarations using dans mon fichier .cs:
using A;
using B;
Lorsque je compile, je reçois la plainte qui ne peut pas trouver B. A va bien. B dépend de A.
Que diable devrais-je faire? J'ai supprimé et rajouté, fermé VS2010, rouvert, consulté le fichier .csproj. Et je ne peux tout simplement pas l'obtenir. Encore une fois, pour la millionième fois.
Quelqu'un s'il te plaît me tape assez de sens pour que j'en apprenne la source une fois pour toutes!
Et oui, cela a probablement été répondu quelque part dans StackOverflow, mais pas dans les réponses les plus fréquentes que j'ai vérifiées jusqu'à présent. Les termes sont trop génériques pour être utiles, trop de questions où la réponse est "duh, ajoutez une référence". J'ai dépassé ce point.
Voici les erreurs que je reçois. Il existe 3 types, mais d’expérience, le dernier est le vrai.
Error 130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an Assembly reference?)
Error 114 'object' does not contain a definition for <blah>
Error 59 The type or namespace name '<blah>' could not be found (are you missing a using directive or an Assembly reference?)
Aha j'ai regardé les avertissements, pas seulement les erreurs, et voici ce que je vois:
Warning 69 The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist. AWI.WWG.EXPMRI.MriUpload.Objects
Ce fichier .csproj est le "B" dans ce cas. Même si je supprime et rajoute la référence du projet, je l’ai. Mais j'ai l'impression de m'approcher!
Hmm, je viens de trouver une autre DLL, appelez-le "D", qui "A" fait référence. Quand je l'ajoute au projet, je commence à recevoir la plainte:
----------------
The Add Reference Dialog could not be shown due to the error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------
Cela pourrait-il être lié, ou juste une autre distraction?
Ok, j'ai trouvé le problème, même si je ne le comprends pas.
Lorsque j'ajoute la référence via l'EDI, il ajoute ceci au fichier csproj de "C":
<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">
Cela ne compile pas, il avertit qu'il ne peut pas trouver le projet référencé, alors toutes ces ERREURS se produisent. Mais alors je change le ProjectReference comme suit:
<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">
... et ça marche très bien. Notez qu'aucun de ces chemins ne sont proches de 256 caractères. Le qualifié complet n’est que de 135 caractères. Mais peut-être que IDE est en train de décorer de manière idiote le chemin.
La solution concerne les limites de chemin de fichier dans Windows, et celles-ci permettent à IDE de traduire les chemins relatifs en chemins complets, comme expliqué dans ce blog .
La solution immédiate consiste à modifier le fichier csproj manuellement pour utiliser le chemin absolu. Jusqu'à ce que la référence soit rajoutée, le chemin absolu sera valide. Un jour, je raccourcirai peut-être mes dossiers, mais ce n’est pas une priorité pour le moment.
Si vous pensez que vous avez ce problème, consultez les messages d’avertissement du compilateur. Je les ai souvent éteints moi-même, ne regardant que des erreurs. Mais l'avertissement concernant "le projet référencé n'existe pas" était l'indice qui a résolu ce problème pour moi.
Au cas où l'autre lien disparaîtrait, voici le lien vers l'article MS. http://support.Microsoft.com/kb/2516078
Il convient de noter que cette même erreur se manifeste pour une variété de problèmes, tels que les problèmes de ciblage client-cadre, et est consignée en tant qu'avertissement lorsqu'un chargement de référence échoue. Vraisemblablement, l'erreur de référence n'est qu'un avertissement, car si la référence n'est pas réellement nécessaire, cela n'a pas d'importance.
Je voudrais m'assurer que votre projet a inclus les références aux assemblées.
Je voudrais vérifier que l'ordre de construction correspond à vos dépendances
Enfin, si tout est configuré correctement, vous devriez voir l'ordre de génération suivant:
Cela ne ressemble pas à votre problème, mais pour être complet, j’ajouterai qu’une autre chose à vérifier (si votre projet cible le .NET Framework 3.5 ou supérieur) est que le cadre cible des deux projets correspond. Si vous liez quelque chose qui cible le profil du client à partir d'une version complète du Framework, vous obtiendrez également une erreur "introuvable":
Allez dans la section d'avertissement et résolvez tous les avertissements et vous avez terminé ...
La section d'avertissement vous indiquera toutes les dépendances internes des dll nécessaires au projet auquel vous faites référence.
Je sais que ce n'est pas la solution à votre problème, mais l'erreur est assez similaire lorsque vous essayez de référencer un projet avec une version .net supérieure à celle que vous utilisez. IE: vous ne pouvez pas référencer quelque chose avec .net 4.5 à partir de .net 3.5
Après plusieurs heures de frustration, j'ai découvert le processus suivant pour résoudre ce problème avec une solution VS2017:
Insure that all reference assemblies have been recognized and have current properties.
If assemblies do not show proper reference, right click the entry
and view properties. This action often resets the reference. This
action must be completed for each project in the solution.
After resolving all references, if the error continues, delete the
following:
-The Obj folder
-The Bin folder
-Reference to the offending Assembly
-Clean and Rebuild the solution. Errors should occur.
-Re-reference the needed Assembly.
The editor should no longer show the namespace error and build should succeed.
Je l'ai eu lors de la mise à jour d'un projet que nous utilisons normalement via NuGet. Je pensais que si je copiais simplement la DLL créée dans le dossier des paquets, je pouvais le tester sans avoir à configurer NuGet sur ma machine, mais ce n'était pas aussi simple, car mon application cherchait toujours l'ancien numéro de version. J'espère que cela aide quelqu'un là-bas.
En gros, cela ressemble à une référence manquante.
Certains contrôles de bon sens auxquels je peux penser sont:
- Êtes-vous sûr que le projet qui génère l'erreur est C?
- Êtes-vous sûr de ne pas avoir fait une faute d'orthographe dans l'espace de noms B lors de votre utilisation?
- Peut-il y avoir eu une erreur de compilation en B avant de compiler C? (Cela peut empêcher le compilateur de trouver l'espace de noms dans B).
- Avez-vous une autre erreur de compilation ou un autre avertissement?
Modifier
Une autre suggestion: la classe de l’assemblée B est-elle définie par public?
J'ai résolu ceci en utilisant global::[namespace][type I want to use] en C # 6.0
Avec VS2017, ce problème est apparu lorsque le projet de ma solution a été déchargé.
Créez un projet propre et testez un nombre minimal d'assemblages que vous utilisez dans votre projet. De cette façon, vous serez sûr s'il y a quelque chose de mal dans votre solution ou si le projet nouvellement créé présente les mêmes symptômes. Si oui, alors peut-être que VS, .net etc est corrompu ou quelque chose.
J'ai soudainement commencé à avoir cette erreur en essayant de résoudre un autre problème
J'ai résolu ce problème en allant dans Solution => properties => dépendances de projets et toutes les dépendances étaient désactivées pour les deux projets pour lesquels je recevais une erreur d'espace de noms. J'ai vérifié les cases à cocher et reconstruit la solution sans erreurs.