Acessar corretamente WCF no Silverlight

Acessar um webservice no Silverlight é fácil: a maneira default é adicionar uma referência ao service no projeto Silverlight. O Visual Studio executa a ferramenta slsvcutil.exe para gerar as classes proxy do serviço. Esta ferramenta é semelhante ao svcutil.exe porém especializada no Silverlight.

Aí, já nos deparamos com a primeira diferença: a proxy é gerada apenas com a versão assíncrona das operações. Isto faz sentido, pois não queremos travar o browser né?

Para cada operação temos um método Asynch() e um evento Completed. A sequência consiste em criar um handler para o evento e invocar o método asynch. Quando o controle retorna da invocação deste método, não podemos dizer que ele já executou, apenas que a mensagem foi enfileirada para envio ao web service.

Vejamos um trecho de código:

Enviar uma imagem no Silverlight do cliente ao serviço

Precisava implementar a carga de uma imagem no meu cadastro em Silverlight. No meu serviço WCF, tem as operações que enviam e recebem as entidades do Entity Framework geradas com o modelo Self-Tracking Entities. A propriedade imagem é um byte[].

Mas como fazer um binding do byte[] para um controle Image? Eu nem tinha trabalhado com imagens ainda, que dirá enviar uma pro serviço. Vamos então à como eu consegui chegar na solução.

Primeiro, como fazer binding? Bom, a Image possui um atributo Source, que pode receber um objeto BitmapImage. Como eu recebo um objeto byte[], eu precisava instanciar uma BitmapImage desta forma. Como meu cadastro não tinha nenhuma imagem ainda, tive que implementar a carga primeiro. Aí começou o drama. O Silverlight implementa um modelo de sandbox para execução no browser, que ao menos pra me atrapalhar, funcionou redondinho. Não posso chamar métodos de System.IO por exemplo. Então veio a calhar o IsolatedStorageFile. Descobri o caminho no file system, xcopy umas imagens pra lá, e voilá! Já posso ver umas imagens na tela.

En passant: referenciar assemblies .NET no Silverlight

Não é possível.

E a questão não é nem técnica, pois o formato dos assemblies e o bytecode é essencialmente é o mesmo.

Ocorre que, apesar da naturalidade com que desenvolvemos no Silverlight, esta é uma plataforma paralela ao .NET, possui seus próprios assemblies, mscorlib, System, etc. Compartilha linguagens, compiladores e outras ferramentas.

Como possui um conjunto de assemblies diferente, o Visual Studio 2010 RC não aceita e alerta o desenvolvedor quando este tenta referenciar um assembly da outra plataforma. Embora há quem tente burlar o mecanismo de detecção de plataforma (o VS faz isso pela versão do assembly), no SL não temos o assembly System.Data por exemplo, então não tem jeito de fazer um assembly com Self-Tracking Entities para ser usado no SL. E vice-versa, no .NET não se tem System.Windows.Browser por exemplo.

Uma solução então, é criar um assembly com target Silverlight, e incluir os arquivos como referência, opção Add existing item, Add as Link. Claro que isso não resolve quando estes arquivos precisam de um assembly não existente no SL.