Olá pessoal, tudo bem?

Em novembro do ano passado decidi tirar a certificação da Microsoft MCSD em Web Applications, começando pelo exame 70-487: Developing Microsoft Azure and Web Services. Fiz um post contando a minha estratégia de estudos, que seria escrever um post sobre cada tópico da prova baseado no livro Exam Ref da Microsoft (você pode ver os links aqui).

No dia que terminei o último dos 31 posts (que totalizaram 32697 palavras 😮 ), marquei a prova já para o dia seguinte. Estudei algum conteúdo sobre as atualizações da prova de 2014 e o resultado foi: aprovado!

Para quem quiser também passar na prova, alguns pontos de atenção:
(mais…)

Leia Mais

Esse é o último post da série sobre a certificação Microsoft 70-487. Os links para todos os posts estão aqui.

Olá pessoal, tudo bem?
Vamos ao último objetivo da certificação, o Share assemblies between multiple applications and servers.

Esse objetivo cobre como preparar o ambiente para usar assemblies entre múltiplos servidores, assinar assemblies com um strong name, fazer o deploy de assemblies para o GAC (global assembly cache), implementar versionamento de assemblies e criar um assembly manifest. Vamos lá?

Preparando O Ambiente Para Usar Assemblies Entre Múltiplos Servidores

Quando você faz o deploy da sua aplicação, todo o código (inclusive o .NET Framework) é compilado para assemblies (DLLs) que são lidos e carregados na memória pelo IIS. Em casos onde um servidor hospeda várias aplicações, vários assemblies serão deployados redundantemente. Por exemplo, se existem 3 aplicações MVC, o assembly System.Web.Mvc será carregado 3 vezes na memória. Isso aumenta o tempo de inicialização e o uso da memória do seu servidor.

Para essa seção, você deve entender 2 conceitos que o ASP.NET utiliza na hospedagem de aplicações para resolver esse problema: Shadow Copying e Assembly Interning.

Shadow Copying é útil no momento de atualização dos assemblies. Normalmente, o CLR (Commom Language Runtime) trava os assemblies quando eles estão em execução. Isso significa que você não pode simplesmente copiar uma nova versão em cima da atual. O Shadow Copying atua nesses cenários copiando o assembly original para a pasta de arquivos temporários do ASP.NET, travando a cópia e liberando a atualização do assembly na localização original. Isso é habilitado por padrão nas pastas de assemblies (bin).

O Assembly Interning, disponível a partir do ASP.NET 4.5, analisa essa pasta temporária procurando por assemblies duplicados (usados 3 vezes ou mais), como no caso de 3 aplicações MVC no mesmo servidor. Esses assemblies são então movidos para uma localização especial, e todas as referências originais são substituídas com “links simbólicos”, que apontam para essa nova localização quando as aplicações fazem requisições aos assemblies que foram compartilhados. Dessa forma, todos esses assemblies são carregados apenas uma vez na memória, economizando tempo e recursos.

Você usa o Assembly Interning pela ferramenta aspnet_intern.exe, na linha de comando. Ela pode ser usada assim:

aspnet_intern -mode exec -sourcedir "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" -interndir C:\CommonAssemblies

Há também um modo de análise, onde a ferramenta mostra quais assemblies podem ser compartilhados:

aspnet_intern -mode analyze -sourcedir "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" -v

Assinando Assemblies Com Um Strong Name

O CLR suporta dois tipos de assemblies: os regulares e os com strong name (“nome forte”). Ambos têm a mesma estrutura, mas os fortemente nomeados têm chaves públicas e privadas que identificam o publicador e o conteúdo do assembly.

Isso garante singularidade, pois nenhum assembly pode ter o mesmo nome forte que o seu (o nome é baseado na chave privada). Os outros benefícios são que somente você pode publicar atualizações para o assembly e que o .NET consegue checar a integridade do assembly desde o momento que ele foi assinado.

Você pode assinar um assembly via linha de comando ou pelo Visual Studio. O primeiro passo é gerar as chaves privada e pública por meio de um arquivo .snk. O seguinte comando gera esse arquivo:

sn -k myKey.snk

Pelo Visual Studio, isso é feito na página de Properties do projeto, na aba Signing:

Habilitando a opção Sign the assembly, o Visual Studio gera o arquivo com a chave e assina o assembly no momento da compilação.

Assemblies assinados só podem referenciar assemblies que também são assinados por motivos de segurança. Caso você referencie um assembly não assinado, ao invocar qualquer código desse assembly o erro Assembly generation failed — Referenced assembly ‘MyLib’ does not have a strong name é lançado.

Após assinar um assembly, você pode ver a chave pública pela ferramenta Sn.exe, instalada no Visual Studio. O seguinte comando pode ser usado:

sn -Tp C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.dll

O resultado é o seguinte, onde o Public key token representa a chave pública:

Microsoft (R) .NET Framework Strong Name Utility Version 4.0.30319.17929 Copyright (c)
Microsoft Corporation. All rights reserved.
Identity public key (hash algorithm: Unknown): 00000000000000000400000000000000
Signature public key (hash algorithm: sha256): 002400000c800000
140100000602000000240000525341310008000001000100613399aff18ef1
a2c2514a273a42d9042b72321f1757102df9ebada69923e2738406c21e5b801552ab8d200a65a2
35e001ac9adc25f2d811eb09496a4c6a59d4619589c69f5baf0c4179a47311d92555cd006acc8b
5959f2bd6e10e360c34537a1d266da8085856583c85d81da7f3ec01ed9564c58d93d713cd0172c
8e23a10f0239b80c96b07736f5d8b022542a4e74251a5f432824318b3539a5a087f8e53d2f135f
9ca47f3bb2e10aff0af0849504fb7cea3ff192dc8de0edad64c68efde34c56d302ad55fd6e80f3
02d5efcdeae953658d3452561b5f36c542efdbdd9f888538d374cef106acf7d93a4445c3c73cd9
11f0571aaf3d54da12b11ddec375b3
Public key token is b77a5c561934e089

Para empresas, é importante manter a chave privada segura, pois alguém pode roubá-la e distribuir assemblies alterados que parecem legítimos. Porém, sem a chave privada, os desenvolvedores não conseguem assinar o assembly para construir a aplicação.

Para evitar esse problema, o conceito de delay/partial signing foi criado. Com isso, os desenvolvedores conseguem assinar o assembly somente com a chave pública, deixando para assinar o assembly com a chave privada somente no momento da publicação. Na figura acima no Visual Studio, a opção Delay sign only faz isso.

Lembre-se para o exame dos benefícios de assinar um assembly e quando usar delayed signing.

Fazendo O Deploy De Assemblies Para O GAC (Global Assembly Cache)

GAC (Global Assembly Cache) é uma biblioteca especializada em guardar assemblies. Fazer o deploy de um assembly para o GAC significa que ele estará disponível para todas as aplicações hospedadas naquele servidor.

Usar o GAC é útil quando um assembly é compartilhado entre múltiplas aplicações. Outra razão é para melhoria de segurança, visto que normalmente somente administradores conseguem alterar o GAC. O GAC também é conveniente para fazer o deploy de múltiplas versões do mesmo assembly.

Para o servidor de produção, você pode fazer o deploy de um assembly para o GAC por meio de alguma ferramenta como o Windows Installer 2.0 ou com o Web Deploy configurado com um provider para fazer a instalação do arquivo no GAC.

No ambiente de desenvolvimento, você usa uma ferramenta chamada Gacutil.exe. Os seguintes comandos podem ser utilizados:

• gacutil -l lista o conteúdo do GAC;
• gacutil -i [assembly name] instala um assembly no GAC;
• gacutil -u [assembly name] remove um assembly do GAC.

Ao referenciar um assembly no seu projeto, você pode adicionar uma referência ao arquivo no GAC ou uma cópia local. Quando o Visual Studio detecta que há um assembly do GAC referenciado, ele adiciona a referência ao GAC.

Implementando Versionamento De Assemblies

Cada assembly carrega no seu manifesto o número da sua versão no seguinte formato: {Major}.{Minor}.{Build}.{Revision}.

Ao fazer o build de um assembly, há 2 números de versão que você deve levar em conta: a versão do arquivo e a versão do assembly .NET. Quando um projeto é criado no Visual Studio, o arquivo AssemblyInfo.cs é automaticamente criado contendo as seguintes linhas:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

AssemblyFileVersionAttribute é o que deve ser incrementado a cada build no seu processo de build. AssemblyVersionAttribute deve ser incrementado manualmente a cada deploy para produção.

Como dito anteriormente, múltiplas versões de um mesmo assembly podem ser deployados para o GAC. Isso é chamado side-by-side hosting.

O processo de encontrar o assembly correto para ser carregado pelo CLR começa no número da versão mencionado no manifesto. Mas isso pode ser influenciado por alguns arquivos de configuração, como o da aplicação, do Publisher Policy ou da Machine Configuration.

Vamos supor que você tem um assembly carregado no GAC e várias aplicações dependem dele. Caso você publique uma nova versão e queira forçar as aplicações a usarem essa nova versão, você pode publicar um Publisher Policy para o GAC com a seguinte configuração:

Nesse exemplo, quando o CLR procura o assembly com a versão 1.0.0.0, é redirecionado para o 2.0.0.0.

Caso todos os assemblies estejam privados dentro da aplicação, você pode adicionar a seção de probing no arquivo web.config para o CLR procurar em outro diretório. Exemplo:

Outra opção é usar o elemento codeBase para especificar uma localização fora do diretório da aplicação, podendo ser outro computador da rede ou algum lugar na internet.

Dois detalhes: os assemblies precisam ser fortemente nomeados (assinados) se estiverem fora da pasta da aplicação e os assemblies localizados em outro computador são baixados para uma pasta especial no GAC.

Um exemplo de configuração do codeBase:

Para o exame, lembre-se que a opção de probing só pode ser usada para localizações dentro do caminho da aplicação, enquanto o codeBase permite outras localizações.

Criando Um Assembly Manifest

O Assembly Manifest é o lugar que contém os metadados do assembly e de todos os assemblies que ele depende.

A ferramenta ILDasm analisa o conteúdo de assemblies compilados. Ela mostra da seguinte forma:

Note a presença do Assembly Manifest. Ele tem as seguintes funções:

• Enumera os arquivos do assembly;
• Governa como as referências ao tipo do assembly são mapeadas para os arquivos que contém a implementação;
• Enumera os assemblies que o assembly depende;
• Provê um nível de separação entre os consumidores do assembly e os detalhes da implementação;
• Renderiza a descrição do assembly.

Ele ainda contém a identidade do assembly, como o nome, o número da versão, cultura e informações da assinatura. Você pode alterar esses valores no arquivo AssemblyInfo.cs, com os atributos AssemblyCultureAttribute, AssemblyTitleAttribute e AssemblyDescriptionAttribute.

Por último, o Assembly Manifest normalmente está no Portable Executable (PE), como uma DLL ou .exe junto com o Intermediate Language (IL) que descreve o assembly. Você pode criar um assembly em múltiplos arquivos com um Assembly Manifest ou com o Assembly Manifest incorporado dentro de cada PE.

---

E finalmente, terminamos todos os objetivos da certificação 😀

Logo faço um post com algumas informações da prova, como as atualizações que vieram em abril de 2014 e algumas dicas a mais.

Obrigado por acompanhar essa jornada e até mais!

Leia Mais

Olá pessoal, tudo bem?
O objetivo Create, configure, and publish a web package, penúltimo da certificação, cobre aspectos do Web Deployment Framework, ou Web Deploy.

Vamos ver como criar um IIS Install Package, configurar o processo de build para fazer o output de um Web Package e aplicar condições pré e pós deploy.

Criando Um IIS Install Package

Nessa seção, vamos cobrir as 4 principais maneiras de se criar um pacote Web Deploy: Visual Studio, IIS, prompt de comando e Windows PowerShell.

Visual Studio

No Visual Studio, você pode usar a ferramenta Publish para criar um pacote Web Deploy. Ela permite que você adicione scripts de banco de dados ou execute Migrations do EF e mude connection strings do web.config.

Você começa o processo no menu Build > Publish {nome do projeto} ou com o botão direito no projeto > Publish. A seguinte tela é mostrada:

Na seção Profile, você precisa criar um Publish Profile, que é guardado na solution para futuros publishs. Você pode criar um Publish Profile para cada ambiente que vai fazer o deploy da aplicação, como desenvolvimento, homologação e produção.

Se você está fazendo deploy no Azure Websites, você pode fazer o download do Publish Profile diretamente do portal.

Na segunda página da janela, você escolhe o método do deploy. No nosso caso, escolhemos Web Deploy ou Web Deploy Package.

Web Deploy faz o deploy diretamente para um servidor remoto que tem o serviço Web Deploy instalado. Você precisa colocar o endereço do servidor e as credenciais. O Web Deploy Package cria um pacote Web Deploy que você pode fazer a instalação manualmente. Você só precisa entrar com uma localização para o pacote e o nome do site, que pode ser mudado no momento do deploy:

Na terceira parte você pode configurar opções como a configuração do build (Release por padrão), precompile do site, excluir arquivos do App_Data e configurar o banco de dados:

Após clicar em Publish, o Visual Studio vai gerar um pacote Web Deploy que você pode usar para fazer o deploy no IIS via IIS Manager ou linha de comando.

Há algumas opções extras na página de Properties do seu projeto, nas páginas Package/Publish Web e Package/Publish SQL.

Em Package/Publish Web, você seleciona os arquivos que quer fazer o deploy nas seguintes opções: somente os arquivos obrigatórios, todos os arquivos do projeto ou todos os arquivos na pasta do projeto. Você pode também selecionar uma opção para incluir as configurações do IIS Express para garantir que os servidores estão configurados corretamente.

A página Package/Publish SQL é desabilitada por padrão, mostrando uma mensagem que você pode fazer as configurações na janela de Publish. Mas você pode habilitá-la e fazer as configurações para o banco de dados.

IIS

Após a instalação do Web Deploy, o IIS Manager suporta tanto a criação de pacotes Web Deploy como a importação deles para instalação.

É possível criar pacotes para uma aplicação, site ou o servidor completo. Nesse último caso, o pacote contém todas as configurações do servidor como o applicationHost.config, registros do IIS, certificados SSL e o conteúdo de todas as aplicações hospedadas.

Você exporta um pacote abrindo o IIS Manager, selecionando a aplicação, site ou servidor a ser exportado e indo em Export Application. A seguinte tela é mostrada:

Na opção Manage Components, você pode configurar providers para configurações de registro, fazer o deploy de assemblies no GAC ou um banco de dados no pacote.

O próximo passo no wizard permite que você configure parâmetros para os providers, como o nome do site ou a localização do banco de dados.

Para fazer a importação de um pacote, você seleciona o servidor ou site e clica em Import Package. Esse pacote pode ter sido criado via exportação do IIS, Visual Studio ou linha de comando. Após selecionar a localização do pacote, uma janela é aberta para a seleção dos arquivos que você quer fazer o deploy. Você pode também especificar os valores dos parâmetros criados na exportação do pacote.

Na importação, há uma opção chamada whatif que mostra as ações que serão feitas no deploy sem que elas sejam feitas de fato.

Prompt De Comando

A ferramenta usada na linha de comando é a MSDeploy. Você pode usá-la para sincronizar servidores, criar e fazer o deploy de pacotes. O comando a seguir, por exemplo, faz a sincronização de 2 servidores com a opção whatif:

msdeploy -whatif -verb:sync -source:iisApp="Default Web Site/MyApp" -dest:iisApp="Default Web Site/MyApp", computerName=Server2

Alguns segmentos importantes são:

• verb: especifica a operação a ser feita (delete, dump, getDependencies, getSystemInfo ou sync);
• source: especifica a fonte dos dados;
• dest: especifica o destino da operação;
• whatif: indica que o comando deve rodar sem fazer as alterações de fato.

Para fazer um deploy com MSDeploy, você pode usar o .cmd gerado pelo Visual Studio na criação do pacote. O comando é o seguinte:

ProjectName.deploy.cmd /y /m:https://DestinationServerName:8172/MSDeploy.axd

Não é necessário memorizar todas as opções do Web Deploy para o exame. Saiba apenas a sintaxe básica, como a flag whatif. A lista completa das opções do MSDeploy pode ser vista aqui.

Windows PowerShell

O Windows PowerShell é uma ferramenta de linha de comando com capacidades extras. Como no prompt, você pode sincronizar servidores, criar e fazer o deploy de pacotes.

Para usar o Web Deploy do PowerShell, você precisa instalar o snap-in WDeploySnapin3.0 com o comando Add-PSSnapin WDeploySnapin3.0.

Depois, você pode obter a lista dos comandos do Web Deploy com o comando Get-Command -module WDeploySnapin3.0. O resultado é:

Para fazer um deploy, você primeiro precisa de um arquivo Publish Settings (o mesmo gerado pelo Visual Studio quando você cria ou importa um Publish Profile). O comando New-WDPublishSettings pode ser usado:

$cred = Get-Credential
New-WDPublishSettings -ComputerName WebServer -Site WebSite1 -Credentials $cred
-AllowUntrusted -SiteUrl "http://www.mywebsite.com" -FileName C:\temp\mywebsite.
publishsettings -AgentType wmsvc

O seguinte arquivo é criado após esse comando:

Depois, o comando Sync-WDApp pode ser usado para fazer o deploy:

Sync-WDApp "MyApp" "MyAppDeployedWithPowerShell" -DestinationPublishSettings "C:\temp\mywebsite.publishsettings"

Configurando O Processo De Build

Você pode configurar o processo de build no TFS para fazer o deploy da sua aplicação.

Editando o template da build com o seguinte comando, você pode criar um pacote em Release para fazer o deploy manualmente:

MSBuild "MyProjectName.csproj" /T:Package /P:Configuration=Release

Também é possível especificar o parâmetro /p:DeployOnBuild=True, que com o publish settings correto, faz o deploy da sua aplicação automaticamente.

Aplicando Condições Pré e Pós Deploy

Com Web Deploy, você pode também executar ações antes e depois de fazer o deploy da aplicação.

Você faz isso com as opções preSync e postSync em conjunto com runcommand:

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2"
-preSync:runcommand="c:\MyBatchFile.bat"

---

Terminamos mais um objetivo 😀

Fique de olho no próximo post que será sobre o último objetivo da certificação, Share assemblies between multiple applications and servers.

Até lá!

Leia Mais

Olá pessoal!
O objetivo 5.4, Manage packages by using NuGet, cobre todos os aspectos do NuGet: como instalar e atualizar um pacote, criar e configurar um pacote e preparar um repositório de pacotes. Vamos lá?

Instalando E Atualizando Um Pacote NuGet Existente

O NuGet permite que você instale bibliotecas para usar no seu código. Caso veja no exame alguma coisa sobre referenciar bibliotecas populares, pense em NuGet. Um pacote NuGet, além de ter uma série de assemblies que você pode referenciar, pode conter arquivos, como JavaScripts e CSSs. Também podem alterar seu arquivo de configuração ou adicionar código no seu projeto. A grande vantagem é que, ao invés de você ter que manualmente baixar assemblies ou arquivos, o NuGet faz isso automaticamente para você.

A partir do Visual Studio 2012, os templates de projetos são baseados no NuGet. Se você criar uma aplicação ASP.NET MVC com o template de Internet, por exemplo, um arquivo chamado packages.config é criado contendo todas as referências ao pacotes utilizados. Esse arquivo é parecido com isso:

Janela Manage NuGet Packages

A janela Manage NuGet Packages serve para você gerenciar os pacotes instalados no seu projeto e instalar novos pacotes.

Você pode acessá-la pelo Visual Studio no menu Tools > Library Package Manager > Manage NuGet Packages. Desse modo, os pacotes da solution inteira são abertos:

Indo na seção Online, você pode procurar os pacotes disponíveis e instalá-los diretamente do Visual Studio. Na parte Update, o Visual Studio detecta todas as atualizações disponíveis e você pode instalá-las com 1 clique.

Você pode abrir os pacotes instalados apenas para 1 projeto, clicando com o botão direito em References > Manage NuGet Packages. A tela funciona exatamente igual.

Outra grande vantagem do NuGet é que, ao instalar ou atualizar um pacote, ele detecta automaticamente todas as dependências e as instala juntamente com o pacote.

Package Manager Console

Para instalar, atualizar ou remover pacotes, você pode também usar o Package Manager Console, que é um Windows PowerShell integrado ao Visual Studio. Ele é assim:

Para instalar um pacote, o comando Install-Package pode ser usado. Exemplo: Install-Package Ninject.

Com isso, o assembly do Ninject é baixado para a pasta packages da solution e uma referência é adicionada ao projeto.

Uma feature interessante do console é o auto complete, acionado quando você aperta a tecla Tab. Ele funciona para os nomes dos comandos e dos pacotes.

Para desinstalar um pacote, o comando é o Uninstall-Package: Uninstall-Package Ninject.

Esse comando remove o pacote do packages.config, remove a referência do projeto e deleta a pasta da packages. Todas as alterações aos arquivos de configuração também são revertidas. Porém, as dependências instaladas não são automaticamente removidas.

Para atualizar um pacote, o comando é Update-Package: Update-Package Ninject.

Caso você não especifique um pacote para o comando Update-Package, todos os pacotes da solution são atualizados. Para atualizar todos os pacotes de apenas um projeto, o parâmetro -Project pode ser usado: Update-Package -Project NuGetTest.

Alguns pacotes oferecem comandos que são integrados ao console. Após instalar o pacote do Entity Framework, por exemplo, você pode usar os comandos Enable-Migrations, Add-Migration e Update-Database para usar Code First Migrations.

O último detalhe é que os comandos são executados por padrão para o primeiro projeto da solution. Isso pode ser alterado no drop-down Default project.

Compartilhando Pacotes

Incluir os pacotes no controle de versão não é uma boa prática, pois todos eles serão guardados e baixados para cada pessoa que acessar o projeto. Se você esquecer de adicionar um pacote no controle de versão, também vai haver problemas para os outros usuários.

Ao clicar com o botão direito na solution no Visual Studio, você pode habilitar a opção Enable Package Restore On Build. Ao fazer isso, uma pasta .nuget é adicionada na solution com um arquivo NuGet.exe. Dessa forma, no build do projeto o NuGet vai validar se todos os pacotes estão instalados e, se algum estiver faltando, vai fazer o download automaticamente. Isso permite que você não precise colocar os pacotes no controle de versão.

Se você quer mudar a localização dos pacotes instalados, basta adicionar um arquivo nuget.config na solution com o seguinte conteúdo:

Criando E Configurando Um Pacote NuGet

Qualquer pessoa pode adicionar um pacote NuGet na galeria, tornando-o disponível a todos. Essa seção explica como criar e configurar um pacote para disponibilizá-lo na galeria.

Conteúdo Do Pacote

Um pacote NuGet é descrito pelo arquivo .nuspec, contendo um XML que descreve seu pacote. Ele é mais ou menos assim:

Em seguida, você vai colocar seus arquivos. A convenção é distribuí-los em 3 pastas: \lib, \content e \tools.

A pasta lib contém os assemblies. Se seu pacote for multiplataforma, você pode usar subpastas para separar essas versões.

A pasta content tem arquivos de configuração, imagens, JavaScript, CSS, etc. Todos os arquivos nessa pasta serão incluídos no projeto. Isso significa que se você tiver uma imagem em \content\images\myimg.png, ela será adicionada no projeto em \images\myimg.png.
Arquivos de transformação também podem ser colocados nessa pasta. Se houver um arquivo app.config.transformation ou web.config.transformation, o NuGet vai colocar os elementos desses arquivos que não estiverem no arquivo de configuração do projeto.
Isso também é possível via código com arquivos .cs.pp quando você quer adicionar código no Global.asax ou alguma classe, por exemplo. Há alguns tokens que podem ser usados, como o $rootnamespace$, que insere o namespace correto: namespace $rootnamespace$.Models.

Por fim, na pasta tools podem ser colocados scripts Windows PowerShell para rodar quando seu pacote é carregado, instalado e desinstalado, com os nomes Init.ps1, Install.ps1 e Uninstall.ps1, respectivamente.

Um último detalhe é que se seu pacote não tiver nada dentro das pastas content e lib ele é considerado um pacote a nível de solution. Você usa isso se seu objetivo for adicionar comandos ao Package Manager Console, como o pacote do Entity Framework.

Criando Seu Pacote NuGet

Você pode criar seu pacote NuGet via linha de comando ou usando a ferramenta NuGet Package Explorer.

Para usar a linha de comando, você deve ter o arquivo NuGet.exe e adicionar a localização dele no PATH.

O primeiro comando que você deve utilizar é o NuGet Update -self, que atualiza o NuGet para a última versão.

Para criar um pacote NuGet a partir de um assembly, o comando é o nuget spec MyAssembly.dll. Com isso o arquivo MyAssembly.nuspec é criado contendo o manifesto para você editar o nome, descrição, dependências, etc.

Depois disso, o comando nuget pack MyAssembly.nuspec cria de fato seu pacote no arquivo MyAssembly.dll.1.0.0.nupkg. Você pode testá-lo no Visual Studio abrindo o Package Manager Console e digitando o comando Install-Package MyAssembly.dll -Source "C:\{location_of_your_package}".

Você pode também criar um pacote NuGet a partir de um projeto do Visual Studio. Basta ir para a pasta do projeto (onde está o arquivo .csproj) e rodar o comando nuget spec. O arquivo .nuspec vai ser criado obtendo os tokens de id, versão, autor e descrição do arquivo AssemblyInfo.cs do projeto. Depois o comando nuget pack MyProject.csproj cria o pacote completo.

Para criar um pacote complexo que contenha as pastas lib, content e tools, você precisa criar seu pacote manualmente com o comando nuget spec, editar o arquivo .nuspec como desejado, adicionar os arquivos nas pastas e criar o pacote com nuget pack YourPackage.nuspec.

Com seu pacote pronto, você vai publicá-lo no NuGet. Com a API Key gerada no site do NuGet, você deve primeiro rodar o comando NuGet SetApiKey Your-API-Key. Depois, a publicação é feita com NuGet Push YourPackage.nupkg.

A outra opção para criar e publicar um pacote é usando o programa NuGet Package Explorer. Essa ferramenta permite que você crie o manifesto com um editor gráfico, adicione arquivos nas pastas lib, content e tools e publique o pacote para o NuGet com 1 clique. Você pode também abrir pacotes, tanto locais quanto do feed, para explorar o conteúdo.

Preparando Um Repositório De Pacotes

Por padrão, o Visual Studio configura o repositório oficial do NuGet para obter pacotes. Você pode adicionar repositórios adicionais, tanto locais quanto remotos.

Para criar um repositório local, você vai em Tools > Library Package Manager > Package Manager Settings. Na aba Package Source, a seguinte tela é mostrada:

Depois é só clicar o botão Add, colocar um nome e um caminho. Todos os arquivos .nupkg serão listados na aba Online da janela Manage NuGet Packages e no Package Manager Console, no drop-down Package-source.

Você pode também criar um feed remoto que roda no IIS. Você deve criar uma web application vazia no Visual Studio e instalar o pacote NuGet.Server. Esse pacote adiciona todo o código necessário para a exposição dos seus pacotes como ATOM. Os pacotes dentro da pasta Packages serão disponibilizados (podendo ser configurado via web.config).

É possível habilitar publicações para seu repositório remoto, como se fosse a galeria oficial do NuGet. Para isso basta adicionar a API Key no web.config.

Depois, basta hospedar sua aplicação no IIS e acessar o feed na URL http://{locationofyoursite}/nuget/. Adicionando essa URL no Package Source, é possível instalar pacotes desse repositório normalmente.

---

E isso é tudo 🙂

Obrigado pela leitura e aguarde o próximo post, que será sobre o objetivo Create, configure, and publish a web package.

Até mais!

Leia Mais

Olá pessoal!
Vamos ao objetivo 5.3, Configure a web application for deployment. Esse objetivo cobre como trocar de release para debug, transformar web.config com XSLT, usar SetParameters e configurar o Windows Azure.

Mudando De Release Para Debug

Ao fazer o build de um projeto, você usa uma build configuration. Duas configurações existem por padrão: release e debug.

Em release, o código é otimizado para rodar o mais rápido possível, o que você com certeza deseja no ambiente de produção.

O modo debug é o ideal para o ambiente de desenvolvimento, pois instruções extra são adicionadas no código compilado, permitindo que ela seja debugado.

Além da build configuration, há uma configuração no web.config que diz respeito a compilação. Mudando o valor do atributo debug para false, você desliga o modo de debug:

<configuration>
<system.web>
<compilation debug="true" targetFramework="4.5" />
</system.web>
</configuration>

No Visual Studio, você tem a opção de escolher quais debuggers utilizar no modo debug:

Transformando O Web.Config Com XSLT

No seu arquivo web.config, você guarda vários tipos de configurações como connection strings, app settings customizadas, etc. Esses valores dependem do ambiente que a aplicação está rodando. Você não pode fazer o deploy de uma aplicação com a connection string do seu banco local, por exemplo. Fazer as alterações manualmente, além de levar tempo, é suscetível a erros.

Aí entra o web.config transformation syntax. Com ele você define um XML que descreve as mudanças a serem feitas no web.config ao mudar de debug para release.

Ao criar uma aplicação ASP.NET MVC, os arquivos de transformação são criados automaticamente:

As transformações trabalham com a sintaxe do XML-Document-Transform. Segue um exemplo de arquivo de transformação que muda a connection string e configura o customErrors:

Você começa especificando o namespace para o arquivo de transformação. Depois, com os atributos xdt:Transform e xdt:Locator, você configura como os elementos devem ser encontrados e o que acontece quando isso acontecer. Nesse exemplo, apenas mudamos a connection string, mas o elemento customErrors é completamente substituído.

Para o atributo Locator, você pode usar os valores Match, XPath e Condition. A explicação detalhada do funcionamento deles pode ser vista aqui. Para o atributo Transform, os possíveis valores são: Insert, InsertBefore, InsertAfter, Remove, RemoveAll, RemoveAttributes e SetAttributes.

Usando SetParameters Para Preparar Um IIS App Pool

A web.config transformation é feita em tempo de compilação. Isso é bom quando você sabe em quais ambientes a aplicação será publicada.

Com Web Deploy, porém, você tem outra opção: parametrização. Com ela você pode parametrizar valores em tempo de instalação, facilitando a distribuição de um pacote para vários lugares.

Um pacote Web Deploy cria alguns arquivos para você, como o {nome do projeto}.zip, que é o pacote Web Deploy, e o {nome do projeto}.deploy.cmd, que permite que você faça o deploy da linha de comando. Há também o arquivo {nome do projeto}.SetParameters.xml, que tem uma série de valores que o MSDeploy.exe usa para fazer o deploy da aplicação. Esse arquivo é gerado dinamicamente, obtendo todas as configurações do seu projeto, como as connection strings do web.config.

A parametrização é feita quando você adiciona um arquivo Parameters.xml para o pacote Web Deploy. Nesse arquivo, você indica o arquivo que quer modificar, quais variáveis serão alteradas e um valor padrão para elas. Na instalação do pacote via IIS Manager, esses valores serão pedidos para o usuário digitar.

Segue um exemplo de uma seção de um web.config abaixo de system.ServiceModel:

O seguinte Parameters.xml pode ser usado:

Segue a explicação de alguns atributos importantes:

• name: o nome que é mostrado no IIS Manager;
• description: a descrição que é mostrada no IIS Manager;
• defaultValue: o valor que é pré-carregado no input;
• scope: uma expressão regular que mostra os arquivos que o parâmetro se aplica;
• kind: especifica o tipo do recurso na qual o parâmetro será aplicado (XmlFile ou TextFile);
• match: no caso de XmlFile, um XPath que seleciona o elemento que será alterado.

Caso você esteja fazendo o deploy pela linha de comando, você pode usar as opções declareParamFile and setParamFile para especificar os arquivos Parameters.xml e SetParameters.xml:

msdeploy.exe -verb:sync -source:apphostconfig="default web site/application"
-dest:archivedir="C:\packages\application" -declareParamFile="C:\source\application\
deployment\declareParamsFile.xml"

msdeploy.exe -verb:sync -dest:apphostconfig="default web site/application"
-source:archivedir="C:\packages\application" -setParamFile="C:\source\application\
deployment\setParamsFile.xml"

Por último, caso você não queira alterar o arquivo SetParameters.xml na mão em um processo de build por exemplo, existe uma task do MSBuild chamada XmlPoke que pode automatizar isso.

Para o exame, lembre-se do seguinte: web.config transformation é feita em tempo de compilação, enquanto parametrização em tempo de instalação.

Configurando O Windows Azure

Um projeto Cloud tem dois arquivos de configuração: ServiceConfiguration.Cloud.cscfg e ServiceConfiguration.Local.cscfg. O arquivo Local tem valores para o Windows Azure Emulator, enquando o Cloud tem os valores que serão usados no deploy para o Azure.

Nesses arquivos você pode configurar o número de instâncias para cada role, quaisquer app settings customizadas, thumbprints para certificados, VPNs no caso de máquinas virtuais (VM), etc.

Ao criar um projeto Cloud com uma web role e uma worker role, o seguinte arquivo de configuração é criado:

O elemento Role, além de especificar o nome da sua role, pode também ter o atributo vmName para ser usado como o nome o DNS para sua VM.

Dentro do elemento Role há o elemento Instances que indica o número de instâncias da role e o elemento ConfigurationSettings, que é uma coleção chave valor.

Outros elementos que podem ser adicionados são o Certificates e o OsImage:

Depois do elemento Roles, você pode especificar o elemento NetworkConfiguration. Essa seção descreve os valores de DNS e VPN. Um exemplo de configuração:

---

Chegamos ao final desse objetivo 🙂 Faltam apenas 3!

Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo Manage packages by using NuGet.

Até mais!

Leia Mais

Olá pessoal, tudo bem?
Vamos ao objetivo Choose a deployment strategy for a Windows Azure web application, que fala de conceitos de deploy voltados para o Azure.

Fazendo In-Place Upgrade E VIP Swap

Em casos de web farm, o Azure oferece 3 maneiras de atualizar sua aplicação: deletando e redeployando, In-Place Upgrade e VIP Swap.

Deletar seu cloud service e redeployar é fácil, mas requer um downtime para seu serviço. Você deve usar essa opção em casos de mudança de número de endpoints, porta, firewall, certificados, etc.

In-Place Upgrade

Para entender o In-Place Upgrade, é necessário entender os conceitos de Upgrade Domain e Fault Domain. Upgrade Domain é uma unidade lógica da sua aplicação, enquanto Fault Domain é uma unidade física.

Vamos supor que você precisa de 5 instâncias para sua aplicação. Automaticamente (isso não é controlável por você), o Azure vai distribuir cada instância entre o número de Upgrade Domains que você configurou no atributo upgradeDomainCount no arquivo Service Definition (valor padrão: 5, valor máximo: 20). Na hora do deploy da sua aplicação (In-Place Upgrade), o Azure atualiza um Upgrade Domain por vez, evitando downtime para o seu serviço.

Fault Domain, também automaticamente atribuído pelo Azure, é quando as instâncias são separadas em servidores físicos diferentes. Somente com 2 Fault Domains o Azure garante o SLA de 99.95%.

Para entender melhor esses conceitos, recomendo esse post: https://blog.tompawlak.org/windows-azure-fault-and-upgrade-domain. Vamos em frente.

Você tem 2 opções para disparar um deploy In-Place Upgrade. A primeira é diretamente pelo portal do Azure, fazendo o upload do pacote direto para seu Cloud Service. A outra é pelo Visual Studio, que necessita de um certificado emitido pelo portal para identificação:

Como dito antes, ao fazer um deploy, o Azure vai atualizar seus Upgrade Domains um por um. Então se você tiver mais do que 2 Upgrade Domains, no momento do deploy eles terão diferentes versões da sua aplicação. Isso pode ser um problema caso haja alterações no schema do banco de dados, por exemplo. Para resolver isso, existe uma técnica de deploy chamada VIP Swap.

VIP Swap

Um Cloud Service no Azure tem 2 ambientes: produção e staging. Ambos têm o mesmo hardware, diferenciando apenas o virtual IP (VIP) e a URL do serviço.

O VIP Swap é quando o VIP e a URL dos ambientes de produção e staging são trocados. Isso significa que você pode fazer o deploy da nova versão da sua aplicação no ambiente de staging, testá-la, e promovê-la para produção instantaneamente com o VIP Swap. Depois, você pode deletar o ambiente de staging para evitar custos.

Isso permite que você atualize todas as instâncias de uma só vez, evitando diferentes versões em produção ao mesmo tempo. Ainda vai haver requests que estão apontando para a versão antiga, mas o problema é bastante minimizado com essa técnica.

Para realizar um VIP Swap, primeiro você precisa fazer o upload da nova versão da aplicação para o ambiente de staging, seja por deletando o serviço e redeployando ou via In-Place Upgrade. Depois de validado, basta ir no portal do Azure no ambiente de staging e clicar no botão Swap:

Criando E Configurando Input E Internal Endpoints

Há dois tipos de endpoints para suas instâncias de Cloud Services: Input Endpoint e Internal Endpoint. Um Input Endpoint é usado para conexões externas (internet) feitas via HTTP, HTTPS ou TCP. Internal Endpoints são usados para conexões internas entre as instâncias do Cloud Services via HTTP ou TCP.

Seu Cloud Service pode ter 25 endpoints de cada tipo, que podem ser espalhados entre as roles. Quando você cria um projeto Cloud com uma web role e uma worker role, o arquivo ServiceDefinition.csdef fica assim:

A web role por padrão vem com um input endpoint na porta 80, padrão para conexões HTTP. A worker role não tem endpoints por padrão, mas você pode adicionar um input endpoint sem problemas:

<Endpoints>
<InputEndpoint name="WorkerRoleInput" port="8080" protocol="http" localPort="8080"/>
</Endpoints>

Agora o load balancer encaminha os requests na porta 8080 para a worker role. Dentro dela, você pode usar um HttpListener para lidar com os requests:

Um ponto importante é que no Windows Azure emulator, as portas são remapeadas para a próxima porta disponível, para evitar conflitos. Isso significa que a porta 80 será remapeada para 81 e a 8080 para 8081.

Você também pode editar as configurações de endpoint diretamente do Visual Studio, clicando duas vezes no nome da role no projeto Cloud Services:

Ao selecionar o tipo do endpoint, há uma terceira opção chamada InstanceInputEndpoint. Nela você pode especificar um range de portas externas que são mapeadas para uma única porta. A configuração fica assim:

<InstanceInputEndpoint name="Endpoint2" localPort="1000" protocol="tcp">
<AllocatePublicPortFrom>
<FixedPortRange min="10016" max="10020"/>
</AllocatePublicPortFrom>
</InstanceInputEndpoint>

O elemento InstanceInputEndpoint especifica a porta local para onde os requests serão direcionados e o protocolo, enquanto o elemento AllocatePublicPortFrom especifica o range de portas públicas que serão ouvidas.

Especificando Configurações Do Sistema Operacional

Quando você cria um projeto Cloud Services, há dois arquivos de configuração: o ServiceDefinition.csdef, que especifica as configurações do Cloud Service como um todo, e o ServiceConfiguration.cscfg para configurações específicas das roles, como o número de instâncias, configurações de diagnostics, certificados, etc.

Uma configuração importante para o exame é a especificação da versão do sistema operacional. Ao criar um novo projeto Cloud com uma web role e uma worker role, o arquivo .cscfg fica assim:

O atributo osFamily é o número da família do sistema operacional. A especificação completa das famílias e o suporte de cada uma delas pode ser vista aqui.

O atributo osVersion especifica exatamente a versão do Guest OS em que sua role vai rodar. O valor * significa sempre a última versão. Para colocar uma versão específica, o seguinte formato deve ser utilizado: WA-GUEST-OS-M.m_YYYYMM-nn, onde WA-GUEST-OS é um valor fixo, M.m é o número da versão, YYYY o ano, MM o mês e nn um número sequencial para diferenciar os releases.

---

Terminamos mais um objetivo 🙂

Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo 5.3: Configure a web application for deployment.

Até mais!

Leia Mais

Olá pessoal, tudo bem?
Esse objetivo é o primeiro do tópico Deploying web applications and services, os últimos 20% da certificação. Nesse objetivo vamos ver como fazer o deploy de aplicações web usando XCopy, criar um IIS Install Package, automatizar deploys com TFS ou Build Server e fazer deploy para web farms.

Fazendo Deploy De Aplicações Web Usando XCopy

O jeito mais fácil de fazer o deploy de uma aplicação para um ambiente de produção é manualmente. Seja via FTP ou conexão remota, chamamos de XCopy quando você copia os arquivos da sua máquina local para uma de produção. XCopy, na verdade, é um comando DOS para transferência de vários arquivos ao mesmo tempo. A sintaxe dele é a seguinte:

xcopy /I /S /E <source path> <destination path>

A opção /I diz que você copiando uma pasta, a /S que você quer copiar todos os subdiretórios e a /E que as subpastas devem ser copiadas mesmo que vazias. Há também a opção /d, que indica que somente os arquivos novos atualizados ou novos devem ser copiados.

Configurando O IIS

Na primeira vez que você copiar os arquivos do seu site para seu servidor, você vai precisar configurá-lo no IIS, que é o servidor de hospedagem para aplicações no Windows. Você precisa dizer ao IIS qual é a pasta do seu site e como ele vai estar disponível para os usuários.

Assumindo que você tenha uma aplicação em C:\Development\MyApp e quer movê-la para C:\inetpub\wwwroot\MyApp, o primeiro passo é fazer o XCopy:

xcopy /I /S C:\Development\MyApp C:\inetpub\wwwroot\MyApp

Para fazer a configuração no IIS, você abre o IIS Manager e a opção de adicionar um website. Você precisa dar um nome e apontar a localização da pasta (nesse caso, C:\inetpub\wwwroot\MyApp). Normalmente também você deve colocar um host name para o IIS mapear os requests HTTP na porta 80.

No exemplo abaixo, alteramos a porta para 81 e deixamos o host name em branco, para podermos acessar o site somente pela porta. A configuração fica assim:

Acessando http://localhost:81 no browser, o ISS já consegue mapear o request e mandá-lo para a aplicação.

Preparando Um Website Para Deploy

Quando os arquivos são atualizados, o IIS detecta as modificações e começa a atualizar o site. Isso gera erros nos requests feitos enquanto a aplicação está parcialmente atualizada.

Para evitar que os usuários vejam uma tela de erro, você pode colocar um arquivo com o nome App_offline.htm no root do website. O IIS então vai mostrar esse HTML ao invés da mensagem de erro. Após a atualização de todos os arquivos, você deve apagar esse arquivos para o IIS voltar a processar os requests.

Outro ponto é que o App Domain pode restartar várias vezes enquanto os arquivos estão sendo atualizados. Você pode configurar o atributo waitChangeNotification no seu web.config para especificar o número de segundos de espera antes que o App Domain restarte:

Ferramental Para Deploys XCopy

Usar o XCopy pela linha de comando não é a melhor maneira de você copiar seus arquivos. O Visual Studio oferece algumas ferramentas para auxiliar o processo de deploy, e vamos analisar uma delas agora: a Copy Website Tool. Nela você pode:

• Copiar arquivos de código para o target especificado;
• Copiar arquivos usando os protocolos suportados: IIS local, IIS remoto, FTP e HTTP (comente com FrontPage Server Extensions);
• Escolher quais arquivos quer sincronizar do seu código para o target;
• Automaticamente copiar o arquivo App_offline.htm quando o deploy começar e removê-lo quando terminar.

Criando Um IIS Install Package

Lançado em 2009, o Web Deploy permite que você crie um pacote de deploy que além dos arquivos do seu site contém configurações de banco de dados, IIS, registro, assemblies para carregar no GAC, etc.

O Web Deployment Framework simplifica o processo podendo ser utilizado via Visual Studio, IIS, prompt de comando e Windows PowerShell. Também ajuda em ambientes complexos como web farm, onde você sincroniza diferentes servidores usando o Web Deploy.

Para o exame, lembre-se: Web Deployment Framework é a ferramenta ideal para deploys complexos.

Automatizando Deploys Com TFS Ou Build Server

Por motivos fora do escopo do exame, você deve saber como automatizar o deploy de uma aplicação com TFS ou Build Server. É importante conhecer os conceitos por trás disso, como Continuous Integration e Continuous Deployment com testes de unidade e integração, mas estes não são prováveis de estarem no exame.

Você pode automatizar o deploy de uma aplicação no Azure de forma bem fácil. Há uma opção “Set up deployment from source control” que implementa o conceito de Continuous Deployment: cada check-in no controle de versão dispara um deploy automaticamente. O repositório pode ser TFS ou Git.

É possível também fazer isso on-premises com TFS. Você pode buildar sua aplicação via linha de comando com MSBuild da seguinte forma:

MSBuild /target:Publish /p:PublishDir=\\myserver\drops\

Depois, editando a Build Definition no TFS, você pode adicionar um comando de Publish para publicar o pacote no Azure.

É importante entender que existem duas ferramentas TFS: uma on-premises e uma na nuvem, atualmente chamada VSTS.

Fazendo Deploys Para Web Farms

Para essa seção, você deve entender os conceitos de scale up e scale out.

Scale up é quando você aumenta a capacidade do seu hardware para fazer uma melhora de performance na sua aplicação. Isso é feito quando você coloca mais memória RAM, troca de processador ou coloca um SSD no lugar do seu HD. Porém, além de ser caro, melhoras no hardware tem o limite do próprio hardware.

Aí entra o conceito de scale out, onde você usa múltiplos servidores para hospedar sua aplicação ao invés de melhorar um. Juntos, eles formam o que chamamos de web farm ou ambiente distribuído. Um load balancer é necessário para “espalhar” os requests entre os servidores da forma mais eficiente possível.

Porém, um trabalho extra é necessário para sua aplicação poder ser hospedada numa web farm. Normalmente você configura 1 servidor, depois cria as aplicações no IIS de todos os outros com exatamente as mesmas configurações.

Outro ponto de preocupação é a session, que são dados do usuário gravados na memória. Com web farm, requests subsequentes de um mesmo usuário podem cair em várias máquinas diferentes, o que pode impossibilitar o uso de session. Para resolver esse problema, você precisa mover os dados da sessão para uma máquina externa ou até um banco de dados. Há 4 tipos de session states:

• InProc: valor padrão, onde os dados da session são gravados na memória;
• StateServer: guarda os dados da session em um processo separado chamado ASP.NET state service;
• SQLServer: guarda os dados da session num banco de dados SQL Server;
• Off: desabilita a session

Você também pode escolher ativar session affinity, onde todos os requests de um usuário vão cair no mesmo servidor, garantindo que os dados da session estarão na memória. Porém, nem todos os load balancers suportam isso.

---

Chegamos ao final desse objetivo.

Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo Choose a deployment strategy for a Windows Azure web application.

Até mais!

Leia Mais

Olá pessoal!
O objetivo Consume Web API web services, o último sobre Web API, cobre como consumir serviços Web API usando HttpClient e mandar e receber requests em formatos diferentes.

Consumindo Serviços Web API

A classe HttpClient é usada para fazer requisições e trabalhar com o retorno. Para os exemplos dessa seção, vamos utilizar o seguinte método como setup:

Vamos passar pelos 4 métodos HTTP mais comuns: Get, Post, Put e Delete, além de aprender como lidar com exceções.

HttpGet

Para fazer um Get, o método GetAsync do HttpClient é usado. Não há um equivalente síncrono, somente o método Async.
Após o retorno da operação, a propriedade IsSuccessStatusCode é populada. O código ficaria assim:

O método ReadAsAsync é um método de extensão, implementado no assembly System.Net.Http.Formatting.

HttpPost

Para executar um Post, você pode usar os métodos PostAsync e PostAsJsonAsync, que simplifica as coisas caso o Content-Type seja JSON. A implementação é bem simples:

HttpPut

Um Put pode ser feito praticamente da mesma forma que um Post. Há os métodos PutAsync e PutAsJsonAsync:

HtpDelete

O método DeleteAsync faz um Delete. O método apenas recebe uma string com a URL, já com o identificador do item a ser deletado:

Exceções

Exceções podem ocorrer ao chamar um serviço Web API.

Nesses casos, porém, na chamada ao método que fez a operação (GetAsync, PostAsync, etc.), a exceção não é automaticamente lançada. Você deve explicitamente chamar o método EnsureSuccessStatusCode para que isso aconteça.

Veja os seguintes trechos de código. O primeiro não lança a exceção, enquanto o segundo faz:

Mandando E Recebendo Requests Em Formatos Diferentes

Há algumas opções em relação aos formatos aceitos pelo framework Web API. Isso inclui application/xml, text/html, image/png, application/json, etc.

Esses valores são retornados no header Content-Type dos responses, indicando o tipo do retorno. Eles também podem ser usados no header Accept para que o client especifique o tipo do retorno que ele quer receber. Nesses headers, múltiplos valores são aceitos sendo separados por vírgula.

É possível também implementar formatos customizados. Você pode fazer isso herdando das classes MediaTypeFormatter ou BufferedMediaTypeFormatter. A principal diferença entre elas é MediaTypeFormatter suporta a leitura assíncrona, enquanto BufferedMediaTypeFormatter suporta somente leituras síncronas.

Primeiro, você deve herdar da classe desejada e adicionar o media type a ser suportado na coleção SupportedMediaTypes:

Você precisa também adicionar seu formatter customizado no HttpConfiguration: config.Formatters.Add(new CustomCsvFormatter());.

Depois, você implementa sua lógica na classe criada. As propriedades CanWriteType e CanReadType devem ser sobrescritas, indicando se o tipo pode ser serializado e desserializado. O método WriteToStream também deve ser implementado e se o formatter suportar desserialização (CanReadType true), o método ReadFromStream precisa ser implementado.

Detalhes sobre a implementação não cairão no exame, mas é bom seguir o exemplo da documentação para ter uma ideia melhor de como implementar um formatter customizado: http://www.asp.net/web-api/overview/formats-and-model-binding/media-formatters.

---

E encerramos o capítulo sobre Web API 😀

O próximo post será sobre o objetivo 5.1, Design a deployment strategy. Esse é o primeiro objetivo do último tópico da certificação.

Obrigado e até mais!

Leia Mais

Olá pessoal!
O objetivo 4.4 da certificação Microsoft 70-487, Host and manage a Web API, trata dos principais mecanismos de hospedagem de um serviço Web API, como self-hosting, IIS e Azure. Também mostra como limitar o tamanho das mensagens recebidas e configurar a hospedagem para streaming. Vamos lá?

Web API Self-Hosting

Para fazer o self-hosting de uma Web API, você pode usar qualquer template de projeto que crie um executável, como Windows Service, Windows Forms Application, Console Application, etc.

Com o projeto criado, você deve instalar o framework de self-hosting via NuGet com o pacote Microsoft ASP.NET Web API Self Host e referenciar os assemblies System.Web.Http e System.Web.Http.SelfHost:

Depois, há dois passos essenciais: instanciar as classes HttpSelfHostConfiguration e HttpSelfHostServer. O código fica assim:

A primeira verificação se MyWebApi.Controllers.ValuesController é null serve para o framework de self-hosting carregar os controllers do seu projeto Web API. Isso somente é necessário quando os controllers estão num assembly separado.

A classe HttpSelfHostConfiguration recebe o endereço base de onde o serviço vai ser acessado. Um ponto importante aqui é que as rotas precisam ser configuradas diretamente na propriedade Routes.

Por último, a classe HttpSelfHostServer é instanciada recebendo a configuração criada anteriormente. O método OpenAsync toma conta de abrir o servidor com as configurações passadas.

Web API IIS Hosting

Hospedar uma Web API no IIS não tem nada diferente de outras aplicações web.

Você pode primeiro criar uma application pool, conforme abaixo:

Depois, criar um novo website embaixo do nodo Sites ou adicionar uma aplicação ou diretório virtual:

Com tudo isso no lugar, sua aplicação deve estar hospedada com sucesso.

Web API Windows Azure Hosting

Essa é uma seção conceitual para as 3 formas de hospedar uma Web API no Azure. São elas:

• Windows Azure Websites: a opção mais rápida. Com Azure Websites você não se importa com a máquina que está hospedando seu serviço, apesar de poder escalar sua aplicação facilmente;
• Windows Azure Cloud Services: Cloud Services oferecem um controle maior. Você tem mais tamanhos de instância para escolher e pode criar uma arquitetura mais complexa, como uma Web API numa Web Role se comunicando via queue com uma Worker Role, por exemplo. Você pode também configurar o IIS e outras configurações da máquina quando a role começar. Consegue também se conectar via remote com a máquina;
• Windows Azure Virtual Machines (VMs): usar VMs no Azure te dá controle completo. Você precisa gerenciar sua máquina inteira, de atualizações até configurações.

Fazer o deploy de uma Web API para o Azure Websites ou Cloud Services é bem simples usando o Visual Studio. Isso será coberto com mais detalhes no capítulo 5.

Limitando O Tamanho Das Mensagens

Ao hospedar sua Web API, você com certeza gostaria de limitar o tamanho dos requests para que seu servidor não sofra de ataques DDoS.

Usando self-hosting, você pode fazer isso setando as propriedades MaxReceivedMessageSize e MaxBufferSize do objeto HttpSelfHostConfiguration:

var config = new HttpSelfHostConfiguration(baseAddress);
config.MaxReceivedMessageSize = 1024;
config.MaxBufferSize = 1024;

Hospedando no IIS, isso é possível pela configuração do atributo maxRequestLength no web.config:

<httpRuntime maxRequestLength="1024" />

Configurando Streaming

Às vezes você quer que seu serviço Web API receba arquivos grandes, como algum upload de imagens ou vídeos. Nesses casos, é importante configurar sua Web API para usar streaming ao invés de buffer, já que bufferizar arquivos grandes consome muita memória.

Hospedando sua aplicação no IIS, você consegue implementar sua lógica se usar buffer ou streaming herdando a classe WebHostBufferPolicySelector, a única que implementa a interface IHostBufferPolicySelector, e sobrescrevendo o método UseBufferedInputStream. Por exemplo, você pode habilitar streaming apenas para um controller específico:

Depois disso, você deve configurar o HttpConfiguration para usar sua implementação: config.Services.Replace(typeof(IHostBufferPolicySelector), new StreamingPolicySelector());.

Por último, você precisa configurar as propriedades do ASP.NET como maxAllowedContentLength e maxRequestLength no web.config para que o IIS não rejeite os requests grandes:

Para self-hosting, você só consegue habilitar streaming para todos os controllers. Você faz isso configurando a propriedade TransferMode no objeto HttpSelfHostConfiguration:

// somente requests
selfHostConf.TransferMode = TransferMode.StreamedRequest;
// somente responses
selfHostConf.TransferMode = TransferMode.StreamedResponse;
// ambos
selfHostConf.TransferMode = TransferMode.Streamed;

---

Isso é tudo para esse objetivo 🙂

Obrigado pela leitura e fique de olho no próximo post, que será o último objetivo sobre Web API: Consume Web API web services.

Até mais!

Leia Mais

Olá pessoal!
O objetivo 4.3 da certificação 70-487, Secure a Web API, trata de forma bem completa sobre as diferentes formas de segurança e autenticação disponíveis para serviços Web API.

Esse objetivo cobre como 1) autenticar e autorizar usuários, 2) implementar a autenticação HTTP Basic com SSL, 3) implementar Windows Authentication, 4) prevenir cross-site request forgery, 5) habilitar requests cross domain e 6) implementar e extender authorization filters.

Autenticar E Autorizar Usuários

Essa seção apenas explica os conceitos de autenticação e autorização.

Autenticação é o processo de identificação do usuário, geralmente por um nome de usuário e senha. O framework da Web API tem uma série de ferramentas para implementação desse processo, o que vamos ver logo mais.

Autorização é o processo que define quais ações o usuário pode fazer no sistema. Por exemplo, você pode permitir que usuários anônimos façam apenas consultas, usuários autenticados façam inserções e usuários administrativos façam atualizações.

Implementando Autenticação HTTP Basic

HTTP Basic é a forma mais simples e fácil de implementar um mecanismo de autenticação. É um formato conhecido e maduro, suportado pela maioria dos browsers e nativamente suportado pelo IIS. A principal desvantagem é que as credenciais são transmitidas em plain text nos headers do request, tornando-se vulnerável a interceptores. Também não há como fazer logout explicitamente a não ser que a sessão do browser se encerre.

O fluxo com HTTP Basic é assim:

Um client faz um request. Se o serviço necessitar autenticação, o server retorna o status code 401 (unauthorized) com o seguinte header: WWW-Authenticate: Basic realm="Realm Name". Esse header especifica que o server suporta a autenticação Basic no domínio especificado (realm).

O client, ao receber um response 401, faz outro request com o header de autenticação. A construção do header começa com o nome de usuário e a senha concatenados por um dois-pontos. Por exemplo, caso o nome de usuário seja JohnQPublic e a senha !*MyPa55w0rd*!, o valor seria JohnQPublic:!*MyPa55w0rd*!. Em seguida esse valor seria encodado por Base64, resultando na string Sm9oblFQdWJsaWM6ISpNeVBhNTV3MHJkKiE=. Por fim, a palavra Basic é adicionada antes dessa string e enviada no header Authorization: Authorization: Basic Sm9oblFQdWJsaWM6ISpNeVBhNTV3MHJkKiE=.

Um ponto importante é que o nome de usuário e senha, apesar de encodados em Base64, não estão encriptados. Qualquer interceptor que tiver acesso aos headers do request vai conseguir decifrar dados sensíveis do usuário facilmente. Por isso, a autenticação Basic não é segura a não ser que feita por HTTPS, onde todo o request é criptografado. Para o exame (e para a vida real), lembre-se: nunca use autenticação Basic sem SSL.

Habilitando SSL

Como a autenticação Basic não deve ser utilizada sem SSL, você deve saber como forçar uma conexão HTTPS para Web API.

Se você viu como implementar Action Filters no objetivo anterior, vai reconhecer como vamos fazer isso agora. De forma simples, basta implementar a classe AuthorizationFilterAttribute e sobrescrever o método OnAuthorization com uma validação. Segue um exemplo:

Depois disso, você deve decorar os controllers desejados com esse atributo ou registrá-lo globalmente no HttpConfiguration.

Não sei se cairá no exame, mas saiba que há uma ferramenta chamada MakeCert.exe para gerar certificados SSL para testes.

Implementando Windows Authentication

Windows Authentication é um processo onde os usuários podem se autenticar pelo seu login no Windows, Kerberos ou NTLM. É ideal para aplicações intranet que serão acessadas somente de dentro do mesmo domínio, em uma empresa por exemplo. Obviamente, não é recomendada para cenários onde usuários “anônimos” vão acessar sua API.

Por ser nativamente suportada pelo IIS, implementar essa autenticação é bem simples. Basta configurar a propriedade Mode do elemento Authentication para “Windows” no web.config, como a seguir:

<system.web>
<authentication mode="Windows" />
</system.web>

Se o client for diretamente um browser, este precisa dar suporte ao esquema de autenticação Negotiation. Não há muito o que se preocupar pois todos os browsers populares têm esse suporte.
Caso seja uma aplicação .NET, a classe HttpClient deve ser usada para fazer o request (como sempre). A única modificação é que ela deve ser instanciada com um HttpClientHandler, que pode ser obtido da seguinte maneira:

HttpClientHandler clientHandler = new HttpClientHandler
{
UseDefaultCredentials = true
};

Prevenindo Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF ou XSRF) é uma forma bastante utilizada por atacantes para acessarem recursos disponíveis para usuários autenticados.

Vamos supor que você está logado no portal do Azure e, no mesmo browser, recebe um e-mail dizendo que você tem desconto de 50% para novos serviços no Azure. Ao clicar no link do e-mail, você é direcionado para a página https://manage.windowsazure.com/api/DeleteAllData sem perceber. É claro que essa página não existe no portal, mas se existisse, você estaria em sérios problemas.

Resumidamente, um ataque XSRF acontece quando você está autenticado em algum sistema e um atacante se aproveita disso para executar alguma ação. Seu sistema está vulnerável a ataques XSFR se você usa um mecanismo de autenticação que mantém o usuário logado (baseado em cookies) ou quando você permite requests cross domain. A autenticação Basic também é vulnerável pois o browser normalmente armazena seu token de autenticação para evitar que o usuário digite o usuário e senha a cada request.

Para se proteger de ataques XSRF, há uma solução pronta em MVC e que os mesmos princípios podem ser aplicados na Web API.

Usando o método Html.AntiForgeryToken na view e o atributo ValidateAntiForgeryToken na action, o MVC primeiro renderiza um input hidden na tela assim: <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />. Esse valor é gerado randomicamente e também é colocado num cookie passado para o usuário. Ao fazer um post, por exemplo, o MVC valida se o valor do cookie e o do form data são iguais. Isso é seguro pois o atacante não vai saber o valor do cookie para forjar um request válido.

Para Web API, como dito, o princípio pode ser aplicado. Você manda um valor no cookie e no HTML e depois garante que eles são o mesmo. Você pode mandar o token antiforgery usando o mesmo método Html.AntiForgeryToken.

Para validar o token na Web API, você deve obter o token do cookie; obter do form data; passar ambos para o método AntiForgery.Validate e retornar um response Unauthorized caso a validação falhe. O código ficaria assim:

Habilitando Requests Cross Domain

Por padrão, os browsers proíbem requests cross domain, ou seja, para domínios diferentes do atual. Por exemplo, se você está no site http://www.contoso.com, você não pode fazer uma requisição AJAX para http://www.someotherwebsite.com. Você também não pode fazer requests para o seu domínio com outro protocolo (HTTP ao invés de HTTPS) ou para outra porta. Isso existe para evitar ataques XSRF, já que a maioria das autenticações funcionam por cookie.

Porém você pode querer que sua API seja consumida por vários clients, e isso se tornaria um problema. Isso se chama CORS (cross origin resource sharing), e você pode habilitá-lo facilmente no arquivo web.config:

Isso adiciona um header nos responses, indicando que CORS está habilitado. Com isso, qualquer site pode fazer requisições para sua API, o que pode não ser desejado.

Para resolver esse problema, a Microsoft criou um pacote NuGet chamado Microsoft.AspNet.WebApi.Cors. Após a instalação, você tem um método de extensão no objeto HttpConfiguration: config.EnableCors();.

Chamando esse método no método WebApiConfig.Register, você habilita o suporte a CORS na sua aplicação. Agora você pode adicionar o atributo EnableCors para controllers e actions assim:

Nesse caso, você habilitou CORS somente para esse método na URL especificada em origins.

Implementando E Extendendo Authorization Filters

A Web API oferece o atributo AuthorizeAttribute que por padrão garante que os usuários acessando esse controller ou action estão autenticados e têm as roles necessárias, se especificadas.

Você pode estender a classe AuthorizeAttribute e sobrescrever o método IsAuthorized para implementar sua própria lógica. O exemplo a seguir faz uma implementação de black list, ou seja, usuários com as roles especificadas não podem acessar a action:

Você também pode estender a classe AuthorizationFilterAttribute ou implementar a interface IAuthorizationFilter para realizar alguma lógica customizada. As diferenças entre elas são as seguintes:

• AuthorizeAttribute: usada para implementar lógica de autorização baseada no usuário e nas roles;
• AuthorizationFilterAttribute: usada para implementar lógica síncrona de autorização que não está baseada no usuário e nas roles (por exemplo, forçar HTTPS);
• IAuthorizationFilter: usada para implementar lógica assíncrona de autorização que não está baseada no usuário e nas roles.

---

Obrigado pela leitura de mais um objetivo!
O próximo post será sobre o objetivo 4.4, Host and manage a Web API.

Até lá!

Leia Mais