[WCF] Voorkomen automatisch genereren (dubbele) classes

[BM]

De volgende situatie is ontstaan bij een tweetal projecten hier op kantoor. Er is een tweetal xsd files gedefinieerd, laten we deze voor het gemak InputType.xsd en ResponseType.xsd noemen.
Vervolgens zijn er twee projecten ontwikkeld, 1 wcf service (ServiceX) die InputType berichten ontvangt, en daar ResponseType berichten op terug geeft. Een andere applicatie (ClientX) genereerd juist InputType berichten, stuurt die naar ServiceX, en verwacht een ResponseType terug. So far, so good.

Waar het probleem nu in zit, is dat zowel ServiceX, als als ClientX hebben zelf mbv xsd.exe hun classes gegenereerd, en gebruikt in hun eigen applicatie. Op het moment dat ServiceX zijn service nu exposed via een WSDL, en ClientX hier een reference naar aanlegt ontstaat het probleem.
Binnen ClientX bestonden InputType en ResponseType al, namelijk als ClientX.DataTypes.InputType/ResponseType. Bij het aanmaken van een reference worden dezelfde 2 types nogmaals aangemaakt, maar nu ClientX.ServiceReference.InputType/ResponseType.
Direct gevolg hiervan is is dat je 2 verschillende varianten van dezelfde class in je applicatie hebt, iets wat imho niet wenselijk is, temeer daar je oorspronkelijk objecten niet te versturen zijn naar de webservice (want, andere namespace, dus ander type, logisch).

De vraag is dus eigenlijk hoe ik bij het aanmaken van en WCF service reference het voor elkaar krijg dat ie de reeds bestaande classes oppakt, en die gebruikt, ipv nieuwe classes te generen.
Met svcutil.exe /reference:Assembly.dll http://localhost/service.wsdl zou ik een eind moeten kunnen komen, maar eis daarvoor is is dat er DataContract gegenereerd zijn van de xsds, en laten die daar nu net niet geschikt voor zijn ( ) Ik ben dus min of meer gebonden aan de classes zoals deze gegenereerd worden door xsd.exe.

Als iemand me hier een schop in de goeie richting zou kunnen geven, gaarne.
De classes gebruiken die de service reference genereerd was eigenlijk niet helemaal de bedoeling

[Amras]

Je zou het genereren van een proxy helemaal achterwege kunnen laten en zelf een implementatie van ClientBase<T> kunnen schrijven. Als je dan je message types al handmatig hebt geschreven en de DataContract/DataMember attributen hebt gezet, dan krijg je zoiets:

C#:

public class MyServiceClient : System.ServiceModel.ClientBase<IMyService>, IMyService
{
    /* constructors */

    public ResponseType MyOperation(InputType input)
    {
        return base.Channel.MyOperation(input)
    }
}

(Deze code is eenvoudig te verkrijgen door eenmalig de proxy te genereren en dan de code van het client object te kopieren)

Nadeel van deze aanpak is dat je zelf verantwoordelijk bent voor het aanpassen van je message types als het contract wijzigt, wat normaal eenvoudig te doen was door je service reference te updaten.

[BM]

Mja, het probleem is dus een beetje dat de XSDs nog wel eens willen wijzigen, en ik er niet automatisch DataContracts van kan genereren. Wellicht dat het handmatig wel zou kunnen, maar ik heb weinig behoefte om dat iedere keer te moeten gaan doen