Windows Service hébergé WCF sur HTTPS
J'ai créé et configuré un certificat SSL par ces instructions à partir de MSDN. Je reçois le message d'erreur que cette question listes, mais je ne suis pas sûr de savoir comment la carte a accepté de répondre à cette question à mon Application.fichier de configuration. Le contenu du fichier de config, et le service lui-même fonctionne correctement sur http, c'est juste sur https que le problème se présente.
Mon App.config fichier est actuellement:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="TransportSecurity">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="LookupServiceHost" behaviorConfiguration="serviceBehaviour">
<host>
<baseAddresses>
<add baseAddress="https://localhost:54321/MyService"/>
</baseAddresses>
</host>
<endpoint address="" binding="wsHttpBinding" contract="ILookupService" bindingConfiguration="TransportSecurity" />
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehaviour">
<serviceMetadata httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="False"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>Le ErreurException retournée dans le Journal des Événements Windows:
Service ne peut pas être démarré. Système.ServiceModel.AddressAlreadyInUseException: HTTP n'a pas pu inscrire URL https://+:54321/MyService/. Une autre application a déjà enregistré cette URL avec HTTP.SYS. ---> Système.Net.HttpListenerException: impossible d'écouter sur le préfixe"https://+:54321/MyService/", car il est en conflit avec un enregistrement existant sur la machine.
Quelqu'un pourrait me donner un pointeur à la façon d'activer cette?
- Depuis c'est .NET, vous ne recevez pas un message d'erreur, vous recevez une exception. Merci de poster l'exception complète.
- pédanterie de côté, j'ai fait état que j'ai reçu le même message (OMI) sur le site de la poste. Cela dit, j'ai ajouté les détails spécifiques à ma question.
Vous devez vous connecter pour publier un commentaire.
Je pense que vous vous connectez deux paramètres différents. Netsh peut être utilisé pour ajouter un certificat SSL, mais aussi afin de permettre l'application à l'écoute sur le port, sans exécuter sous le compte admin. L'exception des cibles deuxième paramètre. Je n'ai pas vu avant, mais je suppose que vous avez déjà enregistré ce port pour HTTP permet donc essayez d'utiliser (et enregistrer) HTTPS sur un autre port ou de remplacer l'enregistrement précédent.
Edit:
Ouvrir l'invite de commandes avec élévation de privilèges (en tant Qu'Administrateur).
Vérifiez d'abord si un certificat SSL est affecté à bon port:
De vérifier si HTTP écoute est inscrit sur ce port en appelant le:
Si donc utiliser la commande suivante pour supprimer cette inscription:
Ajouter l'enregistrement à nouveau à l'appui de l'écoute sur HTTPS:
Où utilisateur est le compte utilisé pour exécuter votre service Windows. Si il ia un compte local utiliser uniquement le nom d'utilisateur.
Remarque: Sous le protocole https, il semble que le générique doit être utilisé dans le urlacl. Nous ne pouvons pas écrire
https://localhost:8733/...pour correspondre à Visual Studios défaut urlacl pour http. C'est probablement ce qui est logique, puisque le nom d'hôte requis n'est pas disponible jusqu'à ce que après le décryptage.Différent cause apparente, mais même symptôme, pour les autres, qui trouvera son chemin vers ce post.
J'ai couru une application qui a "toujours travaillé", et après diverses (pas connecté depuis je ne m'attendais pas à des questions) combinaisons de le lancer via le bureau à distance ou en local, connexion et à la déconnexion, et de le remplacer avec un recompilé à l'identique de la version avec un numéro de version différent j'ai eu le même "une Autre application a déjà enregistré cette URL ...bla, bla".
Apparemment (?) l'enregistrement a été spécifique à l'instance qui a couru, et a persisté à travers les arrêts de la demande. (?) En tout cas, le vieux Windows adage, "quand dans le doute reboot" a pris soin d'elle. Sans apporter de modifications à l'application elle-même, il a couru avec aucune plainte. Il se peut que de l'enregistrement, etc., aurait aussi travaillé. C'était sous Windows 10 - je n'ai jamais vu cela avec les versions antérieures de Windows.
Exécuter Visual Studio dans Exécuter en tant qu'administrateur en mode
Fermer l'application Visual studio et ré ouvrir en mode administrateur, C'est assez l'erreur a disparu. HTTP erreurs se produisent lorsque vous exécutez Visual studio non admin mode