una - No se pueden obtener las páginas de Ayuda de ASP.NET Web API 2 cuando se usa Owin

web api ejemplo

Question

He instalado el paquete correcto para Web Api 2

Install-Package Microsoft.AspNet.WebApi.HelpPage -Pre

Pero el área de ayuda no está siendo mapeada y devuelve 404 (Web Api funciona bien). Estoy usando Microsoft.Owin.Host.SystemWeb como el host. A continuación está mi código de inicio.

 public class Startup
{
public void Configuration(IAppBuilder app)
{
//Required for MVC areas new HttpConfiguration() doesn''t work with MVC
var config = GlobalConfiguration.Configuration;
AreaRegistration.RegisterAllAreas();
WepApiStartup.Configure(config);
app.UseWebApi(config);
}
}

Answer 1

GlobalConfiguration.Configuration es HttpConfiguration, específico del host web, que solo se debe utilizar con el escenario del host web. Úselo con el host OWIN causará problemas inesperados.

Por favor use el siguiente código:

public class Startup
{
public static HttpConfiguration HttpConfiguration { get; private set; }
public void Configuration(IAppBuilder app)
{
HttpConfiguration = new HttpConfiguration();
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(HttpConfiguration);
app.UseWebApi(HttpConfiguration);
}
}

Reemplace toda la Configuración GlobalConfiguración con Inicio. La Configuración Http en el proyecto incluye archivos de página de ayuda.

Answer 2

Encontré la solución después de una gran cantidad de excavación / prueba y error. El problema está bien descrito aquí: http://aspnetwebstack.codeplex.com/discussions/453068

UseWebApi y UseHttpMessageHandler no invocan el middleware de Next OWIN más que para 404. Esto significa que si utiliza UseWebApi, nunca se llamará a Next y no podrá usarlo con ningún otro middleware (páginas de ayuda de Nancy o Web Api, por ejemplo).

Gracias al parche @aliostad: https://github.com/aliostad/CacheCow/blob/master/samples/UsingCacheCowWithNancyAndOwin/HttpMessageHandlerAdapterModified.cs#L43

Puede hacerlo funcionar como se espera. Espero que el equipo combine la solicitud de extracción para esto, ya que UseWebApi rompe los objetivos de diseño de Owin IMO.

Actualización 13 de febrero de 2014

He escrito una extensión de Owin para solucionar esto:

internal static void UseWebApiAndHelp(this IAppBuilder app, HttpConfiguration config)
{
WepApiStartup.Configure(config);
app.UseHandlerAsync((request, response, next) =>
{
if (request.Path == "/") //app.Map using a regex exclude list would be better here so it doesn''t fire for every request
{
response.StatusCode = 301;
response.SetHeader("Location", "/Help");
return Task.FromResult(0);
}
return next();
});
// Map the help path and force next to be invoked
app.Map("/help", appbuilder => appbuilder.UseHandlerAsync((request, response, next) => next()));
app.UseWebApi(config);
}

Actualización 01 de julio de 2015

También puede alojar las páginas de ayuda con WebApi en lugar de MVC, lo cual es ideal para autohost http://blogs.msdn.com/b/yaohuang1/archive/2012/12/20/making-asp-net-web-api -help-page-work-on-self-hosted-services.aspx

Actualización 10 de septiembre de 2015

Para Web Api probé la respuesta @ hongye-sun y también funciona, siga lo que dice @gspatel al cambiar HelpPageAreaRegistration.RegisterArea y el constructor de HelpController . Mi solución alternativa también funciona, así que elija la que mejor funcione para su situación.

Sin embargo, sigo teniendo el problema cuando uso UseWebApi con otro middleware y no invoca a Next () (parece que solo ocurre cuando uso IIS no como host). He encontrado que mi solución de mapeo de la ruta y forzar a invocar es una solución válida para todo el middleware de Owin Nancy, Simple.Web, etc.

Actualización 13 de enero de 2016

Desarrollé el middleware de Owin para generar las páginas de ayuda de API web de ASP.NET que conocemos y amamos, que resuelven por completo este problema. La publicación de mi blog explica los antecedentes de este problema en detalle