c# - net - Kestrel with IIS-libuv.dll falta en ejecución

microsoft asp net core module preview

Question

Estamos configurando un servidor de API web existente para publicar sitios junto con una API existente. He seguido poco a poco este artículo .

Así es como se ve mi Global.asax.cs:

public class WebApiApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
GlobalConfiguration.Configure(WebApiConfig.Register);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
AutoMapperConfig.RegisterMappings();
var host = new WebHostBuilder()
.UseKestrel()
.UseWebRoot("wwwroot")
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
host.Run();
}
}

y Startup.cs:

public partial class Startup
{
public void Configure(IApplicationBuilder app)
{
app.UseDefaultFiles();
app.UseStaticFiles();
}
}

Cuando ejecuto el proyecto, obtengo el error

Imposible cargar DLL ''libuv'': No se pudo encontrar el módulo especificado. (Excepción de HRESULT: 0x8007007E)

libuv es una dependencia de Kestrel. Si lo copio manualmente desde la carpeta de paquetes a la carpeta bin, funciona. Eso parece tener sentido con este comentario de GitHub Issue . Ahora que se está alejando de project.json, ¿cómo puedo hacer que se copie automáticamente?

Algunos han postulado que no sabe si usar versión de libuv de 32 o 64 bits porque la Plataforma está configurada en Cualquier CPU en las propiedades del proyecto. He intentado configurarlo en x64 tanto en la configuración de la solución como del proyecto y el problema persiste.

¿Cómo puedo hacer que libuv.dll copie directamente al directorio de compilación automáticamente?

No considero incluir el archivo en el proyecto (en lugar de hacerlo en la carpeta de paquetes) y configurarlo para copiar al directorio de salida una solución real, solo una solución alternativa. Espero encontrar una solución, no una solución.

Answer 1

Intenta esto: podría resolver tu problema:

var host = new WebHostBuilder()
.UseKestrel()
// .UseWebRoot("wwwroot") keep it if you need it
.UseContentRoot(Directory.GetCurrentDirectory()) // this could solve your problem
// .UseUrls("http://0.0.0.0:5000") use this if you''re using nginx
.UseIISIntegration()
.UseStartup<Startup>()
.Build();

Answer 2

He tenido un problema similar antes al migrar proyectos. Visual Studio puede portarse mal con proyectos que no coinciden.

Respuesta simple: debe cambiar sus proyectos al formato MSBuild / csproj.

Para empezar, si está tratando de usar .NET Core en su solución, haga clic derecho en su proyecto (s) en Visual Studio, y si no ve Edit xxxxxx.csproj , es probable que tenga problemas. como el que estás informando arriba.

Básicamente, las plantillas de proyectos .NET Core utilizan diferentes herramientas al compilar el proyecto.

La siguiente solución es una forma genérica de resolver casi todos los problemas relacionados con los proyectos que intentan enfocarse en .NET Core, pero desean utilizar bibliotecas de otro marco. No hay una buena herramienta (hasta ahora) para resolver este problema, por lo que tendrá que pasar al modo manual.

Empecemos.

La solución es bastante simple (pero es un poco tediosa).

Paso 1: crea un nuevo proyecto usando el nuevo formato MSBuild / csproj

Crea un nuevo proyecto y selecciona ".NET Core".

En casi todos los casos, es probable que desee evitar el uso de la plantilla de la aplicación web ASP.NET Core, pero eso es para otra discusión en conjunto.

Paso 2: apunte al marco correcto

Haga clic con el botón derecho en el proyecto y seleccione Edit xxxxxx.csproj

<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<!--you will also probably want to note that you need these for a console app -->
<OutputType>Exe</OutputType>
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>
</PropertyGroup>

Elige un marco al que quieras enfocar y asegúrate de que sea compatible (aquí hay una tabla).
He usado net452 en el fragmento de código anterior para un ejemplo. Puede encontrar más información sobre cómo nombrar aquí .

Paso 3. Repite para todos los proyectos.

Tendrá que hacer esto para cada proyecto en su solución para evitar que Visual Studio se comporte de forma inesperada.

Realmente no hay mucho en línea sobre cómo hacer que ASP.NET Core funcione bien con viejos frameworks. Espero que esto te ayude. Ojalá tuviera este consejo antes que yo.

Answer 3

Escribe estos códigos:

using Microsoft.Owin;
using Owin;
using System.Web.Http;
[assembly: OwinStartup(typeof(WebApiAndStaticFiles.OwinStartup))]
namespace WebApiAndStaticFiles
{
public class OwinStartup
{
public void Configuration(IAppBuilder app)
{
app.UseDefaultFiles();
app.UseStaticFiles();
HttpConfiguration webApiConfiguration = new HttpConfiguration();
GlobalConfiguration.Configure(webApiConfiguration); // Instead of GlobalConfiguration.Configure(WebApiConfig.Register);
app.UseWebApi(webApiConfiguration);
}
}
}

e instala estos paquetes nuget:

<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net462" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net462" />
<package id="Microsoft.AspNet.WebApi.Owin" version="5.2.3" targetFramework="net462" />
<package id="Microsoft.Owin" version="3.1.0" targetFramework="net462" />
<package id="Microsoft.Owin.FileSystems" version="3.1.0" targetFramework="net462" />
<package id="Microsoft.Owin.Host.SystemWeb" version="3.1.0" targetFramework="net462" />
<package id="Microsoft.Owin.StaticFiles" version="3.1.0" targetFramework="net462" />
<package id="Newtonsoft.Json" version="10.0.2" targetFramework="net462" />
<package id="Owin" version="1.0" targetFramework="net462" />

No se puede simplemente usar las tuberías principales de asp.net dentro de la tubería de aplicaciones alojadas asp.net/iis. Pero Owin tiene integración para ese oleoducto que funciona como un encanto.