Visual Studio 2010 ne peut soudainement plus voir les espaces de noms ?

Question

Ma solution C# WinForms comporte deux projets. Une DLL qui est le projet principal sur lequel je travaille, et un exécutable WinForms que j'appelle "Sandbox" afin que je puisse compiler/exécuter/débugger facilement la DLL en une seule fois.

Je travaille en .Net 4.0 pour les deux projets.

Tout fonctionnait bien jusqu'à ce que j'ajoute du code apparemment innocent, et une référence à System.Web dans la DLL. Maintenant, mon projet Sandbox ne peut pas voir l'espace de nom du projet DLL. Je n'ai rien changé qui aurait pu avoir une incidence sur ce problème.

Si je supprime la référence du projet à la DLL des références Sandbox et que je la réintroduis, les soulignements rouges disparaissent et le codage couleur est rétabli pour toutes mes classes, etc.

Lorsque je clique avec le bouton droit de la souris sur le projet DLL dans les références de l'Environnement de test et que je l'affiche dans le navigateur d'objets, je peux voir l'espace de noms et tous les éléments qui s'y trouvent.

J'ai l'impression que ça pourrait être une sorte de bug ?

S'agit-il d'une sorte de bug de VS2010 ? J'ai eu ce même problème il y a quelques mois et je n'ai pu le résoudre qu'en créant un tout nouveau projet et en réimportant mes fichiers. Cette fois, cependant, j'ai un bajillion de fichiers et je ne le ferai qu'en dernier recours !

Modifier : Après avoir paniqué et annulé tous mes changements, en essayant de trouver ce qui a causé les problèmes, il semble que ce soit cette ligne :

string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);

Si je commente cette ligne, je n'obtiens aucune erreur d'espace de nom et le projet se construit bien. Je ne vois rien d'anormal dans cette ligne.

Answer 1

Je suis prêt à déclarer qu'il s'agit d'un bug dans VS2010, cela a déjà mordu beaucoup trop de programmeurs. La solution est simple : Projet + Propriétés, onglet Application, changer le Target Framework en ".NET Framework 4" au lieu du Client Profile qui est sélectionné par défaut.

System.Web n'est pas inclus dans le profil du client. Le fait d'avoir cette option en premier lieu est assez stupide, le profil client est seulement 15% plus petit que la version complète de .NET 4.0. Le fait qu'elle soit sélectionnée par défaut est encore plus stupide. Mais je m'égare.

MISE À JOUR : heureusement, tout cela a été corrigé dans VS2012. Ce dernier ne fait plus du profil client le profil par défaut pour un nouveau projet. Et le profil client a été complètement supprimé dans .NET 4.5, bon débarras.

Answer 2

Vérifiez que les deux projets utilisent le profil non-client pour leur framework cible (allez dans les propriétés de chaque projet pour le faire).

Answer 3

Essayez d'abord de construire uniquement le projet avec la dll Sandbox indépendamment.

Ensuite, faites pointer votre projet exécutable vers la dll requise et assurez-vous que copy local est réglé sur true . dans des cadres de référence.

Ensuite, construisez le projet exécutable.

Answer 4

Le fait de changer le cadre cible de ".NET Framweork 4 Client Profile" à ".NET Framework 4" a fonctionné pour moi avec un problème similaire. Je suis d'accord sur le fait que le profil client ne semble pas avoir beaucoup d'avantages à être utilisé. J'ai l'impression de me faire coincer par des erreurs bizarres que je recherche jusqu'à ce que je me rappelle que Visual Studio utilise par défaut le profil client. Je suppose que la morale de l'histoire lorsque vous obtenez une erreur est : si "Rebuild Solution" ne fonctionne pas, vérifiez le cadre cible ...

Answer 5

Si vous avez déjà essayé de faire le changement de Framework, et que cela n'a toujours pas fonctionné, j'espère que ceci fonctionnera pour vous (comme cela a fonctionné pour moi) : Ajoutez simplement les références nécessaires à partir de vos projets. C'est très évident mais je le faisais mal jusqu'à ce que je trouve le problème.