Erreurs de compilation dans Reference.cs après l'ajout d'une référence de service provoquée par un espace de noms en plusieurs parties

J'ai frappé cette étrange espace de noms problème lors de l'ajout de mon premier "Service de Référence" pour un projet client dans Visual Studio 2010.

Si mon projet de l'espace de noms par défaut utilise deux ou plusieurs parties, par exemple MyCompany.MyApp puis lors de l'ajout d'un Service de Référence une Référence.cs fichier est créé contenant les noms MyCompany.MyApp.ServiceReferenceName avec beaucoup d'auto-gen de code avec des noms pleinement qualifiés, par exemple System.SerializableAttributeSystem.Runtime.Serialization.DataContractAttribute.

La Référence.cs fichier sera plein d'erreurs de compilation car le compilateur commence le traitement de l'espace de noms System sous membre de la MyCompany.MyApp espace de noms. Vous obtenez beaucoup d'erreurs le long des lignes de:

The type or namespace name 'Runtime' does not exist in the namespace 'MyCompany.MyApp.System'...

Si je modifie l'espace de noms en haut de la Référence.cs fichier à quelque chose de simple, par exemple MyCompanyMyApp.ServiceRefernceName puis le compilateur se comporte et reconnaît l'espace de noms du Système de références que de decleration de .net de l'espace de noms System.

Je suis en utilisant une solution à ce problème pour le moment car j'ai vraiment envie de garder ma partie multi-espaces de noms. Mon alternative est d'ajouter global:: en face de l'espace de noms du Système de références pour forcer le compilateur à faire la bonne chose. En fait, si le " Ajouter une Référence de Service assistant utilise les modèles de T4 je peut juste modifier celles à incorporer ma solution de contournement à la source.

Questions

J'aimerais vraiment comprendre ce qui se passe ici et pourquoi un multi-partie de l'espace de noms sont les causes de ce problème. Sans doute il y a plus d'espaces de noms que je ne le pensais. Deuxièmement, voudrais vraiment travailler une meilleure solution que d'effectuer une recherche/remplacement global à chaque fois que je ajouter une Référence de Service ou de déblayage autour, avec certains des modèles T4.

source d'informationauteur Simon Needham

.net c#service-reference visual-studio-2010 wcf

24

J'ai trouvé la réponse ici peu claires, alors j'ai pensé que je voudrais ajouter ceci comme un exemple (je voudrais le faire dans les commentaires, mais il ressemble mieux ici):

J'ai donc ce que mon espace de noms par défaut:
```
namespace RelatedData.Loader
```
Mais j'ai aussi ajouter une classe nommée:
```
 public class RelatedData
{
}
```
Parce que le nom de la classe correspond à une portion de l'espace de noms lors de la génération de votre proxy à Ajouter une Référence de Service, il devient confus.

Ici, la réponse a été de renommer ma classe:
```
 public class RelatedDataItem
```
16

Ahh bien, j'ai trouvé la cause par la suite.

Je suis à l'encontre d'un très gros tiers de la WCF API ... et un de leurs espaces de noms est LameCompany.System (!!) Carnage en découle...

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

La leçon à tirer ici est lorsque Visual Studio/.net compilateur s'arrête la reconnaissance de la BCL est System espace de noms, vous disposez d'un espace de noms/type dans votre projet appelé System. Trouver l'enlever, tirer le développeur qui l'a créé.
6

J'ai trouvé que le fait d'avoir un nom de classe similaire à votre espace de noms sont les causes de cette.

Essayez de renommer le nom de la classe
1

J'ai rencontré un problème similaire avec VS2012 décrit par jabu.hlong et Simon Needham après des modifications mineures dans le projet du client qui a des références pour les services WCF après la mise à jour de la référence à la services de. J'ai eu beaucoup d'erreurs de compilation de la Référence.cs fichiers générés et ainsi de suite (les fichiers générés de la XAML).

J'ai choisi de réutiliser les types d'assemblées spécifiques dans ma solution et a obtenu un des problèmes similaires avec les espaces de noms.

L'erreur que je reçois est que l'espace de noms de la réutilisés de l'assemblée et de l'espace de noms des types générés ne peuvent pas être trouvés lorsqu'il est utilisé dans la Référence.cs. Les deux espaces ont en commun les premières parties, comme ils sont de la même solution. Mes espaces de noms dans la solution sont comme appname.tier.technology.project. À la fois contradictoires les espaces de noms sont Appname.Dto.Modulename (le réutilisés assemblée) et Appname.Client.Wpf.ServiceName (l'espace de noms dans le projet du client en utilisant les services pour les types générés).

Le problème se pose après un changement mineur dans le projet du client, lorsque j'ai créé une nouvelle classe utilitaire dans l'espace de noms Appname.Client.Wpf.Appname. J'ai choisi de l'espace de noms parce que le Nom est aussi le nom d'un module dans le projet du client. Cela semble confondre le compilateur et ne peut pas résoudre à la fois des espaces de noms dans le générés de Référence.cs. Après la modification de l'espace de noms de la classe utilitaire afin d'éviter l'utilisation de deux pièces identiques en elle et la mise à jour de la référence de service, les erreurs du compilateur dans la Référence.cs disparaît.
0

J'ai essayé différentes choses (et j'ai essayé différents espaces de noms lors de l'ajout de la référence de service), mais rien n'a fonctionné pour moi, sauf que cette force brute fixe - dans mon cas, c'était OK, mais je suis conscient que c'est laid (et doit être répété si vous utilisez la mise à Jour "de Référence" dans le futur):

Depuis le service WCF espace de noms est ajouté à votre espace de noms par défaut, il suffit de chercher et remplacer toutes les mentions de la nouvelle
```
MyNamespace.ServiceNamespace
```
avec
```
ServiceNamespace
```
dans l'ensemble de la solution (utiliser vos propres espaces de cours), y compris les auto-généré de Référence.cs fichier.

Vous devez vous connecter pour publier un commentaire.