2010-12-26 11 views
11

newbie WCF qui ... Sto tentando di auto-ospitare un servizio WCF usando NetTcpBinding. Sulla base del MSDN "how-to" tutorial Ho fatto tutto il legame nel codice, che ho poi cambiato da WsHttpBinding a NetTcpBinding, e ora si presenta così:Puoi fare NetTcpBinding nel codice? Dovresti?

var baseAddress = new Uri("net.tcp://localhost:8000/MyWebService"); 
var selfHost = new ServiceHost(typeof(ConcreteWebService), baseAddress); 
try { 
    var binding = new NetTcpBinding(); 
    binding.Security.Mode = SecurityMode.Message; 
    selfHost.AddServiceEndpoint(typeof(IWebService), binding, "TRWebService"); 
    selfHost.Open(); 
    Console.WriteLine("The service is ready at {0}", baseAddress.AbsoluteUri); 
    Console.WriteLine("Press <ENTER> to terminate service."); 
    Console.WriteLine(); 
    Console.ReadLine(); 

    selfHost.Close(); 
} catch (CommunicationException ce) { 
    Console.WriteLine("An exception occurred: {0}", ce.Message); 
    selfHost.Abort(); 
} 

La cosa è, il tutorial poi dice che dovete correre a svcutil.exe generare un proxy per il client ... ma da quando sono passato a NetTcpBinding, svcutil non funziona più - non riesce a rilevare il mio servizio. Ho cercato su Google il problema e ho scoperto che ogni singolo esempio di NetTcpBinding esegue l'installazione nel file app.config, non nel codice, e tutti aggiungono un endpoint chiamato "Mex", con tipo vincolante di "mexTcpBinding". Non sembra esserci alcun equivalente di questo nel codice.

Quindi, devo modificare il mio progetto per utilizzare app.config e abbandonare l'approccio basato sul codice? Qualcuno può spiegarmi cos'è Mex, perché ne ho bisogno e perché (apparentemente) non può essere chiamato in codice - o se può, come, o perché è scoraggiato? In generale, quando è meglio usare app.config e quando il codice per i servizi WCF?

+0

Stavo seguendo esattamente lo stesso tutorial e volevo i contratti di callback, quindi dopo essere passato a TCP ho avuto lo stesso identico problema. – bryanbcook

risposta

17

Se si utilizza netTcpBinding - e in un ambiente LAN "dietro-the-corporate-firewall", è sicuramente una buona idea farlo - è necessario anche esporre un endpoint MEX (Metadata Exchange) utilizzando il mexTcpBinding in ordine per svcutil per essere in grado di rilevare e trovare quel servizio.

MEX = Metadata Exchange è il meccanismo che WCF utilizza per "pubblicizzare pubblicamente" l'aspetto di un servizio. Se si dispone di un endpoint MEX, le utilità come svcutil possono interrogare e "scoprire" un servizio, ad es. scoprire tutti i metodi di servizio che espone, i parametri che si aspetta di ottenere e così via.

Per aggiungere un endpoint MEX, è possibile utilizzare anche il codice! Qualcosa di simile a questo frammento:

var mexBinding = MetadataExchangeBindings.CreateMexTcpBinding(); 
selfHost.AddServiceEndpoint(typeof(IMetadataExchange), mexBinding, "mex"); 

Senza MEX, è necessario in qualche modo "raccontare" il cliente cercando di consumare il vostro servizio che cosa è il vostro servizio offre in modo che il cliente può fare in modo di chiamare i metodi corretti con il corretto parametri.

+0

+1 Grazie per la spiegazione! Che ne dici di impostare in app.config vs nel codice? –

+0

@Shaul: app.config ti offre una maggiore flessibilità - puoi cambiarlo in basicHttpBinding senza modificare il codice e ricompilare - ma a parte questo, farlo nel codice va bene. Scegli quello che fa al caso tuo! –

+0

Grazie .. ottima risposta. – Prasanth

Problemi correlati