Discussion :

[WebPac]

Ah, je n'ai pas vérifié pour WPF. J'ai choisi appli windows console (comme tu voulaisfaire une appli de test WCF, ca me semblait le modèle adapté).

En effet, j'ai fait le test avec une application WinForms et on n'a pas besoin de créer le fichier de config car il existe déjà.
J'ai déjà un peu travaillé en WPF et je n'avais pas eu besoin de fichiers de configuration, le futur projet doit être en WPF, c'est pour ça que j'ai utilisé cette techno pour faire les tests.

Je te laisse faire le test avec un nouveau projet en WPF, le fonctionnement par défaut n'est pas celui attendu, pour le nommage par défaut du fichier de config.

[cinemania]

Bon je viens apporter mon grain de sel...

Alors pour information Visual Studio que ce soit 2008 ou 2010... ce comporte différemment non pas en fonction du type d'application souhaité, mais en fonction du langage de base utilisé...

Si tu opte pour un environnement VB... son comportement, est toujours celui par défaut de VB même si ton projet est en C#, en revanche l'inverse n'est pas vrai, car le comportement des projets VB est très différent des projets C#.
Cela n'a rien avoir avec la plateforme Service, Console, Winforms, WPF.

En VB lors d'un application, (pas d'une bibliothèque de classes) il inclu automatiquement Settings.Settings, qui est un système de configuration intégré, qui suppose donc d'avoir un fichier de configuration App.Config...
par conséquent il inclus également un app.config.

Pour C#, le Settings.Settings n'est pas natif, et n'est pas naturel, car C# n'a pas pour vocation d'être un langage pour débutant/assisté (il n'hérite pas non plus d'un passif, contrairement à VB.NET)
Par conséquent, il n'inclue pas non plus de fichier app.config dans les applications... quelque soit la plateforme, par défaut, si l'application n'en a pas besoin... tout dépend des différentes options choisies quand on peut en choisir.

Ensuite pour le nommage.
Quand un fichier app.config existe dans le répertoire, où il va être inséré, le nouveau sera nommé app1.config, et VS utilisera la convention spécifiée par BlueDeep lors de son explication.
Si le fichier n'existe pas (cas par défaut le plus courant sous C#) alors il sera créé en app.config...

C'est toutefois le cas général, mais il est possible que VS ne soit pas correctement paramétré et génère alors des appx.config avec x débutant à 1 même si aucun fichier n'existe... mais ce n'est pas son comportement par défaut, et dans ce cas, c'est au développeur de faire attention, car des fichiers de config tu as le droit d'en avoir 500, si tu veux en utiliser un par type de section... il faut juste que tu les inclue par programmation.

Voilà j'espère avoir éclairé un peu, sur les arcanes du fonctionnement de VS2010.

Autre détail, relatif à WCF... l'utilisation de ending point en wsHttp(s)Binding ou même customBinding ou basicHttpBinding nécessite sous Windows Vista et Windows 7 et à fortiori pour Windows Serveur 2008 d'enregistrer/réserver le port et l'adresse complète (donc http://localhost:8772/machin) va réserver l'adresse machin sur le port 8772 sur l'ip de loopback.
Ceci est due notamment en dehors de l'UAC... au système d'activation WAS et compagnie.
Cette restriction ne s'applique toutefois que dans le cadre d'un hosting dans une application... dans le cas d'un hosting par WAS ou IIS... le problème ne se pose pas.

[WebPac]

C'est toutefois le cas général, mais il est possible que VS ne soit pas correctement paramétré et génère alors des appx.config avec x débutant à 1 même si aucun fichier n'existe... mais ce n'est pas son comportement par défaut, et dans ce cas, c'est au développeur de faire attention, car des fichiers de config tu as le droit d'en avoir 500, si tu veux en utiliser un par type de section... il faut juste que tu les inclue par programmation.

Merci beaucoup pour ces précisions, mais sais-tu comment reparamétrer VS ?
J'ai mis C# comme langage par défaut et dans ma solution, je n'ai fait que des projets C#.

Autre détail, relatif à WCF... l'utilisation de ending point en wsHttp(s)Binding ou même customBinding ou basicHttpBinding nécessite sous Windows Vista et Windows 7 et à fortiori pour Windows Serveur 2008 d'enregistrer/réserver le port et l'adresse complète (donc http://localhost:8772/machin) va réserver l'adresse machin sur le port 8772 sur l'ip de loopback.
Ceci est due notamment en dehors de l'UAC... au système d'activation WAS et compagnie.
Cette restriction ne s'applique toutefois que dans le cadre d'un hosting dans une application... dans le cas d'un hosting par WAS ou IIS... le problème ne se pose pas.

Merci pour ces précisions, je comprends mieux pourquoi basicHttpBinding ne fonctionnait pas et j'ai dû passer en net.tcp pour finaliser les tests.
Qu'entends-tu par WAS ?
Est-ce que pour les services Windows le problème ou pas ? A moins que WAS ne soit les services windows ?
As-tu un tuto ou un article qui explique comment faire cette configuration sur les postes qui le nécessitent ?