Arquivo da categoria: ASP.Net MVC

Diversos artigos e dicas sobre ASP.Net MVC

Como foi o ASP.NET Brasil Conference 2014

Publicado em por

A comunidade ASP.NET Brasil em comemoração aos seus mais de 1.300 usuários realizou o evento chamado ASP.NET Brasil Conference 2014. Confira como foi.

O agitação do evento começou bem cedo, às 08h00 algumas pessoas já haviam chegado. Rapidamente o auditório que nos foi cedido pela PUC estava lotado, foi necessário colocar cadeiras extras para poder comportar mais pessoas, trabalhamos com a lotação máxima.

O propósito principal do evento foi entregar o máximo de conteúdo sobre ASP.NET de forma que os presentes pudessem aprender sobre recursos disponíveis e abrir os olhos e a mente para diversas possibilidades nesta plataforma.

Foram 6 palestras de conteúdo de alto nível, todas ministradas por MVPs em ASP.NET (7 no total), o que nunca tinha sido realizado antes num evento, foi algo inédito. Tivemos cerca de 122 participantes e o feedback sobre o evento foi melhor do que o esperado.

Todos os palestrantes apresentaram seus temas dentro do horário sem atrasos, houveram muitas perguntas, por sinal todas muito interessantes o que proporcionou um bate papo aberto entre participantes e os palestrantes que participaram das respostas não apenas na apresentação de seus temas e sim de forma geral, foi uma dinâmica muito boa.

Fomos prestigiados pela nossa MVP Lead Fernanda Saraiva que também esteve presente durante a apresentação dos temas.

Ao final do evento foram sorteados os prêmios, inscrições gratuítas para cursos promovidos por mim e pelo Waldyr Félix, além de livros sobre ASP.NET em português.
Foram coletados cerca de 150 kilos de alimentos que foram doados a instituições carentes.

As apresentações e os slides de todas as apresentações estarão disponíveis no site oficial do evento.

O evento foi todo organizado em cerca de um mês e foi a primeira edição de um evento que está programado para ser semestral. Para as próximas edições teremos muito mais novidades.

Gostaria de agradecer a todos os participantes e aos palestrantes que se comprometeram e entregaram ótimas palestras e ao Waldyr Félix que sem seu engajamento e esforço não teria sido possível realizar este evento.

Aguardem pelo próximo em breve. Ate lá!

Links

O Futuro do ASP.NET vNext – MVC 6

Publicado em por

Você já parou para pensar no futuro do ASP.NET daqui alguns anos? O futuro chegou e foi anunciado hoje! Quem acompanha já deve ter reparado no termo OWIN ou lido algo sobre Project Katana / Helios, etc. Hoje uma página de 12 anos foi virada para um novo tempo. Conheça aqui o ASP.NET do Futuro.

ASP.NET vNext

O artigo é extenso e foi utilizada uma linha cronológica para apresentar todo o processo da evolução do ASP.NET.

Um breve olhar no passado do ASP.NET

O ASP.NET desde seu lançamento foi criado originalmente para dois publicos em específico:

  • Desenvolvedores ASP Clássico
  • Desenvolvedores Windows

O resultado não podia ser diferente, a primeira versão do ASP.NET conhecida como Web Forms é uma combinação do desenvolvimento Windows (componentes ricos, desenvolvimento rápido, arrastar e soltar) com a plataforma Web.

Para suportar toda a riqueza de funcionalidades do Web Forms foi necessário implementar muitas classes no .Net Framework, este que por sua vez é mono-bloco, ou seja, muitas funcionalidades estão acopladas em um único assembly, o System.Web (núcleo de objetos HTTP e o próprio framework de WebForms).

Devido a isso o ASP.NET sempre esteve fortemente acoplado ao .Net Framework e dependente de um específico Web host, o Internet Information Services (IIS).

O ASP.NET Web Forms foi a única forma conhecida de ASP.NET durante muitos anos.

Evolução da plataforma ASP.NET e suas dificuldades

Quem desevolve com ASP.NET desde seus primórdios sabe que antigamente era necessário muito tempo (ordem de anos) para que fosse liberada uma nova versão do ASP.NET, e isso nunca foi bom, pois as outras plataformas avançavam muito mais rápido, muitas novas tecnologias surgiam e o ASP.NET precisava se manter competitivo para atender as novas necessidades.

O grande ponto é que o ASP.NET sempre precisou crescer numa velocidade muito maior do que o .NET Framework cresce, porém ambos sempre estiveram muito acoplados através do System.Web que faz parte do .NET Framework, ou seja, muitas vezes para a implementação de um simples recurso no ASP.NET poderia haver algum impacto no .NET Framework e que por sua vez poderia demorar anos até receber a atualização para suporte a tal recurso.

Além do problema do alto acoplamento, por mais que o ASP.NET e o .NET Framework recebessem novas funcionalidades a adoção era demorada demais, o motivo maior é que as empresas não atualizam o .NET Framework de imediato, é necessário todo um processo de validação, revisão de plataforma, homologação e etc, até hoje em 2014 boa parte dos servidores de hospedagem não trabalham com a versão 4.5 do .NET Framework.

O desenvolvedor muitas vezes precisava esperar anos e anos para utilizar um novo recurso da plataforma.

Como resolver isso?

Solução número 1 – Separar

O ASP.NET MVC foi introduzido em 2007-2008 sendo que é distribuido separadamente do ASP.NET clássico, ou seja, isso aumentou a velocidade da entrega de novidades para o ASP.NET as versões do MVC foram entregues como complemento através de novas versões do Visual Studio, via NuGet ou via o aspnetwebstack do ASP.NET, onde é possível utilizar as versões dos build noturnos, código ASP.NET que foi desenvolvido a menos de 24 horas.

Quem desenvolve com ASP.NET há algum tempo vem nos últimos anos presenciando muitas mudanças, além do ASP.NET MVC ainda vieram o Razor, Web API, SignalR, SPA, ASP.NET Identity e todos foram distribuidos separadamente.

Existe a sensação que a Microsoft esta com grande foco em evoluir a plataforma ASP.NET, atualmente em média de a cada seis meses é liberada uma nova versão ou novas funcionalidades / tecnologias agregadas ao ASP.NET. para que ela se mantenha altamente competitiva entre as demais de mercado, e isso já é fato, analisando a produtividade em utilizar ASP.NET com Visual Studio e todas as vantagens que o ASP.NET oferece, fica muito claro o motivo pelo qual cada vez mais empresas e profissionais adotam o ASP.NET como plataforma oficial de desenvolvimento Web.

Para um maior detalhamento assista meu vídeo da palestra Novidades do ASP.NET MVC 5.x

Mesmo com a separação do ASP.NET MVC em relação ao ASP.NET clássico ainda existe uma forte dependência com o System.Web e por sua vez a necessidade de utilizar IIS como única opção de Host.

Quando iniciamos um projeto em ASP.NET MVC, por mais que seja um simples “Olá Mundo!” pode ser que não tenha reparado, mas as dependências com o System.Web estão lá, o System.Web provê suporte a envio de e-mail, controles do Web Forms, sessão e etc… Você não precisa disso? Não importa, vai ter que usar, pois se tirar o System.Web de suas referências seu projeto simplesmente não vai funcionar.

O outro problema é que por mais que o ASP.NET MVC tenha capacidade de ser uma plataforma leve e performática ela sofre uma boa perda devido ao fardo do System.Web que precisa estar presente para fazer o pipeline com o IIS.

Solução número 2 – Quebrar as dependências.

Em 2012-2013 surgiram o ASP.NET SignalR e ASP.NET WebAPI, estes dois componentes ASP.NET não possuem nenhuma dependência com o System.Web, foram desenvolvidos para levar o ASP.NET a um novo patamar, a da independência de plataforma, pois tanto o SignalR como o WebAPI podem rodar em ambientes não Microsoft (Linux/OSx).

Essa foi a quebra da independência ao legado do System.Web, mas até então apenas estes dois componentes podiam rodar independente do IIS, System.Web e Windows.

Foi neste momento que a comunidade técnica conheceu o OWIN.

Apresentando o OWIN

Desde meados de 2009 o ASP.NET se tornou open source e devido a este fato a comunidade técnica pode se juntar ao time de engenheiros da Microsoft para conhecer e implementar melhorias e sugestões. Foram os próprios membros da comunidade técnica que baseando-se no design do Node.js e do Rack da comunidade Ruby, criaram uma especificação chamada OWIN (Open Web Interface for .NET).

O OWIN define uma interface padrão entre servidores Web e aplicações .NET.
O objetivo da interface OWIN é desacoplar o servidor e a aplicação, incentivar a criação de módulos simples para o desenvolvimento em ASP.NET, e, por ser um padrão aberto, estimular o ecossistema open source de ferramentas .NET de desenvolvimento Web.

Resumidamente o OWIN é uma camada de abstração entre o server e a aplicação.

O objetivo do OWIN é que novos componentes possam ser facilmente desenvolvidos e consumidos, porém de forma agnostica, ou seja, que possam rodar em outras plataformas como Unix (Mac/Linux) e que possam ser portados de uma plataforma para outra sem necessidade de recompilação.

  • É um “standart” uma especificação.
  • Não existe exatamente como código ou componente.
  • É a descrição de como idealmente o comportamento de sua implementação deve funcionar.

Katana Project

É uma implementação Microsoft da especificação OWIN no ASP.NET.

A Microsoft apostou na proposta do OWIN e o implementou nos projetos ASP.NET SignalR e ASP.NET WebAPI, essa implementação recebe o nome de Katana Project. Mais tarde o ASP.NET Identity surgiu implementando bibliotecas do Katana Project também.

Além da Microsoft, outros projetos implementam OWIN como NancyFx, FubuMVC, NOWIN etc.

Confira no vídeo abaixo mais detalhes sobre arquitetura OWIN – Katana Project.

Project Helios

A implementação do OWIN atrávés do Katana Project proporcionou a criação de componentes ASP.NET muito mais leves, performáticos, independentes de plataforma e SelfHost, porém caso seja necessário contar com alguns recursos que o Host ASP.NET clássico (IIS) provê, tudo isso fica a cargo do desenvolvedor da aplicação.

O IIS apesar de trabalhar apenas no pipeline do ASP.NET clássico (System.Web) possui uma série de benefícios que nem sempre podem ser deixadas de lado:

  • IIS lida com gerenciamento da vida útil aplicação.
  • Ele pode suspender (em vez de encerrar) processos que estão ociosos para ajudar a equilibrar os recursos disponíveis do sistema.
  • IIS oferece um cache de modo de usuário embutido e pode comprimir automaticamente o conteúdo dos responses se for o caso.
  • IIS suporta filtragem de requests e transient worker process identities.
  • Mais de 10 anos de implementações e melhorias de segurança.
  • No cenário do Self Host você é responsável por muitas das responsabilidades que o IIS toma conta, além disso ele já existe para isso por que não utilizá-lo?

São esses os motivadores do Project Helios, porém devido à necessidade do IIS trabalhar no pipeline no System.Web muita performance seria perdida, por isso o Project Helios trabalha apenas com o “Core” do IIS o utilizando como uma espécie de API, o “Core” do IIS é extremamente rápido e poderoso, pois disponibiliza apenas as suas funcionalidades sem depender do pipeline do ASP.NET clássico (System.Web).

O Project Helios oferece suporte aos projetos desenvolvidos em Katana (OWIN), porém não é dependente dele para ser utilizado, é possível desenvolver uma aplicação baseada apenas em Project Helios que rodará apenas no padrão IIS e não terá opções de SelfHost e multiplataforma, em uma arquitetura de aplicações para Windows pode ser muito vantajoso, pois é pelo menos 96% mais rápido que o ASP.NET clássico. Na demo exibida no vídeo abaixo o resultado foi quase 6x mais rápido utilizando Helios.

Requerimentos mínimos para utilização do Project Helios

  • Windows 8 ou Windows Server 2012
  • .NET Framework 4.5.1
  • Visual Studio 2012 ou 2013

Resumo Cronológico

O ASP.NET desde seu lançamento sofreu com a grande demora de liberações de novas versões, algumas plataformas novas surgiram e passaram a frente devido uma evolução mais rápida, com a implementação do ASP.NET MVC esse tempo de liberações diminuiu, porém a plataforma ainda era limitada em relação às outras devido a herança historica do Web Forms (System.Web) em seu pipeline, impedindo que algumas melhorias fossem implementadas.

Com o surgimento do OWIN e os projetos Katana e Helios novas frentes se abriram e a engenharia do time de ASP.NET começou a trabalhar em uma nova versão, a maior e melhor mudança do ASP.NET em todo o seu período de existência, hoje o futuro chegou.

ASP.NET vNext – MVC 6

Foi anunciado dia 13/05 durante uma sessão do TechEd North America 2014 a nova versão do ASP.NET chamada vNext e que vai mudar tudo o que você sabe sobre ASP.NET, é um novo paradigma, um novo stack, tudo que os desenvolvedores Web mais maduros sabiam que era possível e torciam para que um dia fosse feito.

Todos os nomes que vimos como Katana, Helios e ASP.NET vNext provavelmente irão mudar, são nomes dados para projetos em execução, na versão final ganham um outro nome mais familiar.

Você desenvolvedor ASP.NET veterano, levante agora da cadeira e aplauda, você está diante a maior mudança do ASP.NET em seus 12 anos de existência. Você iniciante ASP.NET nem pense em Web Forms, caia direto nesse stack e comece a entender tudo como funciona daqui pra frente.

O que mudou

  • Web Pages, MVC, Web API agora é uma coisa só, chamado de MVC 6
  • Novas versões otimizadas para nuvem do MVC 6, SignalR 3 e Entity Framework 7
  • Acabou a dependência do System.Web, MVC 6 agora é um middleware, leve e performático, agora apenas o Web Forms depende (para sempre) do System.Web.
  • Versões otimizadas para nuvem do MVC, Web API, Web Pages, SignalR e Entity Framework.
  • Maior portabilidade, não existe dependência de assemblies do GAC facilitando o deploy em nuvem e em ambientes não Windows (Linux/OSx/Etc)
  • Possibilidade de hospedar sua aplicação no IIS ou em um processo self hosted
  • Injeção de dependência nativa dentro do framework
  • Suporte ao legado do Web Forms, MVC 5, Web API 2, Web Page 3 , SignalR 2 e EF 6
  • Deploy do runtime e framework com a sua aplicação, possibilitando rodar lado a lado 2 versões diferentes do framework
  • Arquivo project.json irá integrar o arquivo de projeto (.csproj), o packages.config e o Nuget specifications (nuspec);
  • Suporte ao Rosyln, ou seja, não precisa mais parar a aplicação para alterar uma classe, basta alterar salvar e dar F5 no browser, pronto! Muita produtividade!
  • Tudo é entrege via NuGet até o runtime!
  • Mais open source que nunca (foi para o GitHub) e faz parte do .Net Foundation.
  • Baixissimo consumo de memória
  • Completamente Multiplataforma!!! Rode ASP.NET onde quiser!

Veja alguns screenshots

Assista ao vídeo da palestra – O Futuro do ASP.NET + Novidades do vNext – MVC 6

Acompanhe os slides da palestra

Assista esse vídeo exibindo como rodar a nova versão do ASP.NET vNext – MVC 6

Bons estudos!!!

Referências

Vamos continuar a troca de conhecimentos, escreva seu comentário abaixo 😉

Visual Studio Summit 2014 – Novidades do ASP.NET MVC 5.x – Palestra + Vídeo

Publicado em por

No sábado dia 26/04/14 aconteceu a terceira edição do Visual Studio Summit, um evento que eu participo como organizador e palestrante.

Sobre o Visual Studio Summit 2014

O Visual Studio Summit é o maior evento de desenvolvedores Microsoft do Brasil, ocorre pelo terceiro ano consecutivo na Sede da Microsoft Brasil na capital de São Paulo.

Eu tenho um grande prazer de atuar na organização deste evento ao lado do mestre Ramon Durães, meses antes do evento nós já estamos trabalhando para oferecer a melhor experiência possível para toda a comunidade técnica.

Alguns números sobre o evento

  • Palestrantes: 28
  • Staff apoio operação: 8
  • Palestras: 79 palestras 
  • Total de horas de conteúdo: 39.5 horas  
  • Salas: 6 simultâneas e 3 salas Ask the Expert.

Minha Palestra

A palestra apresentada nesta edição foi “Novidades do ASP.NET MVC 5.x” onde eu abordei todas as atualizações desde a versão do ASP.NET MVC 5.

Como a versão do Visual Studio Summit 2014 não foi gravada eu fiz questão de regravar minha palestra em casa e disponibilizar para quem não viu ou quer ver de novo, só que agora com 1h00 de duração e mais detalhes no conteúdo.

Segue minha apresentação de slides também para acompanhar o tema

Durante o lançamento da versão do ASP.NET MVC 5 eu escrevi alguns artigos relacionados

Gostaria de agradecer a todos presentes, palestrantes e staffs, especialmente o time de MSP’s e MTACs que foram indicados pela Microsoft para apoiar a realização do evento. Todos foram muito prestativos, educados e dedicados. Parabéns a vocês!

Aguardo você na próxima edição 😀

Links para seguir

ASP.NET BRASIL CONFERENCE – São Paulo

Publicado em por

O grupo ASP.NET BRASIL qual faço parte e atuo no time de líderes está organizando um evento épico sobre ASP.NET no dia 10/05, um formato inédito, 6 MVPs de ASP.NET dividindo o mesmo palco no mesmo dia, confira como participar.

ASP.NET BRASILO Grupo ASP.NET BRASIL em comemoração pelos seus mais de 1.000 participantes ativos realizará este evento gratuíto, e para falar de ASP.NET nada melhor do que reunir 6 MVPs de ASP.NET não acham?

Horário Palestrante Tema
08:00 – 09:00 Credenciamento  
09:00 – 09:30 Abertura  
09:30 – 10:20 Alexandre Tarifa (MVP) Construindo sites Mobile com ASP.NET
10:30 – 11:20 André Baltieri (MVP) Desenvolvendo APIs RESTful com Web API
11:30 – 12:20 Eduardo Pires (MVP) O Futuro do ASP.NET
12:30 – 14:00 Almoço  
14:00 – 14:50 Fabrício Sanchez (MVP) Breve
15:00 – 15:50 Victor Cavalcante (MVP) ASP.NET Identity o substituto do Membership
16:00 – 16:50 Waldyr Félix (MVP) Novidades do ASP.NET MVC 5.X
17:00 – 18:00 Encerramento Sorteio de Prêmios

Para participar basta levar 1kg de alimento não-perecível que será doado para instituições carentes.

10 de Maio – Sábado – PUC-SP – Departamento de Computação
Rua Marquês de Paranaguá 111 – Consolação – 01303-050

Faça sua inscrição e divulgue para seus conhecidos
https://www.sympla.com.br/aspnet-brasil-conference—sao-paulo—presencial__19070 

Site do Evento
http://aspnetbrasil.azurewebsites.net/ 

Inscreva-se no grupo ASP.NET BRASIL
https://www.facebook.com/groups/aspnetmvcbr

Sorteio de Prêmios

Serão sorteadas duas inscrições gratuítas para os cursos:

Os prêmios serão sorteados apenas para os cadastrados pelo site e que estiverem presentes até o final do evento.

Comprovante de Participação

Todos os presentes receberão comprovante de participação eletrônico que será enviado por e-mail.

Inscrição Rápida

As vagas são limitadas, por favor, em caso de desistência realize o cancelamento via site ou nos comunique sobre o cancelamento da inscrição.

*Grade sujeita à mudanças.

ASP.NET Identity – Nome de usuário no formato de e-mail.

Publicado em por

O ASP.NET Identity é altamente customizável, pois foi desenvolvido justamente para ser adaptado em diversos cenários, nesse artigo iremos implementar como permitir que o nome de usuário esteja no formato de e-mail.

 

ASP.NET Identity

Muitos portais e sistemas Web optam por utilizar o próprio e-mail do usuário registrado como nome de usuário, isso proporciona algumas vantagens:

  • Um username a menos para o usuário decorar.
  • Estimula o usuário fornecer um e-mail real.
  • O usuário não precisa se chatear por que seu username escolhido já esta em uso.
  • Usuários não mudam de e-mail com tanta frequência.
  • Um campo a menos para o usuário preencher no cadastro.
  • Os maiores portais utilizam e-mail como username (Facebook, Microsoft, Google, Linkedin, etc…)

Por padrão o ASP.NET Identity não permite que o username possua caracteres especiais, logo o “@” não será permitido, para permitir que o usuário utilize seu e-mail como username será necessário realizar as mudanças a seguir.

*O exemplo a seguir está com base no projeto utilizado no artigo anterior sobre ASP.NET Identity

Método 1

Esse é o método mais rápido de implementar que é desabilitando a validação de caracteres especiais da classe UserManager, é simples e rápido, localize o arquivo Controllers > AccountController.cs, o construtor da controller estará como no código a seguir.

public AccountController(UserManager userManager)
{
    UserManager = userManager;
}

Nesse caso basta criar um novo UserValidator qual possui a propriedade AllowOnlyAlphanumericUserNames que ao ser setada como false permite que outros caracteres sejam utilizados no nome de usuário.

public AccountController(UserManager userManager)
{
    UserManager = userManager;

    // Criando um UserValidator
    UserManager.UserValidator = new UserValidator(UserManager)
    {
        // Desabilitando a regra de apenas caracteres alfanumericos.
        AllowOnlyAlphanumericUserNames = false
    };
}

É funcional mas eu pessoalmente não acho nada elegante.

Método 2

Uma opção mais complexa é criar seu próprio CustomValidator para ser utilizado no momento da validação do username. Para isso sugiro que seja criada uma pasta específica chamada Validators por ex. Nesta pasta crie uma classe chamada CustomUserValidator.cs e utilize o código a seguir.

using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;
using System.Threading.Tasks;
using Microsoft.AspNet.Identity;

namespace DemoIdentity.Validator
{
    public class CustomUserValidator<TUser> : IIdentityValidator<TUser>
        where TUser : class, IUser
    {
        private static readonly Regex EmailRegex = new Regex(@"^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}$", RegexOptions.Compiled | RegexOptions.IgnoreCase);
        private readonly UserManager<TUser> _manager;

        public CustomUserValidator()
        {
        }

        public CustomUserValidator(UserManager<TUser> manager)
        {
            _manager = manager;
        }

        public async Task<IdentityResult> ValidateAsync(TUser item)
        {
            var errors = new List<string>();
            if (!EmailRegex.IsMatch(item.UserName))
                errors.Add("O endereço de email não é válido.");

            if (_manager != null)
            {
                var otherAccount = await _manager.FindByNameAsync(item.UserName);
                if (otherAccount != null && otherAccount.Id != item.Id)
                    errors.Add("Já existe uma conta utilizando este email, selecione um diferente.");
            }

            return errors.Any()
                ? IdentityResult.Failed(errors.ToArray())
                : IdentityResult.Success;
        }
    }
}

Note que a validação de formato de e-mail é feita através de expressão regular e a classe de validação também verifica se o e-mail já não está cadastrado na base, caso qualquer erro seja encontrado uma mensagem de erro é adicionada à uma lista de mensagens e no final é repassada para o helper Failed da classe IdentityResult.

Para implementar a classe CustomUserValidator basta modificar o construtor da controller AccountController da mesma forma que foi feito no método 1.

public AccountController(UserManager<ApplicationUser> userManager)
{
    UserManager = userManager;

    // Aplicando um UserValidator customizado.
    UserManager.UserValidator = new CustomUserValidator<ApplicationUser>(UserManager);
}

Notem que a classe UserManager que é exposta pelo ASP.NET Identity permite que você utilize uma classe de validação que implemente a interface IIdentityValidator e esta classe pode ser customizada para atender qualquer regra que sua validação exigir.

Desta forma além de mais elegante é possível realizar diversas validações em uma classe exclusivamente responsável por validar o nome de usuário.

Caso esteja utilizando o exemplo iniciado no artigo anterior basta realizar as modificações a seguir.

  1. Remover a propriedade “Email” das classes/arquivos
    • ApplicationUser
    • RegisterViewModel
    • View Account
    • AccountController (método Register)
  2. Utilizar o DataAnnotation [Email] na propriedade UserName da classe RegisterViewModel
  3. Atualizar o banco de dados (usando migrations por ex).

Referências

Este artigo faz parte da série de como customizar diversas funcionalidades no ASP.NET Identity. Aguarde pelos próximos.

Ficou com dúvidas? Quer compartilhar conosco alguma experiência? Utilize os comentários abaixo 😉

Até a próxima.

ASP.NET Identity – Customizando o cadastro de usuários

Publicado em por

Com o lançamento do ASP.NET MVC 5 um novo modelo de autenticação e autorização foi disponibilizado, o ASP.NET Identity, uma solução muito mais aberta e granular, acompanhe aqui como efetuar algumas customizações.

O ASP.NET Identity pode ser configurado no momento da criação da aplicação web, onde algumas opções são disponibilizadas para sua utilização, neste exemplo utilizarei o modelo de Individual User Accounts (modelo padrão).

ASP.NET Identity

O template de projeto que o Visual Studio disponibiliza na criação da aplicação ASP.NET MVC contempla uma implementação do ASP.NET Identity da qual já é possivel cadastrar-se como usuário. Ao executarmos o projeto pela primeira vez e clicar no link Register no topo da aplicação, será exibida a View de registro.

ASP.NET Identity

Até este ponto mais fácil seria impossível certo?
Suponha que o seu cadastro necessite de mais algumas informações como:

  • Nome
  • Sobrenome
  • E-mail

O ASP.NET Identity expõe um conjunto de classes de forma que fica muito fácil realizar qualquer tipo de customização. Mãos à obra.

Passo 1 – Customizar a classe de usuário

Localize e abra o arquivo IdentityModels.cs na pasta Models do seu projeto ASP.NET MVC. O código original será este:

namespace DemoIdentity.Models
{
    public class ApplicationUser : IdentityUser
    {
    }

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
    {
        public ApplicationDbContext()
            : base("DefaultConnection")
        {
        }
    }
}

Observe que existem duas classes nesse arquivo (depois refatoramos) a classe ApplicationUser é sua classe de usuário, note que ela não possui propriedade nenhuma apenas herda de IdentityUser, pois é esta classe que possui as propriedades de usuário, a classe ApplicationUser está ali disponível justamente para a customização.

Abaixo o código após a customização

namespace DemoIdentity.Models
{
    public class ApplicationUser : IdentityUser
    {
        public string Nome { get; set; }

        public string Sobrenome { get; set; }

        public string Email { get; set; }
    }

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
    {
        public ApplicationDbContext()
            : base("DefaultConnection")
        {
        }
    }
}

Passo 2 – Customizar a ViewModel

Neste projeto está sendo utilizado o padrão ViewModel, isso significa que a View de registro é baseada nesta ViewModel para exibir as informações em tela.

Localize e abra o arquivo AccountViewModels.cs na pasta Models, originalmente existem quatro classes neste mesmo arquivo (mais um item para refatorar). Encontre a classe RegisterViewModel:

public class RegisterViewModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

A mesma classe agora após a customização:

public class RegisterViewModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    public string Nome { get; set; }

    [Required]
    public string Sobrenome { get; set; }

    [Required]
    [Display(Name = "E-mail")]
    [EmailAddress]
    public string Email { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

Note que fiz uso de alguns DataAnnotations para configurar que os campos sejam requeridos e para ocorrer a validação de formato de email durante o input dos dados.

Passo 3 – Customizar a View

Agora para preencher com dados as novas propriedades da ViewModel será necessário customizar a View.

Localize e abra o arquivo Register.cshtml na pasta Views > Account.
Note que a View faz uso da ViewModel que acabamos de customizar

@model DemoIdentity.Models.RegisterViewModel

O resultado final da View será esse:

@model DemoIdentity.Models.RegisterViewModel
@{
    ViewBag.Title = "Register";
}

<h2>@ViewBag.Title.</h2>

@using (Html.BeginForm("Register", "Account", FormMethod.Post, new { @class = "form-horizontal", role = "form" }))
{
    @Html.AntiForgeryToken()
    <h4>Create a new account.</h4>
    <hr />
    @Html.ValidationSummary()
    <div class="form-group">
        @Html.LabelFor(m => m.UserName, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Nome, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Nome, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Sobrenome, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Sobrenome, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Email, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Password, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.PasswordFor(m => m.Password, new { @class = "form-control" })
        </div>
    </div>
    <div class="form-group">
        @Html.LabelFor(m => m.ConfirmPassword, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.PasswordFor(m => m.ConfirmPassword, new { @class = "form-control" })
        </div>
    </div>
    <div class="form-group">
        <div class="col-md-offset-2 col-md-10">
            <input type="submit" class="btn btn-default" value="Register" />
        </div>
    </div>
}

@section Scripts {
    @Scripts.Render("~/bundles/jqueryval")
}

Execute a aplicação para validar o resultado:

ASP.NET Identity

Passo 4 – Customizar a Controller

Este é o passo final, apesar da navegação estar pronta, a Controller ainda não está apta a receber as novas propriedades customizadas e realizar a gravação no banco.

Localize e abra o arquivo AccountController.cs na pasta Controllers
Identifique a Action de registro, o código original será este:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser() { UserName = model.UserName };
        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
            await SignInAsync(user, isPersistent: false);
            return RedirectToAction("Index", "Home");
        }
        else
        {
            AddErrors(result);
        }
    }

    return View(model);
}

Após a customização o resultado deverá ser este:

public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser()
        {
            UserName = model.UserName,
            Nome = model.Nome,
            Sobrenome = model.Sobrenome,
            Email = model.Email
        };

        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
            await SignInAsync(user, isPersistent: false);
            return RedirectToAction("Index", "Home");
        }
        else
        {
            AddErrors(result);
        }
    }

    return View(model);
}

Note que esta Action recebe o objeto RegisterViewModel como parâmetro, foi necessário apenas inserir as novas propriedades do objeto ApplicationUser que receberão as informações que vieram da ViewModel.

Sua customização está finalizada, execute a aplicação, registre um usuário e confira o resultado.

Observações:

  • O primeiro cadastro pode demorar um pouco, pois o mecanismo do Code First está criando o banco de dados e as tabelas necessárias para o ASP.NET Identity operar.
  • Faça testes no formulário, por ex, deixar algum campo em branco ou usar um e-mail em formato inválido.

Após registrar o usuário pela aplicação, você pode conferir o resultado da criação do banco de dados através do painel SQL Server Object Explorer do Visual Studio:

ASP.NET Identity

Vimos que é muito fácil realizar uma customização de um controle de acesso pelo ASP.NET Identity, caso queira criar mais campos basta seguir o mesmo roteiro.

Referências

Em breve publicarei mais artigos de customização do ASP.NET Identity, com técnicas mais avançadas e refatoração do projeto original.

Ficou com dúvidas? Quer compartilhar conosco alguma experiência? Utilize os comentários abaixo 😉

Até a próxima.

Campus Party 2014 – Palestra sobre ASP.NET

Publicado em por

No dia 31/01 eu tive o prazer de palestrar na Campus Party 7 – Edição 2014 / SP meu tema foi sobre ASP.NET, novidades, tendências e mobilidade.

Para quem não sabe a Campus Party é o maior evento tecnológico do mundo, ela atrai anualmente geeks, nerds, empreendedores, gamers, cientistas e muitos outros criativos que reúnem-se para acompanhar centenas de atividades sobre Inovação, Ciência, Cultura e Entretenimento Digital.

Foi o maior evento onde palestrei, fico muito satisfeito em ter palestrado no mesmo evento que meu ídolo Bruce Dickinson 😉

Motivos não faltaram para eu compilar e buscar compartilhar o máximo de informações possíveis sobre a plataforma ASP.NET, minha palestra foi na virada da madrugada, mas mesmo assim o público foi chegando e quando notei a audiência estava ótima!

Ao finalizar minha apresentação o retorno também foi ótimo, recebi muitos feedbacks positivos, tirei bastante dúvidas e conversei com o pessoal que ficou para continuar o assunto comigo fora do palco.

Disponibilizo para visualização os slides que utilizei em minha palestra.

Com certeza estarei de volta na Campus Party ano que vem, espero que me apresentando novamente também.

Acompanhe e conheça mais o evento no site oficial da Campus Party.

Abraços!

ASP.NET MVC 5.1 – O que mudou?

Publicado em por

Foi anunciado em 20/01/2014 o release do ASP.NET MVC 5.1 que chegou com boas novidades e atualizações, na mesma data o Visual Studio recebeu o Update 1, confira em detalhes.

ASP.NET MVC 5.1

Requerimentos de Software

Download

A release do ASP.NET MVC 5.1 foi liberada como um pacote disponível na galeria NuGet. Todos os pacotes sequem a especificação Semantic Versioning, por exemplo o ASP.NET MVC 5.1 RTM tem a seguinte versão: “5.1.0”.

Para facilitar mais você ainda pode utilizar o NuGet Package Manager Console com o seguinte comando:

Install-Package Microsoft.AspNet.Mvc -Version 5.1.0

Documentação

Tutoriais e outras informações sobre o ASP.NET MVC 5.1 estão disponíveis no site oficial do ASP.NET (http://www.asp.net)

Novidades no ASP.NET MVC 5.1

Melhorias no Attribute routing

O Attribute Routing agora suporta restrições, permitindo o versionamento e header baseado na seleção da rota. Muitos aspectos de attribute routes podem agora ser customizados via a interface IDirectRouteFactory e a classe RouteFactoryAttribute.

Suporte a Enum nas views

  1. Novo helper @Html.EnumDropDownListFor() Pode ser usado como a maioria dos HTML helpers com a ressalva que a expressão precisa ser avaliada como um tipo de Enum ou um Nullable<T> onte T é um tipo de enun. Utilize EnumHelper.IsValidForEnumHelper() para verificar estes requerimentos.

    2.  

  2. Novo método EnumHelper.GetSelectList() qual retorna um IList<SelectListItem>.
    Isto é útil quando você precisa manipular uma select lista antes de chamá-la, por exemplo um @Html.DropDownListFor(), ou quando você desejar exibir os nomes que o @Html.EnumDropDownListFor() mostra.

O código a seguir demonstra como aplicar:

@if (EnumHelper.IsValidForEnumHelper(ViewData.ModelMetadata))
{
    @Html.EnumDropDownListFor(model => model, htmlAttributes: new { @class = "form-control" })
}
@if (EnumHelper.IsValidForEnumHelper(ViewData.ModelMetadata))
{
    foreach (SelectListItem item in EnumHelper.GetSelectList(ViewData.ModelMetadata,
	(Enum)Model)) { … }
}

Você pode conferir um exemplo completo aqui.

suporte a Bootstrap em editor templates

Agora é possível passar no EditorFor um atributo HTML como um objeto anônimo:

Exemplo:

@Html.EditorFor(model => model, new { htmlAttributes = new { @class = "form-control" }, })

Validação não intrusiva para MinLengthAttribute e MaxLengthAttribute

Validações client-side para string e arrays agora são suportadas para as propriedades decoradas com os atributos MinLength e MaxLength.

Supporte ao contexto ‘this’ no Ajax não intrusivo

As funções de callback (OnBegin, OnComplete, OnFailure, OnSuccess) agora estão habilitadas a localizar o elemento da invocação através do contexto ‘this’. Exemplo:

@Ajax.ActionLink("Click me", "AjaxAction", new AjaxOptions { UpdateTargetId = "foo", OnBegin = "OnClick" })

<script>
    function OnClick(jqXHR) {
        if ($(this).hasClass("foo")) {
            jqXHR.setRequestHeader("custom-header", "value");
        }
    }
</script>

Problemas Conhecidos e Mudanças Significativas

Attribute Routing

Ambiguidades nas correspondências de attribute routing agora irão reportar um erro em vez de escolher a primeira correspondência.

Attribute Routes estão proibidos de usar o parâmetro {controller} e de usar o parâmetro {action} em rotas colocada em actions. O uso destes parâmetros muito provavelmente levará a gerar ambiguidades.

utilizar Scaffolding de MVC/Web API em um projeto com pacotes 5.1 resultará em pacotes 5.0 para aqueles que ainda não existem no projeto.

Atualizar para ASP.NET MVC 5.1 através dos pacotes NuGet não atualiza as ferramentas como Scaffolding ou o template de ASP.NET Web Application.

Eles usam uma versão anterior do ASP.NET (5.0.0.0). Como resultado o Scaffolding irá instalar os pacotes antigos (5.0.0.0) como pacotes requeridos se ainda não estiverem disponíveis em seu projeto. Entretanto o Scaffolding do Visual Studio 2013 RTM ou Update 1 não sobrescreve os últimos pacotes em seu projeto.

Se você usar Scaffolding após ter atualizados os pacotes em seu projeto para Web API 2.1 ou ASP.NET MVC 5.1, confira se as versões estão consistentes.

Syntax Highlighting para Razor Views no Visual Studio 2013

Se você atualizar para o ASP.NET MVC 5.1 RTM sem atualizar o Visual Studio 2013, você não conseguirá o suporte no editor para o syntax highlighting enquanto estiver editando as Razor Views, você precisará atualizar o Visual Studio 2013 para obter este suporte.

tipos renomeados

Alguns dos tipos (types) utilizados para a extensibilidade do attribute routing foram renomeados na versão do ASP.NET MVC 5.1 RTM.

Nome do Tipo Antigo (5.1 RC) Novo Nome do Tipo (5.1 RTM)
IDirectRouteProvider IDirectRouteFactory
RouteProviderAttribute RouteFactoryAttribute
DirectRouteProviderContext DirectRouteFactoryContext

Correções de Bugs

O time do ASP.NET realizou a correção de diversos bugs da versão anterior como parte deste release (ASP.NET MVC 5.1 RTM). Confira a lista completa de todos os bugs corrigidos (e outros ainda em andamento) aqui.

Estas são todas as novidades da versão ASP.NET MVC 5.1, lembre-se de atualizar a sua versão do Visual Studio 2013 para o melhor proveito das novidades.

Em breve publicarei um artigo sobre as novidades do ASP.NET WebAPI 2.1.

Referências

Até a próxima 😉

Workshop de ASP.Net MVC 5 – Microsoft Technology Center

Publicado em por

Foi realizado no dia 09/09 o Workshop de ASP.Net MVC 5 Fundamentals no Microsoft Technology Center (MTC) em São Paulo, onde foi realizada uma imersão de alto impacto para profissionais da área.

ASP.Net MVC 5 Fundamentals

Compartilho que tive o prazer de ministrar e conduzir o conteúdo técnico deste workshop exclusivo, cerca de 20 profissionais se inscreveram e compareceram para uma imersão completa ao ASP.Net MVC, profissionais de diversas áreas de TI, em sua maioria desenvolvedores.

O conteúdo do workshop abordou toda a trajetória do ASP.Net onde foram feitas comparações técnicas entre WebForms e MVC. Benefícios e diferenças do padrão MVC foram colocadas em destaque para que os profissionais pudessem descobrir as inúmeras vantagens em optar pelo ASP.Net MVC em seus projetos.

ASP.Net MVC 5 Fundamentals

O ASP.Net MVC 5 é uma das novidades que acompanham o lançamento do Visual Studio 2013, escrevi um artigo dedicado a esse assunto, no workshop os profissionais além de serem apresentados aos conceitos do padrão MVC também conheceram todas as novidades presentes no ASP.Net MVC 5 em conjunto com o Visual Studio 2013.

ASP.Net MVC 5 Fundamentals

Foram 8 horas de apresentação de conteúdos que proporcionaram um conhecimento geral, foram eles:

  • Controllers
  • Views
  • Models
  • Bootstrap
  • HTML Helpers
  • Data Annotations e Validation
  • Rotas
  • jQuery, JSON e Ajax
  • OutputCache
  • View Model e AutoMapper
  • ASP.Net Identity
  • Segurança
  • One ASP.Net
  • Filters Overrides
  • Authentication Filters

Foi muito bom interagir e conhecer novos profissionais da área, seus projetos, experiências, poder compartilhar conhecimento e claro apresentar as novidades.

O workshop foi organizado e realizado pelo Ramon Durães – 2PC, onde fui convidado a conduzir o conteúdo, registro aqui minha satisfação pelo convite.

ASP.Net – Web Application Projects x Web Site Projects

Publicado em por

No Visual Studio, você pode criar Web Application Projects ou Web Site Projects. É melhor escolher o tipo certo antes de criar um projeto web, porque pode ser demorado, difícil e propenso a erros para depois converter de um tipo para o outro.

Web Application Project

Web Application Project ou Web Site Project? Estas duas opções de criar uma aplicação web costumam gerar diversas dúvidas e problemas. Este artigo aborda todas as vantagens e desvantagens de cada uma para que a melhor escolha seja tomada conforme o seus cenários e necessidades.

Nota
Para um novo desenvolvimento é recomendado que seja escolhido o Web Application Project. Este artigo explica que Web Site Projects possuem algumas vantagens, mas muitos desenvolvedores que escolhem Web Site Projects, eventualmente descobrem que as desvantagens superam as vantagens percebidas. Além disso, à medida que novos recursos ASP.Net são desenvolvidos eles não vão estar sempre disponíveis para Web Site Projects. Por exemplo, a versão do Visual Studio 2013 possui novas ferramentas para a criação de projetos web e esta nova ferramenta vai trabalhar apenas com Web Application Projects. Para mais informações consulte Creating an ASP.NET Web Project in Visual Studio 2013.

Este artigo contém as seguintes seções:

Cenários

Cenários em que os Web Application Projects são uma escolha indicada incluem as condições:

    • Você quer ser capaz de usar o recurso Edit and Continue característico do depurador do Visual Studio.
    • Você deseja executar testes de unidade em código que está nos arquivos de classe que estão associados a páginas ASP.Net.
    • Você quer se referir às classes que estão associadas com as páginas e user controls a partir de classes standalone.
    • Você quer estabelecer dependências do projeto entre vários projetos web.
    • Você quer que o compilador crie um assembly único para todo o site.
    • Você quer controle sobre o nome do assembly e número de versão que é gerado para o site.
    • Você quer usar MSBuild ou Team Build para compilar o projeto. Por exemplo, você pode querer adicionar passos prebuild e postbuild.
    • Você quer evitar colocar o código-fonte em um servidor de produção.

Cenários em que Web Site Projects são uma escolha indicada incluem as condições:

    • Você deseja incluir o código C # e Visual Basic em um único projeto web. (Por padrão, uma aplicação web é compilada com base em configurações de idioma no arquivo de projeto. Exceções podem ser feitas, mas é relativamente difícil.)
    • Você deseja abrir o site em produção no Visual Studio e atualizá-lo em tempo real, utilizando FTP.
    • Você não quer ter que compilar explicitamente o projeto.
    • Se você pré-compilar o site, você quer que o compilador crie vários assemblies para o site, que pode incluir um assembly por página ou controle de usuário, ou um ou mais assemblies por pasta.
    • Você quer ser capaz de atualizar arquivos individuais na produção copiando apenas novas versões para o servidor de produção, ou editando os arquivos diretamente no servidor de produção.
    • Se você pré-compilar o site, você quer ser capaz de atualizar páginas da Web ASP.NET. Individuais (aspx) sem ter que recompilar todo o site.
    • Você gosta de manter seu código fonte no servidor de produção, pois pode servir como uma cópia de segurança adicional.

Resumo das Diferenças

A tabela a seguir resume as principais diferenças.

Área Web Application Projects Web Site Projects
Estrutura do arquivo de projeto
  • Um arquivo de projeto Visual Studio (. Csproj ou. Vbproj) armazena informações sobre o projeto, tais como a lista de arquivos que estão incluídos no projeto, e todas as referências de projeto a projeto.
  • Não há nenhum arquivo de projeto (. Csproj ou. Vbproj). Todos os arquivos em uma estrutura de pastas são automaticamente incluídas no site.
Compilação
  • O código fonte é compilado no computador que é usado para o desenvolvimento ou source control.
  • Por padrão, a compilação de arquivos de código (excluindo. Arquivos.ascx aspx e.) Produz um único assembly.
  • O código-fonte é normalmente compilado dinamicamente (automaticamente) pelo ASP.NET no servidor pela primeira vez quando um request é recebido depois que o site foi instalado ou atualizado. É possível pré-compilar o site (compilar com antecedência em um computador de desenvolvimento ou no servidor).
  • Por padrão, a compilação produz múltiplos assemblies.
Namespaces
  • Namespaces explícitos são adicionados a páginas, controles e classes por padrão.
  • Namespaces explícitos não são adicionados a páginas, controles e classes por padrão, mas você pode adicioná-los manualmente.
Desenvolvimento
  • Você copia o assembly para o servidor. O assembly é produzido através da compilação do aplicativo.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.
  • Você copia os arquivos de origem do aplicativo em um computador que tem o IIS instalado.
  • Se você pré-compilar o site em um computador de desenvolvimento, você pode copiar os assemblies produzidas por compilação para o servidor IIS.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.

Estrutura de Arquivos

Web Application Projects usam arquivos de projeto do Visual Studio (. Csproj ou. Vbproj) para acompanhar as informações sobre o projeto. Isso torna possível especificar quais arquivos são incluídos ou excluídos do projeto e, portanto, os arquivos que são criados durante uma compilação.

Para Web Site Projects todos os arquivos em uma estrutura de pastas são automaticamente considerados para serem incluídos no site. Se você quiser excluir algo da compilação, você deve remover o arquivo da pasta do projeto do web site ou alterar a sua extensão de nome de arquivo para uma extensão que não é compilado e não é enviado ao IIS.

Uma vantagem de usar arquivos de projeto em Web Application Projects é o seguinte:

  • É fácil de remover temporariamente os arquivos do site, mas ainda certificar-se de que você não perdê-los, porque eles permanecem na estrutura da pasta. Por exemplo, se uma página não está pronta para ser implantada, você pode excluí-la temporariamente a partir da compilação sem excluí-la da estrutura da pasta. Você pode implantar o assembly compilado e em seguida incluir o arquivo no projeto novamente. Isto é especialmente importante se você estiver trabalhando com um repositório de source control.

Uma vantagem de usar estrutura de pastas sem arquivos de projeto em Web Site Projects é o seguinte:

  • Você não tem que gerenciar a estrutura do projeto exclusivamente no Visual Studio. Por exemplo, você pode copiar os arquivos para o projeto ou excluí-los do projeto usando o File Explorer.

Compilação

Para Web Application Projects, você normalmente pode compilar o projeto no Visual Studio ou usando um ASP.Net batch compiler em um computador que não é o servidor IIS de produção. Todos os arquivos de classe code-behind e arquivos de classe standalone no projeto são compilados em um único assembly, que é então colocado na pasta Bin do Web Application Projects. (Os arquivos. Aspx e. Ascx são compilados dinamicamente de forma semelhante ao que é feito para Web Site Projects.)

Para Web Site Projects, você não tem que compilar manualmente o projeto. Web Site Projects normalmente são compilados dinamicamente pelo ASP.NET (tanto no computador de desenvolvimento e servidor IIS de produção). Você pode escolher entre o modo de compilação em lotes, que normalmente produz um assembly por pasta e modo de compilação fixa, que normalmente produz um assembly para cada página ou user control.

Vantagens do modelo de compilação de Web Application Projects incluem o seguinte:

    • Você pode usar o MSBuild para criar um custom batch-compilation process.
    • É fácil especificar os atributos do assembly, tais como nome e versão.
    • Compilando com antecedência garante que os usuários não tenham que esperar enquanto o site compila no servidor de produção. (Se o site é muito grande, compilação dinâmica de um Web Site Project pode levar uma quantidade considerável de tempo. Compilação dinâmica ocorre quando um request para um site é recebido após uma atualização, o request que desencadeia a compilação pode ser retardado enquanto os recursos necessários são compilados. Se o atraso for inaceitável, é possível pré-compilar o site. No entanto, em seguida, algumas das vantagens da compilação dinâmica são perdidas.)
    • Você tem o controle completo sobre onde colocar os arquivos de código fonte na estrutura de pasta do projeto e como as classes no projeto referem-se uns aos outros. (Compilação dinâmica requer que o código fonte para todas as classes que são usados em todo o site deve estar na pasta App_Code).

Vantagens do modelo de compilação para Web Site Projects incluem o seguinte:

    • Você pode testar as páginas específicas, independentemente do estado de outras páginas. Isso ocorre porque a rodar uma página individual não requer que todo o site seja compilado com sucesso, apenas a página e quaisquer componentes que depende, como o código na pasta App_Code ou no Global.asax. (Em um Web Application Project, se houver erros de compilação em qualquer lugar do site, você não pode criar os assemblies e, portanto, não pode testar até mesmo as partes do site que compilaram.)
    • É fácil atualizar um site em produção. Você pode atualizar os arquivos de código fonte individuais no servidor de produção sem ter que recompilar explicitamente o site. Você pode atualizar arquivos individuais que estão prontos para a implantação, mesmo que outros arquivos não estejam prontos devido a erros de compilação. Você também pode abrir o site no servidor IIS de produção diretamente no Visual Studio e atualizar o site em tempo real.
    • Pré-compilação de vários assemblies pode ter uma vantagem de desempenho em alguns cenários. Um exemplo típico é um site que tem muitas páginas com um monte de código escrito para eles. A maioria das páginas raramente são solicitadas e só algumas são usadas com freqüência. Se você compilar um site como este em várias assemblies o servidor de produção pode carregar apenas os assemblies que são necessários para as requisições atuais. Se uma página não é solicitada, a sua assembly correspondente não será carregada.
Nota
Não há diferença de desempenho entre um Web Site Project e um Web Application Project. As únicas exceções significativas são as que já foram observadas e por uma questão prática que se aplicam apenas aos sites muito grandes. O primeiro request para o web site pode requerer o site a ser compilado, o que pode resultar em um atraso. Se o site está sendo executado em um servidor IIS que possui pouca memória, possuindo todo o site em um único assembly pode usar mais memória do que seria necessário para vários assemblies.

Deploy

Para realizar o deploy de um Web Application Project, você pode copiar o assembly que é criado ao compilar o projeto para um servidor IIS. Em contraste, para realizar o deploy de um Web Site Project, você pode normalmente copiar os arquivos de origem do projeto para um servidor IIS. (Qualquer uma destas tarefas pode ser feita manualmente ou através de ferramentas de deploy).

Vantagens da estratégia de deploy de Web Application Projects incluem o seguinte:

    • Evitar a exposição de código-fonte no servidor IIS. Em alguns cenários, tais como ambientes de hospedagem compartilhada, você pode estar preocupado com o acesso não autorizado ao código fonte no servidor IIS. (Para um Web Site Project, você pode evitar este risco pré-compilando em um computador de desenvolvimento e realizando o deploy dos assemblies gerados em vez do código fonte. Entretanto, nesse caso, você perde alguns dos benefícios de facilidade de atualizações do site).
    • O deploy muitas vezes envolve outras tarefas além de copiar assemblies ou código para um servidor. Por exemplo, os scripts de banco de dados podem precisar serem executados em produção e connection strings no arquivo Web.config podem precisar serem alteradas para um servidor de produção. O Visual Studio fornece ferramentas que com um clique publicam que trabalham com Web Application Projects para automatizar muitas destas tarefas. Essas ferramentas não estão disponíveis para Web Site Projects.

Vantagens da estratégia de deploy para Web Site Projects incluem o seguinte:

    • Se você fizer uma pequena mudança em um site, você não tem que realizar o deploy de todo o site. Em vez disso, pode copiar apenas o arquivo alterado para o servidor IIS de produção. Você também pode editar arquivos diretamente no servidor de produção. (Como os arquivos de código fonte de um Web Application Projects são compilados em um único arquivo assembly, você deve realizar o deploy de todo o site, mesmo para pequenas mudanças, a menos que a única mudança é para um arquivo aspx ou ascx).

Fonte