502.5 IIS hatası üzerinde ASP.NET Core 1.0

Sunucumu (Windows 2012R2) .Net Core 1.0 RTMönceki sürümden Windows Hosting paketine güncelledim .Net Core 1.0 RC2. Uygulamam herhangi bir sorun olmadan bilgisayarımda çalışıyor ancak sunucu şunu göstermeye devam ediyor:

HTTP Error 502.5 - Process Failure


Common causes of this issue:

The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port

Daha önce RC2 versiyonu ile çalışıyordu. Neyin yanlış gidebileceğini bilmiyorum.

Olay görüntüleyicinin hepsi bu diyor:

Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.

en kötü yanı, uygulama günlüklerinin boş olmasıdır! Demek istediğim, bu stdout_xxxxxxxxx.log dosyaları tamamen boş ve hepsi 0 bayt boyutuna sahip.

Ne yapmalıyım?? Günlüğe kaydedilmediğinde hatanın nedenini nasıl bilebilirim?

Çalıştırarak düzeltebildim

"C: \ Program Files \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

komut isteminde bana çok daha anlamlı bir hata verdi:

"Belirtilen çerçeve 'Microsoft.NETCore.App', sürüm '1.0.1' bulunamadı. - Uygulama bağımlılıklarını kontrol edin ve şu konumda yüklü bir çerçeve sürümünü hedefleyin: C: \ Program Files \ dotnet \ shared \ Microsoft.NETCore.App - Aşağıdaki sürümler kurulur: 1.0.0 - Alternatif olarak, '1.0.1' çerçeve sürümünü kurun.

Gördüğünüz gibi, sunucuma yanlış NET Core sürümünü yükledim. Önceki sürüm 1.0.0'ı kaldırdıktan ve doğru 1.0.1 sürümünü yükledikten sonra uygulamamı çalıştırabildim.

Aynı sorunu yaşadım, benim durumumda Uygulama Havuzumun kullanıcı kimliğinin izninin yetersiz olması, asp.net belgesinin IIS sayfasında yayınlama , bu hatanın birkaç nedeni var:

• Eğer kendi kendine yeten bir uygulama yayınladı Eğer onayla sen bir platform halini almadığı buildOptionsbir project.jsonyayıncılık RID o çakışmaları. Örneğin, bir x86 platformu belirtmeyin ve win81-x64 ( dotnet publish -c Release -r win81-x64) RID'si ile yayınlamayın . Proje herhangi bir uyarı veya hata olmadan yayınlanacak, ancak sunucuda yukarıda kaydedilen istisnalarla başarısız olacaktır.
• Taşınabilir bir uygulama için olduğunu doğrulamak için web.config processPathiçindeki <aspNetCore>öğenin dotnetveya kendi kendine yeten bir uygulama için. \ My_application.exe öğesinin özniteliğini kontrol edin .
• Taşınabilir bir uygulama için, dotnet.exePATH ayarlarından erişilemeyebilir. C:\Program Files\dotnet\Sistem PATH ayarlarında var olduğunu doğrulayın .
• Taşınabilir bir uygulama dotnet.exeiçin, Uygulama Havuzunun kullanıcı kimliği için erişilebilir olmayabilir. AppPool kullanıcı kimliğinin C:\Program Files\dotnetdizine erişimi olduğunu doğrulayın .
• .UseIISIntegration()Uygulamanın yöntemini çağırarak IIS Entegrasyon ara yazılımına doğru şekilde başvurduğunuzu onaylayın WebHostBuilder().
• Eğer kullanıyorsanız .UseUrls()daha önce konumlandırılmış onayla olduğunu, kerkenez ile kendi kendine barındırmayı uzatma yöntemi .UseIISIntegration()üzerinde uzatma yöntemiyle WebHostBuilder(). Kestrel'i IIS arkasında çalıştırırken ters proxy için .UseIISIntegration()ayarlamalıdır Urlve değeri tarafından geçersiz kılınmamalıdır .UseUrls().

Benim durumumda bu dördüncü nedendi, uygulama havuzuma sağ tıklayarak onu değiştirdim ve İşlem Modeli altındaki gelişmiş ayarda Kimliği yeterli izne sahip bir kullanıcıya ayarladım:

Bunu, IIS'nin sert bir sıfırlamasıyla çalıştırdım (yalnızca barındırma paketini yeni yükledim).

IIS Yöneticisi'nde sadece 'Yeniden Başlat'a basmanın yeterli olmadığı ortaya çıktı. Sadece bir komut istemi açıp 'iisreset' yazmam gerekiyordu

Bu yüzden yeni bir sunucum var, bu sefer Windows 2008R2 ve uygulamam iyi çalışıyor.

Eski sunucudaki sorunun ne olduğunu kesin olarak söyleyemem ama bir fikrim var.

Bu yüzden uygulamayı önceden aklımda herhangi bir platform olmadan derlediğim için , bana dllyalnızca hedef ana bilgisayarda .Net Core Windows Hostingpaket kuruluysa çalışan sürümü verdi . Benim durumumda kuruldu ve bu iyiydi .

Uygulama çalışmadığında, onu win7-x64çalışma zamanı ile bir konsol uygulaması olarak derlemeye karar verdim . Bu sefer exeuygulamamı sunucuda çalıştırdığım anda , eksik bir dll ile ilgili bir hata ile çöktü:

The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing

Bu dll, Visual Studio 2015 için Visual C ++ Yeniden Dağıtılabilir'e dahil olan Evrensel C Çalışma Zamanı'ndan alınmıştır .

Bu paketi (hem x64 hem de x86) yüklemeye çalıştım ancak Windows Server 2012 R2'de her seferinde başarısız oldu (nedenini bilmiyorum).

Ancak bunları yeni sunucuya, Windows Server 2008 R2'ye yüklemeye çalıştığımda, başarıyla yüklediler. Bunun arkasındaki sebep bu olabilir, ancak yine de kesin olarak söyleyemeyiz.

Web uygulamasını yayınlarken aynı sorunu yaşadım. Herhangi biri hala bu sorunu yaşıyorsa, {AppName} .runtimeconfig.json dosyasını değiştirerek sorunu çözdü.

    {
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.1.2"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Dan sürümünü değiştirin "sürümü": "1.1.2" için "sürümü": "1.1.1" ve everythign amele Tamam

Ben de aynı sorunu yaşadım.

Tam kaynağını bulmak için web.config dosyasında oturum açmaya başladım:

<aspNetCore processPath="dotnet" arguments=".\MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile=".\logs\stdout" />

ve MyWebService kök klasöründe günlükler alt klasörü oluşturdu.

IIS'yi yeniden başlattıktan ve API'yi çalıştırmaya çalıştıktan sonra bir hata aldım ve uygun Core Runtime eksikti. DotNetCore.1.0.5_1.1.2-WindowsHosting kurulumunu indirdikten sonra hata gitti.

Aynı sorun vardı ve tüm çözümler işe yaramadı. Bu mücevheri buldum ve başka birine yardım ederse yanımda olacağımı düşündüm. DLL eksik hatası alan Server 2012 R2'ye yükleyin, VS C ++ 2015'i yeniden yüklemeyi deneyin ve bir hata alın. Düzeltme, aşağıdakileri yapmaktır:

Dosyanın C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msuyükleme sorunları var gibi görünüyor . Yönetici komut istemini açın:

c:
mkdir tmp
mkdir tmp\tmp
move "C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu" c:\tmp
expand -F:* c:\tmp\Windows8.1-KB2999226-x64.msu c:\tmp\tmp
dism /online /add-package /packagepath:c:\tmp\tmp\Windows8.1-KB2999226-x64.cab

NOT: "..." karakterini doğru klasör adıyla değiştirin. Bundan sonra VS C ++ 2015 paketini yeniden yükleyin.

Benzer bir sorunum vardı ve Sherlock Holmes'tan alıntı yapacak olursam: " İmkansızı ortadan kaldırdığınızda, geriye kalan her ne olursa olsun, ne kadar imkansız olursa olsun, gerçek olmalı? "

Hedeflediğim .NET çerçevesinin sunucuya yüklenip yüklenmediğini kontrol ettim ve öyle olmadığı ortaya çıktı. 4.6.2 .NET Framework'ü yükledim ve işe yaradı.

VS projem otomatik olarak .NET Core 1.1.2'ye yükseltildikten sonra üretim sunucumda bu sorunu yaşadım.

1.1.2 .net çekirdek çalışma zamanını buradan üretim sunucuma kurdum: https://www.microsoft.com/net/download/core#/runtime

ÇÖZÜLDÜ Bugün AZURE'e konuşlandırırken aynı sorunu yaşadım . Sonra yerel IIS için aynısını denedim, aynı sorunu aldım. .Net CORE'da yeni olduğum için, gerçekten çözmeden önce birkaç saat uğraştım.

Çözümümüzde IIS'ye yayınladıktan sonra web.confile dosyamı özellikle aşağıdaki satırda gözlemledim <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Dağıtım klasörümüzde oluşturulan web.config şuna benzer:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Şimdi LÜTFEN görsel stüdyo çözümünde yukarıdaki yapılandırmayı şu şekilde değiştirmeyi deneyin:<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

Yeni dağıtım klasörümüzde oluşturulan web.config şuna benzer:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Ve bu benim sorunumu çözdü, umarım yardımcı olur.

Dev makinemi Core 1.0.1'e güncellediğimde de aynı sorunu yaşadım, ancak sunucuyu güncellemeyi unuttum.

NET Core 2.0 API'mi AWS EB'ye yayınlamaya çalışırken 502.5 HTTP Hatası alıyordum ve .csproj dosyasına aşağıdaki kodu ekleyerek çözdüm:

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>

Ben de aynı sorunu yaşadım. Uygulama havuzu kimliğini ağ hizmeti hesabına değiştirdim. Daha sonra @danielyewright'ın github yorumunda söylediği gibi uygulamanın düzgün çalışması için web.config dosyasındaki dotnet.exe yolunu açıkça belirledim . Yolu belirledikten sonra çalışır.

Teşekkürler

Benim durumumda bu hatayı paylaşmak, project.json'u güncellemeyi unuttuğum için :

"buildOptions": {
    "emitEntryPoint": true
  }

Söz konusu hatayı, VSG24 tarafından Önerilen yanıtta açıklanan sorunların aynısıyla aldım - CMD'ye 'dotnet' yazarken kötü hata mesajı:

Api-ms-win-crt-runtime-l1-1-0.dll eksik olduğundan program başlatılamıyor

Bunu, aşağıdaki 2 güncellemeyi Windows Server 2012 R2'ye manuel olarak yükleyerek çözdüm (ve ön koşullar ve bağlantılı diğer tüm güncellemeler - Microsoft web sitesinde kurulum talimatlarını dikkatlice okuyun):

1. KB2919355
2. KB2999226

Umarım bu birine yardımcı olur.

Web uygulamamın Debug sürümünü yayınlamaya çalıştığımda da aynı sorunla karşılaştım. Bu dosya grubu web.config, uygun öznitelik değerine sahip dosyayı içermiyordu processPath.

Bu dosyayı Release sürümünden aldım, exe dosyamın yoluna değer atandı.

<aspNetCore processPath=".\My.Web.App.exe" ... />

Benim durumumda sunucuda yüklü olan Net Core sürümü ile ilgili bir sorun vardı. Sadece geliştirme makinemdeki ile aynı sürümü kuruyorum ve her şey yolunda :-)

Burada bulunan en son .net Core sürümünü yüklemem gerekiyordu . Siteyi veya sunucuyu yeniden başlatmaya gerek yok

Sitenin uygulamasına "düzenleme izni" ekleyerek, fiziksel dizinle eşleştirerek ve ardından bu kök klasöre erişimi olabilecek Windows kullanıcısını seçerek çözdüm. (özel ağ).

Benim durumumda, yükledikten sonra AspNetCore.2.0.6.RuntimePackageStore_x64.exeve DotNetCore.2.0.6-WindowsHosting.exeben gerek yeniden başlatma sunucuya 502 bozuk ağ geçidi ve proxy hatası olmadan çalışmasını sağlamak için .

GÜNCELLEME:

Yeniden başlatmadan kullanmanın bir yolu var: https://stackoverflow.com/a/50808634/3634867

Yönetici ile komut istemini açın kimlik bilgileri

Aşağıdaki komutu yazın ve enter tuşuna basın

> IISRESET

VEYA

Yönetici ile Visual Studio 2017'yi açın kimlik bilgileri

Paket Yöneticisi Konsoluna aşağıdaki komutu yazın ve enter tuşuna basın

PM > IISRESET

PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

Benim için bunun nedeni .Net Core'un farklı sürümlerinin kurulu olmasıydı. Geliştirme ve üretim sunucumu eşleştirdim ve işe yaradı.

Bu problemi de yaşadım (Hata hem VS 15 hem de 17'de oluştu). Ancak VS15'te bir CONNECTION_REFUSEDhata döndürdü ve VS17'de geri döndü ASP.NET Core 1.0 on IIS error 502.5.

FIX

1. Proje dizininize gidin ve gizli klasörü bulun .vs(projeler klasörü dizininde bulunur). (Gizli dosyaları / klasörleri göstermeyi unutmayın)

2. VS'yi kapat

3. .Vs klasörünü sil
4. VS'yi yönetici olarak başlatın (.vs klasörü VS tarafından yeniden oluşturulacaktır)

İşte anladığım şey ve bu, bir güncelleme yüklendikten sonra son zamanlarda Windows 10'da oldu. Topladığım kadarıyla, "Project.dll" (bir asp.net çekirdek projesi) 'nin bir virüs gibi davrandığını ve dolayısıyla silindiğini varsayan bir Windows Defender güncellemesi yüklendi.

Bu nedenle, malzemeleri yüklemeye / kaldırmaya başlamadan önce yapmanızı önerdiğim ilk şeylerden biri, "Project.dll" dosyanızın olması gereken yerde olup olmadığını kontrol etmektir .

Artık orada değilse, konuma geri kopyalayın.

Dosyayı geri kopyalamakta güçlük çekiyorsanız , Windows Defender'daki proje klasörünüze bir dışlama ekleyin . ( Bunu nasıl yapacağınızı buradan öğrenin .)

Bu benim için anında çalıştı ve bunu birden çok uygulama sunucusunda tekrarladım.

Benim için Startup.cs'deki connectionString'in şu konumda null olmasıydı:

services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

ve uygulama bağlantı dizesi için appsettings.json dosyasına bakmadığından boştu.

Program.cs'nin şu şekilde değiştirilmesi gerekiyordu:

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}

public static IWebHost BuildWebHost(string[] args) =>
     WebHost.CreateDefaultBuilder(args)
     .ConfigureAppConfiguration((context, builder) => builder.SetBasePath(context.HostingEnvironment.ContentRootPath)
     .AddJsonFile("appsettings.json").Build())
     .UseStartup<Startup>().Build();

Bunun benim için çalıştı neden hiçbir fikrim yok, ama Windows Kimlik ve benim Bu kod biraz vardı kullanıyorum BuildWebHostin Program.cs:

.UseStartup<Startup>()
.UseHttpSys(options =>
{
    options.Authentication.Schemes =
        AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
    options.Authentication.AllowAnonymous = false;
})
.Build();

.UserHttpSysBit kaldırıldıktan sonra artık çalışıyor ve hala bir etki alanı kullanıcısı olarak kimlik doğrulaması yapabilirim.

BuildWebHost şimdi benziyor

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .Build();

Aynı hatayı alıyordum ve sorunun, Azure'a yayınlama sırasında web.config dosyamın değiştirildiğini ve bu nedenle aşağıdaki satırın şu şekilde sonlandığını öğrendim :

<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" />

Üretim için sorun , bağımsız değişkenlerin içeriğidir : "-argFile IISExeLauncherArgs.txt"

Görünüşe göre bu sorun bir sonraki .NET Core SDK'da (şu anda önizlemede) ele alınacak, ancak şimdilik geçici çözüm bu bloğu .csproj dosyasına eklemektir:

<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
    <Exec Command="powershell &quot;(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'&quot;" />
  </Target>

Bu, web.config dosyasını değiştirecek ve yayınlama için sorunlu kısmı kaldıracaktır.

Referans: https://github.com/aspnet/websdk/issues/242

Umarım yardımcı olur.

Yayınlama yapılandırmasını değiştirdikten sonra benim için çalıştı.

64 bit Windows sunucusunda IIS'de 32 bit asp.net çekirdek uygulamasını çalıştırmaya çalışmaktan kaynaklanan benzer bir sorunla (Asp.Net Core 2.x) karşılaştım. Temel neden, otomatik olarak oluşturulan web.config'in (projeniz açıkça bir tane içermiyorsa, asp.net çekirdek projelerinin varsayılan olarak bulunmadığı) dotnet yürütülebilir dosyasının tam yolunu içermemesidir. Hosting paketini 64 bitlik bir makineye yüklediğinizde, dotnet'in 64 ve 32 bit sürümlerini yükler, ancak yol varsayılan olarak 64 bit olarak çözülür ve 32 bit asp.net çekirdek uygulamanız yüklenemez. Tarayıcınızda 502.5 hatası görebilirsiniz ve sunucu olay günlüğüne bakarsanız 0x80004005 hata kodunu görebilirsiniz. O sunucuya asp.net çekirdek uygulama dll'nizi yüklemek için bir komut isteminden dotnet.exe'yi çalıştırmayı denerseniz, "BadImageFormatException" veya "gibi bir hata görebilirsiniz.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <handlers>
                <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
            </handlers>
            <aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\My32BitAspNetCoreApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
       </system.webServer>
   </location>
</configuration>

Aynı sorunu yaşadım ve benim durumumdaki sebep, EF çekirdeğinin appsettings.development.jsondosyadan bağlantı dizesini okumaya çalışmasıydı . Açtım ve bağlantı dizesinin yorumlandığını gördüm.

//{
//  "ConnectionStrings": {
//    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
//    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
//  }
//}

Daha sonra onları aşağıdaki gibi taahhüt etmedim ve sorun çözüldü:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
  }
}