ASP.NET Core Uygulaması Plesk'te Nasıl Yayınlanır?

ASP.NET Core uygulamasını Plesk'te yayınlamak için önce sunucudaki .NET sürümünün projeyle uyumlu olduğu kontrol edilir. Proje Visual Studio'dan Web Deploy ile ya da dotnet publish çıktısı dosya yöneticisi veya FTP ile yüklenerek yayınlanır. IIS, ASP.NET Core Module ve web.config üzerinden uygulamayı çalıştırır. Bağlantı cümlesi ve ortam değişkenleri ayarlanır; 500.30 hataları için stdout logları açılır.

Adımlar Plesk'li Windows hosting ortamı için yazıldı. Plesk menü adları sürüme ve sağlayıcının yapılandırmasına göre küçük farklar gösterebilir; bu yüzden genel yolu tarif ediyoruz.

Başlamadan önce: sürüm uyumu

Yayından önce iki soruyu yanıtlayın: Sunucuda projenizin hedeflediği ASP.NET Core çalışma zamanı (runtime) kurulu mu ve uygulamayı çalışma zamanına bağımlı mı, yoksa kendi içinde mi yayınlayacaksınız?

.NET Hosting Bundle ve desteklenen sürümler

IIS'in ASP.NET Core uygulamalarını çalıştırabilmesi için sunucuya .NET Hosting Bundle kurulur. Microsoft'un belgelerine göre bu paket .NET çalışma zamanını, .NET kütüphanelerini ve ASP.NET Core Module'ü (ANCM) kurar. ANCM, IIS'e eklenen ve gelen istekleri ASP.NET Core uygulamasına ileten, uygulama sürecini başlatıp yöneten modüldür. Paylaşımlı hostingte bu kurulumu sağlayıcı yapar.

Plesk'in belgelerine göre Plesk for Windows, ASP.NET Core 2.1 ve sonrasını destekler; bunun için sunucuda "Microsoft ASP.NET Core" bileşeninin kurulu olması gerekir. Hangi .NET sürümlerinin kurulu olduğu ise sunucudan sunucuya değişir. Paketinizde desteklenen sürümü paket sayfasından veya destek ekibinden kontrol edin.

Microsoft'un destek takvimini de dikkate alın: çift numaralı sürümler LTS (36 ay), tek numaralı sürümler STS (24 ay) destek alır. .NET 8 ve .NET 9 için destek bitiş tarihi 10 Kasım 2026'dır; .NET 10 LTS ise 14 Kasım 2028'e kadar desteklenir. Projenizin hedeflediği sürümü .csproj dosyasındaki TargetFramework değerinden, kendi makinenizde kurulu çalışma zamanlarını ise şu komutla görebilirsiniz:

dotnet --list-runtimes

Framework-dependent ile self-contained yayın

Framework-dependent (çalışma zamanına bağımlı) yayında yalnızca uygulamanız ve bağımlılıkları paketlenir; sunucuda uygun .NET çalışma zamanının kurulu olması gerekir. Self-contained (kendi içinde) yayında ise .NET çalışma zamanı da uygulamayla birlikte gelir, sunucuda ayrıca kurulu olması gerekmez.

KonuFramework-dependentSelf-contained
Sunucuda .NET çalışma zamanıGerekliGerekmez
Yayın boyutuKüçükBüyük
Güvenlik yamalarıSunucudaki en güncel yamalı çalışma zamanını kullanırYalnızca uygulamayı yeniden yayınlayınca güncellenir
PlatformTaşınabilirHedef platforma özgü (ör. win-x64)

Sunucuda doğru çalışma zamanı varsa framework-dependent yayın daha pratiktir. Self-contained yayın, sunucuda bulunmayan bir sürümü hedeflediğinizde çözüm olabilir; ancak güvenlik güncellemeleri için uygulamayı sizin yeniden yayınlamanız gerekir:

# Framework-dependent
dotnet publish -c Release -o .\publish

# Self-contained, 64 bit Windows için
dotnet publish -c Release -r win-x64 --self-contained true -o .\publish

Yöntem 1: Visual Studio ve Web Deploy

Web Deploy, Microsoft'un IIS'e içerik ve yapılandırma aktarmak için geliştirdiği istemci-sunucu aracıdır. FTP'den farkı, yalnızca değişen dosyaları göndermesi, HTTPS üzerinden çalışabilmesi ve yayın sırasında bağlantı cümlesi gibi ayarları dönüştürebilmesidir.

Plesk'in belgelerine göre Web Deploy yayın ayarları dosyası Websites & Domains altında ilgili alan adının Web Deploy Publishing Settings bağlantısından indirilir. Bu ayarlar yalnızca sunucuda Web Deploy kurulu ve çalışır durumdaysa görünür. Panelinizde bu bağlantı yoksa Web Deploy'un paketinizde sunulup sunulmadığını destek ekibine sorun; yoksa aşağıdaki ikinci yöntemi kullanabilirsiniz.

  1. Plesk'ten yayın ayarları dosyasını (.publishsettings) indirin.
  2. Visual Studio'da projeye sağ tıklayıp Publish seçeneğini açın ve profil içe aktarma (Import Profile) adımında bu dosyayı seçin.
  3. Profil ayarlarında yapılandırmayı Release, hedef çerçeveyi projenizin sürümü, dağıtım modunu ise framework-dependent veya self-contained olarak belirleyin.
  4. Bağlantıyı doğrulayın ve Publish ile yayını başlatın.
  5. Siteyi açıp veritabanı kullanan bir sayfayı test edin.

Web Deploy, dağıtım süresince uygulama klasörüne otomatik olarak app_offline.htm dosyası koyar; böylece uygulama düzgünce kapanır ve kilitli DLL'ler güncellenebilir.

Yöntem 2: dotnet publish + FTP veya dosya yöneticisi

Web Deploy kullanılamıyorsa uygulamayı yerelde yayınlayıp çıktıyı FTP veya Plesk dosya yöneticisiyle yükleyebilirsiniz. Bu yöntemde kilitli dosyalar için app_offline.htm adımını elle yapmanız gerekir.

  1. Uygulamayı yayınlayın ve çıktıyı sıkıştırın:
    dotnet publish .\MyApp.csproj -c Release -o .\publish
    Compress-Archive -Path .\publish\* -DestinationPath .\publish.zip
  2. Sitenin kök klasörüne (Plesk'te genellikle httpdocs) içinde kısa bir bakım mesajı bulunan app_offline.htm dosyasını yükleyin. Dosya var olduğu sürece ASP.NET Core Module uygulamayı kapatır ve gelen isteklere bu dosyanın içeriğini gösterir.
  3. Zip dosyasını yükleyip dosya yöneticisinde açın ya da klasörün içeriğini FTP ile aktarın. Mevcut appsettings.Production.json veya elle düzenlediğiniz web.config varsa üzerine yazmadan önce yedekleyin.
  4. app_offline.htm dosyasını silin. Bir sonraki istekte uygulama yeniden başlar.

web.config ve hosting modeli (in-process / out-of-process)

dotnet publish, web projeleri için ASP.NET Core Module'ü yapılandıran bir web.config dosyası üretir. Bu dosya uygulamanın kök klasöründe bulunmalıdır. Framework-dependent bir yayında tipik içerik şöyledir:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet"
                  arguments=".\MyApp.dll"
                  stdoutLogEnabled="false"
                  stdoutLogFile=".\logs\stdout"
                  hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Self-contained yayında processPath değeri dotnet yerine .\MyApp.exe olur ve arguments satırı kullanılmaz.

In-process modelde uygulama, IIS'in çalışan süreci (w3wp.exe) içinde çalışır. İstekler yerel ağ bağdaştırıcısı üzerinden aktarılmadığı için Microsoft bu modelin out-of-process'e göre belirgin şekilde daha yüksek istek kapasitesi sunduğunu belirtir; güncel şablonlarda varsayılan model budur. Out-of-process modelde ise uygulama ayrı bir süreçte Kestrel web sunucusuyla çalışır ve IIS istekleri ona iletir. Out-of-process'e geçmek için proje dosyasında AspNetCoreHostingModel özelliği OutOfProcess olarak ayarlanır.

In-process modelin bir kısıtı vardır: aynı uygulama havuzunda (application pool) birden fazla in-process uygulama çalışamaz. Ana sitenin altına ayrı bir ASP.NET Core uygulaması eklerseniz, alt uygulamanın ayrı bir uygulama havuzunda çalışması gerekir.

Ortam değişkenleri ve appsettings

ASP.NET Core yapılandırmayı birden fazla kaynaktan okur. Aynı anahtar birden çok yerde varsa Microsoft'un belgelerindeki öncelik sırası (yüksekten düşüğe) geçerlidir:

  1. Komut satırı argümanları
  2. Ortam değişkenleri
  3. Kullanıcı gizli bilgileri (yalnızca Development ortamında)
  4. Ortama özel ayar dosyası (ör. appsettings.Production.json)
  5. appsettings.json

Uygulamanın hangi ortamda çalıştığını ASPNETCORE_ENVIRONMENT değişkeni belirler; tanımlanmamışsa ortam Production kabul edilir. IIS'te bu değişkeni ve diğer ortam değişkenlerini web.config içinde tanımlayabilirsiniz:

<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" hostingModel="inprocess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
  </environmentVariables>
</aspNetCore>

İç içe yapılandırma anahtarları ortam değişkenlerinde iki alt çizgiyle yazılır: ConnectionStrings:DefaultConnection anahtarının ortam değişkeni karşılığı ConnectionStrings__DefaultConnection'dır. Microsoft, ASPNETCORE_ENVIRONMENT değerini Development yapmayı yalnızca internete açık olmayan test sunucularında önerir; bu mod ayrıntılı hata sayfalarını ziyaretçiye gösterebilir.

Yayın sırasında web.config yeniden üretilebildiği için elle eklediğiniz ortam değişkenlerini projenizdeki web.config dosyasına da işleyin; aksi halde bir sonraki yayında kaybolabilirler.

MSSQL bağlantı cümlesi

Bağlantı cümlesi, uygulamanın veritabanına nasıl bağlanacağını tarif eden metindir. Plesk'te veritabanını ve kullanıcısını oluşturduktan sonra yapı şöyledir:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=mssql-sunucu-adresi;Database=veritabani_adi;User Id=kullanici_adi;Password=parola;Encrypt=True;TrustServerCertificate=False"
  }
}

Microsoft'un belgelerine göre Microsoft.Data.SqlClient 4.0 sürümünden itibaren Encrypt varsayılan olarak True'dur; sunucunun doğrulanabilir bir sertifikası yoksa bağlantı kurulamaz. TrustServerCertificate=True bağlantıyı şifreler ama sertifikayı doğrulamaz ve araya girme (man-in-the-middle) saldırılarına açık kapı bırakır. Sertifika hatası alırsanız önce destek ekibinden doğru sunucu adını ve sertifika durumunu öğrenin; bu değeri ancak riski bilerek, geçici olarak kullanın.

Parolayı kaynak koduna ve depoya koymamak için bağlantı cümlesini appsettings.Production.json yerine ConnectionStrings__DefaultConnection ortam değişkeniyle vermek daha güvenlidir. Paketinizdeki MSSQL sürümünü de kontrol edin; daha yeni bir SQL Server sürümünde alınmış bir yedek, daha eski bir sürüme geri yüklenemez.

Sık karşılaşılan hatalar

ASP.NET Core Module başlatma sorunlarını belirli HTTP kodlarıyla bildirir. Microsoft'un sorun giderme belgelerine göre en sık görülenler şunlardır:

KodAnlamıOlası nedenlerİlk kontrol
500.30In-process başlatma hatası; uygulama başlamadıSunucuda bulunmayan bir ASP.NET Core sürümünü hedeflemek, başlangıçta fırlayan istisna (hatalı bağlantı cümlesi, eksik ayar)stdout logu, Olay Görüntüleyici
500.19Sayfanın yapılandırma verisi geçersizASP.NET Core Module veya Hosting Bundle kurulu değil, izin sorunu, alt uygulamanın web.config dosyasında handlers bölümü bulunmasıweb.config, sunucudaki bileşenler
502.5Süreç hatası; out-of-process uygulama başlamadıHatalı processPath veya arguments, eksik çalışma zamanı, platform uyumsuzluğustdout logu, web.config
500.32DLL yüklenemedi32 bit uygulama havuzunda 64 bit yayın (veya tersi)Yayın mimarisi
500.35Aynı süreçte birden fazla in-process uygulamaİki uygulama aynı uygulama havuzundaUygulama havuzları

HTTP 500.30

"ANCM In-Process Start Failure" olarak görünür: uygulama IIS çalışan süreci içinde başlatılamamıştır. Microsoft'un belirttiği yaygın neden, sunucuda kurulu olmayan bir ASP.NET Core sürümünün hedeflenmesidir. Belgelerde ayrıca uygulamanın kendi yapılandırma veya kod hatası da sayılır; örneğin Program.cs içinde yanlış bağlantı cümlesi ya da eksik bir yapılandırma anahtarı. Nedeni en hızlı stdout logu gösterir.

HTTP 500.19

"The requested page cannot be accessed because the related configuration data for the page is invalid" mesajıyla görünür; IIS, web.config içindeki bir bölümü okuyamamış ya da tanıyamamıştır. Microsoft'un listelediği nedenler: ASP.NET Core Module'ün veya Hosting Bundle'ın kurulu olmaması, uygulama havuzu kimliğinin klasöre erişememesi ve bir alt uygulamanın web.config dosyasında handlers bölümü bulunması. Bu hatada stdout logu oluşmaz; sunucu tarafı kontrol için destek ekibine başvurun.

HTTP 502.5

"Process Failure" olarak görünür ve out-of-process modele özgüdür: ASP.NET Core Module arka plandaki uygulama sürecini başlatamamış ya da süreç başlamış ama yapılandırılan portu dinlememiştir. web.config içindeki processPath ve arguments değerlerini, sunucudaki çalışma zamanını ve yayınladığınız platformu kontrol edin.

stdout logunu açmak

Başlatma hatalarının ayrıntısını görmek için web.config içinde stdout logunu geçici olarak açın:

  1. Uygulama klasöründe logs adında bir klasör oluşturun.
  2. web.config içinde stdoutLogEnabled="true" yapın ve stdoutLogFile=".\logs\stdout" değerini kontrol edin.
  3. Siteye bir istek gönderin ve logs klasöründe oluşan stdout_ ile başlayan dosyayı okuyun.
  4. Sorunu bulduktan sonra stdoutLogEnabled="false" yaparak logu kapatın.

Uyarı: Microsoft, stdout logunun dosya boyutu veya dosya sayısı için bir sınırı olmadığını ve açık bırakılırsa uygulama ya da sunucu arızasına yol açabileceğini belirtir. Uygulama havuzu kimliğinin logs klasörüne yazma izni yoksa log oluşmaz.

Güncelleme ve kesintisiz yayın

Paylaşımlı hostingte güncelleme sırasında kısa bir kesinti kaçınılmazdır; amaç onu kısa ve kontrollü tutmaktır.

Güncellemede şu sırayı izleyin: veritabanının yedeğini alın, app_offline.htm ile uygulamayı durdurun (Web Deploy bunu kendisi yapar), dosyaları yükleyin, veritabanı şemasını güncelleyin, app_offline.htm dosyasını kaldırın ve kritik sayfaları test edin. ASP.NET Core Module app_offline.htm dosyasını gördüğünde uygulamanın düzgünce kapanmasını varsayılan olarak 10 saniye bekler, süre dolarsa süreci sonlandırır.

Entity Framework Core kullanıyorsanız şema değişikliklerini canlı veritabanına uygulamadan önce gözden geçirebileceğiniz bir SQL betiği üretmek güvenli bir yöntemdir:

dotnet ef migrations script --idempotent -o migration.sql

Betiği önce veritabanının bir kopyasında deneyin. Tamamen kesintisiz yayın ise birden fazla uygulama örneği ve yük dengeleyici gerektirir; bu, paylaşımlı hostingin değil sunucu tabanlı bir altyapının konusudur.

Sık sorulan sorular

Hangi .NET sürümleri destekleniyor?

Plesk for Windows, ASP.NET Core 2.1 ve sonrasını destekler; ancak sunucuda hangi çalışma zamanlarının kurulu olduğunu hosting sağlayıcısı belirler. Paketinizde desteklenen sürümü paket sayfasından veya destek ekibinden kontrol edin.

Web Deploy nasıl etkinleştirilir?

Web Deploy sunucu tarafında kurulur; paylaşımlı hostingte müşteri kuramaz. Kuruluysa Plesk'te alan adının altında "Web Deploy Publishing Settings" bağlantısı görünür, görünmüyorsa destek ekibine sorun.

Uygulama yerelde çalışıyor ama sunucuda açılmıyor, nereden başlamalıyım?

Tarayıcıdaki hata kodunu yukarıdaki tabloyla eşleştirin, ardından stdout logunu geçici olarak açıp başlangıç hatasını okuyun. Sık görülen nedenler sunucuda eksik .NET sürümü ve üretim ortamında bulunmayan bir yapılandırma değeridir.

Windows hosting ile Linux hosting arasındaki genel farkları merak ediyorsanız Windows hosting mi Linux hosting mi yazımıza bakabilirsiniz.

Uygulamanızı yayınlamaya hazırsanız, .NET sürümünüzü destekleyen Windows hosting paketlerini inceleyin. Bulutzone'un Windows hosting paketleri Windows Server 2022 üzerinde Plesk, ASP.NET ve .NET Core desteği ile 2 çekirdek ve 4 GB RAM sunuyor.

Kaynaklar

Windows Hosting konusundaki hizmetlerimiz için Windows hosting paketleri sayfasına göz atabilirsiniz.

İncele

İlgili rehberler