Notas de Lançamento do ASP.NET e Ferramentas Web para o Visual Studio 2013
por Microsoft
Este documento descreve o lançamento do ASP.NET e Web Tools para Visual Studio 2013.
Índice
Novos recursos no ASP.NET e ferramentas da Web para Visual Studio 2013
- One ASP.NET
- Nova Experiência em Projetos Web
- ASP.NET Andaimes
- Link do Navegador
- Aprimoramentos do Editor da Web do Visual Studio
- Suporte a Aplicativos Web do Serviço de Aplicativo do Azure no Visual Studio
- Aprimoramentos de publicação na Web
- NuGet 2.7
- ASP.NET Web Forms
- ASP.NET MVC 5
- ASP.NET Web API 2
- ASP.NET SignalR
- ASP.NET Identidade
- Componentes Microsoft OWIN
- Entity Framework 6
- ASP.NET Razor 3
- ASP.NET Aplicação Suspender
- Problemas conhecidos e alterações recentes
Notas de instalação
ASP.NET e Web Tools for Visual Studio 2013 estão agrupadas no instalador principal e podem ser baixadas aqui.
Documentação
Tutoriais e outras informações sobre ASP.NET e ferramentas da Web para Visual Studio 2013 estão disponíveis no site da ASP.NET.
Requisitos de software
ASP.NET and Web Tools requer o Visual Studio 2013.
Novos recursos no ASP.NET e ferramentas da Web para Visual Studio 2013
As seções a seguir descrevem os recursos que foram introduzidos na versão.
Um só ASP.NET
Com o lançamento do Visual Studio 2013, demos um passo para unificar a experiência de usar tecnologias ASP.NET, para que você possa facilmente misturar e combinar as que deseja. Por exemplo, você pode iniciar um projeto usando MVC e facilmente adicionar páginas de Web Forms ao projeto mais tarde, ou scaffold Web APIs em um projeto de Web Forms. One ASP.NET é sobre facilitar a sua vida como desenvolvedor, permitindo que faça o que ama em ASP.NET. Não importa qual tecnologia você escolha, você pode ter certeza de que está desenvolvendo a estrutura subjacente confiável do One ASP.NET.
Nova experiência de projeto Web
Aprimoramos a experiência de criação de novos projetos da Web no Visual Studio 2013. Na caixa de diálogo New ASP.NET Web Project você pode selecionar o tipo de projeto desejado, configurar qualquer combinação de tecnologias (Web Forms, MVC, Web API), configurar opções de autenticação e adicionar um projeto de teste de unidade.
A nova caixa de diálogo permite alterar as opções de autenticação padrão para muitos dos modelos. Por exemplo, ao criar um projeto de Web Forms ASP.NET, você pode selecionar qualquer uma das seguintes opções:
- Sem autenticação
- Contas de usuário individuais (ASP.NET associação ou login de provedor social)
- Contas organizacionais (Ative Directory em um aplicativo da Internet)
- Autenticação do Windows (Ative Directory em um aplicativo de intranet)
Para obter mais informações sobre as novas opções de autenticação, consulte ASP.NET Identity mais adiante neste documento.
ASP.NET Scaffolding
ASP.NET Scaffolding é uma estrutura de geração de código para aplicações Web ASP.NET. Ele facilita a adição de código clichê ao seu projeto que interage com um modelo de dados.
Em versões anteriores do Visual Studio, o scaffolding era limitado a projetos MVC de ASP.NET. Com o Visual Studio 2013, agora você pode usar andaimes para qualquer projeto ASP.NET, incluindo Web Forms. Atualmente, o Visual Studio 2013 não oferece suporte à geração de páginas para um projeto de Web Forms, mas você ainda pode usar scaffolding com Web Forms adicionando dependências MVC ao projeto. O suporte para gerar páginas para Web Forms será adicionado em uma atualização futura.
Ao usar andaimes, garantimos que todas as dependências necessárias sejam instaladas no projeto. Por exemplo, se você começar com um projeto ASP.NET Web Forms e, em seguida, usar scaffolding para adicionar um controlador de API Web, os pacotes e referências NuGet necessários serão adicionados ao seu projeto automaticamente.
Para adicionar scaffolding MVC a um projeto Web Forms, adicione um Novo Item de Estrutura e selecione Dependências do MVC 5 na janela de diálogo. Existem duas opções de scaffolding MVC: Mínimo e Completo. Se você selecionar Mínimo, somente os pacotes NuGet e as referências para ASP.NET MVC serão adicionados ao seu projeto. Se você selecionar a opção Completo, as dependências mínimas serão adicionadas, bem como os arquivos de conteúdo necessários para um projeto MVC.
O suporte para controladores assíncronos de andaime usa os novos recursos assíncronos do Entity Framework 6.
Para mais informações e tutoriais, consulte Visão geral do ASP.NET Scaffolding.
Browser Link – Canal SignalR entre o navegador e o Visual Studio
O novo recurso Browser Link permite conectar vários navegadores ao Visual Studio e atualizá-los todos clicando em um botão na barra de ferramentas. Você pode conectar vários navegadores ao seu site de desenvolvimento, incluindo emuladores móveis, e clicar em atualizar para atualizar todos os navegadores ao mesmo tempo. O Browser Link também expõe uma API para permitir que os desenvolvedores escrevam extensões do Browser Link.
Ao permitir que os desenvolvedores aproveitem a API do Browser Link, torna-se possível criar cenários muito avançados que cruzam os limites entre o Visual Studio e qualquer navegador conectado. O Web Essentials aproveita a API para criar uma experiência integrada entre o Visual Studio e as ferramentas de desenvolvedor do navegador, emuladores móveis de controle remoto e muito mais.
Aprimoramentos do Editor Web do Visual Studio
O Visual Studio 2013 inclui um novo editor de HTML para arquivos Razor e arquivos HTML em aplicativos Web. O novo editor de HTML fornece um único esquema unificado baseado em HTML5. Ele tem preenchimento automático de chaves, jQuery UI e atributo AngularJS IntelliSense, atributo IntelliSense Grouping, ID e nome da classe Intellisense, e outras melhorias, incluindo melhor desempenho, formatação e SmartTags.
A captura de tela a seguir demonstra o uso do atributo Bootstrap IntelliSense no editor de HTML.
O Visual Studio 2013 também vem com editores CoffeeScript e LESS integrados. O editor LESS vem com todos os recursos interessantes do editor CSS e tem Intellisense específico para variáveis e mixins em todos os documentos LESS na cadeia de @import.
Suporte a Aplicativos Web do Serviço de Aplicativo do Azure no Visual Studio
No Visual Studio 2013 com o SDK do Azure para .NET 2.2, você pode usar Server Explorer para interagir diretamente com seus aplicativos Web remotos. Pode iniciar sessão na sua conta do Azure, criar novas aplicações Web, configurar aplicações, ver registos em tempo real e muito mais. Logo após o lançamento do SDK 2.2, você poderá executar no modo de depuração remotamente no Azure. A maioria dos novos recursos dos Aplicativos Web do Serviço de Aplicativo do Azure também funciona no Visual Studio 2012 quando você instala a versão atual do SDK do Azure para .NET.
Para obter mais informações, consulte os seguintes recursos:
- Criar um aplicativo Web ASP.NET no Serviço de Aplicativo do Azure
- Solucionar problemas de um aplicativo Web no Serviço de Aplicativo do Azure usando o Visual Studio
Aprimoramentos de publicação na Web
O Visual Studio 2013 inclui recursos novos e aprimorados de publicação na Web. Aqui estão alguns deles:
- Automatize a encriptação de ficheiros
Web.config facilmente. (Este link e os dois a seguir apontam para a documentação no MSDN que pode não estar disponível até o final do dia 17/10.) - Automatize facilmente colocar um aplicativo offline durante a implantação.
- Configure a Implantação da Web para usar a soma de verificação de arquivo em vez da de data da última alteração para determinar quais arquivos devem ser copiados para o servidor.
- Publique rapidamente arquivos individuais selecionados (incluindo Web.config) ao utilizar métodos de publicação como FTP, sistema de arquivos ou Web Deploy.
Para obter mais informações sobre a implantação de aplicações web ASP.NET, consulte site ASP.NET.
NuGet 2.7
O NuGet 2.7 inclui um rico conjunto de novos recursos que são descritos em detalhes em Notas de versão do NuGet 2.7.
Esta versão do NuGet também elimina a necessidade de fornecer consentimento explícito para o recurso de restauração de pacotes do NuGet para baixar pacotes. O consentimento (e a caixa de seleção associada na caixa de diálogo de preferências do NuGet) agora é concedido pela instalação do NuGet. Agora, a restauração de pacotes simplesmente funciona por padrão.
ASP.NET Web Forms
One ASP.NET
Os modelos de projeto Web Forms integram-se perfeitamente com a nova experiência One ASP.NET. Você pode adicionar suporte a MVC e API da Web ao seu projeto de Web Forms e pode configurar a autenticação usando o assistente de criação de projeto One ASP.NET.
ASP.NET Identidade
Os modelos de projeto Web Forms suportam a nova estrutura ASP.NET Identity. Além disso, os modelos agora suportam a criação de um projeto de intranet de Web Forms.
Bootstrap
Os modelos de Web Forms usam Bootstrap para fornecer uma aparência elegante e responsiva que você pode personalizar facilmente.
ASP.NET MVC 5
One ASP.NET
Os modelos de projeto Web MVC integram-se perfeitamente com a nova experiência One ASP.NET. Você pode personalizar seu projeto MVC e configurar a autenticação usando o assistente de criação de projeto One ASP.NET. Um tutorial introdutório para ASP.NET MVC 5 pode ser encontrado em Introdução ao ASP.NET MVC 5.
Para obter informações sobre como atualizar projetos MVC 4 para MVC 5, consulte How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2.
ASP.NET Identidade
Os modelos de projeto MVC foram atualizados para usar ASP.NET Identity para autenticação e gerenciamento de identidade. Um tutorial que apresenta a autenticação do Facebook e do Google e a nova API de adesão está disponível em Crie um aplicativo MVC 5 ASP.NET com Facebook e Google OAuth2 e Autenticação OpenID e Crie um aplicativo MVC ASP.NET com autenticação e Banco de Dados SQL e implante no Serviço de Aplicativo do Azure.
Bootstrap
O modelo de projeto MVC foi atualizado para usar Bootstrap para fornecer uma aparência elegante e responsiva que você pode personalizar facilmente.
Filtros de autenticação
Os filtros de autenticação são um novo tipo de filtro em ASP.NET MVC que é executado antes dos filtros de autorização no pipeline MVC ASP.NET e permitem especificar a lógica de autenticação por ação, por controlador ou globalmente para todos os controladores. Os filtros de autenticação processam credenciais na solicitação e fornecem uma entidade correspondente. Os filtros de autenticação também podem adicionar desafios de autenticação em resposta a solicitações não autorizadas.
Substituições de filtro
Agora você pode substituir quais filtros se aplicam a um determinado método de ação ou controlador especificando um filtro de substituição. Os filtros de substituição especificam um conjunto de tipos de filtros que não devem ser executados para um determinado escopo (ação ou controlador). Isso permite configurar filtros que se aplicam globalmente, mas excluem determinados filtros globais da aplicação a ações ou controladores específicos.
Roteamento de atributos
ASP.NET MVC agora suporta roteamento de atributos, graças a uma contribuição de Tim McCall, o autor de http://attributerouting.net. Com o roteamento de atributos, você pode especificar suas rotas anotando suas ações e controladores.
ASP.NET Web API 2
Roteamento de atributos
ASP.NET API Web agora suporta roteamento de atributos, graças a uma contribuição de Tim McCall, o autor de http://attributerouting.net. Com o roteamento de atributos, você pode especificar suas rotas de API da Web anotando suas ações e controladores da seguinte forma:
[RoutePrefix("orders")]
public class OrdersController : ApiController
{
[Route("{id}")]
public Order Get(int id) { }
[Route("{id}/approve")]
public Order Approve(int id) { }
}
O roteamento de atributos oferece mais controle sobre os URIs em sua API da Web. Por exemplo, você pode definir facilmente uma hierarquia de recursos usando um único controlador de API:
public class MoviesController : ApiController
{
[Route("movies")]
public IEnumerable<Movie> Get() { }
[Route("actors/{actorId}/movies")]
public IEnumerable<Movie> GetByActor(int actorId) { }
[Route("directors/{directorId}/movies")]
public IEnumerable<Movie> GetByDirector(int directorId) { }
}
O roteamento de atributos também fornece uma sintaxe conveniente para especificar parâmetros opcionais, valores padrão e restrições de rota:
// Optional parameter
[Route("people/{name?}")]
// Default value
[Route("people/{name=Dan}")]
// Constraint: Alphabetic characters only.
[Route("people/{name:alpha}")]
Para obter mais informações sobre roteamento de atributos, consulte Roteamento de atributos na API Web 2.
OAuth 2.0
Os modelos de projeto API Web e Aplicativo de Página Única agora oferecem suporte à autorização usando OAuth 2.0. O OAuth 2.0 é uma estrutura para autorizar o acesso do cliente a recursos protegidos. Ele funciona para uma variedade de clientes, incluindo navegadores e dispositivos móveis.
O suporte para OAuth 2.0 é baseado no novo middleware de segurança fornecido pelo Microsoft OWIN Components para autenticação de portador e implementação da função de servidor de autorização. Como alternativa, os clientes podem ser autorizados usando um servidor de autorização organizacional, como o Azure Ative Directory ou o ADFS no Windows Server 2012 R2.
Melhorias no OData
Suporte para $select, $expand, $batch e $value
ASP.NET API Web OData agora tem suporte total para $select, $expand e $value. Você também pode usar o $batch para solicitar lotes e processar conjuntos de alterações.
As opções $select e $expand permitem alterar a forma dos dados retornados de um endpoint OData. Para obter mais informações, consulte Introdução ao suporte para $select e $expand no Web API OData.
Extensibilidade melhorada
Os formatadores OData são agora extensíveis. Você pode adicionar metadados de entrada Atom, dar suporte a entradas de fluxo nomeado e link de mídia, adicionar anotações de instância e personalizar como os links são gerados.
Suporte sem tipo
Agora você pode criar serviços OData sem precisar definir tipos CLR para seus tipos de entidade. Em vez disso, os controladores OData podem tomar ou retornar instâncias de IEdmObject, que os formatadores OData serializam/desserializam.
Reutilizar um modelo existente
Se você já tiver um modelo de dados de entidade (EDM) existente, agora poderá reutilizá-lo diretamente, em vez de ter que criar um novo. Por exemplo, se você estiver usando o Entity Framework, poderá usar o EDM que o EF cria para você.
Solicitar Batching
O processamento em lote de solicitações combina várias operações em uma única solicitação HTTP POST, para reduzir o tráfego de rede e fornecer uma interface de usuário mais suave e menos tagarela. ASP.NET API Web agora suporta várias estratégias para processamento em lote de solicitações:
- Utilize o ponto de extremidade $batch de um serviço OData.
- Empacote várias solicitações em uma única solicitação de várias partes MIME.
- Use um formato de lote personalizado.
Para habilitar o processamento em lote de solicitações, basta adicionar uma rota com um manipulador de lotes à configuração da API Web:
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpBatchRoute(
routeName: "WebApiBatch",
routeTemplate: "api/batch",
batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer));
}
}
Você também pode controlar se as solicitações são executadas sequencialmente ou em qualquer ordem.
Cliente de API Web ASP.NET portátil
Agora você pode usar o ASP.NET Web API Client para criar bibliotecas de classes portáteis que funcionam em seus aplicativos da Windows Store e do Windows Phone 8. Você também pode criar formatters portáteis que podem ser compartilhados entre cliente e servidor.
Capacidade de teste melhorada
A API Web 2 torna muito mais fácil testar em unidade seus controladores de API. Basta instanciar seu controlador de API com sua mensagem de solicitação e configuração e, em seguida, chamar o método de ação que você deseja testar. Também é fácil simular a classe UrlHelper, para métodos de ação que executam a geração de links.
IHttpActionResult
Agora você pode implementar IHttpActionResult para encapsular o resultado de seus métodos de ação de API Web. Um IHttpActionResult retornado de um método de ação da API da Web é executado pelo runtime da API Web ASP.NET para gerar a mensagem de resposta resultante. Um IHttpActionResult pode ser retornado de qualquer ação de API Web para simplificar o teste de unidade de sua implementação de API Web. Por conveniência, várias implementações IHttpActionResult são fornecidas prontamente, incluindo resultados para retornar códigos de status específicos, conteúdo formatado ou respostas negociadas por conteúdo.
HttpRequestContext
O novo HttpRequestContext rastreia qualquer estado que esteja vinculado à solicitação, mas não esteja imediatamente disponível na solicitação. Por exemplo, você pode usar o HttpRequestContext para obter dados de rota, a entidade de segurança associada à solicitação, o certificado do cliente, o UrlHelper e a raiz do caminho virtual. Você pode criar facilmente um HttpRequestContext para fins de testes unitários.
Como o principal da solicitação acompanha a solicitação em vez de depender de Thread.CurrentPrincipal, ele agora está disponível durante todo o tempo de vida da solicitação enquanto estiver no pipeline da API Web.
CORS
Graças a outra grande contribuição de Brock Allen, ASP.NET agora suporta totalmente o Cross Origin Request Sharing (CORS).
A segurança do navegador impede que uma página da Web faça solicitações AJAX para outro domínio. CORS é um padrão W3C que permite que um servidor relaxe a política de mesma origem. Usando o CORS, um servidor pode permitir explicitamente algumas solicitações de origem cruzada enquanto rejeita outras.
A Web API 2 agora suporta CORS, incluindo a manipulação automática de pedidos preflight. Para obter mais informações, consulte Habilitando solicitações entre origens em ASP.NET API Web.
Filtros de autenticação
Os filtros de autenticação são um novo tipo de filtro em ASP.NET API Web que é executado antes dos filtros de autorização no pipeline da API Web ASP.NET e permite especificar a lógica de autenticação por ação, por controlador ou globalmente para todos os controladores. Os filtros de autenticação processam credenciais na solicitação e fornecem uma entidade correspondente. Os filtros de autenticação também podem adicionar desafios de autenticação em resposta a solicitações não autorizadas.
Substituições de filtro
Agora você pode substituir quais filtros se aplicam a um determinado método de ação ou controlador, especificando um filtro de substituição. Os filtros de substituição especificam um conjunto de tipos de filtro que não devem ser executados para um determinado escopo (ação ou controlador). Isso permite que você adicione filtros globais, mas exclua alguns de ações ou controladores específicos.
Integração OWIN
ASP.NET API Web agora suporta totalmente OWIN e pode ser executada em qualquer host compatível com OWIN. Também está incluído um HostAuthenticationFilter que fornece integração com o sistema de autenticação OWIN.
Com a integração OWIN, pode hospedar diretamente a API Web no seu próprio processo juntamente com outro middleware OWIN, como SignalR. Para obter mais informações, consulte Utilizar o OWIN para Self-Host API Web do ASP.NET.
ASP.NET SignalR 2.0
As seções a seguir descrevem os recursos do SignalR 2.0.
- Construído sobre OWIN
- MapHubs e MapConnection agora são MapSignalR
- Suporte entre domínios
- suporte iOS e Android via MonoTouch e MonoDroid
- Cliente .NET Portátil
- Novo pacote Self-Host
- Suporte a servidores compatíveis com versões anteriores
- Suporte de servidor removido para .NET 4.0
- Enviar uma mensagem para uma lista de clientes e grupos
- Enviar uma mensagem para um usuário específico
- Melhor suporte ao tratamento de erros
- Teste de unidades de hubs mais fácil
- Manipulação de erros em JavaScript
Para obter um exemplo de como atualizar um projeto 1.x existente para o SignalR 2.0, consulte Atualizando um projeto SignalR 1.x.
Construído em OWIN
O SignalR 2.0 é construído completamente sobre OWIN (Open Web Interface for .NET). Essa alteração torna o processo de configuração do SignalR muito mais consistente entre aplicativos SignalR hospedados na Web e auto-hospedados, mas também exigiu várias alterações na API.
MapHubs e MapConnection agora são MapSignalR
Para compatibilidade com os padrões OWIN, esses métodos foram renomeados para MapSignalR.
MapSignalR chamado sem parâmetros mapeará todos os hubs (assim como MapHubs faz na versão 1.x); para mapear objetos individuais PersistentConnection, indique o tipo de conexão como parâmetro e a extensão de URL para a conexão como o primeiro argumento.
O método MapSignalR é chamado numa classe de inicialização Owin. Visual Studio 2013 contém um novo modelo para uma classe de inicialização Owin; Para usar esse modelo, faça o seguinte:
- Clique com o botão direito do rato no projeto
- Selecione Adicionar, Novo Item...
- Selecione classe Owin Startup. Nomeie a nova classe Startup.cs.
Em um aplicativo Web , a classe de inicialização Owin que contém o método MapSignalR é então adicionada ao processo de inicialização do Owin usando uma entrada no nó de configurações do aplicativo do arquivo Web.Config, conforme mostrado abaixo.
Em um aplicativo autogerido, a classe Startup é passada como o parâmetro de tipo do método WebApp.Start.
Mapeamento de hubs e conexões no SignalR 1.x (a partir do arquivo de aplicativo global em um aplicativo Web):
protected void Application_Start(object sender, EventArgs e)
{
// Map all hubs to "/signalr"
RouteTable.Routes.MapHubs();
// Map the Echo PersistentConnection to "/echo"
RouteTable.Routes.MapConnection<myconnection>("echo", "/echo");
}
Mapeando hubs e conexões no SignalR 2.0 (a partir de um arquivo de classe Owin Startup):
using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;
[assembly: OwinStartup(typeof(MyWebApplication.Startup))]
namespace MyWebApplication
{
public class Startup
{
public void Configuration(IAppBuilder app)
{
// Map all hubs to "/signalr"
app.MapSignalR();
// Map the Echo PersistentConnection to "/echo"
app.MapSignalR<echoconnection>("/echo");
}
}
}
Em uma aplicação auto-hospedada, a classe Startup é passada como o parâmetro de tipo para o método WebApp.Start, conforme mostrado abaixo.
string url = "http://localhost:8080";
using (WebApp.Start<startup>(url))
{
Console.WriteLine("Server running on {0}", url);
Console.ReadLine();
}
Suporte entre domínios
No SignalR 1.x, as solicitações entre domínios eram controladas por um único sinalizador EnableCrossDomain. Esse sinalizador controlava as solicitações JSONP e CORS. Para maior flexibilidade, todo o suporte a CORS foi removido do componente de servidor do SignalR (clientes JavaScript ainda usam CORS normalmente se for detetado que o navegador o suporta), e um novo middleware OWIN foi disponibilizado para suportar esses cenários.
No SignalR 2.0, se o JSONP for necessário no cliente (para suportar solicitações entre domínios em navegadores mais antigos), ele precisará ser habilitado explicitamente definindo EnableJSONP no objeto HubConfiguration para true, conforme mostrado abaixo. O JSONP está desativado por padrão, pois é menos seguro que o CORS.
Para adicionar o novo middleware CORS no SignalR 2.0, adicione a biblioteca Microsoft.Owin.Cors ao seu projeto e chame UseCors antes do middleware do SignalR, conforme mostrado na seção abaixo.
Adicionando Microsoft.Owin.Cors ao seu projeto: Para instalar essa biblioteca, execute o seguinte comando no Console do Gerenciador de Pacotes:
Install-Package Microsoft.Owin.Cors
Este comando adicionará a versão 2.0.0 do pacote ao seu projeto.
Chamando UseCors
Os trechos de código a seguir demonstram como implementar conexões entre domínios no SignalR 1.x e 2.0.
Implementando solicitações entre domínios no SignalR 1.x (a partir do arquivo de aplicativo global)
protected void Application_Start(object sender, EventArgs e)
{
var hubConfiguration = new HubConfiguration();
hubConfiguration.EnableCrossDomain = true;
RouteTable.Routes.MapHubs(hubConfiguration);
}
Implementando solicitações entre domínios no SignalR 2.0 (a partir de um arquivo de código C#)
O código a seguir demonstra como habilitar CORS ou JSONP em um projeto SignalR 2.0. Este exemplo de código usa Map e RunSignalR em vez de MapSignalR, para que o middleware CORS seja executado apenas para as solicitações SignalR que exigem suporte a CORS (em vez de todo o tráfego no caminho especificado em MapSignalR.) Map também pode ser usado para qualquer outro middleware que precise ser executado para um prefixo de URL específico, em vez de para todo o aplicativo.
using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Cors;
using Owin;
[assembly: OwinStartup(typeof(MyWebApplication.Startup))]
namespace MyWebApplication
{
public class Startup
{
public void Configuration(IAppBuilder app)
{
// Branch the pipeline here for requests that start with "/signalr"
app.Map("/signalr", map =>
{
// Setup the CORS middleware to run before SignalR.
// By default this will allow all origins. You can
// configure the set of origins and/or http verbs by
// providing a cors options with a different policy.
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration
{
// You can enable JSONP by uncommenting line below.
// JSONP requests are insecure but some older browsers (and some
// versions of IE) require JSONP to work cross domain
// EnableJSONP = true
};
// Run the SignalR pipeline. We're not using MapSignalR
// since this branch already runs under the "/signalr"
// path.
map.RunSignalR(hubConfiguration);
});
}
}
}
Suporte iOS e Android via MonoTouch e MonoDroid
Importante
Xamarin.Android, Xamarin.iOS, Xamarin.Mac agora estão integrados diretamente ao .NET (começando com .NET 6) como .NET para Android, .NET para iOS e .NET para macOS. Se você estiver criando com esses tipos de projeto hoje, eles devem ser atualizados para projetos no estilo SDK do .NET para suporte contínuo. Para obter mais informações sobre como atualizar projetos Xamarin para .NET, consulte a documentação Upgrade from Xamarin to .NET & .NET MAUI.
Foi adicionado suporte para clientes iOS e Android usando componentes MonoTouch e MonoDroid da biblioteca Xamarin. Para obter mais informações sobre como usá-los, consulte Usando componentes Xamarin. Esses componentes estarão disponíveis no Xamarin Store quando a versão RTW do SignalR estiver disponível.
Para facilitar melhor o desenvolvimento entre plataformas, os clientes Silverlight, WinRT e Windows Phone foram substituídos por um único cliente .NET portátil que suporta as seguintes plataformas:
- NET 4,5
- Silverlight 5
- WinRT (.NET para aplicativos da Windows Store)
- Windows Phone 8
Novo pacote Self-Host
Agora há um pacote NuGet para facilitar a introdução ao SignalR Self-Host (aplicativos SignalR que são hospedados em um processo ou outro aplicativo, em vez de serem hospedados em um servidor web). Para atualizar um projeto de autohost criado com o SignalR 1.x, remova o pacote Microsoft.AspNet.SignalR.Owin e adicione o pacote Microsoft.AspNet.SignalR.SelfHost. Para obter mais informações sobre como começar a usar o pacote de host automático, consulte Tutorial: SignalR Self-Host.
Suporte a servidores compatíveis com versões anteriores
Em versões anteriores do SignalR, as versões do pacote SignalR usadas no cliente e no servidor precisavam ser idênticas. Para suportar aplicativos thick-client que seriam difíceis de atualizar, o SignalR 2.0 agora suporta o uso de uma versão mais recente do servidor com um cliente mais antigo. Nota: O SignalR 2.0 não suporta servidores construídos com versões mais antigas com clientes mais recentes.
Suporte de servidor removido para .NET 4.0
O SignalR 2.0 descartou o suporte para interoperabilidade de servidor com o .NET 4.0. O .NET 4.5 deve ser usado com servidores SignalR 2.0. Ainda há um cliente .NET 4.0 para SignalR 2.0.
Enviar uma mensagem para uma lista de clientes e grupos
No SignalR 2.0, é possível enviar uma mensagem usando uma lista de IDs de cliente e grupo. Os trechos de código a seguir demonstram como fazer isso.
Enviar uma mensagem para uma lista de clientes e grupos usando o PersistentConnection
using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatConnection : PersistentConnection
{
static List<string> ConnectionIds = new List<string>();
static List<string> groups = new List<string>{"chatGroup", "chatGroup2"};
protected override System.Threading.Tasks.Task OnReceived(IRequest request, string connectionId, string data)
{
Connection.Send(ConnectionIds, data);
Groups.Send(groups, data);
return base.OnReceived(request, connectionId, data);
}
protected override System.Threading.Tasks.Task OnConnected(IRequest request, string connectionId)
{
ConnectionIds.Add(connectionId);
Groups.Add(connectionId, "chatGroup");
return base.OnConnected(request, connectionId);
}
protected override System.Threading.Tasks.Task OnDisconnected(IRequest request, string connectionId)
{
ConnectionIds.Remove(connectionId);
return base.OnDisconnected(request, connectionId);
}
}
Enviar uma mensagem para uma lista de clientes e grupos usando Hubs
using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatHub : Hub
{
static List<string> ConnectionIds = new List<string>();
static List<string> groups = new List<string> { "chatGroup", "chatGroup2" };
public void Send(string name, string message)
{
// Call the broadcastMessage method to update clients.
Clients.Clients(ConnectionIds).broadcastMessage(name, message);
Clients.Groups(groups).broadcastMessage(name, message);
}
public override System.Threading.Tasks.Task OnConnected()
{
ConnectionIds.Add(Context.ConnectionId);
Groups.Add(Context.ConnectionId, "chatGroup");
return base.OnConnected();
}
public override System.Threading.Tasks.Task OnDisconnected()
{
ConnectionIds.Remove(Context.ConnectionId);
return base.OnDisconnected();
}
}
Enviar uma mensagem a um utilizador específico
Este recurso permite que os utilizadores especifiquem em que se baseia o userId, através de um IRequest, usando uma nova interface IUserIdProvider.
A interface IUserIdProvider
public interface IUserIdProvider
{
string GetUserId(IRequest request);
}
Por padrão, haverá uma implementação que usa o IPrincipal.Identity.Name do usuário como o nome de usuário.
Nos hubs, você poderá enviar mensagens para esses usuários por meio de uma nova API:
Usando a API Clients.User
public class MyHub : Hub
{
public void Send(string userId, string message)
{
Clients.User(userId).send(message);
}
}
Melhor suporte ao tratamento de erros
Os utilizadores agora podem lançar HubException a partir de qualquer invocação de hub. O construtor do HubException pode receber uma mensagem de texto e um objeto com dados de erro adicionais. O SignalR serializará automaticamente a exceção e a enviará para o cliente, onde será usada para rejeitar/falhar a chamada do método hub.
O mostrar exceções detalhadas do hub configuração não tem nenhuma relação com HubException sendo enviado de volta ao cliente ou não; é sempre enviado.
Código do lado do servidor demonstrando o envio de um HubException para o cliente
public class MyHub : Hub
{
public void Send(string message)
{
if(message.Contains("<script>"))
{
throw new HubException("This message will flow to the client", new { user = Context.User.Identity.Name, message = message });
}
Clients.All.send(message);
}
}
código do cliente JavaScript demonstrando responder a um HubException enviado do servidor
myHub.server.send("<script>")
.fail(function (e) {
if (e.source === 'HubException') {
console.log(e.message + ' : ' + e.data.user);
}
});
código do cliente .NET demonstrando responder a um HubException enviado do servidor
try
{
await myHub.Invoke("Send", "<script>");
}
catch(HubException ex)
{
Conosle.WriteLine(ex.Message);
}
Testes de unidade de hubs mais fáceis
O SignalR 2.0 inclui uma interface chamada IHubCallerConnectionContext em Hubs que facilita a criação de invocações simuladas do lado do cliente. Os trechos de código a seguir demonstram o uso desta interface com as populares ferramentas de teste xUnit.net e moq.
Teste unitário SignalR com xUnit.net
[Fact]
public void HubsAreMockableViaDynamic()
{
bool sendCalled = false;
var hub = new MyHub();
var mockClients = new Mock<IHubCallerConnectionContext>();
hub.Clients = mockClients.Object;
dynamic all = new ExpandoObject();
all.send = new Action<string>(message =>
{
sendCalled = true;
});
mockClients.Setup(m => m.All).Returns((ExpandoObject)all);
hub.Send("foo");
Assert.True(sendCalled);
}
Testes unitários do SignalR com moq
[Fact]
public interface IClientContract
{
void send(string message);
}
public void HubsAreMockableViaType()
{
var hub = new MyHub();
var mockClients = new Mock<IHubCallerConnectionContext>();
var all = new Mock<IClientContract>();
hub.Clients = mockClients.Object;
all.Setup(m => m.send(It.IsAny<string>())).Verifiable();
mockClients.Setup(m => m.All).Returns(all.Object);
hub.Send("foo");
all.VerifyAll();
Tratamento de erros JavaScript
No SignalR 2.0, todos os retornos de chamada de tratamento de erros JavaScript retornam objetos de erro JavaScript em vez de cadeias de caracteres brutas. Isso permite que o SignalR flua informações mais ricas para seus manipuladores de erros. Você pode obter a exceção interna da propriedade source do erro.
código do cliente JavaScript que manipula a exceção Start.Fail
connection.start().fail(function(e) {
console.log('The error is: ' + e.message);
});
ASP.NET Identidade
Novo Sistema de Membros ASP.NET
ASP.NET Identity é o novo sistema de associação para aplicações ASP.NET. O ASP.NET Identity facilita a integração de dados de perfil específicos do usuário com dados de aplicativos. ASP.NET Identity também permite que você escolha o modelo de persistência para perfis de usuário em seu aplicativo. Você pode armazenar os dados em um banco de dados do SQL Server ou outro armazenamento de dados, incluindo armazenamentos de dados NoSQL, como Tabelas de Armazenamento do Azure. Para obter mais informações, consulte Contas de usuário individuais em Criando projetos Web ASP.NET no Visual Studio 2013.
Autenticação baseada em declarações
ASP.NET agora oferece suporte à autenticação baseada em declarações, onde a identidade do usuário é representada como um conjunto de declarações de um emissor confiável. Os usuários podem ser autenticados usando um nome de usuário e senha mantidos em um banco de dados de aplicativo, ou usando provedores de identidade social (por exemplo: Contas da Microsoft, Facebook, Google, Twitter), ou usando contas organizacionais por meio do Azure Ative Directory ou dos Serviços de Federação do Ative Directory (ADFS).
Integração com o Azure Ative Directory e o Windows Server Ative Directory
Agora você pode criar ASP.NET projetos que usam o Azure Ative Directory ou o Windows Server Ative Directory (AD) para autenticação. Para obter mais informações, consulte Contas Organizacionais em Criando Projetos da Web ASP.NET no Visual Studio 2013.
Integração OWIN
A autenticação do ASP.NET agora é baseada em middleware OWIN, que pode ser usado em qualquer host baseado em OWIN. Para obter mais informações sobre o OWIN, consulte a seção
Componentes Microsoft OWIN
Open Web Interface for .NET (OWIN) define uma abstração entre servidores Web .NET e aplicativos Web. O OWIN separa a aplicação Web do servidor, tornando as aplicações Web agnósticas em relação ao anfitrião. Por exemplo, você pode hospedar um aplicativo Web baseado em OWIN no IIS ou hospedá-lo automaticamente em um processo personalizado.
As alterações introduzidas nos componentes do Microsoft OWIN (também conhecido como o projeto Katana) incluem novos componentes de servidor e host, novas bibliotecas auxiliares e middleware e novo middleware de autenticação.
Para obter mais informações sobre OWIN e Katana, consulte O que há de novo no OWIN e Katana.
Nota: aplicativos OWIN não podem ser executados no modo clássico do IIS; eles devem ser executados no modo integrado.
Nota: aplicativos OWIN devem ser executados em total confiança.
Novos Servidores e Anfitriões
Com esta versão, novos componentes foram adicionados para habilitar cenários de auto-host. Esses componentes incluem os seguintes pacotes NuGet:
- Microsoft.Owin.Host.HttpListener. Fornece um servidor OWIN que usa HttpListener para ouvir solicitações HTTP e direcioná-las para o pipeline OWIN.
- Microsoft.Owin.Hosting Fornece uma biblioteca para desenvolvedores que desejam hospedar automaticamente um pipeline OWIN em um processo personalizado, como um aplicativo de console ou serviço do Windows.
-
OwinHost. Fornece um executável autônomo que encapsula
Microsoft.Owin.Hostinge permite que você hospede automaticamente um pipeline OWIN sem precisar escrever um aplicativo host personalizado.
Além disso, o pacote Microsoft.Owin.Host.SystemWeb agora permite que o middleware forneça dicas para o servidor SystemWeb, indicando que o middleware deve ser chamado durante um estágio de pipeline de ASP.NET específico. Esse recurso é particularmente útil para middleware de autenticação, que deve ser executado no início do pipeline de ASP.NET.
Bibliotecas auxiliares e middleware
Embora você possa escrever componentes OWIN usando apenas as definições de função e tipo da especificação OWIN, o novo pacote Microsoft.Owin fornece um conjunto mais amigável de abstrações. Este pacote combina vários pacotes anteriores (por exemplo, Owin.Extensions, Owin.Types) em um único modelo de objeto bem estruturado que pode ser facilmente usado por outros componentes OWIN. Na verdade, a maioria dos componentes do Microsoft OWIN agora usa este pacote.
Observação
aplicativos OWIN não podem ser executados no modo clássico do IIS; eles devem ser executados no modo integrado.
Observação
aplicações OWIN devem ser executadas em total confiança.
Esta versão também inclui o pacote Microsoft.Owin.Diagnostics, que inclui middleware para validar um aplicativo OWIN em execução, além de middleware de página de erro para ajudar a investigar falhas.
Componentes de autenticação
Os seguintes componentes de autenticação estão disponíveis.
- Microsoft.Owin.Security.ActiveDirectory. Permite a autenticação usando serviços de diretório locais ou baseados em nuvem.
-
Microsoft.Owin.Security.Cookies Permite a autenticação usando cookies. Este pacote foi anteriormente nomeado
Microsoft.Owin.Security.Forms. - Microsoft.Owin.Security.Facebook Permite a autenticação usando o serviço baseado em OAuth do Facebook.
- Microsoft.Owin.Security.Google Permite a autenticação usando o serviço baseado em OpenID do Google.
- Microsoft.Owin.Security.Jwt Habilita a autenticação usando tokens JWT.
- Microsoft.Owin.Security.MicrosoftAccount Habilita a autenticação usando contas da Microsoft.
- Microsoft.Owin.Security.OAuth. Fornece um servidor de autorização OAuth, bem como middleware para a autenticação de tokens de portadores.
- Microsoft.Owin.Security.Twitter Permite a autenticação usando o serviço baseado em OAuth do Twitter.
Esta versão também inclui o pacote Microsoft.Owin.Cors, que contém middleware para processar solicitações HTTP de origem cruzada.
Observação
O suporte para assinatura JWT foi removido na versão final do Visual Studio 2013.
Estrutura de Entidades 6
Para obter uma lista de novos recursos e outras alterações no Entity Framework 6, consulte Histórico de versões do Entity Framework.
ASP.NET Razor 3
ASP.NET Razor 3 inclui os seguintes novos recursos:
- Suporte para edição de guias. Anteriormente, o comando Formatar Documento, a indentação automática e a formatação automática no Visual Studio não funcionavam corretamente ao usar a opção Manter Guias. Essa alteração corrige a formatação do Visual Studio para o código Razor para formatação de guias.
- Suporte para regras de reescrita de URL ao gerar links.
- Remoção do atributo transparente de segurança.
Observação
Esta é uma alteração disruptiva e torna o Razor 3 incompatível com o MVC4 e anteriores, enquanto o Razor 2 é incompatível com o MVC5 ou assemblies compilados contra o MVC5.
=======
Suspensão de Aplicações ASP.NET
ASP.NET App Suspend é um recurso revolucionário no .NET Framework 4.5.1 que muda radicalmente a experiência do usuário e o modelo econômico para hospedar um grande número de sites ASP.NET em uma única máquina. Para obter mais informações, consulte ASP.NET App Suspend – responsive shared .NET web hosting.
Problemas conhecidos e alterações recentes
Esta seção descreve problemas conhecidos e alterações significativas no ASP.NET e Web Tools para Visual Studio 2013.
NuGet
- A restauração de novos pacotes não funciona no Mono ao usar o arquivo SLN – será corrigida num próximo download de nuget.exe e na atualização do pacote NuGet.CommandLine.
- A nova restauração de pacotes não funciona nos projetos Wix – será corrigida em um próximo download nuget.exe e na atualização do pacote NuGet.CommandLine.
ASP.NET Web API
ODataQueryOptions<T>.ApplyTo(IQueryable)não retornaIQueryable<T>sempre, pois adicionamos suporte para$selecte$expand.As nossas amostras anteriores para
ODataQueryOptions<T>converteram sempre o valor de retorno deApplyToparaIQueryable<T>. Isso funcionou anteriormente porque as opções de consulta suportadas anteriormente ($filter,$orderby,$skip,$top) não alteram a forma da consulta. Agora que suportamos$selecte$expando valor de retorno deApplyTonão seráIQueryable<T>sempre.// Sample ODataQueryOptions<T> usage from earlier public IQueryable<Customer> Get(ODataQueryOptions<Customer> query) { IQueryable<customer> result="query.ApplyTo(_customers)" as iqueryable<customer>; return result; }Se você estiver usando o código de exemplo anterior, ele continuará funcionando se o cliente não enviar
$selecte$expand. No entanto, se você deseja apoiar$selecte$expandvocê tem que alterar esse código para este.public IHttpActionResult Get(ODataQueryOptions<Customer> query) { IQueryable result = query.ApplyTo(_customers); return Ok(result, result.GetType()); } private IHttpActionResult Ok(object content, Type type) { Type resultType = typeof(OkNegotiatedContentResult<>).MakeGenericType(type); return Activator.CreateInstance(resultType, content, this) as IHttpActionResult; }Request.Url ou RequestContext.Url é nulo durante uma requisição em lote
Num cenário de processamento em lote, o UrlHelper é nulo quando acessado a partir de Request.Url ou RequestContext.Url.
A solução alternativa para esse problema é criar uma nova instância do UrlHelper, como no exemplo a seguir:
Criando uma nova instância do UrlHelper
if (RequestContext.Url == null) { RequestContext.Url = new UrlHelper(Request); }
ASP.NET MVC
Ao usar MVC5 e OrgAuth, se você tiver visualizações que fazem a validação do AntiForgerToken, poderá se deparar com o seguinte erro ao postar dados na exibição:
Erro:
Erro do servidor no aplicativo '/'.
Uma declaração do tipo
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifierouhttps://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovidernão estava presente na ClaimsIdentity fornecida. Para habilitar o suporte a tokens antifalsificação com autenticação baseada em afirmações, verifique se o provedor de afirmações configurado está a fornecer ambas as afirmações nas instâncias ClaimsIdentity que ele gera. Se, em vez disso, o provedor de declarações configurado usar um tipo de declaração diferente como um identificador exclusivo, ele poderá ser configurado definindo a propriedade estática AntiForgeryConfig.UniqueClaimTypeIdentifier.Solução alternativa:
Adicione a seguinte linha em Global.asax para corrigi-lo:
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;Isso será corrigido para a próxima versão.
Depois de atualizar um aplicativo MVC4 para MVC5, crie a solução e inicie-a. Você verá o seguinte erro:
[A]System.Web.WebPages.Razor.Configuration.HostSection não pode ser convertido para [B]System.Web.WebPages.Razor.Configuration.HostSection. O Type A tem origem em 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' no contexto 'Default' na localização 'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. O tipo B origina-se de 'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' no contexto 'Default' no local 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6d05bbd0\e8b5908e\assembly\dl3\c9cbca63\f8910382_6273ce01\System.Web.WebPages.Razor.dll'.
Para corrigir o erro acima, abra todos os arquivos Web.config (incluindo os da pasta Views) em seu projeto e faça o seguinte:
Atualize todas as ocorrências da versão "4.0.0.0" de "System.Web.Mvc" para "5.0.0.0".
Atualize todas as ocorrências da versão "2.0.0.0" de "System.Web.Helpers", "System.Web.WebPages" e "System.Web.WebPages.Razor" para "3.0.0.0"
Por exemplo, depois de fazer as alterações acima, as ligações de assembly devem ter esta aparência:
<dependentAssembly> <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="5.0.0.0" /> </dependentAssembly>Para obter informações sobre como atualizar projetos MVC 4 para MVC 5, consulte How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2.
Ao usar a validação do lado do cliente com a Validação discreta do jQuery, a mensagem de validação às vezes está incorreta para um elemento de entrada HTML com type='number'. O erro de validação para um valor obrigatório ("O campo Idade é obrigatório") é mostrado quando um número inválido é inserido em vez da mensagem correta de que um número válido é necessário.
Este problema é comumente encontrado com código gerado automaticamente para um modelo com uma propriedade inteira nas vistas Criar e Editar.
Para contornar este problema, altere o assistente do editor de:
@Html.EditorFor(person => person.Age)Para:
@Html.TextBoxFor(person => person.Age)ASP.NET MVC 5 não suporta mais confiança parcial. Os projetos vinculados aos binários MVC ou WebAPI devem remover o atributo SecurityTransparent e o atributo AllowPartiallyTrustedCallers. A remoção desses atributos eliminará erros do compilador, como os seguintes.
Attempt by security transparent method ‘MyComponent' to access security critical type 'System.Web.Mvc.MvcHtmlString' failed. Assembly 'PagedList.Mvc, Version=4.3.0.0, Culture=neutral, PublicKeyToken=abbb863e9397c5e1' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.Observe que, como efeito colateral disso, você não pode usar assemblies 4.0 e 5.0 no mesmo aplicativo. Você precisa atualizar todos eles para 5.0.
Modelo de SPA com autorização do Facebook pode causar instabilidade no IE enquanto o site está hospedado na zona da intranet
O modelo SPA fornece login externo com o Facebook. Quando o projeto criado com o modelo está sendo executado localmente, entrar pode fazer com que o IE falhe.
Solução:
Hospedar o site na zona da internet; ou
Teste o cenário em um navegador diferente do IE.
Andaimes de Web Forms
Web Forms Scaffolding foi removido do VS2013 e estará disponível em uma atualização futura para o Visual Studio. No entanto, você ainda pode usar scaffolding dentro de um projeto Web Forms adicionando dependências MVC e gerando scaffolding para MVC. Seu projeto conterá uma combinação de Web Forms e MVC.
Para adicionar MVC ao seu projeto de Web Forms, adicione um novo item estruturado e selecione Dependências do MVC 5. Selecione Mínimo ou Completo, dependendo se você precisa de todos os arquivos de conteúdo, como scripts. Em seguida, adicione um item de andaime para MVC, que criará exibições e um controlador em seu projeto.
MVC e Web API Scaffolding - HTTP 404, erro não encontrado
Se for encontrado um erro ao adicionar um item de andaime a um projeto, é possível que seu projeto seja deixado em um estado inconsistente. Algumas das alterações feitas no andaime serão revertidas, mas outras alterações, como os pacotes NuGet instalados, não serão revertidas. Se as alterações de configuração de roteamento forem revertidas, os usuários receberão um erro HTTP 404 ao navegar para itens de andaime.
Solução alternativa:
Para corrigir este erro no MVC, adicione um novo item gerado automaticamente e selecione as Dependências do MVC 5 (Mínimo ou Completo). Esse processo adicionará todas as alterações necessárias ao seu projeto.
Para corrigir esse erro para a API da Web:
Adicione a classe WebApiConfig ao seu projeto.
public static class WebApiConfig { public static void Register(HttpConfiguration config) { config.MapHttpAttributeRoutes(); config.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } }Public Module WebApiConfig Public Sub Register(ByVal config As HttpConfiguration) config.MapHttpAttributeRoutes() config.Routes.MapHttpRoute( name:="DefaultApi", routeTemplate:="api/{controller}/{id}", defaults:=New With {.id = RouteParameter.Optional} ) End Sub End ModuleConfigure WebApiConfig.Register no método Application_Start em Global.asax da seguinte maneira:
public class WebApiApplication : System.Web.HttpApplication { protected void Application_Start() { GlobalConfiguration.Configure(WebApiConfig.Register); } }Public Class WebApiApplication Inherits System.Web.HttpApplication Sub Application_Start() GlobalConfiguration.Configure(AddressOf WebApiConfig.Register) End Sub End Class