Olá pessoal, tudo bem?
Recentemente fiz a migração do projeto que estou trabalhando atualmente na Lambda3 do ASP.NET Core RC 1 para
RC 2. Foram feitas muitas mudanças significativas no framework, principalmente no ferramental do .NET Core.
Nesse post vou indicar as principais mudanças que você vai precisar fazer para realizar a migração e contar
algumas experiências dessa transição. (mais…)
Olá pessoal, tudo bem?
O último passo para conquistar meu objetivo de me tornar MCSD em Web Applications era a certificação 70-486: Developing ASP.NET MVC Web Applications. Fui aprovado com 768 pontos e consegui minha certificação!
Nesse post, assim como nas provas 70-487 e 70-480, vou contar algumas dicas e impressões do exame.
Olá pessoal, tudo bem?
Continuando com o meu objetivo de me tornar MCSD em Web Applications, fiz a prova da certificação 70-480: Programming in HTML5 with JavaScript and CSS3. Fui aprovado com 968 pontos 🙂
Nesse post vou contar as minhas impressões da prova, como se preparar para o exame e algumas dicas finais.
(mais…)
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…)
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á?
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
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.
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.
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.
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:
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!
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.
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.
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.
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.
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:
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.
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"
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.
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á!
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á?
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:
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.
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.
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:
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.
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.
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.
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!
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.
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:
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.
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:
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.
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!
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.
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.
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.
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:
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.
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!
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.
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.
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.
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:
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:
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.
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.
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:
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!