J'ai récemment créé un service WCF (dll) et un hôte de service (exe). Je sais que mon service WCF fonctionne correctement car je suis en mesure d'ajouter avec succès le service à WcfTestClient.
Cependant, il semble que je rencontre un problème lorsque j'utilise mon WCF à partir d'un hôte de service (exe). Je peux ajouter une référence à la WCF (dll) à mon hôte de service (exe) et créer les composants nécessaires à l'exe; comme le programme d'installation du service, l'hôte du service et l'app.config, compilez puis installez enfin l'exe à l'aide d'InstallUtil. Mais, lorsque j'ai essayé de démarrer le service dans la console de gestion Microsoft, le service s'arrête immédiatement après son démarrage.
J'ai donc commencé à enquêter sur la cause exacte de ce problème et j'ai trouvé cette erreur à partir du journal des applications dans l'Observateur d'événements.
La description:
Le service ne peut pas être démarré. System.InvalidOperationException: Le service 'Service' n'a aucun point de terminaison d'application (non-infrastructure). Cela peut être dû au fait qu’aucun fichier de configuration n’a été trouvé pour votre application, qu’aucun élément de service correspondant au nom de service n’a été trouvé dans le fichier de configuration, ou qu’aucun point de terminaison n’a été défini dans l’élément de service.
Cette erreur est en fait générée dans le OnStart
; de mon exe, quand j'effectue cet appel ServiceHost.Open()
. J'ai vu de nombreux articles où d'autres personnes se sont heurtées à ce problème, mais la plupart, sinon la totalité, affirment que le nom du service ou le contrat; l'espace de noms et le nom de la classe ne sont pas spécifiés. J'ai vérifié ces deux entrées dans mon fichier de configuration; dans l'exe ainsi que dans la dll, et ils correspondent parfaitement. D'autres personnes au bureau ont vérifié derrière moi pour s'assurer que je ne deviendrais pas aveugle à un moment donné, mais bien sûr, elles sont arrivées à la même conclusion que moi que tout semblait avoir été spécifié correctement. Je suis vraiment perdu quant à ce qui se passe à ce stade. Quelqu'un pourrait-il m'aider avec ce problème?
Une autre chose qui est apparue comme une raison possible que cela puisse se produire est que le fichier app.config n'est jamais lu; du moins pas celui qui, à mon avis, devrait être lu. Cela pourrait-il être le problème? Si tel est le cas, comment puis-je résoudre ce problème. Encore une fois, toute aide serait appréciée.
la source
Réponses:
Je viens d'avoir ce problème et je l'ai résolu en ajoutant l'espace de noms au nom du service, par exemple
est devenu
Je l'ai également vu résolu avec un Web.config au lieu d'un App.config.
la source
Le point de terminaison doit également avoir l'espace de noms:
la source
Une chose à penser est la suivante: votre WCF est-il complètement dissocié du WindowsService (WS)? Un WS est douloureux car vous n'avez pas beaucoup de contrôle ou de visibilité sur eux. J'essaye d'atténuer cela en ayant tous mes éléments non-WS dans leurs propres classes afin qu'ils puissent être testés indépendamment du WS hôte. L'utilisation de cette approche peut vous aider à éliminer tout ce qui se passe avec le runtime WS par rapport à votre service en particulier.
John a probablement raison de dire qu'il s'agit d'un problème de fichier .config. WCF recherchera toujours le contexte d'exécution .config . Donc, si vous hébergez votre WCF dans différents contextes d'exécution (c'est-à-dire, tester avec une application console et déployer avec un WS), vous devez vous assurer que les données de configuration WCF sont déplacées vers le fichier .config approprié. Mais le problème sous-jacent pour moi est que vous ne savez pas quel est le problème parce que le WS goo gêne. Si vous ne l'avez pas encore refactorisé pour pouvoir exécuter votre service dans n'importe quel contexte (c'est-à-dire un test unitaire ou une console), je vous suggère de le faire. Si vous lancez votre service dans un test unitaire, il échouerait probablement de la même manière que vous le voyez avec le WS, ce qui est beaucoup plus facile à déboguer que d'essayer de le faire avec la plomberie WS dégueulasse.
la source
Copiez simplement le fichier App.config du projet de service vers l'application hôte de la console et collez-le ici, puis supprimez-le du projet de service.
la source
J'ai eu une exception plus détaillée lorsque je l'ai ajoutée par programme -
AddServiceEndpoint
:la source
Préparer la configuration pour WCF est difficile, et parfois une définition de type de service passe inaperçue.
J'ai écrit uniquement l'espace de noms dans la balise de service, donc j'ai eu la même erreur.
N'oubliez pas que le numéro de service nécessite un nom de classe de service complet.
Pour les autres gens qui sont comme moi.
la source
TechResponse
) mais le mien n'écrit que l'espace de noms (ServiceNameSpace
).Aujourd'hui, j'ai rencontré le même problème, en publiant ici mon erreur et en la corrigeant afin que cela puisse aider quelqu'un.
Lors de la restructuration du code, j'avais en fait changé les noms de classe de service et d'IService et changé ServiceHost pour qu'il pointe vers ce nouveau nom de classe de service (comme indiqué dans l'extrait de code), mais dans le fichier App.Config de mes applications hôtes, j'utilisais toujours l'ancien nom de la classe de service. . (reportez-vous au champ de nom de la section de configuration dans l'extrait ci-dessous)
Voici l'extrait de code,
et dans le fichier App.config sous la section services, je faisais référence à l'ancien nom de la classe de service, en le changeant en New ServiceClassName, un problème résolu pour moi.
la source
J'ai eu le même problème. Tout fonctionne dans VS2010 mais lorsque je lance le même projet dans VS2008, j'obtiens l'exception mentionnée.
Ce que j'ai fait dans mon projet VS2008 pour le faire fonctionner a été d'ajouter un appel au
AddServiceEndpoint
membre de mon objet ServiceHost.Voici mon extrait de code:
Je n'ai pas modifié le fichier app.config. Mais je suppose que le point de terminaison du service aurait également pu être ajouté dans le fichier .config.
la source
Je viens de résoudre ce problème sur mon service. Voici l'erreur que je recevais:
Voici les deux étapes que j'ai utilisées pour le réparer:
Utilisez le nom de classe complet correct:
Activez un point de terminaison avec mexHttpBinding et, surtout, utilisez le contrat IMetadataExchange:
la source
Cette erreur se produit si le fichier de configuration de l'application d'hébergement de votre service WCF n'a pas la configuration appropriée.
Souvenez-vous de ce commentaire de la configuration:
Si vous avez un service WCF hébergé dans IIS, lors de l'exécution via VS.NET, il lira le fichier app.config du projet de bibliothèque de services, mais lira le fichier web.config de l'hôte une fois déployé. Si web.config n'a pas la même
<system.serviceModel>
configuration, vous recevrez cette erreur. Assurez-vous de copier la configuration depuis app.config une fois qu'elle a été perfectionnée.la source
Je viens de rencontrer ce problème et j'ai vérifié toutes les réponses ci-dessus pour m'assurer de ne rien manquer d'évident. Eh bien, j'ai eu un problème semi-évident. Ma casse de mon nom de classe dans le code et le nom de classe que j'ai utilisé dans le fichier de configuration ne correspondaient pas.
Par exemple: si le nom de la classe est CalculatorService et que le fichier de configuration fait référence à Calculatorservice ... vous obtiendrez cette erreur.
la source
J'ai exécuté Visual Studio en mode Administrateur et cela a fonctionné pour moi :) Aussi, assurez-vous que le fichier app.config que vous utilisez pour écrire la configuration WCF doit se trouver dans le projet où la classe "ServiceHost" est utilisée, et non dans le service WCF réel projet.
la source
Mon problème était lorsque j'ai renommé ma classe Service1 par défaut pour le fichier .svc en un nom plus significatif, ce qui a amené web.config behaviorConfiguration et endpoint à correspondre à l'ancienne convention de dénomination. Essayez de réparer votre fichier web.config.
la source
Une chose cruciale à retenir pour ceux qui travaillent avec une application console pour héberger le service WCF est que le fichier Web.config dans le projet WCF est complètement ignoré. Si votre
system.serviceModel
configuration est là, vous devez déplacer cette section de config vers le App.config de votre projet Console.Ceci s'ajoute aux réponses concernant la garantie que l'espace de noms est spécifié aux bons endroits.
la source
Comme autre indice, cela a en effet résolu ce problème dans mon cas.
Je migre certains services WCF d'une application console (qui configure en code quelques services WCF) vers un Azure WebRole pour les publier dans Azure. Chaque fois que j'ajoute un nouveau service VS modifie mon web.config et ajoute cette ligne:
Eh bien, avec tous les conseils et réponses ci-dessus, je ne pouvais pas le faire fonctionner tant que je n'aurais pas supprimé tous les attributs de l'élément serviceHostingEnvironment. Comme vous pouvez le voir, je ne suis pas une rockstar WCF mais je l'ai fait fonctionner avec le premier service simplement en le configurant comme:
mais quand j'ai ajouté le deuxième service, il a cessé de fonctionner et j'ai réalisé que ces attributs étaient à nouveau là.
J'espère que cela vous fera gagner du temps.
la source
J'ai eu cette erreur dans un service Windows lorsque ma bibliothèque de services WCF que j'ai créée n'était pas connectée pour l'hébergement, mais était connectée pour la connexion. Il me manquait un point final. (Je voulais à la fois une connexion et un hébergement dans mon service Windows pour pouvoir servir le service WCF à d'autres connexions, ainsi que pour que le processus principal de mon service Windows l'utilise également pour effectuer diverses tâches selon un minuteur / calendrier.)
Le correctif était que j'avais choisi à droite mon fichier App.config et choisi Modifier la configuration WCF. Ensuite, j'ai suivi les étapes de création d'un service afin de pouvoir me connecter à mon service WCF. Maintenant, j'avais deux points de terminaison dans mon App.config, pas un seul. Un point de terminaison était pour la connexion à la bibliothèque de services WCF, et un autre était pour son hébergement.
la source