Une des premières choses est qu’on voit beaucoup de choses sur le net et dans les livres avec du localhost partout. Jamais de conditions réelles…

Comment fait-on alors quand on a une ip publique ? ou un nom de domaine ?

1) De ma maigre expérience, ca devient tout de suite plus facile avec un nom de domaine… Dans ce cas, il ne faut pas oublier de le renseigner dans les bindings du site :

2) Et si on doit faire de l’https ?

Ajoutons un binding https me direz vous ?

Oui, mais ce n’est pas suffisant.

On ne peut pas renseigner le nom du domaine … Dans ce cas, il va falloir avoir recourt à une formule magique en ligne de commande :

   1: C:\Windows\System32\inetsrv>appcmd.exe set site /site.name:"MonSite" /+bindings.[protocol='https',bindingInformation='*:443:mon.domaine.com']

on devra ensuite ouvrir le fichier C:\Windows\System32\inetsrv\config\applicationHost.config et supprimer la ligne :

   1: <binding protocol="https" bindingInformation="*:443:" />

3) Si vous travaillez avec des certificats, n’oubliez pas d’accorder les droits adéquats à ceux-ci dans la console MMC : (manage private keys)

Il faut qu’ils correspondent au process défini dans la configuration avancée de l’application pool, disons NetworkService :

4) Si le wsdl génère le nom de la machine à la place du nom du domaine, normalement le binding avec nom de domaine défini au 1) suffit.

Si ca ne suffit pas, une solution est d’utiliser l’attribut factory du fichier svc et d’instancier un custom service host avec quelque chose du genre :

   1: <%@ ServiceHost Language="C#" Debug="true" Service="Service..." Factory="CustomHostFactory" %>

   1: public class CustomHostFactory : System.ServiceModel.Activation.ServiceHostFactory

   2: {

   3:     protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)

   4:     {

   5:         CustomHost customServiceHost = new CustomHost(serviceType, baseAddresses);

   6:         return customServiceHost;

   7:     }

   8: }

   1: public class CustomHost : ServiceHost

   2: {

   3:     public CustomHost(Type serviceType, params Uri[] baseAddresses)

   4:  

   5:         : base(serviceType, GetBaseAddresses())

   6:     { }

   7:  

   8:  

   9:     private static Uri[] GetBaseAddresses()

  10:     {

  11:         List<Uri> addresses = new List<Uri>();

  12:         AddBaseAddress(addresses);

  13:         return addresses.ToArray();

  14:     }

  15:  

  16:     private static void AddBaseAddress(List<Uri> addresses)

  17:     {

  18:  

  19:         string address = "http://mon.domaine.com/MonService.svc";

  20:         addresses.Add(new Uri(address));

  21:     }

  22: }

Par contre, tout ceci ne fonctionnera correctement qu’avec le port 80 … En effet, avec un autre port, le wsdl généré contiendra le numéro de port. S’il est ouvert depuis l’extérieur, tout va bien …

5) Sinon, on se retrouve dans une configuration classique de déploiement.

Un client accède à un nom de domaine : http://mon.domaine.com, une translation NAT est faite pour aller sur une machine interne http://MaMachine, et redirigée vers un port précis : http://MaMachine:12345.

Un Web service est hébergé sur cette machine.

Dans ce cas, le wsdl généré contient des adresses avec le numéro de port, qui est bloqué. Qu’à cela ne tienne, on va définir explicitement que l’adresse du endpoint (dans le web config ou dans la factory) est l’adresse sans le numéro de port. Et là, une magnifique erreur, du genre :

No protocol binding matches the given address ‘http://mon.domaine.com:12345/MonService.svc’. Protocol bindings are configured at the Site level in IIS or WAS configuration.

Pour résoudre ce bug, j’ai nommé le correctif : http://support.microsoft.com/kb/977420. Notez qu’il vous faudra installer le framework 3.5 SP1. (attention, différents correctifs existent en fonction des versions de son windows).

Et voilà pour ces quelques infos. En espérant que ca puisse vous aider.

Loin de moi l’idée de vous faire croire que je suis un expert IIS, au contraire. Je tiens à préciser que d’une manière générale, les informations sont plutôt difficile à trouver. Mais je tiens quand même à reconnaitre que les progrès entre IIS6 et IIS7 sont indéniables, rien que dans la gestion des utilisateurs …

Gageons que la prochaine version d’IIS sera encore plus complète.

The message with To ‘http://localhost/monservice.svc/MaMethode’ cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver’s EndpointAddresses agree.

Après avoir cherché sur le net, j’ai trouvé cette solution :

Il suffit de rajouter un attribut ServiceBehavior sur la classe du web service en précisant le mode de filtrage :

   1: [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

   2: public class MonService : IMonService

   3: {

   4:     ...

   5: }

HTH