Microsoft is doing a lot of great things recently but their support forum is not one of them. In fact half of the time if you are asking something not obvious you get completely unrelated answers from people that are looking for MVP points or whatever, so they copy & paste the first code snippet that looks remotely related to the question.

Other times you have the impression that moderators are paid in function of the number of reply they mark as “answer”, so they scan through threads without even bothering to read them.

Fortunately there are smart people too, and they are often helpful.

Microsoft, if you are listening, please address this issue as right now in my opinion it’s the real weak link in the .NET development ecosystem.

Rant over.

Olá a todos,

                Nesse post demonstraremos como uma consumir um serviço WCF a partir de uma aplicação desenvolvida em Silverlight no contexto em que estão hospedados em domínios diferentes. A explicação de como consumir um serviço WCF em Silverlight já foi abordada em outro post, porém nele nos limitamos hospedando o serviço e o consumidor no mesmo local de origem. Para montar a estrutura necessária para esse exemplo utilizarei duas roles do Windows Azure, portanto também demonstraremos como hospedar aplicações WCF e Silverlight no Windows Azure com o CTP de novembro, que trouxe algumas mudanças.

                Antes de iniciarmos nosso exemplo precisamos entender o motivo e como funciona a restrição no consumo de aplicações em outros domínios. Na verdade a restrição não é apenas para outros domínios, mas sim para outros “locais de origem”. Um local de origem nesse contexto é o conjunto de domínio, protocolo de comunicação e porta acessada. Essa regra existe nos browsers como medida de segurança para códigos JavaScript não acessarem recursos de outros locais de origem que possam ser maliciosos. Portanto ela é aplicada para aplicações desenvolvidas em Silverlight, Flash ou qualquer outra ferramenta que faça uso de JavaScript para acessar recursos na web. Logo quando temos uma aplicação desenvolvida em Silverlight e desejarmos acessar um serviço WCF ou outro recurso que esteja exposto em outro domínio, porta ou que utilize outro protocolo de comunicação nos depararemos com essa medida de segurança.

                Para lidarmos com essa restrição temos duas alternativas. A primeira é colocarmos um serviço WCF ou outro recurso no mesmo local de origem da aplicação Silverlight que consuma o serviço original que está no outro local de origem. A segunda alternativa é possibilitarmos o consumo desse recurso através da inclusão dos arquivos crosssdomain.xml e clientaccesspoliciy.xml. Porém esses arquivos devem ser adicionados no servidor que expõem o serviço, logo deveremos ter acesso a esse servidor ou ao publicador do serviço para adicioná-lo, caso contrário nos restará somente a primeira opção. O arquivos clientaccesspolicy.xml é exclusivo para aplicações escritas em Silverlight, já o arquivo crossdomain.xml pode ser utilizado para permitir ou restringir o acesso a qualquer aplicação que tente acessar o recurso através de JavaScript.

                Vamos agora iniciar o nosso exemplo que será um projeto do tipo Windows Azure Cloud Service e terá uma ASP .Net Web Role para hospedar a aplicação escrita em Silverlight e uma WCF Service Web Role para hospedar o serviço WCF. A aplicação será a mesma utilizada na demonstração de consumo de serviço WCF por aplicações em Silverlight no mesmo local de origem.

Criando o projeto principal

Adicionando as web roles na solucao

Estrutua inicial da solucao

Após criada a solução com os projetos devemos adicionar também o projeto da aplicação Silverlight. Durante esse processo devemos indicar para o Visual Studio que desejamos hospedar esse projeto na ASP .Net Web Role:

Adicionando o projeto da aplicacao Silverlight

Hospedando a aplicacao Silverlight na Web Role

Estrutura da solucao com o projeto silverlight

Em seguida vamos modificar a página principal do projeto Web para expor a aplicação Silverlight. Vamos utilizar o mesmo código já desenvolvido em outro post.

Codigo da pagina que hospeda a aplicacao Silverlight

XAML da aplicacao Silverlight

Partiremos agora para a construção do Serviço WCF que será hospedado na outra Web Role e que será disponibilizado em outra porta, portanto estará em outro local de origem. Nesse serviço teremos o mesmo método do post anterior sobre consumo de serviços WCF por aplicações Silverlight. Para essa tarefa vamos remover o serviço inicial disponibilizado pelo template e adicionar outro item do tipo Silverlight-enabled WCF Service: 

Adicionando o servico na Web Role

Codigo do servico WCF

Para finalizar a estrutura devemos adicionar a referência do serviço WCF na aplicação Silverlight. Para isso clique com o botão da direita sobre o projeto Silverlight e selecione a opção Add Service Reference e em seguida clique no botão Discover:

Adicionando a referencia do servico na aplicacao Silverlight

Agora adicionaremos o código para consumir o serviço a partir da aplicação Silverlight e em seguida tentaremos consumir o serviço. 

Codigo da aplicacao Silverlight

Porém como ainda não adicionamos os arquivos que permitem o consumo do serviço por código JavaScript de outros locais de origem nos deparamos com a seguinte exceção: System.ServiceModel.CommunicationException was unhandled by user code  Message=”An error occurred while trying to make a request to URI ‘http://localhost:8080/TesteSL.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.”

Mensagem de erro ao consumir recurso em outro local de origem

 A origem dessa exceção não o nosso código Silverlight ou WCF, mas sim a segurança do browser que não permite que um código JavaScript consuma recursos de outros locais de origem. Para permitir o consumo do serviço por nossa aplicação deveremos colocar os arquivos crossdomain.xml e clientaccesspolicy.xml no diretório raiz do site/aplicação que hospeda o serviço, no nosso caso a web role.

Arquivos clientaccesspolicy.xml e crossdomain.xml adicionados no projeto

Conteudo do arquivo clientaccesspolicy.xml

Note que no arquivo clientaccesspolicy.xml podemos definir quais URIs poderão acessar o recurso, no nosso caso o serviço WCF, além de configurar também quais os diretórios estarão acessíveis a essas URIs. Já no arquivo crossdomain.xml configuramos somente quais domínios terão acesso aos nossos recursos. 

Conteudo do arquivos crossdomain.xml

Adicionados os arquivos no projeto vamos testar novamente a solução, que funcionará corretamente.

Aplicacao funcionando corretamente

Com isso temos nossa aplicação Silverlight consumindo um serviço WCF em outro local de origem, que poderia ser em outro domínio também, desde que no servidor que hospeda o serviço tenhamos os arquivos para permitir o seu consumo. Como sempre deixei no meu Sky Drive os fontes utilizados para escrever o post, nesse caso o arquivo está com o nome LocaisOrigem.zip

Abraço a todos e até o próximo post.

You are inheriting from 2 contracts to create a contract. Both contracts that you are inheriting from have a method with same name and signature. You don’t have much control over these interfaces as they are tightly coupled with your subsystem. You create an implementation class with help of explicit interface implementations and dispatch calls to subsystem. Now you have a challenge of invoking the right implementation from client side? Will WCF work even when we can’t have any config files? Fortunately YES, WCF supports such scenarios. Below is a code sample on same, hope it helps you when you have a sharp knife against your throat :

//Contracts
[ServiceContract]
public interface IIPV4Location
{
[OperationContract]
string GetLocationId();
}

[ServiceContract]
public interface ILocation : IIPV4Location, IIPV6Location
{ }

//Server Side
class LocationImpl : ILocation
{
string IIPV4Location.GetLocationId()
{
return "Ipv4";
}

host.Open();
Console.WriteLine("Running...");
Console.ReadLine();
host.Close();
}
}
//Client Side
class Program
{
static void Main(string[] args)
{
ILocation location = new ChannelFactory(new BasicHttpBinding(),
"http://localhost:9999/Location")
.CreateChannel();

var ipv6Location = ((IIPV6Location)location).GetLocationId();
Console.WriteLine(ipv6Location);
}
}

Se você não conhece Silverlight, aproveite esta vídeo aula, onde você irá aprender os princípios básicos de como iniciar uma aplicação em Silverlight 4 , utilizando a ferramenta Microsoft Blend 4 e Visual Studio 2010 Beta 2. Assim, conhecer a interação entre as duas ferramentas. Você poderá aplicar os mesmos conceitos utilizando o Silverlight 3 com o Blend 3 e Visual Studio 2008.

Você ainda não conhece Silverlight ? O que está esperando para aprender também?

veja a vídeo aula:

http://www.dowhile.com.br/videos/silverlight/115-video-aula-aplicacao-em-silverlight.html

abraços,

WCF es una tecnología que no debe tomarse a la ligera, por una buena razón: es demasiado útil. Permite desarrollar aplicaciones distribuidas de forma relativamente fácil. En este post crearemos una aplicación WCF muy básica.

Como cualquier aplicación basada en servicios, la finalidad de un servicio WCF es permitir la ejecución de sus métodos (posiblemente devolviendo resultados) a aplicaciones cliente, las cuales pueden estar corriendo en otras máquinas. La estructura básica de un servicio es simple y consta de dos partes: un contrato de servicio y el servicio propiamente dicho.

Contratos de servicio y de datos

El contrato de servicio es en realidad un interfaz con algunos métodos que habrá que implementar más tarde en la clase del servicio. Este interfaz tiene la particularidad de estar decorado con atributos.

using System;
using System.ServiceModel;

namespace Acme.Contracts
{
 [ServiceContract]
 public interface ITestService
 {
 [OperationContract]
 UserData getUserData(int userId);
 }
}

El atributo ServiceContract indica que el interfaz es un contrato de servicio WCF, mientras que OperationContract indica que la operación está expuesta como parte del servicio. Estos atributos están definidos en el ensamblado System.ServiceModel, de modo que es necesario tenerlo referenciado.

Adicionalmente el servicio puede requerir contratos de datos. Se trata de tipos definidos (clases, tipos enumerados, estructuras…) para el intercambio de datos con los clientes. También están decorados con atributos especiales:

using System;
using System.Runtime.Serialization;

namespace Acme.Contracts
{
 [DataContract]
 public class UserData
 {
 [DataMember]
 public int userId { get; set; }

 [DataMember]
 public string userName { get; set; }
 }
}

El atributo DataContract indica que la clase es un contrato de datos WCF y  DataMember que la propiedad a la que se aplica es un miembro de datos expuesto. Ambos están definidos en el ensamblado System.Runtime.Serialization, que debe estar referenciado.

Lo más práctico es poner los contratos en un ensamblado aparte, a fin de facilitar el posterior mantenimiento. Para ello hay dos opciones:

• Crear un nuevo proyecto de librería de servicios WCF (y posteriormente eliminar el fichero de configuración y de servicio creados por el asistente).
• Crear un nuevo proyecto de librería de clases y agregar manualmente referencias a los ensamblados  System.ServiceModel y (de ser necesario) System.Runtime.Serialization.

Implementar el servicio

El servicio WCF es una clase que implementa el contrato de servicio correspondiente. No se ejecuta por sí solo, sino que debe ser hospedado por otra aplicación cuyo tipo dependerá de los requerimientos de nuestra solución. Por ejemplo, un servicio de Windows es lo más apropiado para una ejecución desatendida del servicio.

using System;
using Acme.Contracts;

namespace Acme.Services
{
 public class TestService : ITestService
 {
 public UserData getUserData(int userId)
 {
 if (userId == 1)
 {
 UserData data = new UserData() { userId = 1, userName = "David Liñán" };
 return data;
 }
 else
 return null;
 }
 }
}

El servicio debería estar en un ensamblado aparte si se pretende que pueda ser hospedado por distintos tipos de aplicación. De lo contrario podría incluirse en el propio proyecto de la aplicación contenedora como una clase más.

Hospedar el servicio

La aplicación contenedora puede ser casi de cualquier tipo: una aplicación Winforms, un servicio de Windows, una aplicación de consola, incluso podría ser IIS. En cualquier caso, es necesaria una referencia a System.ServiceModel y otra al ensamblado del servicio (si es que reside en otro distinto).

La forma más fácil de hospedar el servicio es usando la clase ServiceHost, definida en System.ServiceModel. Los métodos a usar invariablemente son Open() y Close(), para arrancar y detener el servicio.

using System;
using System.ServiceModel;

namespace Acme.Services
{
 class Program
 {
 static void Main(string[] args)
 {
 try
 {
 ServiceHost sHost = new ServiceHost(typeof(TestService));
 sHost.Open();
 Console.WriteLine("Cualquier tecla para finalizar...");
 Console.Read();
 sHost.Close();
 }
 catch (Exception ex)
 {
 Console.WriteLine("Excepción inesperada: " + ex.Message);
 }
 }
 }
}

Además de esta forma se toman automáticamente los datos de configuración del servicio, que deben estar en en fichero de configuración de la aplicación contenedora. En nuestro ejemplo es el siguiente:

<configuration>
 <system.serviceModel>
 <services>
 <service name="Acme.Services.TestService">
 <endpoint name="testEndpoint"
 address="net.tcp://localhost:7000/TestService"
 binding="netTcpBinding"
 contract="Acme.Contracts.ITestService" />
 </service>
 </services>
 </system.serviceModel>
</configuration>

En este fichero cada servicio viene identificado por su nombre completo, incluyendo su espacio de nombres (Acme.Services.TestService). Adicionalmente hacen falta tres datos: una dirección (net.tcp://localhost:7000/TestService), el tipo de canal a usar (en nuestro caso es TCP, indicado por netTcpBinding) y el nombre completo del contrato.

Implementar el cliente

Una aplicación cliente necesita conocer tres cosas de un servicio: su contrato, su dirección y el tipo de canal a usar. La primera la obtenemos añadiendo una referencia al ensamblado del contrato. Las otras dos las podemos definir en el fichero de configuración de la aplicación cliente y sus valores deben coincidir con los definidos en el fichero de configuración del servicio (para ser exactos, de la aplicación que lo hospeda). El cliente debe tener además una referencia a System.ServiceModel.

<configuration>
 <system.serviceModel>
 <client>
 <endpoint name="testEndpoint"
 address="net.tcp://localhost:7000/Testservice"
 binding="netTcpBinding"
 contract="Acme.Contracts.ITestService" />
 </client>
 </system.serviceModel>
</configuration>

La clase ChannelFactory (en System.ServiceModel) nos permite crear un proxy para invocar a los métodos del servicio desde el cliente. El nombre del endPoint a usar viene definido en el fichero de configuración del cliente.

using System;
using System.ServiceModel;
using Acme.Contracts;

namespace Acme.Clients
{
 class Program
 {
 static void Main(string[] args)
 {
 try
 {
 // Inicia la comunicación
 ChannelFactory<ITestService> factory = new ChannelFactory<ITestService>("testEndpoint");
 factory.Open();
 ITestService proxy = factory.CreateChannel();
 // Invocando métodos del servicio
 bool fin = false;
 while (!fin) {
 Console.Write("Introduzca un id de usuario o <Intro> para terminar:");
 string sUserId = Console.ReadLine();
 int userId;
 if (!Int32.TryParse(sUserId, out userId) )
 {
 fin=true;
 }
 else
 {
 UserData userData = proxy.getUserData(userId);
 if (userData == null)
 Console.WriteLine("Usuario no encontrado");
 else
 Console.WriteLine("Usuario: " + userData.userName);
 }
 }
 // Finaliza la comunicación
 factory.Close();
 }
 catch (Exception ex)
 {
 Console.WriteLine("Excepción no esperada: " + ex.Message);
 }
 }
 }
}

Aplicación de ejemplo

Consiste en una solución con tres proyectos:

• una librería de clases que contiene los contrato de servicio y de datos
• una aplicación de consola que hospeda al servicio, implementado como parte de ella
• y una aplicación de consola para invocar al servicio

Aviso: durante la ejecución es posible que aparezca el siguiente error:

“The target assembly contains no service types. You may need to adjust the Code Access Security policy of this assembly”

Esto puede ser debido a que hayamos creado un proyecto separado para el contrato de servicio. Si lo hemos hecho mediante la plantilla de proyecto WCF Library tenemos que borrar de ese proyecto el fichero de configuración (de todas formas no tendría sentido dejarlo ahí).

After a few busy weeks (Mondays and Thursdays) our workshop has reached the end. I hope that guys who had attended this workshop had some joy and got some knowledge/experience with these technologies

I’d be glad to repeat it, but there are some other interesting areas to cover, so keep reading my blog to find out when’s the next workshop.

Best wishes!

If you’ve installed the SharePoint 2010 public beta, you’ve likely run into the WCF bug. This following errors occur when provisioning Service Applications or when accessing pages that make service calls.

System.Configuration.ConfigurationErrorsException: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\<Service Area>\client.config line <Line Number>).

The service application proxy “User Profile Service Application” could not be provisioned because of the following error: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Profile\client.config line 56).

You may see this error in the ULS logs after installing SharePoint 2010, or displayed on the page as an error message when provisioning service applications or accessing SharePoint pages that make WCF service calls.

How To Fix It

This is a known WCF issue when installing SharePoint 2010 on Windows 7, Windows Server 2008, or Windows Server 2008 R2.  It’s, lovingly called the WCF Sharepoint Shared Services Roll-up issue. To fix it, install a WCF OS patch:

KB971831: WCF fix for Windows Server 2008 and Vista only
http://support.microsoft.com/kb/971831

KB976462: WCF fix for Windows 2008 R2 and Windows 7
http://support.microsoft.com/kb/976462 
Note:  This link is not activated yet, but you can download the WCF fix at http://go.microsoft.com/fwlink/?LinkID=166231

If you have already installed Microsoft SharePoint Server 2010 on a server running Microsoft Windows Server 2008 R2 or Microsoft Windows 7, Microsoft SharePoint Server 2010 does not need to be reinstalled. You can install the WCF fix afterward. However, Service Applications that have been provisioned without the update installed may need to be removed and re-provisioned once the update has been successfully applied.

References

SharePoint Team Blog: Installation Notice for the SharePoint Server Public Beta on Microsoft Windows Server 2008 R2 and Microsoft Windows 7

Jie Lie’s GeekWorld: SharePoint 2010 Pre-Requisites Download Links

By default when you add a WCF Service reference in WPF, it does not give async functions. If your application needs async features, while adding a reference to the service, lookout for a ‘Advanced’ button on Add service reference window at bottom right corner. On clicking on that button, a new window appears. There is a checkbox called ‘Generate Asynchronous Operations’. Hit Ok and you are done!

Simple isn’t it

WCF es una tecnología que no se debe tomar a la ligera, por una buena razón: es demasiado útil. Permite desarrollar aplicaciones distribuidas de forma relativamente fácil, incluso con otras plataformas distintas de .Net. En este post crearemos una aplicación WCF sencilla.

La utilidad de un servicio WCF es permitir la ejecución de sus métodos, posiblemente devolviendo resultados, a aplicaciones cliente que pueden estar corriendo en otras máquinas. La estructura básica de un servicio es simple y consta de dos partes: un contrato de servicio y el servicio propiamente dicho.

Contratos de servicio y de datos

El contrato de servicio es realmente un interfaz con una serie de métodos. Estos métodos son los que habrá que implementar más tarde, en la clase del servicio. El atributo ServiceContract determina que el interfaz es un contrato de servicio WCF, mientras que OperationContract determina que la operación está expuesta como parte de ese contrato. Estos atributos están definidos en el ensamblado System.ServiceModel, de modo que es necesario tenerlo referenciado.

using System;
using System.ServiceModel;

namespace Acme.Contracts
{
    [ServiceContract]
    public interface ITestService
    {
        [OperationContract]
        UserData getUserData(int userId);
    }
}

Adicionalmente el servicio puede incluir contratos de datos: se trata de tipos definidos para el intercambio de datos con los clientes (clases, tipos enumerados, estructuras…). De manera similar, el atributo DataContract determina que la clase es un contrato de datos WCF y DataMember que la propiedad a la que se aplica es un miembro de datos expuesto. Ambos están definidos en el ensamblado System.Runtime.Serialization, que habrá que tener referenciado.

using System;
using System.Runtime.Serialization;

namespace Acme.Contracts
{
    [DataContract]
    public class UserData
    {
        [DataMember]
        public int userId { get; set; }

        [DataMember]
        public string userName { get; set; }
    }
}

Lo más práctico es poner los contratos en un ensamblado separado, a fin de facilitar el posterior mantenimiento. Para ello hay dos opciones:

• Crear un nuevo proyecto de librería de servicios WCF (y posteriormente eliminar el fichero de configuración y de servicio creados por el asistente).
• Crear un nuevo proyecto de librería de clases y agregar manualmente referencias a los ensamblados  System.ServiceModel y (de ser necesario) System.Runtime.Serialization.

Implementar el servicio

Un servicio WCF es simplemente una clase que implementa el contrato de servicio correspondiente. Y no se ejecuta por sí solo, sino que debe ser hospedado por otra aplicación cuyo tipo dependerá de los requerimientos de nuestra solución. Por ejemplo, un servicio de Windows es lo más apropiado para una ejecución desatendida.

using System;
using Acme.Contracts;

namespace Acme.Services
{
    public class TestService : ITestService
    {
        public UserData getUserData(int userId)
        {
            if (userId == 1)
            {
                UserData data = new UserData() { userId = 1, userName = "David Liñán" };
                return data;
            }
            else
                return null;
        }
    }
}

El servicio también debería estar en un ensamblado aparte si se pretende que pueda ser hospedado por distintos tipos de aplicación. Si no, puede incluirse en el propio proyecto de la aplicación que lo hospeda como una clase más.

Hospedar el servicio

La aplicación contenedora puede ser casi de cualquier tipo: una aplicación Winforms, un servicio de Windows, una aplicación de consola… También se puede hospedar bajo IIS. En el ejemplo lo haremos en una aplicación de consola que al arrancar hará lo propio con el servicio. Es necesario tener una referencia a System.ServiceModel y otra al ensamblado del servicio (si es que reside en otro distinto).

using System;
using System.ServiceModel;

namespace Acme.Services
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                ServiceHost sHost = new ServiceHost(typeof(TestService));
                sHost.Open();
                Console.WriteLine("Cualquier tecla para finalizar...");
                Console.Read();
                sHost.Close();
            }
            catch (Exception ex)
            {
                Console.WriteLine("Excepción inesperada: " + ex.Message);
            }
        }
    }
}

La forma más fácil de hospedar el servicio es usando la clase ServiceHost, definida en System.ServiceModel. Los métodos a usar invariablemente se Open() y Close(), para arrancar y detener el servicio. Además esta clase toma automáticamente los datos de configuración del servicio, que deben estar en en fichero de configuración de la aplicación contenedora. En nuestro ejemplo es el siguiente:

<configuration>
  <system.serviceModel>
    <services>
      <service name="Acme.Services.TestService">
        <endpoint name="testEndpoint"
                  address="net.tcp://localhost:7000/TestService"
                  binding="netTcpBinding"
                  contract="Acme.Contracts.ITestService" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

Cada servicio viene identificado por su nombre completo, incluyendo su espacio de nombres (Acme.Services.TestService). Adicionalmente hacen falta tres datos: una dirección (net.tcp://localhost:7000/TestService), el tipo de canal a usar (en nuestro caso es TCP, definido por netTcpBinding) y el contrato (su nombre completo, incluyendo el espacio de nombres).

El proyecto que define los contratos debe ser una librería de clases y debe referenciar System.ServiceModel para usar los atributos ServiceContract, OperationContract, etc.. Los contratos de datos requieren además de System.Runtime.Serialization.

El cliente

La aplicación cliente necesita conocer tres cosas del servicio: su contrato, su dirección y el tipo de canal a usar. La primera la obtenemos añadiendo una referencia al ensamblado del contrato. Las otras dos las podemos definir en el fichero de configuración de la aplicación cliente y sus valores deben coincidir con los definidos en el fichero de configuración del servicio (para ser exactos, de la aplicación que lo hospeda). El cliente debe tener además una referencia a System.ServiceModel y también al ensamblado que contiene el contrato de servicio.

using System;
using System.ServiceModel;
using Acme.Contracts;

namespace Acme.Clients
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                // Inicia la comunicación
                ChannelFactory<ITestService> factory = new ChannelFactory<ITestService>("testEndpoint");
                factory.Open();
                ITestService proxy = factory.CreateChannel();
                // Invocando métodos del servicio
                bool fin = false;
                while (!fin) {
                    Console.Write("Introduzca un id de usuario o <Intro> para terminar:");
                    string sUserId = Console.ReadLine();
                    int userId;
                    if (!Int32.TryParse(sUserId, out userId) )
                    {
                        fin=true;
                    }
                    else
                    {
                        UserData userData = proxy.getUserData(userId);
                        if (userData == null)
                            Console.WriteLine("Usuario no encontrado");
                        else
                            Console.WriteLine("Usuario: " + userData.userName);
                    }
                }
                // Finaliza la comunicación
                factory.Close();
            }
            catch (Exception ex)
            {
                Console.WriteLine("Excepción no esperada: " + ex.Message);
            }
        }
    }
}

La clase ChannelFactory (en System.ServiceModel) nos permite crear un proxy para invocar a los métodos del servicio desde el cliente. El nombre del endPoint a usar viene definido en el fichero de configuración del cliente:

<configuration>
  <system.serviceModel>
    <client>
      <endpoint name="testEndpoint"
                address="net.tcp://localhost:7000/Testservice"
                binding="netTcpBinding"
                contract="Acme.Contracts.ITestService" />
    </client>
  </system.serviceModel>
</configuration>

Aplicación de ejemplo

Consiste en una solución con tres proyectos:

• una librería de clases que contiene los contrato de servicio y de datos,
• una aplicación de consola que hospeda al servicio, implementado como parte de ella,
• y una aplicación de consola para invocar al servicio.

Ejecutando el cliente

Aviso: durante la ejecución es posible que aparezca el siguiente error:

“The target assembly contains no service types. You may need to adjust the Code Access Security policy of this assembly”

Esto puede ser debido a que hayamos creado un proyecto separado para el contrato de servicio. Si lo hemos hecho mediante la plantilla de proyecto WCF Library tenemos que borrar de ese proyecto el fichero de configuración (de todas formas no tendría sentido dejarlo ahí).

In the new release of .NET 4, the WCF team has added support for JSONP.  There are many resource out on the internet about the need for JSONP, if you are reading this article I’m assuming your familar with the concept of JSONP.  Essentially, JSONP utilitzes the <script /> tag as a work around to the cross domain access limitations of web browsers.  This new feature is exposed as an CrossDomainScriptAccessEnabled setting on the WebHttpBinding, and as such is configurable through code or through configuration.

Download

The full source code is available for download from my website

• JsonpWithWcfAndJquery.zip (46kb)

This code requires the latest download of .NET 4 Beta 2 with Visual Studio 2010

Example

In this example we are returning a list of sample customers.  In a standard JSON service using the WebHttpBinding you would recieve this result:

http://localhost:65025/CustomersService.svc/GetCustomers

[{"Email":"bob@example.com","Name":"Bob"},
{"Email":"mark@example.com","Name":"Mark"},
{"Email":"john@example.com","Name":"John"}]

Now using the same service you can supply the optional callback parameter like this http://localhost:65025/CustomersService.svc/GetCustomers?callback=JsonpCallback, which would return the results as the first argument to a function call with a name equal to the one supplied in the query parameter.

JsonpCallback([{"Email":"bob@example.com","Name":"Bob"},
{"Email":"mark@example.com","Name":"Mark"},
{"Email":"john@example.com","Name":"John"}])

So, if you have a javascript function setup on the page, the function will be called successfully without violating the cross-site scripting exceptions.

function JsonpCallback(customers) {
     alert(cutomers.length);
}

WCF Service with CrossDomainScriptAccessEnabled

Creating the WCF Service with CrossDomainScriptAccessEnabled is the same as it would be for any other web enabled WCF service.  In our example we are exposing a simple CustomersService

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class CustomersService
{
    [OperationContract]
    [WebGet(ResponseFormat = WebMessageFormat.Json)]
    public List GetCustomers()
    {
        return Customer.GetSampleData().ToList();
    }
}

The new JSONP feature is exposed via the WebHttpBinding.  The configuration for the CustomersService would looks like this:

<system.serviceModel>
  <behaviors>
    <endpointBehaviors>
      <behavior name="webHttpBehavior">
        <webHttp />
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <bindings>
    <webHttpBinding>
      <binding name="webHttpBindingWithJsonP" crossDomainScriptAccessEnabled="true" />
    </webHttpBinding>
  </bindings>
  <services>
    <service name="ServiceSite.CustomersService">
      <endpoint address="" binding="webHttpBinding"
                bindingConfiguration="webHttpBindingWithJsonP"
                contract="ServiceSite.CustomersService"
                behaviorConfiguration="webHttpBehavior"/>
    </service>
  </services>
</system.serviceModel>

Notice that we’ve created a new bindingConfiguration for webHttpBindingWithJsonP, in this new binding configuration we’ve set the new property of crossDomainScriptAccessEnabled to true.  This enables the new callback parameter and under the covers attaches the JavascriptCallbackMessageInspector.  I’ve choosen to explicitly setup my binding configuration, but it should be noted that .NET 4 has created default configuration features, a sample of this is available for download with the WCF Samples for .NET 4 Beta2.

Consuming JSONP with jQuery

Now, consuming this JSONP endpoint with jQuery couldn’t be easier.  jQuery ships with an ajax convenience function called getJSON that accepts a url, data, and a callback function.  In the url property you can provide a ? following a query parameter and the ajax function will replace it with a dynamic function to handle the JSONP callback.  With that being said this is what the code to access the customers would look like.

// Get the JsonP data
$.getJSON('http://localhost:65025/CustomersService.svc/GetCustomers?callback=?', null, function (customers) {
    alert('Received ' + customers.length + ' Customers');
});

Conclusion

Many of the code samples above use an abridged version of the code in the sample, so for more detail you should download the source code above.  Additionally this article and samples are based on the .NET 4 Beta 2 product.  I’ll do my best to update the code and ensure everything is in order with the official release.

For example, you need to upload log file in case of error from desktop application to remote site using WCF service and if the log file is too big, you might have to tweak your WCF service’s Web.config.

By default the configuration for the service will be

      <services>
            <service behaviorConfiguration="ServiceBehavior" name="Service">
                <endpoint address="" binding="basicHttpBinding" contract="IService">
                </endpoint>
                <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
            </service>
        </services>

You need to specify the binding manually and add binding reference as highlighted below.   

    <services>
            <service behaviorConfiguration="ServiceBehavior" name="Service">
                <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService" contract="IService">
                </endpoint>
                <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
            </service>
        </services>
        <bindings>
                <basicHttpBinding>
                    <binding name="BasicHttpBinding_IService" closeTimeout="00:01:00"
                        openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                        allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                        maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
                        maxReceivedMessageSize="2147483647" messageEncoding="Text"
                        textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
                        <readerQuotas maxDepth="32" maxStringContentLength="2147483647"
                            maxArrayLength="2147483647" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                        <security mode="None">
                            <transport clientCredentialType="None" proxyCredentialType="None"
                                realm="" />
                            <message clientCredentialType="UserName" algorithmSuite="Default" />
                        </security>
                    </binding>
                </basicHttpBinding>
            </bindings>

That’s it Simple isn’t it?

This is a series of articles where we will look how to develop WCF based service development and its hosting.

Service based applications changed the development practices. Service oriented architecture provided a new way to look at the application development and took it one step ahead in development world.

Web service and Simple Object Access Protocol (SOAP) has made data transmission between different applications very easy without worrying about underlying architecture and platform detail. SOAP architecture provides good platform for secured data transmission over HTTP with that said, if you have to develop an application that is going to run over TCP then you would have to determine and develop application that is going to support that kind of network.

Windows Communication Foundation (WCF) supports various protocols like TCP/IP, HTTP and even Peer networking using mesh network topology. In other words, WCF contains everything that modern service oriented application need.

Lets start with some basic ABC of WCF:

ABC of WCF: Address, Binding, Contract.

Address: is the location. It defines endpoint where the message should be sent by the client like: http://www.example.com/service1/

Binding: is channel. It defines the way by which messages will pass over the network like: TCP,HTTP or Named Pipes etc.

Contract: is methods or features. It defines what all methods or functions are available for client to use. It also defines message format.

Lets build our first WCF application:

1) Create new project in Visual Studio 2008 by selecting: File->New->Project -> Visual C# -> WCF -> WCF Service Library.

2) Visual Studio will create a number of files for you automatically, at this point as we are building our first application so we will not go into the detail of those files but there are two files we are interested in: IService1.cs and Service1.cs as shown:

3) IService1.cs is the interface that will define method that will be accessible to the client.

4) Replace your interface IService1 with the code below:

[ServiceContract]
public interface IService1
{
[OperationContract]
string GetProduct(int productID);
}

4) Now its time to implement our interface. I have created a conditional branch to return results in my code.

5) Save all changes in IService1.cs and open Service1.cs to implement the interface. Replace code of Service1.cs from the code below:

public class Service1 : IService1
{
private string result;

#endregion
}

6) Now its time to run the application. Run your application this will bring up WCF Test Client which is an internal hosting environment from VS2008.

7) Double click on your method “GetProducts()”. In the request section in the value field enter “1″ and click “invoke”. This will invoke the service and result will returned back in response section as shown:

Congratulations!!! you have just created your very first WCF based application.

In the next article we will explore WCF in more detail. Till than stay tuned and Happy Coding!!!

Olá pessoal.

Como eu estou mudando o meu blog para um site, então atualizei as informações.

Segue alguns artigos e vídeos sobre Silverlight.

Usando Javascript e Silverlight

http://www.dowhile.com.br/artigos/silverlight/63-usando-funcao-javascript-em-silverlight-.html

Usando e-mail e Webservice

http://www.dowhile.com.br/artigos/silverlight/60-enviando-e-mail-com-silverlight-parte-ii-.html

http://www.dowhile.com.br/artigos/silverlight/59-enviando-e-mail-com-silverlight-parte-i-.html

Usando linq to sql

http://www.dowhile.com.br/artigos/silverlight/58-populando-datagrid-usando-linq-to-sql-em-silverlight-parte-ii.html

http://www.dowhile.com.br/artigos/silverlight/57-populando-datagrid-usando-linq-to-sql-em-silverlight-parte-i.html

vídeo

Usando Javascript e Silverlight

http://www.dowhile.com.br/videos/silverlight/64-acessando-metodo-csharp-pelo-javascript.html

Abraços

Flávia Moreira

http://www.dowhile.com.br