domingo, 26 de abril de 2015

Acessando o SQLite a partir de uma PCL e uma aplicação Windows Phone 8.1

Recentemente precisei acessar o SQLite a partir de uma Portable Class Library, por sua vez acessada por uma aplicação Windows Phone 8.1.

Passei por um bom perrengue até conseguir colocar a coisa toda pra funcionar e por essa razão decidi documentar o passo a passo para a solução final. Segue abaixo:

1) No assembly PCL em que você deseja acessar o SQLite, referencie o pacote NuGet "SQLitePCL.raw_basic". Este pacote fornece acesso ao SQLite sem conter o SQLite em si e portanto é independente de plataforma, podendo ser usado numa PCL. Ele não será usado em tempo de execução, mas permitirá que sua solução compile sem problemas.

2) Ainda no mesmo assembly, referencie o pacote "SQLite-net PCL". Esse pacote é quem fornece a API .NET que você utilizará para acessar o SQLite, como o objeto SQLiteConnection, por exemplo. Internamente, ele acessa o "SQLitePCL.raw" que é o pacote que de fato acessa a 'sqlite3.dll'.

3) No projeto que irá consumir a sua PCL, referencie o pacote NuGet "SQLitePCL.raw". Esse pacote vem com versões específicas para cada plataforma e apenas aquela referente à plataforma do seu projeto será utilizada. É este também o pacote que trás consigo a biblioteca 'sqlite3.dll'.

4) Por alguma razão que não consegui descobrir qual seja, ao compilar e executar o projeto neste ponto, quando tudo já deveria estar funcionando, o runtime informa que a 'sqlite3.dll' não pode ser carregada, mesmo ela estando presente junto aos binários do projeto. A forma como resolvi esse problema foi adicionar, e em seguida remover, uma referência ao pacote oficial do SQLite para Windows Phone 8.1. É necessário remover a referência após adicioná-la pois caso contrário o compilador irá reclamar de duplicidade da biblioteca 'sqlite3.dll', presente nessa extensão, com a outra, disponível no pacote "SQLitePCL.raw". Após esse 'recurso técnico' ser aplicado, tudo parece passar a funcionar sem problemas, mesmo após apagar completamente os binários do projeto e compilar novamente (sem repetir a gambiarra com o pacote oficial).

Escrevi uma breve aplicação para ilustrar essa solução.

quinta-feira, 9 de abril de 2015

Windows Nano Server - A maior evolução para o DevOps Microsoft

O grande gargalo para o uso de sistemas Windows em ambientes de nuvem e para uma boa infraestrutura de DevOps fora do Microsoft Azure é sem dúvida o footprint gigantesco do sistema. Manter uma maquina virtual onde apenas processos de backend precisam ser executados demanda a instalação do sistema operacional completo, incluindo ferramentas gráficas e tudo que as suporta, algo completamente desnecessárias nesse tipo de cenário. 

Atualmente, para preparar uma maquina Windows Server precisamos de cerca de 32GB de espaço em disco, com sorte, o que torna praticamente inviável o uso do sistema em muitos cenários, levando à preferência por ambientes mais leves e modularizados, casos das inúmeras distribuições Linux que temos hoje dominando os ambientes de nuvem e containers.

No entanto, neste último dia 8 de Abril, a Microsoft anunciou o desenvolvimento do Windows Nano Server, uma versão reduzida do sistema operacional, contendo apenas aquilo que é de fato necessário para a execução de uma infraestrutura de nuvem, removendo totalmente sua interface gráfica e demais funcionalidades desnecessárias. Com isso o footprint do sistema caiu expressivos 93%, o que nos leva a crer que poderemos ter uma maquina Windows Nano Server, totalmente viável para a execução de sistemas de backend, com razoáveis 2,3GB de espaço em disco, talvez até menos.

Isso torna viável também o uso do Windows Nano Server com Vagrant e, segundo a Microsoft, até Docker, simplificando absurdamente a criação de ambientes de DevOps para softwares desenvolvidos para a plataforma .NET, principalmente considerando o desenvolvimento do novo .NET Core 5 e ASP.NET 5, também bastante reduzidos em tamanho e muito melhor modularizados, se comparados às versões atuais.

A partir do lançamento desse novo sistema, com pouco investimento, será possível a distribuição e gestão do ciclo de vida de serviços de backend executados sobre a plataforma .NET e Windows em ambientes como o IBM BlueMix, ou Amazon AWS, de forma tão prática quanto é feita hoje para sistemas Java executados sobre uma distribuição Linux.

Essa foi sem dúvida a melhor notícia dos últimos tempos para desenvolvedores .NET e administradores de infraestrutura Windows. Ansioso para ver tudo isso funcionando na prática. Que 2016 chegue logo.

Atualização: Na Build 2015, foi anunciado que o Nano Server tem uma imagem de cerca de 400MB, contra quase 5GB da versão Server Core, a menor disponível atualmente. Além disso, o sistema gasta cerca de 40 segundos para ser instalado, 15 segundos para ser inicializado e ocupa apenas 63MB de memória. Números realmente impressionantes, mesmo em comparação ao atual Server Core.

Vejam mais detalhes em: