Preciso de ajuda para decidir entre o silverlight / silverlight fora do navegador / wpf

Estou na fase inicial de planejamento de um projeto de reescrita e estou decidindo entre o silverlight / silverlight oob / wpf. TL; DR no final.

É um aplicativo LOB que lida com calendários de leads / clientes / compromissos. Não é muito complicado. Estou pesquisando essas opções independentemente em outro lugar, mas pensei em perguntar. Alguns requisitos iniciais aproximados / problemas previsíveis são:

Eu tenho que poder chamar um exe no sistema com args da linha de comando (telefone sip).

Faz do SL um problema

A base de usuários é distribuída e eu quero limitar o tráfego que passa pela conexão o máximo possível e evitar alguns problemas desagradáveis ​​de simultaneidade

Eu vejo que isso é um problema usando o WPF

A implantação / atualização de software deve ser simples . Alguns usuários são altamente não técnicos (consulte: 70 anos de idade, em um computador pela primeira vez)

Agora, esse não é um grande problema com o aplicativo ClickOnce que estamos substituindo, e eu tenho controle sobre as máquinas nas quais ele é usado. No entanto, é mais simples para os usuários se eles nem precisam clicar no botão "Instalar". Não sei como isso é tratado com o Silverlight OOB.

A empresa está planejando uma forte expansão em 12 meses, para que a implantação do hardware seja rápida / fácil. A idéia é obter uma conexão à Internet em um novo local, conectar alguns computadores e poder trabalhar sem a necessidade de pessoas dedicadas à TI ou de configuração do servidor.

Torna o SL atraente

A integração com outros serviços (software financeiro, servidor asterix) não é uma meta imediata, mas é uma meta eventual de fazer parte do sistema. Isso é muito mais simples / eficiente se um único serviço estiver configurado para integrar-se com esses serviços secundários e não precisar transferir todos esses dados pela conexão

Torna o SL atraente

Fazer várias 'versões' está fora da janela. Não sei como é manter uma versão silverlight + silverlight oob (se houver algum problema)

Pode fazer do WPF uma opção melhor.

TL; DR: Do meu ponto de vista, um aplicativo silverlight faz mais sentido para 90% dos usuários - os outros 10% não podem usá-lo porque precisam executar um exe. O Silverlight OOB pode ser um meio-termo feliz, mas não sei no momento como é o modelo de execução (ainda existe um conceito de código do lado do servidor? Nesse caso, isso seria o ideal) e não sei saber como a implantação / atualização funciona para isso.

Bem - problema interessante. Você esqueceu de mencionar que pode ter um aplicativo de confiança total do Silverlight a partir do SL4; portanto, se estiver pensando no WPF, considere isso. Seria necessário instalar (ClickOnce), mas você parece estar se afastando disso.

Ainda não fiz nada com o OOB, mas tenho certeza de que o mesmo binário pode ser usado tanto no navegador quanto no navegador, pois é uma configuração de projeto e não um destino de compilação separado.

"Ativar aplicação em execução fora do navegador"

na guia Silverlight do projeto Silverlight.

Portanto, não haveria problema de manutenção separado lá.

Você pode criar uma quantidade razoável de código no aplicativo Web que hospeda o aplicativo Silverlight e se comunicar usando os Serviços RIA do WCF - novamente, você teria que usar o .NET 4 e o SL 4 para obter a versão 1.0 disso. O .NET 3.5 e SL 4 oferecem suporte apenas aos serviços WCF RIA beta. Isso reduziria a) o tamanho do download eb) a quantidade de código que seria necessário executar no cliente, mas aumentaria o tráfego da rede.

Nessa pontuação, você pode dividir seu código do Silverlight em vários conjuntos e usar algo como o Prism configurá-los para carregar sob demanda. Isso significa que o usuário baixa apenas as partes do aplicativo que está realmente usando. Você pode reduzir ainda mais a quantidade baixada verificando a

"Reduza o tamanho do XAP usando o cache da biblioteca de aplicativos"

opção.

Se você tiver um arquivo "extmap" para qualquer DLL externa (terceiros ou .NET), isso significa que eles são agrupados em um arquivo zip e baixados separadamente para serem compartilhados em todos os arquivos xap do seu projeto. Isso mantém os arquivos xap individuais no tamanho mínimo e garante que você tenha apenas uma cópia dessas outras dlls na máquina cliente.

Sua análise é muito boa.

A única outra coisa que eu mencionaria é que nem toda a estrutura está disponível para você em um aplicativo Silverlight. Essa restrição PODE inclinar sua escolha para o WPF, mas você precisará ver como essa restrição se aplica ou não às necessidades de sua aplicação.

Apenas algumas coisas rápidas:

Implantação e "código do lado do servidor": um aplicativo Silverlight é um aplicativo do lado do cliente, simples e simples. Não deixe que o simples fato de ser entregue pelo navegador o confunda - quando você executa um aplicativo SL no navegador, está baixando os assemblies para esse aplicativo em um pacote compactado, extraindo-os e executando-os usando o plug-in. O Silverlight por si só não tem noção de "código do lado do servidor" - se você deseja que o código seja executado em um servidor remoto, escreva um serviço WCF.

Atualizando o aplicativo: este é um cenário comum para aplicativos OOB e o SL possui suporte interno. Pesquise no Google por CheckAndDownloadUpdateAsync.

Editar: Esqueci de mencionar - a instalação do aplicativo é feita de dentro do aplicativo. Por padrão, um aplicativo SL instalável terá uma ação no menu de contexto para instalá-lo. No entanto, a instalação também pode ser feita programaticamente em resposta ao usuário clicar em um botão. O estado de instalação também pode ser detectado de forma programática, então o que eu vi alguns aplicativos de SL destinados apenas a executar OOB fazer é primeiro detectar se eles estão instalados. Nesse caso, execute o aplicativo. Caso contrário, basta mostrar uma tela inicial com um botão que instala o aplicativo.