IIS: efetuando deploy no Windows 10 e IIS 10

Não é mais recomendado usar o protocolo FTP para transferência de arquivos por conta de suas vulnerabilidades, tão pouco para publicar aplicações que carregam consigo códígos e senhas altamente sensíveis. Então, a plataforma do Visual Studio e o IIS fornecem um meio muito mais rápido e seguro de subir publicações para aos ambientes de testes e produção chamado Web Deploy, neste artigo vou mostrar como configurar e publicar a um site a partir do Visual Studio 2017.

Web Platform Installer

Para facilitar a Instaleinstalação de ferramentas no IIS é preciso instalar a Web Platform Installer, para isso acesse o site https://www.microsoft.com/web/downloads/platform.aspx.

Clique em Install this extension e faça download do pacote para IIS.

Excute o instalador, e clique em I accept the terms in the License Agreement e em seguida em Install. Se o instalador pedir para executar como administrador, clique em Sim.

Aguarde o término da instalação e clique em Finish.

Agora no IIS, em gerenciamento, teremos a opção do Web Platform Installer.

Instale Web Deploy 3.6

Abra o IIS, e clique duas vezes em Web Platform Installer e pesquise por Web Deploy 3.6. Clique em Adicionar e então em Instalar.

Em Pré-Requisitos, clique em Aceito.

Aguarde o download e instalação.

Ao terminar a instalação, clique em Concluir.

Obs.: Talvez seja preciso verificar algumas coisas antes de publicar uma aplicação, segue uma lista de procedimentos que talvez sejam necessários:

  • Reiniciar os serviços do IIS,
  • Reiniciar o Site,
  • Reiniciar o Serviço de Gerenciamento da Web (wmsvc),
  • Desativar o Firewall ou liberar a porta 8172,
  • Fechar e abrir novamente a aba de Profile de publicação no Visual Studio.

Adicione o host deploy.sitelocal.com

Para facilitar o trabalho de depuração com a aplicação e simular um acesso direto pela internet, configure o host e adicione o site no IIS com a URL deploy.sitelocal.com seguindo este artigo.

Crie uma aplicação ASP.NET MVC

No Visual Studio, crie uma solução chamada DeploySite, e adicione um projeto do tipo ASP.NET Web Application chamado Deploy.Site. O nível de detalhes e complexidade não importa, pois só será preciso para publicação, eu criei um aplicação MVC e deixei pronta no GitHub, caso não queira nem se dar ao trabalho e só fazer um clone.

https://github.com/tiagopariz/DeploySite

Crie o perfil de publicação

Após criar e carregar a aplicação, vamos usar nosso servidor de deploy para subir nosso site. Para isso, clique com o botão direito sobre o projeto e clique com o esquerdo em Publish.

Em Pick a publish target, clique em IIS, FTP, etc e em seguida em Create Profile.

Preencha os campos de conexão, com os dados:

  • Server: O endereço do servidor de deploy, que pode não ser o mesmo do host, pois um servidor com IIS pode ter vários hosts, no nosso caso, é http://localhost.
  • Site name: o nome do site configurado no IIS, no caso deploy.sitelocal.com.
  • Destination URL: o endereço da Internet da aplicação que está sendo publicada, no nosso caso http://deploy.sitelocal.com, este endereço será aberto ao final da publicação.

Clique em Validate Connection para testar a configuração e se estiver tudo ok, clique em Next >.

Em Settings, selecione Release em Configuration e clique em Save.

Ao abrir a aba de publicação, clique em Rename Profile.

Digite o novo nome como DeployReleaseProfile e clique em Save.

Clique em Publish e visualize na janela Output os resultados.

Após a publicação, o site será aberto no navegador.

Dica: instale apenas o Web Deploy

É possível instalar no windows apenas o Web Deploy sem o Web Platform Installer, então para isso, entre no site https://www.iis.net/downloads/microsoft/web-deploy e faça o download do Web Deploy Installer.

Visual Studio: o desafio de hoje é recolher e estrutura da solução sem usar o mouse

Um tarefa muito comum no dia a dia de um programador que usa o Microsoft Visual Studio é recolher todos as pastas da solução para facilitar a navegação pelos arquivos e projetos.

O simples fato de recolher uma estrutura como esta:

Para deixá-la assim:

Sempre foi é preciso largar um pouco o teclado e usar o mouse para clicar no botão Collapse All, pois não há um atalho nativo na IDE, mas seu problemas acabaram! pois é possível configurar um novo atalho, então vamos ao trabalho.

Clique no menu Tools, em seguida em Options.

Em Options, expanda Enviroment e clique em Keyboard, e use Show commands containing para encontrar o comando SolutionExplorer.CollapseAll.

Em Use new shortcut in, selecione Global e em Press shortcut keys pressione a tecla / (barra) e por fim clique em OK.

O atalho ainda tem um problema, pois ele só funciona quando o foco está na janela da solução, mas para contornar isso foi vai ter que decorar as combinação de teclas que trás esta janela para o primeiro plano. Então, tecle CTRL + ALT + L e logo após /, e pronto a solução está recolhida!

Até a próxima.

Visual Studio: abrir a pasta atual do arquivo na solution

Muitas vezes trabalhamos com soluções complexas, com várias dezenas ou centenas de arquivos, e quando precisamos encontrar fisicamente o arquivo no disco ou no projeto, temos que olhar o tooltip da guia e abrir pasta a pasta.

Felizmente, tem uma opção, que não vem marcada por default no Visual Studio que facilita esta navegação. Ao ativar esta opção, a solution já abre a pasta e coloca o foco no arquivo assim que se inicia a trabalhar nele.

Para configurar esta opção, clique no menu Tools, e em seguida em Options, abra o nó Environment e clique em Documents. Deixe marcada a opção Open file using directory of currently active document e clique em OK.

Outro atalho bastante útil é CTRL + , (Control e vírgula), no qual é possível procurar arquivos por nome e referências.

Anote estas duas dicas, pois vão facilitar muito a navegação pela solução no seu dia a dia.

Git: convenção para estrutura de pastas

Desde que comecei trabalhar com repositórios de controle de versão do Git, tenho buscado melhores práticas, tanto para armazenar projetos como versioná-los de forma eficiente. Mas o meu espírito metódico começou perceber que as pessoas e empresas armazenavam coisas muito além dos códigos fontes de seus projetos, criando um verdadeiro ambiente com todas informações e ferramentas usadas centralizadas no mesmo repositório, tornando assim algo que pareça realmente um projeto completo.

Acredito que não há um convenção oficial explicando como a estrutura de pastas deveria ser organizada dentro de um repositório, mas encontrei alguns exemplos, nos quais os desenvolvedores justificam suas escolhas, e estas justificativas fazem muito sentido. Portanto, o melhor modelo, na minha opinião, que encontrei foi este:

A solução de organização apresentada, possui uma lógica bem coerente, mas que não está livre de sugestões, adaptações e críticas:

src

Projetos principais, ou seja, o código fonte do produto. Mas é preciso deixar claro que, quando criamos uma nova solução no Visual Studio, o padrão criado não é este, então, é preciso alguns ajustes nos projetos existentes e a criar novo selecionar a pasta.

core

Assim como temos a pasta src na raíz do repositório, podemos criar superclasses genéricas que podem ser reaproveitadas em outras soluções, para isso, é possível criar uma pasta chamada core e dentro dela ter outras pastas de projeto, como src e tests.

tests

Projetos de testes. Embora os projetos de testes possam estar incluídos na mesma solução, nesta convenção, eles são fisicamente alocados em um pasta própria. Mas cuidado para não confundir esta pasta física com as Solution folders, que são diretórios que apenas existem dentro da estrutura de projetos do Visual Studio.

tools

Ferramentas e utilitários em geral. Este diretório serve como apoio ao desenvolvimento do projeto, podendo centralizar softwares, addons, executáveis bibliotecas úteis no dia a dia.

docs

Documentação em geral como arquivos de notas, ajuda, relatórios, etc.

samples

Projetos de exemplo ou exemplos de uso. Esta é uma pasta opcional, mas pode ser útil para demonstrar algum recurso ou funcionalidade na prática.

lib

Coisas que nunca poderão estar em um pacote NuGet, por exemplo.

sql

Arquivos SQL para criação do banco de dados ou para suporte.

artifacts

Armezene aqui as saídas de compilações do produto, todavia, é preciso configurar a IDE para usar esta pasta em seus builds, como por exemplo arquivos nupkgs, dlls, pdbs, etc.

packages

Armazene aqui os pacotes NuGet compilados.

build

Builds dos projetos, assim como scripts de build customizados, como por exemplo, para o Msbuild. Pastas bin e obj. É quase igual ao artefacts, mas difere pela relação com o produto final, sendo que em artefacts serão armazenadas já versão estáveis dos builds e aqui é a pasta de cache para o desenvolvimento do dia a dia, podendo até estar no .gitignore.

build.cmd

Arquivos de comando que geram o build para windows

build.sh

Arquivos de comando que geram o build para unix, linux…

global.json

Arquivo de solução ASP.NET Core

LICENSE

Arquivo que contém a licença de uso do software e seu código fonte

README.md

Arquivo com informações relevantes do projeto em formato markdown, podendo  ser um tutorial ou resultados de testes

Outros arquivos

Os arquivos .editorconfig, .gitignore, .gitattributes são arquivos do Git e/ou para configurações pessoais de editores

NuGet.Config

Arquivo de configuração para pacotes NuGet

Referências:

https://gist.github.com/davidfowl/ed7564297c61fe9ab814
https://github.com/kriasoft/Folder-Structure-Conventions

Visual Studio: alterar o framework padrão para novos projetos

Introdução

Muitas vezes é preciso que todos os novos projetos já estejam em uma versão do .Net Framework específica, ou simplesmente, que já seja criado com o target na última versão disponível no Visual Studio.

Alterando a versão padrão

Abra o Visual Studio, clique em File, em seguida em New e por último em Project…

Anote a versão do .Net Framework que será a padrão para os novos projetos, como por exemplo “4.6.1”.

Pressione as teclas Win + R, em Abrir digite o comando regedit e clique em Ok.

A janela do Editor do Registro será exibida.

Localize a chave HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\NewProjectDialog, e edite a chave fxVersion para a versão do .Net Framework desejada.

Observação: onde está escrito 14.0, que equivale a versão do Visual Studio 2015, pode ser alterada para a versão do seu Visual Studio, como por exemplo, 13.0 para o 2013.

O Visual Studio 2017 não precisa desta configuração, pois ele lembra a última versão usada ao criar um projeto.

Pronto, agora todas os novos projetos serão automaticamente definido com a versão configurada por padrão.