Visão geral de migração ASP.NET 2.0
Muitos dos conceitos de programação usados nas versões anteriores do ASP.NET permanecem os mesmos no ASP.NET 2.0, portanto o desenvolvimento de aplicativos em ASP.NET 2.0 será familiarizado para usuários do ASP.NET 1.x.ASP.NET 2.0 será executado nos mesmos sistemas operacionais e hardware que você usa para executar seus aplicativos ASP.NET 1.x, incluindo o Microsoft Windows 2000 Microsoft Internet Information Services (IIS) 5.0, Microsoft Windows XP e IIS 5.1, e Microsoft Windows Server 2003 e o IIS 6.0.
Se você tiver um aplicativo da Web existente que decidiu migrar para o ASP.NET, você deve examinar os novos recursos do ASP.NET 2.0 antes de fazer a migração.Os aspectos mais importantes a considerar envolvem as alterações no modelo code-behind da página, a estrutura de pasta de aplicativo da Web, e o modelo de compilação de página.
Antes de migrar verifique que o aplicativo ASP.NET 1.x possa ser compilado e executado na versão do .NET Framework que ele foi desenvolvido.Além disso, antes de iniciar a migração, garanta que o Microsoft .NET Framework versão 2.0 será instalado e estará funcionando.
Este tópico aborda considerações gerais que devem ser levadas em conta antes de fazer a migração.As seções a seguir são apresentadas neste tópico:
Vantagens de migração
Modelos de página
Compartilhando dados entre versões do ASP.NET
Autenticação de formulários em versões do ASP.NET
Conflitos de nome
Compatibilidade de marcação
HttpOnly e scripts entre sites
Vantagens de migração
Há vários benefícios para migrar o aplicativo da Web para ASP.NET 2.0, incluindo marcação aprimorada e separação de código, pastas reservadas de aplicativo e compilação automática de código.
O novo modelo code-behind com base em classes parciais permite maior separação de marcação e código e remove a necessidade de declarações de controle e ocorre código wire-up em seus arquivos code-behind.No modelo de página ASP.NET de compilação, arquivos code-behind são compilados em tempo de execução em vários módulos (assemblies) na primeira solicitação para os arquivos .aspx correspondentes.
ASP.NET agora usa uma estrutura de aplicativo da Web aprimorada com base em pastas reservadas.Essas pastas contêm conteúdo específico para ajudá-lo a organizar seu aplicativo com mais eficiência.Algumas pastas reservadas, como App_Data, não servem conteúdo em resposta às solicitações da Web mas podem ser acessadas a partir do código do aplicativo.Para obter mais informações, consulte Estrutura do site da Web ASP.NET.
Por padrão, o ASP.NET 2.0 compila automaticamente o código de aplicativos e recursos dependentes quando uma solicitação é feita a um recurso em seu site da Web.Por exemplo, alterações em uma página da Web existente ou recursos dependentes no ASP.NET 2.0 podem simplesmente ser salvos e a página solicitada novamente para a página e seus recursos a serem recompilados.Isso se aplica a recursos como código de arquivos na pasta App_Code, recurso de arquivos nas pastas App_GlobalResources e App_LocalResources, e temas na pasta App_Themes.Para mais informações no modelo de compilação de página, veja Visão geral da Compilação do ASP.NET.
Se você estiver migrando um aplicativo grande, é recomendável usar Visual Web Developer 2005, Visual Web Developer 2005 Express Edition,Visual Studio 2005, ou Visual Studio 2005 Team System, cada um deles possui um assistente de migração que automatiza muitas das tarefas envolvidas em uma migração típica.O assistente faz as alterações necessárias para converter aplicativos da Web ASP.NET 1.x para ASP.NET 2.0.
Não é necessário migrar aplicativos da Web pois ASP.NET 2.0 oferece um alto grau de compatibilidade de versões anteriores com versões anteriores.Se você não migrar, você pode ainda usar muitos dos recursos do ASP.NET 2.0 no seu aplicativo da Web, desde que o aplicativo use o .NET Framework 2.0.Para configurar seu aplicativo da Web existente para usar o.NET Framework 2.0, consulte Como: Executar o ASP.NET 1.x Applications no .NET estrutura 2.0.
Modelos de página
O modelo do ASP.NET de página code-behind da Web permite que você armazene a marcação de uma página da Web em um arquivo – o arquivo .aspx – e o código de programação em outro arquivo – o arquivo code-behind.O modelo code-behind para ASP.NET 2.0 é diferente de versões em que usa um novo recurso de idioma conhecido como classes parciais.O novo modelo code-behind em ASP.NET 2.0 permite ainda maior separação de marcação e código que as versões anteriores do ASP.NET.
Páginas da Web que usam o modelo antigo code-behind baseado no atributo CodeBehind da diretiva @ Page continuarão a funcionar em ASP.NET 2.0.Entretanto, é recomendado que você migre estas páginas para o modelo code-behind usando o atributo CodeFile da diretiva @ Page e a definição da classe parcial no arquivo code-behind para ter a vantagem de melhorar a marcação e a separação de código bem como a compilação automática de código.Páginas da Web que usam o modelo antigo code-behind devem ser compiladas manualmente.
Você pode fazer as alterações manualmente, conforme descrito em Como: Migrar um ASP.NET 1.1 página da Web usando o atributo CodeBehind para o ASP.NET 2.0, ou você pode usar uma das edições Microsoft Visual Studio 2005 que inclui um assistente de migração, como Visual Web Developer 2005 Express Edition.
A versão do ASP.NET 1.1 também suporta uma variante de modelo code-behind no qual o atributo CodeBehind da diretiva @ Page foi substituído com o atributo Src.Uma página da Web usando o atributo Src continuará a funcionar no ASP.NET 2.0 e não requer modificação para ser executada.
Como uma alternativa para o modelo code-behind, o modelo de página de arquivo único coloca a página da marcação e código de programação no mesmo arquivo físico .aspx.Páginas de arquivo único de versões anteriores do ASP.NET continuarão a funcionar no ASP.NET 2.0 e não exigem modificações para serem executadas.
Compartilhando dados entre versões do ASP.NET
Você pode escolher migrar algumas partes do seu site da Web para ASP.NET 2.0, deixando outros inalterados.Se o seu site da Web é dividido em aplicativos da Web independentes trabalhando juntos para fornecer funcionalidade de seu site da Web, você pode decidir migrar alguns aplicativos e outros não.Nesse cenário, você não poderá compartilhar o estado entre aplicativos migrados e aplicativos não migrados do aplicativo.O estado da sessão não será da mesma forma compartilhado entre aplicativos, a menos que você forneça uma solução personalizada de estado de sessão que possa ser acessada a partir do ASP.NET 1.x e páginas ASP.NET 2.0.Para obter mais informações, consulte Implementar um Provedor de Armazenamento de Estado da Sessão.
Autenticação de formulários em versões do ASP.NET
Autenticação de formulários lhe oferece uma maneira de autenticar usuários usando seu próprio código e então manter uma símbolo de autenticação em um cookie ou no URL da página.A autenticação de formulários do ASP.NET pode ser feita para funcionar para todos os aplicativos que executam versões diferentes do ASP.NET assim estes tíquetes de autenticação emitidos por uma versão podem ser consumidos por outra.
Configurar a autenticação para trabalhar em versões do ASP.NET é semelhante ao processo de configurar a autenticação em uma rede de servidores da Web (um Web farm).Em ambos os casos, você define validationKey explicitamente e atributos do decryptionKeyelemento machineKeypara os aplicativos compartilharem permissões de autenticação com a mesma chave.Para oferecer suporte à autenticação entre versões do ASP.NET, você deve fazer o alterações adicionais de configuração definindo o atributo decryption do elemento machineKey para 3DES no arquivo Web.config do aplicativo ASP.NET 2.0.A criptografia padrão para ASP.NET 2.0 é AES,enquanto as versões anteriores do ASP.NET usam 3DES.Para obter mais informações, consulte Visão geral sobre autenticação de formulários ASP.NET.
Conflitos de nome
Antes de migrar, é recomendável que você verifique o aplicativo da Web e procure nomes que entrem em conflito com classes de recurso e namespaces no .NET Framework 2.0.Conflitos podem ocorrer quando nomes comuns, como cache, membros, perfil e função são usados no seu aplicativo da Web mas já estão em uso no .NET Framework.Para evitar um conflito de nomes, localize as referências no seu código para todos os nomes em questão e use uma referência totalmente qualificada.
ASP.NET 2.0 utiliza um layout de site Web diferente das versões anteriores.Para facilitar trabalhar com seu aplicativo, o ASP.NET reserva determinados nomes de arquivos e pastas que você pode usar para tipos específicos de conteúdo.Conteúdo de pastas reservadas não é divulgado às solicitações da Web feitas a ele; isso pode levar a problemas no seu aplicativo existente.Portanto, antes da migração de arquivos de aplicativos individuais é recomendável que você altere os nomes de qualquer uma das suas pastas de aplicativo ou arquivos que entrem em conflito com a pasta reservada ASP.NET 2.0 e nomes de arquivo.Para obter mais informações sobre as pastas reservadas nos layouts de site da Web ASP.NET, consulte Layout de Site Web do ASP.NET.
Compatibilidade de marcação
Por padrão, todas as marcações que são geradas pelo ASP.NET e pelos controles do servidor Web incluídos no ASP.NET, agora estão de acordo com o padrão XHTML Transitional 1.0.Isso pode levar a problemas de processamento HTML não pretendidos depois da migração.Para ajudar na migração de uma aplicativo da Web, você pode definir o atributo do elemento xhtmlConformance para Legacy no arquivo web.config.Isso deve ser uma etapa temporária no processo de migração.A longo prazo, é recomendável executar o aplicativo com o atributo mode do elemento xhtmlConformance definido como Transitional.Além disso, é recomendável que você adicione o elemento DOCTYPE às suas páginas migradas.Para obter mais informações sobre os benefícios de páginas da Web XHTML-conformant, consulte O ASP.NET e o XHTML.
HttpOnly e scripts entre sites
A propriedade HttpOnly da classe HttpCookie é nova no .NET Framework 2.0.A definição dessa propriedade como true pode ajudar atenuar ameaças de scripts entre sites.O HttpOnly é definido como true automaticamente para os cookies de autenticação de formulários e os cookies de sessão de identificação para que esses cookies não fiquem disponíveis para o script do lado do cliente.Se uma página da Web migrada gera uma exceção NullReferenceException, ela pode indicar que a sessão a partir do cliente foi perdida porque a propriedade HttpOnly foi definida como true.Se esse for o caso, você pode usar uma das resoluções da seguir:
Defina a propriedade HttpOnly de cada cookie para false no manipulador de evento EndRequest da classe HttpApplication no arquivo Global.asax.
Escreva um módulo personalizado que copia o cookie para outro cookie e limpa a propriedade HttpOnly para que ele possa ser manipulado pelo script de cliente.
Escreva um gerente de identificação de sessão personalizado que não defina a propriedade HttpOnly como true.
Para obter mais informações sobre a atenuação de script entre sites, consulte Diminuição de script entre sites com cookies HTTP-only.
Consulte também
Conceitos
Visão geral de Projetos de Aplicativos Web
Visão geral sobre autenticação de formulários ASP.NET