Notas de versão do ASP.NET MVC 4 Beta

Este documento descreve o lançamento do ASP.NET MVC 4 Beta para Visual Studio 2010.

Observação

Esta não é a versão mais atual. As notas de versão do ASP.NET MVC 4 RC estão disponíveis aqui.

Notas de instalação

ASP.NET MVC 4 Beta para Visual Studio 2010 pode ser instalado na home page do ASP.NET MVC 4 usando o Web Platform Installer.

Você deve desinstalar as visualizações instaladas anteriormente do ASP.NET MVC 4 antes de instalar o ASP.NET MVC 4 Beta.

Esta versão não é compatível com o .NET Framework 4.5 Developer Preview. Você deve desinstalar o .NET 4.5 Developer Preview antes de instalar o ASP.NET MVC 4 Beta.

ASP.NET MVC 4 pode ser instalado e pode ser executado lado a lado com ASP.NET MVC 3.

Documentação

A documentação do ASP.NET MVC está disponível no site do MSDN na seguinte URL:

https://go.microsoft.com/fwlink/?LinkID=243043

Tutoriais e outras informações sobre ASP.NET MVC estão disponíveis na página MVC 4 do site do ASP.NET (https://www.asp.net/mvc/mvc4).

Suporte

Esta é uma versão prévia e não tem suporte oficial. Se você tiver dúvidas sobre como trabalhar com esta versão, poste-as no fórum do ASP.NET MVC (https://forums.asp.net/1146.aspx), em que os membros da comunidade ASP.NET são frequentemente capazes de fornecer suporte informal.

Requisitos de software

Os componentes do ASP.NET MVC 4 para Visual Studio exigem o PowerShell 2.0 e o Visual Studio 2010 com Service Pack 1 ou Visual Web Developer Express 2010 com Service Pack 1.

Atualizando um projeto do ASP.NET MVC 3 para ASP.NET MVC 4

ASP.NET MVC 4 pode ser instalado lado a lado com ASP.NET MVC 3 no mesmo computador, o que oferece flexibilidade na escolha de quando atualizar um aplicativo MVC 3 ASP.NET para ASP.NET MVC 4.

A maneira mais simples de atualizar é criar um novo projeto ASP.NET MVC 4 e copiar todos os modos de exibição, controladores, código e arquivos de conteúdo do projeto MVC 3 existente para o novo projeto e, em seguida, atualizar as referências de assembly no novo projeto para corresponder ao projeto antigo. Se você tiver feito alterações no arquivo Web.config no projeto MVC 3, também deverá mesclar essas alterações no arquivo Web.config no projeto MVC 4.

Para atualizar manualmente um aplicativo MVC 3 ASP.NET existente para a versão 4, faça o seguinte:

  1. Em todos os arquivos Web.config no projeto (há um na raiz do projeto, um na pasta Exibições e outro na pasta Exibições para cada área do projeto), substitua todas as instâncias do seguinte texto:

    System.Web.Mvc, Version=3.0.0.0
    System.Web.WebPages, Version=1.0.0.0
    System.Web.Helpers, Version=1.0.0.0
    System.Web.WebPages.Razor, Version=1.0.0.0
    

    com o seguinte texto correspondente:

    System.Web.Mvc, Version=4.0.0.0
    System.Web.WebPages, Version=2.0.0.0
    System.Web.Helpers, Version=2.0.0.0,
     System.Web.WebPages.Razor, Version=2.0.0.0,
    
  2. No arquivo de Web.config raiz, atualize o elemento webPages:Version para "2.0.0.0" e adicione uma nova chave PreserveLoginUrl que tenha o valor "true":

    <appSettings>
      <add key="webpages:Version" value="2.0.0.0" />
      <add key="PreserveLoginUrl" value="true" />
    </appSettings>
    
  3. Em Gerenciador de Soluções, exclua a referência a System.Web.Mvc (que aponta para a DLL da versão 3). Em seguida, adicione uma referência a System.Web.Mvc (v4.0.0.0). Em particular, faça as seguintes alterações para atualizar as referências de assembly. Estes são os detalhes:

    1. Em Gerenciador de Soluções, exclua as referências aos seguintes assemblies:

      • System.Web.Mvc(v3.0.0.0)
      • System.Web.WebPages(v1.0.0.0)
      • System.Web.Razor(v1.0.0.0)
      • System.Web.WebPages.Deployment(v1.0.0.0)
      • System.Web.WebPages.Razor(v1.0.0.0)
    2. Adicione uma referência aos seguintes assemblies:

      • System.Web.Mvc(v4.0.0.0)
      • System.Web.WebPages(v2.0.0.0)
      • System.Web.Razor(v2.0.0.0)
      • System.Web.WebPages.Deployment(v2.0.0.0)
      • System.Web.WebPages.Razor(v2.0.0.0)
  4. Em Gerenciador de Soluções, clique com o botão direito do mouse no nome do projeto e selecione Descarregar Projeto. Em seguida, clique com o botão direito do mouse no nome novamente e selecione Editar ProjectName.csproj.

  5. Localize o elemento ProjectTypeGuids e substitua {E53F8FEA-EAE0-44A6-8774-FFD645390401} por {E3E379DF-F4C6-4180-9B81-6769533ABE47}.

  6. Salve as alterações, feche o arquivo do projeto (.csproj) que você estava editando, clique com o botão direito do mouse no projeto e selecione Recarregar Projeto.

  7. Se o projeto fizer referência a quaisquer bibliotecas de terceiros compiladas usando versões anteriores do ASP.NET MVC, abra o arquivo de Web.config raiz e adicione os três elementos bindingRedirect a seguir na seção de configuração :

    <configuration>
      <!--... elements deleted for clarity ...-->
     
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Helpers" 
                 publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" 
                 publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="4.0.0.0"/>
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.WebPages" 
                 publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
    </configuration>
    

Novos recursos no ASP.NET MVC 4 Beta

Esta seção descreve os recursos que foram introduzidos na versão ASP.NET MVC 4 Beta.

ASP.NET Web API

ASP.NET MVC 4 agora inclui ASP.NET Web API, uma nova estrutura para criar serviços HTTP que podem alcançar uma ampla gama de clientes, incluindo navegadores e dispositivos móveis. ASP.NET Web API também é uma plataforma ideal para a criação de serviços RESTful.

ASP.NET Web API inclui suporte para os seguintes recursos:

  • Modelo de programação HTTP moderno: Acesse e manipule diretamente solicitações e respostas HTTP em suas APIs Web usando um novo modelo de objeto HTTP fortemente tipado. O mesmo modelo de programação e o pipeline HTTP estão simetricamente disponíveis no cliente por meio do novo tipo HttpClient.
  • Suporte completo para rotas: as APIs Web agora dão suporte ao conjunto completo de recursos de rota que sempre fizeram parte da pilha da Web, incluindo parâmetros de rota e restrições. Além disso, o mapeamento para ações tem suporte total para convenções, portanto, você não precisa mais aplicar atributos como [HttpPost] às suas classes e métodos.
  • Negociação de conteúdo: o cliente e o servidor podem trabalhar juntos para determinar o formato certo para os dados que estão sendo retornados de uma API. Fornecemos suporte padrão para formatos codificados em URL de formulário, JSON e XML, e você pode estender esse suporte adicionando seus próprios formatadores ou até mesmo substituir a estratégia de negociação de conteúdo padrão.
  • Associação e validação de modelo: Os associadores de modelo fornecem uma maneira fácil de extrair dados de várias partes de uma solicitação HTTP e converter essas partes de mensagem em objetos .NET que podem ser usados pelas ações da API Web.
  • Filtros: As APIs Web agora dão suporte a filtros, incluindo filtros conhecidos, como o atributo [Authorize]. Você pode criar e conectar seus próprios filtros para ações, autorização e tratamento de exceções.
  • Composição de consulta: Simplesmente retornando IQueryable<T>, sua API Web dará suporte à consulta por meio das convenções de URL do OData.
  • Capacidade de teste aprimorada dos detalhes de HTTP: Em vez de definir detalhes HTTP em objetos de contexto estático, as ações da API Web agora podem funcionar com instâncias de HttpRequestMessage e HttpResponseMessage. Versões genéricas desses objetos também existem para permitir que você trabalhe com seus tipos personalizados, além dos tipos HTTP.
  • IoC (Inversão de Controle) aprimorada por meio de DependencyResolver: A API Web agora usa o padrão de localizador de serviço implementado pelo resolvedor de dependência do MVC para obter instâncias para muitas instalações diferentes.
  • Configuração baseada em código: A configuração da API Web é realizada exclusivamente por meio do código, deixando seus arquivos de configuração limpo.
  • Auto-host: As APIs Web podem ser hospedadas em seu próprio processo, além do IIS, enquanto ainda usam todo o poder de rotas e outros recursos da API Web.

Para obter mais detalhes sobre ASP.NET Web API visite https://www.asp.net/web-api.

ASP.NET aplicativo de página única

ASP.NET MVC 4 agora inclui uma visualização antecipada da experiência para a criação de aplicativos de página única com interações significativas do lado do cliente usando JavaScript e APIs Web. Esse suporte inclui:

  • Um conjunto de bibliotecas JavaScript para interações locais mais avançadas com dados armazenados em cache
  • Componentes adicionais da API Web para unidade de trabalho e suporte a DAL
  • Um modelo de projeto MVC com scaffolding para começar rapidamente

Para obter mais detalhes sobre o suporte ao Aplicativo de Página Única no ASP.NET MVC 4, visite https://www.asp.net/single-page-application.

Aprimoramentos nos modelos de projeto padrão

O modelo usado para criar novos projetos ASP.NET MVC 4 foi atualizado para criar um site mais moderno:

Captura de tela da exibição do navegador do modelo de projeto padrão.

Além das melhorias cosméticas, há funcionalidade aprimorada no novo modelo. O modelo emprega uma técnica chamada renderização adaptável para ter uma boa aparência em navegadores da área de trabalho e em navegadores móveis sem nenhuma personalização.

Captura de tela da exibição do navegador móvel do modelo de projeto padrão.

Para ver a renderização adaptável em ação, você pode usar um emulador móvel ou apenas tentar redimensionar a janela do navegador da área de trabalho para ser menor. Quando a janela do navegador ficar pequena o suficiente, o layout da página será alterado.

Outro aprimoramento no modelo de projeto padrão é o uso do JavaScript para fornecer uma interface do usuário mais avançada. Os links Logon e Registro usados no modelo são exemplos de como usar a caixa de diálogo de interface do usuário do jQuery para apresentar uma tela de logon avançada:

Captura de tela do log do modelo de projeto padrão na tela.

Modelo de projeto móvel

Se você estiver iniciando um novo projeto e quiser criar um site especificamente para navegadores móveis e tablets, poderá usar o novo modelo de projeto de Aplicativo Móvel. Isso se baseia no jQuery Mobile, uma biblioteca de software livre para criar interface do usuário com otimização de toque:

Captura de tela da exibição do navegador móvel do log padrão do modelo de projeto na tela.

Esse modelo contém a mesma estrutura de aplicativo que o modelo de Aplicativo da Internet (e o código do controlador é praticamente idêntico), mas é estilizado usando jQuery Mobile para parecer bem e se comportar bem em dispositivos móveis baseados em toque. Para saber mais sobre como estruturar e estilizar a interface do usuário móvel, consulte o site do projeto jQuery Mobile.

Se você já tiver um site orientado para área de trabalho ao qual deseja adicionar modos de exibição otimizados para dispositivos móveis ou se quiser criar um único site que atenda a modos de exibição com estilos diferentes para navegadores móveis e desktop, poderá usar o novo recurso Modos de Exibição. (Confira a próxima seção.)

Modos de Exibição

O novo recurso Modos de Exibição permite que um aplicativo selecione exibições dependendo do navegador que está fazendo a solicitação. Por exemplo, se um navegador da área de trabalho solicitar a Home page, o aplicativo poderá usar o modelo Views\Home\Index.cshtml. Se um navegador móvel solicitar a Home page, o aplicativo poderá retornar o modelo Views\Home\Index.mobile.cshtml.

Layouts e parciais também podem ser substituídos para tipos de navegador específicos. Por exemplo:

  • Se a pasta Views\Shared contiver os modelos _Layout.cshtml e _Layout.mobile.cshtml, por padrão, o aplicativo usará _Layout.mobile.cshtml durante solicitações de navegadores móveis e _Layout.cshtml durante outras solicitações.
  • Se uma pasta contiver _MyPartial.cshtml e _MyPartial.mobile.cshtml, a instrução @Html.Partial("_MyPartial") renderizará _MyPartial.mobile.cshtml durante solicitações de navegadores móveis e _MyPartial.cshtml durante outras solicitações.

Se você quiser criar modos de exibição, layouts ou exibições parciais mais específicos para outros dispositivos, poderá registrar uma nova instância DefaultDisplayMode para especificar qual nome pesquisar quando uma solicitação atender a condições específicas. Por exemplo, você pode adicionar o seguinte código ao método Application_Start no arquivo Global.asax para registrar a cadeia de caracteres "iPhone" como um modo de exibição que se aplica quando o navegador Apple iPhone faz uma solicitação:

DisplayModeProvider.Instance.Modes.Insert(0, new
DefaultDisplayMode("iPhone")
{
    ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf
        ("iPhone", StringComparison.OrdinalIgnoreCase) >= 0)
 });

Depois que esse código for executado, quando um navegador apple iPhone fizer uma solicitação, seu aplicativo usará o layout Views\Shared\_Layout.iPhone.cshtml (se existir).

jQuery Mobile, o seletor de exibição e a substituição do navegador

O jQuery Mobile é uma biblioteca de código aberto para a criação da interface do usuário da Web com otimização de toque. Se você quiser usar o jQuery Mobile com um aplicativo ASP.NET MVC 4, poderá baixar e instalar um pacote NuGet que ajuda você a começar. Para instalá-lo do Console do Gerenciador de Pacotes do Visual Studio, digite o seguinte comando:

Install-Package jQuery.Mobile.MVC

Isso instala o jQuery Mobile e alguns arquivos auxiliares, incluindo o seguinte:

  • Views/Shared/_Layout.Mobile.cshtml, que é um layout baseado em jQuery Mobile.
  • Um componente de comutador de exibição, que consiste na exibição parcial Views/Shared/_ViewSwitcher.cshtml e no controlador ViewSwitcherController.cs.

Depois de instalar o pacote, execute seu aplicativo usando um navegador móvel (ou equivalente, como o complemento Firefox User Agent Switcher ). Você verá que suas páginas são bem diferentes, pois o jQuery Mobile manipula o layout e o estilo. Para aproveitar isso, você pode fazer o seguinte:

  • Crie substituições de exibição específicas para dispositivos móveis conforme descrito em Modos de Exibição anteriormente (por exemplo, crie Views\Home\Index.mobile.cshtml para substituir Views\Home\Index.cshtml para navegadores móveis).
  • Leia a documentação do jQuery Mobile para saber mais sobre como adicionar elementos de interface do usuário otimizados para toque em exibições móveis.

Uma convenção para páginas da Web otimizadas para dispositivos móveis é adicionar um link cujo texto é algo como Modo de exibição da área de trabalho ou Modo de site completo que permite aos usuários alternar para uma versão da área de trabalho da página. O pacote jQuery.Mobile.MVC inclui um componente de comutador de exibição de exemplo para essa finalidade. Ele é usado na exibição Padrão Views\Shared\_Layout.Mobile.cshtml e tem esta aparência quando a página é renderizada:

Captura de tela do modo de exibição móvel e dos links de exibição da área de trabalho.

Se os visitantes clicarem no link, eles mudarão para a versão da área de trabalho da mesma página.

Como o layout da área de trabalho não incluirá um seletor de modo de exibição por padrão, os visitantes não terão uma maneira de chegar ao modo móvel. Para habilitar isso, adicione a seguinte referência a _ViewSwitcher ao layout da área de trabalho, dentro do <elemento body> :

<body>
    @Html.Partial("_ViewSwitcher")
    ...

O alternador de exibição usa um novo recurso chamado Substituição de Navegador. Esse recurso permite que seu aplicativo trate as solicitações como se elas fossem provenientes de um navegador (agente do usuário) diferente daquela da qual elas realmente são. A tabela a seguir lista os métodos que o Browser Overriding fornece.

HttpContext.SetOverriddenBrowser(userAgentString) Substitui o valor do agente de usuário real da solicitação usando o agente de usuário especificado.
HttpContext.GetOverriddenUserAgent() Retorna o valor de substituição do agente de usuário da solicitação ou a cadeia de caracteres do agente de usuário real se nenhuma substituição tiver sido especificada.
HttpContext.GetOverriddenBrowser() Retorna uma instância HttpBrowserCapabilitiesBase que corresponde ao agente do usuário definido atualmente para a solicitação (real ou substituído). Você pode usar esse valor para obter propriedades como IsMobileDevice.
HttpContext.ClearOverriddenBrowser() Remove qualquer agente de usuário substituído da solicitação atual.

A Substituição de Navegador é um recurso principal do ASP.NET MVC 4 e está disponível mesmo que você não instale o pacote jQuery.Mobile.MVC. No entanto, ele afeta apenas a exibição, o layout e a seleção de exibição parcial — ele não afeta nenhum outro recurso de ASP.NET que depende do objeto Request.Browser .

Por padrão, a substituição de agente do usuário é armazenada usando um cookie. Se você quiser armazenar a substituição em outro lugar (por exemplo, em um banco de dados), poderá substituir o provedor padrão (BrowserOverrideStores.Current). A documentação desse provedor estará disponível para acompanhar uma versão posterior do ASP.NET MVC.

Receitas para geração de código no Visual Studio

O novo recurso Receitas permite que o Visual Studio gere código específico da solução com base em pacotes que você pode instalar usando o NuGet. A estrutura Receitas facilita para os desenvolvedores escrever plug-ins de geração de código, que você também pode usar para substituir os geradores de código internos para Adicionar Área, Adicionar Controlador e Adicionar Exibição. Como as receitas são implantadas como pacotes NuGet, elas podem ser facilmente verificadas no controle do código-fonte e compartilhadas com todos os desenvolvedores no projeto automaticamente. Eles também estão disponíveis por solução.

Suporte a tarefas para controladores assíncronos

Agora você pode escrever métodos de ação assíncrona como métodos únicos que retornam um objeto do tipo Task ou Task<ActionResult>.

Por exemplo, se você estiver usando o Visual C# 5 (ou usando o ASync CTP), poderá criar um método de ação assíncrona semelhante ao seguinte:

public async Task<ActionResult> Index(string city) {
    var newsService = new NewsService();
    var sportsService = new SportsService();
    
    return View("Common",
        new PortalViewModel {
        NewsHeadlines = await newsService.GetHeadlinesAsync(),
        SportsScores = await sportsService.GetScoresAsync()
    });
}

No método de ação anterior, as chamadas para newsService.GetHeadlinesAsync e sportsService.GetScoresAsync são chamadas de forma assíncrona e não bloqueiam um thread do pool de threads.

Métodos de ação assíncrona que retornam instâncias task também podem dar suporte a tempos limite. Para tornar seu método de ação cancelável, adicione um parâmetro do tipo CancellationToken à assinatura do método de ação. O exemplo a seguir mostra um método de ação assíncrona que tem um tempo limite de 2500 milissegundos e que exibe um modo de exibição TimedOut para o cliente se ocorrer um tempo limite.

[AsyncTimeout(2500)]
[HandleError(ExceptionType = typeof(TaskCanceledException), View = "TimedOut")]
public async Task<ActionResult> Index(string city,
    CancellationToken cancellationToken) {
    var newsService = new NewsService();
    var sportsService = new SportsService();
   
    return View("Common",
        new PortalViewModel {
        NewsHeadlines = await newsService.GetHeadlinesAsync(cancellationToken),
        SportsScores = await sportsService.GetScoresAsync(cancellationToken)
    });
}

SDK do Azure

ASP.NET MVC 4 Beta dá suporte à versão de setembro de 2011 1.5 do SDK do Windows Azure.

Problemas conhecidos e alterações interruptivas

  • Depois de instalar ASP.NET MVC 4 Beta, o editor CSHTML/VBHTML no editor CSHTML/VBHTML do Visual Studio 2010 Service Pack 1 CSHTML/VBHTML pode pausar por um longo tempo depois de digitar snippet ou JavaScript dentro de arquivos cshtml ou vbhtml. Isso ocorre apenas em ASP.NET aplicativos MVC 4 que acabaram de ser criados e ainda não foram compilados.

    A solução alternativa é compilar o projeto para obter os assemblies na pasta bin. Observe que, se você limpo o projeto que remove os assemblies da pasta bin, o problema do editor voltará.

    Isso será corrigido na próxima versão.

  • Os modelos do Projeto C# para Visual Studio 11 Beta contêm uma cadeia de conexão incorreta em Global.asax.cs. A conexão padrão especificada no método Application_Start para projetos criados no Visual Studio 11 Beta contém uma cadeia de conexão LocalDB que contém um caractere de barra invertida sem escape (). Isso resulta em um erro de conexão após tentativas de acessar um Entity Framework DbContext, que gera um SqlException.

    Para corrigir esse problema, escape o caractere de barra invertida no método App_Start de Global.asax.cs para que ele leia da seguinte maneira:

    Database.DefaultConnectionFactory = 
       new SqlConnectionFactory(
         "Data Source=(localdb)\\v11.0; Integrated Security=True; MultipleActiveResultSets=True");
    
  • ASP.NET aplicativos MVC 4 direcionados ao .NET 4.5 lançarão um FileLoadException na tentativa de acessar o assembly System.Net.Http.dll quando executado no .NET 4.0. ASP.NET aplicativos MVC 4 criados no .NET 4.5 contêm um redirecionamento de associação que resultará em um FileLoadException que indica "Não foi possível carregar o arquivo ou assembly 'System.Net.Http' ou uma de suas dependências." quando o aplicativo é executado em um sistema com o .NET 4.0 instalado. Para corrigir esse problema, remova o seguinte redirecionamento de associação de web.config:

    <dependentAssembly>
     <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" 
        culture="neutral" />
     <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
    </dependentAssembly>
    

    O elemento de associação de assembly no web.config modificado deve aparecer da seguinte maneira:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <dependentAssembly>
      <assemblyIdentity name="System.Web.Helpers" 
        publicKeyToken="31bf3856ad364e35" />
      <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
     </dependentAssembly>
     <dependentAssembly>
      <assemblyIdentity name="System.Web.Mvc" 
        publicKeyToken="31bf3856ad364e35" />
      <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
     </dependentAssembly>
     <dependentAssembly>
      <assemblyIdentity name="System.Web.WebPages" 
        publicKeyToken="31bf3856ad364e35" />
      <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
     </dependentAssembly>
    </assemblyBinding>
    
  • O modelo de item "Adicionar Controlador" em projetos do Visual Basic gera um namespace incorreto quando invocadode dentro de uma área. Quando você adiciona um controlador a uma área em um projeto MVC ASP.NET que usa o Visual Basic, o modelo de item insere o namespace errado no controlador. O resultado é um erro "arquivo não encontrado" quando você navega para qualquer ação no controlador.

    O namespace gerado omite tudo após o namespace raiz. Por exemplo, o namespace gerado é RootNamespace , mas deve ser RootNamespace.Areas.AreaName.Controllers .

  • Alterações interruptivas no Mecanismo de Exibição do Razor. Como parte de uma reescrita do analisador Razor, os seguintes tipos foram removidos de System.Web.Mvc.Razor:

    • ModelSpan
    • MvcVBRazorCodeGenerator
    • MvcCSharpRazorCodeGenerator
    • MvcVBRazorCodeParser

    Os seguintes métodos também foram removidos:

    • MvcCSharpRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
    • MvcWebPageRazorHost.DecorateCodeGenerator(System.Web.Razor.Generator.RazorCodeGenerator)
    • MvcVBRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
  • Quando WebMatrix.WebData.dll é incluído no diretório /bin de um ASP.NET aplicativos MVC 4, ele assume a URL para autenticação de formulários. Adicionar o assembly WebMatrix.WebData.dll ao seu aplicativo (por exemplo, selecionando "Páginas da Web do ASP.NET com sintaxe razor" ao usar a caixa de diálogo Adicionar Dependências Implantáveis) substituirá o redirecionamento de logon de autenticação para /account/logon em vez de /account/login, conforme esperado pelo padrão ASP.NET Controlador de Conta do MVC. Para evitar esse comportamento e usar a URL especificada já na seção de autenticação do web.config, você pode adicionar um appSetting chamado PreserveLoginUrl e defini-lo como true:

    <appSettings>
        <add key="PreserveLoginUrl" value="true"/>
    </appSettings>
    
  • O gerenciador de pacotes NuGet falha ao tentar instalar ASP.NET MVC 4 para instalações lado a lado do Visual Studio 2010 e do Visual Web Developer 2010. Para executar o Visual Studio 2010 e o Visual Web Developer 2010 lado a lado com ASP.NET MVC 4, você deve instalar ASP.NET MVC 4 depois que ambas as versões do Visual Studio já tiverem sido instaladas.

  • A desinstalação ASP.NET MVC 4 falhará se os pré-requisitos já tiverem sido desinstalados. Para desinstalar ASP.NET MVC 4you deve desinstalar ASP.NET MVC 4 antes de desinstalar o Visual Studio.

  • A execução de um projeto de API Web padrão mostra instruções que direcionam incorretamente o usuário para adicionar rotas usando o método RegisterApis, que não existe. As rotas devem ser adicionadas ao método RegisterRoutes usando a tabela de rotas ASP.NET.

  • Instalar ASP.NET quebras MVC 4 Beta ASP.NET aplicativos MVC 3 RTM. ASP.NET aplicativos MVC 3 que foram criados com a versão RTM (não com a versão ASP.NET Atualização de Ferramentas do MVC 3) exigem as seguintes alterações para trabalhar lado a lado com ASP.NET MVC 4 Beta. Criar o projeto sem fazer essas atualizações resulta em erros de compilação.

    Atualizações necessárias

    1. No arquivo de Web.config raiz, adicione uma nova <entrada appSettings> com a chave webPages:Version e o valor 1.0.0.0.

      <appSettings>
          <add key="webpages:Version" value="1.0.0.0"/>
          <add key="ClientValidationEnabled" value="true"/>
          <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
      </appSettings>
      
    2. Em Gerenciador de Soluções, clique com o botão direito do mouse no nome do projeto e selecione Descarregar Projeto. Em seguida, clique com o botão direito do mouse no nome novamente e selecione Editar ProjectName.csproj.

    3. Localize as seguintes referências de assembly:

      <Reference Include="System.Web.WebPages"/> 
      <Reference Include="System.Web.Helpers" />
      

      Substitua-os pelo seguinte:

      <Reference Include="System.Web.WebPages, Version=1.0.0.0,
      Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL "/> 
      <Reference Include="System.Web.Helpers, Version=1.0.0.0,
      Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
      
    4. Salve as alterações, feche o arquivo do projeto (.csproj) que você estava editando e clique com o botão direito do mouse no projeto e selecione Recarregar.