WCF REST Starter Kit - Une propriété « UriTemplateMatchResults » le nom existe déjà

Question

Je viens de commencer avec le WCF REST Starter Kit.

J'ai créé un service simple qui renvoie un tableau d'un objet.

Utilisation du navigateur, tout fonctionne bien, mais quand j'utilise un client WCF, je reçois un ArgumentException.

Je ne suis pas en utilisant IIS et le code est ici:

Le marché:

[ServiceContract]
    public interface IGiftService {

        [WebGet(UriTemplate="gifts")]
        [OperationContract]
        List<Gift> GetGifts();

    }

    public class GiftService : IGiftService {

        public List<Gift> GetGifts() {
            return new List<Gift>() {
                new Gift() { Name = "1", Price = 1.0 },
                new Gift() { Name = "2", Price = 1.0 },
                new Gift() { Name = "3", Price = 1.0 }
            };
        }

    }

    [DataContract]
    public class Gift {

        [DataMember]
        public string Name { get; set; }
        [DataMember]        
        public double Price { get; set; }
    }

Pour démarrer le service:

WebServiceHost2 host = new WebServiceHost2(
                typeof(GiftService), 
                true, 
                new Uri("http://localhost:8099/tserverservice"));
            host.Open();

            Console.WriteLine("Running");
            Console.ReadLine();
            host.Close();

Pour démarrer le client:

WebChannelFactory<IGiftService> factory = new WebChannelFactory<IGiftService>(
                new Uri("http://localhost:8099/tserverservice"));

            IGiftService service = factory.CreateChannel();
            List<Gift> list = service.GetGifts();

            Console.WriteLine("-> " + list.Count);
            foreach (var item in list) {
                Console.WriteLine("-> " + item.Name);
            }

Le serveur et le client sont dans la même solution et j'utilise la même interface à la fois (pour décrire le contrat de service).

L'exception dit: « Une propriété avec le nom « UriTemplateMatchResults » existe déjà. » et qui est la trace de la pile:

Classe de tir à l'exception -> Microsoft.ServiceModel.Web.WrappedOperationSelector

Stack trace:

  at System.ServiceModel.Channels.MessageProperties.UpdateProperty(String name, Object value, Boolean mustNotExist)
   at System.ServiceModel.Channels.MessageProperties.Add(String name, Object property)
   at System.ServiceModel.Dispatcher.WebHttpDispatchOperationSelector.SelectOperation(Message& message, Boolean& uriMatched)
   at System.ServiceModel.Dispatcher.WebHttpDispatchOperationSelector.SelectOperation(Message& message)
   at Microsoft.ServiceModel.Web.WrappedOperationSelector.SelectOperation(Message& message) in C:\Program Files\WCF REST Starter Kit\Microsoft.ServiceModel.Web\WrappedOperationSelector.cs:line 42
   at Microsoft.VisualStudio.Diagnostics.ServiceModelSink.ServiceMethodResolver.GetOperation()
   at Microsoft.VisualStudio.Diagnostics.ServiceModelSink.ServiceMethodResolver..ctor(ContractDescription contract, DispatchRuntime runtime, Message request, InstanceContext instanceContext)

Qu'est-ce que je fais mal?

Mise à jour: J'ai désactivé la page d'aide et le service fonctionne maintenant. Est-ce un bug?

host.EnableAutomaticHelpPage = false;

Merci!

André Carlucci

Answer 1

eu le même problème, désactivé la page d'aide et le fixe. L'exception était levée si certains urls REST ont été appelés dans une séquence très rapidement. Il était très bien lors de l'attente entre les appels.

protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            return new WebServiceHost2(serviceType, true, baseAddresses) {EnableAutomaticHelpPage = false};
        }

Answer 2

J'ai eu le même probem, mais je voulais voir la page d'aide si invalidante n'était pas une solution pour moi. J'ai découvert que URITemplating dans la WCF REST Toolkit est à l'origine les problèmes, quand il voit qu'il a déjà ce modèle dans les tableaux de modèle. Fondamentalement, vous aurez seulement besoin d'un modèle lorsque l'URL de votre méthode est différente selon les données demandées, après tout, c'est ce que les modèles sont pour. J'ai eu les mêmes URITemplates pour mes opérations POST, de sorte que les URL ne diffèrent pas entre des requêtes distinctes qui provoque cette erreur. alors j'ai découvert que je ne fait pas besoin de tout templating, au moins pour les opérations POST, en outre faire youvannot une requête POST si l'URL si votre méthode nécessite un objet complexe pour être passé en paramètre. Donc, je l'ai enlevé le paramètre nommé UriTemplate de l'attribut WebInvoke dans l'interface de service, je pense que le problème résolu. Bien sûr, si vous faites GET requêtes au serveur et compter sur URITemplating vous aurez encore soit mis en place avec ou laisser loin la page d'aide.

Answer 3

Dans mon cas, le problème ne se produisait que lorsque vous accédez au point final en utilisant un canal WCF avec l'intégration du débogueur Visual Studio activé.

Je travaille autour de la question en ajoutant un code pour supprimer le comportement de la VS ChannelFactory:

var vsBehaviour = channelFactory.Endpoint.EndpointBehaviors
    .FirstOrDefault(i =>
        i.GetType().Namespace == "Microsoft.VisualStudio.Diagnostics.ServiceModelSink");
if (vsBehaviour != null)
{
    channelFactory.Endpoint.Behaviors.Remove(vsBehaviour);
}

Apparemment, il y a d'autres façons de désactiver l'intégration WCF du débogueur Visual Studio, mais ils semblent être l'ensemble du système, alors que cette solution est locale.