Compartilhar Assemblies entre Silverlight. NET Apps

23 06 2010

Este post foi copiado e traduzido do CLR Team Blog.

Fonte: http://blogs.msdn.com/b/clrteam/archive/2009/12/01/sharing-silverlight-assemblies-with-net-apps.aspx

No PDC recente, Scott Guthrie anunciou em seu Silverlight 4 keynote que tinham implementado um novo recurso, para permitir aos desenvolvedores compartilhar certos assemblies entre Silverlight e. NET. Há muitas diferenças entre o Silverlight e full .NET, incluindo WPF, e este novo recurso não resolve as diferenças – nesses casos, você ainda precisa compilar seu código duas vezes. Mas em alguns casos, os desenvolvedores escrevem códigos que utilizam apenas recursos cujo comportamento é idêntico entre Silverlight e .NET, e nesses casos, queremos permitir que o código seja compartilhado. Este post fornece mais detalhes sobre a portabilidade, e explica como os desenvolvedores podem alvejá-la, e quais são os restrições.

Cenário Developer

Hoje, muitos desenvolvedores escrevem códigos que será executado em e Silverlight .NET. Um bom exemplo seria o código de validação: ao escrever uma aplicação cliente-servidor, que pretende validar os dados do cliente (para se certificar de que o usuário recebe um feedback rápido) e, em seguida, re-validá-lo novamente no servidor (para certificar-se de um implementação do cliente mal intencionada não poder enviar dados ruins.) Hoje, para conseguir esse cenário para trabalhar, os desenvolvedores precisam compilar seu código para Silverlight e também para. NET. Além disso, a compilação dupla, os desenvolvedores precisam gerenciar e implantar os assemblies separadamente, garantindo que eles sejam implantados no lugar certo e consumidos pela plataforma certa (ou Silverlight. NET). O modelo de hoje é certamente viável, mas não é ideal.

Temos ouvido de muitos desenvolvedores que querem algo melhor. Nós também lemos um bom número de blogs e posts do fórum dizendo o mesmo. Nós vimos mesmo algumas soluções interessantes para tentar tornar a situação melhor para si e para outros desenvolvedores. Legal! Especificamente, os desenvolvedores querem escrever e compilar seu código uma vez e implantá-lo como parte dos seus aplicativos Silverlight e .NET, sem a necessidade de dupla compilação ou se preocupar em prestar a atenção para o alvo de compilação. Essa capacidade tem a vantagem óbvia de evitar a duplicação de esforços para uma série de etapas em seu desenvolvimento e os processos de implantação.

Explicando a Portabilidade

Chamamos esse novo recurso ” assembly portability”(portabilidade de assembly), uma vez que o recurso permita que o código sejar “portatil” entre Silverlight e .NET. Portabilidade fornece a capacidade de compilar sua fonte, com as ferramentas do Silverlight, e executar seus conjuntos construídos em ambos Silverlight e Runtimes .NET.Este recurso não altera a implementação subjacente do Silverlight ou qualquer NET .Runtimes, ao contrário, se você escrever um código que só usa APIs que têm o mesmo comportamento em Silverlight e .NET, ele permite que você use um conjunto de binários para atingir ambos. Mas como você sabe se as APIs que você está usando são compatíveis? Nós identificamos cinco conjuntos de chaves que são compatíveis entre Silverlight e. NET. (A camada de interface de usuário do Silverlight não é, obviamente uma delas – há algumas diferenças importantes entre Silverlight e WPF UI).

Como a maioria dos recursos que construímos, nós tínhamos um monte de escolha sobre como criar o recurso, e quais os cenários que permitam. No centro do recurso, uma escolha de design principal era permitir a portabilidade do Silverlight para. NET. A motivação para esta escolha foi que o Silverlight expõe um subconjunto da API .NET, e assim um assembly construídos em Silverlight deve “funcionar” em .NET, enquanto que no sentido inverso (.NET assemblies Executando em Silverlight) seria tecnicamente mais desafiador ( para todos nós).

Outra opção importante do projeto foi identificar o conjunto de assemblies Silverlight /.NET que os desenvolvedores podem usar com segurança, mantendo a comparabilidade binária. Nós olhamos para os cenários que se beneficiariam mais tanto da portabilidade, e seria fácil para os desenvolvedores a utilizar. Nós olhamos um monte de cenários, incluindo: o mais baixo nível, a lógica de negócio típico, networking e também UI. Nós decidimos que iria começar com o cenário mais fundamental e pedido para esta versão. Como resultado, para .NET 4 e SL4, permitimos a portabilidade para um conjunto significativo de assemblies de baixo nível que acreditamos que irá permitir uma variedade de cenários interessantes.

Para SL 4 e .NET 4, temos feito os conjuntos seguintes portáteis:

  • Mscorlib
  • System
  • System.Core
  • System.ComponentModel.Composition
  • Microsoft.VisualBasic

Note novamente que a superfície Silverlight para estes conjuntos é o que nós fizemos portátil. Há um grande número de tipos e membros no. NET superfície que não podem ser executados em Silverlight. Como resultado, você precisa escrever um código que visa o Silverlight versões destes conjuntos, a fim de obter esse cenário para o trabalho.

Observe também que pode haver alguns comportamentos que não são rigorosamente idênticas em ambas as plataformas. Nós trabalhamos para evitar esses comportamentos, porém, essas diferenças são muito sutis e, por vezes difíceis de identificar. Por favor, entre em contato conosco se você ver as diferenças comportamentais entre Silverlight e. NET, APIs para portáteis, que estão incomodando.

Experiência Visual Studio

Como todas as caracteristicas .NET, é importante que nós fornecemos o apoio de ferramentas boas no Visual Studio. Este recurso pode ser usado no Visual Studio, da maneira que se possa imaginar. Os desenvolvedores devem escrever a sua lógica portátil em projetos Silverlight Class Library e, em seguida, são livres para fazer referência a tais projectos de ambos os projetos Silverlight e .NET. Para esclarecer, no lado .NET, Você pode fazer referência a tal biblioteca de qualquer tipo de. NET (Ex: WPF, winforms, WCF, WF, ASP.NET, …).

A única ressalva é que o suporte no Visual Studio foi implementado de tal forma que você precisa clicar várias vezes extra para obter uma referência a um projeto portátil configuração correta. Para VS 2010, você deve contar com a navegação para o binário – AKA “binary reference” – que é construída a partir da biblioteca de classes Silverlight para fazer uma referência. Você não pode fazer referência apenas o próprio projeto – também conhecido como – AKA “project to project reference”. Note que esta restrição existe apenas para .NET, e não os do Silverlight.

A seguir estão as etapas básicas a seguir para habilitar o uso de códigos portáteis no Visual Studio 2010, seguido por um conjunto de prints de tela que espero que fique super claro o que fazer.

Etapas:

  1. Setup projects
    1. Criar .NET application
    2. Criar ou adicionar projetos existentes de biblioteca de classe Silverlight
    3. Compilar o projeto Silverlight
  2. Estabelecer referência de Código portátil
    1. Referência a biblioteca de classes Silverlight ao .NET application.
  3. Código
  4. Rodar a aplicação!

Prints da tela:

projectos Passo 1 – Instalação

Passo 2 – Estabelecer o código de referência portátil para o outro projeto (obrigatório subir e descer a estrutura de diretórios para o projeto de biblioteca Silverlight).

Passo 3 – Código

Passo 4 – Rodar a aplicação!

Nota: Minha app é um aplicativo WPF que se destina a mostrar quantos dias existem até o inicio dos jogos Olímpicos de Vancouver 2010, a partir de hoje. A biblioteca Silverlight é o que faz a contagem regressiva de cálculo real, e é (naturalmente), utilizáveis em ambos as aplicações .NET e Silverlight. Legal!

Olhando para a frente e Comentários

É ótimo ver tanta energia em torno de ambos .NET e Silverlight, e particularmente em torno da partilha de código máxima em todas as plataformas. Convido você a usar este novo cenário para toda a sua extensão, e para comunicar-nos de volta para onde você gostaria de ver a funcionalidade expandida no futuro.

Estamos conscientes de algumas situações que não estão habilitados para ser portátil, mas que os desenvolvedores provavelmente irá deparar-se com bastante rapidez. As mais óbvias são XML, networking, chamada WCF web-services e código UI. Outro interessante é o XAML portátil. Seria muito útil para ouvi-lo sobre os cenários específicos que você gostaria de implementar no código do portátil, mas não consegue executar devido às limitações que eu já mencionei. Eu também gosto de ouvir porque você viu a possibilidade de implementar esse cenário no código portáteis como sendo tal benefício. Os seus comentários vão ajudar a orientar-nos com as mudanças futuras no espaço do código portátil.

Este post foi copiado e traduzido do CLR Team Blog.

Fonte: http://blogs.msdn.com/b/clrteam/archive/2009/12/01/sharing-silverlight-assemblies-with-net-apps.aspx

Anúncios

Ações

Information

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s




%d blogueiros gostam disto: