ASP.NET Core Blazor WebAssembly barındırma ve dağıtma

Bu makalede ASP.NET Core, Content Delivery Networks (CDN), dosya sunucuları ve GitHub Pages kullanılarak nasıl barındırılacağı ve dağıtılacağı Blazor WebAssembly açıklanır.

Barındırma modeli ileBlazor WebAssembly:

• Uygulama Blazor , bağımlılıkları ve .NET çalışma zamanı paralel olarak tarayıcıya indirilir.
• Uygulama doğrudan tarayıcı kullanıcı arabirimi iş parçacığında yürütülür.

Aşağıdaki dağıtım stratejileri desteklenir:

• Uygulama Blazor bir ASP.NET Core uygulaması tarafından sunulur. Bu strateji, ASP.NET Core ile barındırılan dağıtım bölümünde ele alınmıştır.
• Uygulama Blazor statik bir barındırma web sunucusuna veya hizmetine yerleştirilir; burada .NET, uygulamayı sunmak Blazor için kullanılmaz. Bu strateji, bir Blazor WebAssembly uygulamayı IIS alt uygulaması olarak barındırmayla ilgili bilgileri içeren Tek başına dağıtım bölümünde ele alınmıştır.
• bir ASP.NET Core uygulaması birden çok Blazor WebAssembly uygulamayı barındırıyor. Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Önceden (AOT) derleme

Blazor WebAssembly , .NET kodunuzu doğrudan WebAssembly'de derleyebileceğiniz önceden (AOT) derlemeyi destekler. AOT derlemesi, daha büyük bir uygulama boyutuna zarar verebilirsiniz.

AOT derlemesini etkinleştirmeden, Blazor WebAssembly uygulamalar WebAssembly'de uygulanan bir .NET Ara Dil (IL) yorumlayıcısını kullanarak tarayıcıda çalışır. .NET kodu yorumlandığından, uygulamalar genellikle sunucu tarafı .NET tam zamanında (JIT) çalışma zamanına göre daha yavaş çalışır. AOT derlemesi, tarayıcı tarafından yerel WebAssembly yürütmesi için uygulamanın .NET kodunu doğrudan WebAssembly'ye derleyerek bu performans sorununu giderir. AOT performans geliştirmesi, YOĞUN CPU kullanan görevleri yürüten uygulamalar için önemli geliştirmeler sağlayabilir. AOT derlemesini kullanmanın dezavantajı, AOT ile derlenen uygulamaların genellikle IL tarafından yorumlanan karşılıklarından daha büyük olmasıdır, bu nedenle ilk istendiğinde istemciye indirilmesi genellikle daha uzun sürer.

.NET WebAssembly derleme araçlarını yüklemeyle ilgili yönergeler için bkz. ASP.NET Core Blazoriçin araç oluşturma.

WebAssembly AOT derlemesini <RunAOTCompilation>true etkinleştirmek için Blazor WebAssembly , özelliğini uygulamanın proje dosyasına ekleyin:

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

Uygulamayı WebAssembly'de derlemek için uygulamayı yayımlayın. Yapılandırmanın yayımlanması Release , yayımlanan uygulamanın boyutunu küçültmek için .NET Ara Dil (IL) bağlamasının da çalıştırılmasını sağlar:

dotnet publish -c Release

WebAssembly AOT derlemesi yalnızca proje yayımlandığında gerçekleştirilir. AOT derlemesi genellikle küçük projelerde birkaç dakika ve büyük projeler için büyük olasılıkla çok daha uzun sürdüğünden, proje geliştirme (Development ortam) sırasında çalıştırıldığında kullanılmaz. AOT derlemesi için derleme süresini kısaltmak, ASP.NET Core'in gelecek sürümleri için geliştirme aşamasındadır.

AOT ile derlenmiş Blazor WebAssembly bir uygulamanın boyutu genellikle .NET IL'de derlenmişse uygulamanın boyutundan daha büyüktür:

• Boyut farkı uygulamaya bağlı olsa da, AOT ile derlenen uygulamaların çoğu IL ile derlenmiş sürümlerinin yaklaşık iki katı boyuttadır. Başka bir deyişle, AOT derlemesi kullanıldığında çalışma zamanı performansı için yük süresi performansından yararlanılır. Bu dezavantajın AOT derlemesini kullanmaya değip değmeyeceği uygulamanıza bağlıdır. Blazor WebAssembly YOĞUN CPU kullanan uygulamalar genellikle AOT derlemesinden en çok yararlanan uygulamalardır.

• AOT ile derlenmiş bir uygulamanın boyutunun büyük olması iki koşuldan kaynaklanır:

  • Yerel WebAssembly'de üst düzey .NET IL yönergelerini göstermek için daha fazla kod gerekir.
  • AOT, uygulama yayımlandığında yönetilen DLL'leri kırpmaz . Blazor yansıma meta verileri için DLL'leri gerektirir ve bazı .NET çalışma zamanı özelliklerini destekler. İstemcide DLL'lerin gerekli hale getirilmesi indirme boyutunu artırır ancak daha uyumlu bir .NET deneyimi sağlar.

Not

Mono/WebAssembly MSBuild özellikleri ve hedefleri için bkz WasmApp.targets . (dotnet/runtime GitHub deposu). Yaygın MSBuild özellikleri için resmi belgeler , Document blazor msbuild yapılandırma seçeneklerine göre planlanmaktadır (dotnet/docs #27395).

Çalışma zamanı yeniden bağlama

Bir Blazor WebAssembly uygulamanın en büyük parçalarından biri, uygulamaya kullanıcının tarayıcısı tarafından ilk kez erişildiğinde tarayıcının indirmesi gereken WebAssembly tabanlı .NET çalışma zamanıdır (dotnet.wasm). .NET WebAssembly çalışma zamanının yeniden bağlanması kullanılmayan çalışma zamanı kodunu kırparak indirme hızını artırır.

Çalışma zamanı yeniden bağlama için .NET WebAssembly derleme araçlarının yüklenmesi gerekir. Daha fazla bilgi için bkz. ASP.NET Core Blazoraraçları.

.NET WebAssembly derleme araçları yüklendiğinde, yapılandırmada Release bir uygulama yayımlandığında çalışma zamanı yeniden bağlama işlemi otomatik olarak gerçekleştirilir. Genelleştirme devre dışı bırakıldığında boyut azaltma özellikle çarpıcıdır. Daha fazla bilgi için bkz. genelleştirme ve yerelleştirme ASP.NET CoreBlazor.

Önyükleme kaynaklarının yüklenme biçimini özelleştirme

API kullanarak önyükleme kaynaklarının nasıl yüklendiğini özelleştirin loadBootResource . Daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırma

Bir Blazor WebAssembly uygulama yayımlandığında, uygulamanın boyutunu azaltmak ve çalışma zamanı sıkıştırma ek yükünü kaldırmak için çıkış yayımlama sırasında statik olarak sıkıştırılır. Aşağıdaki sıkıştırma algoritmaları kullanılır:

• Brotli (en yüksek düzey)
• Gzip

Blazor uygun sıkıştırılmış dosyaları sunmak için konağa dayanır. ASP.NET Core BarındırılanBlazor WebAssembly proje kullanılırken, konak projesi içerik anlaşması gerçekleştirebilir ve statik olarak sıkıştırılmış dosyalara hizmet yapabilir. Tek başına bir Blazor WebAssembly uygulama barındırırken, statik olarak sıkıştırılmış dosyaların sunulduğunda emin olmak için ek çalışma gerekebilir:

• IIS web.config sıkıştırma yapılandırması için IIS: Brotli ve Gzip sıkıştırma bölümüne bakın.

• GitHub Pages gibi statik olarak sıkıştırılmış dosya içeriği anlaşmasını desteklemeyen statik barındırma çözümlerinde barındırırken uygulamayı Brotli sıkıştırılmış dosyalarını getirmek ve kodunu çözmek için yapılandırmayı göz önünde bulundurun:

  • Google/brotli GitHub deposundan JavaScript Brotli kod çözücüsü edinin. Küçültüldü kod çözücü dosyası olarak adlandırılır decode.min.js ve deponun js klasöründe bulunur.

    Not

    Betiğin (decode.min.js) küçültüldü sürümü decode.js başarısız olursa, bunun yerine doğrulanmamış sürümü (decode.js) kullanmayı deneyin.

  • Uygulamayı kod çözücü kullanacak şekilde güncelleştirin.

    wwwroot/index.html dosyasında, 'nin <script> etiketinde falseBlazorolarak ayarlayınautostart:

    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    

    etiketinden <script> sonra Blazorve kapanış </body> etiketinden önce aşağıdaki JavaScript kod <script> bloğunu ekleyin:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            return (async function () {
              const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
              if (!response.ok) {
                throw new Error(response.statusText);
              }
              const originalResponseBuffer = await response.arrayBuffer();
              const originalResponseArray = new Int8Array(originalResponseBuffer);
              const decompressedResponseArray = BrotliDecode(originalResponseArray);
              const contentType = type === 
                'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
              return new Response(decompressedResponseArray, 
                { headers: { 'content-type': contentType } });
            })();
          }
        }
      });
    </script>
    

    Önyükleme kaynaklarını yükleme hakkında daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırmayı BlazorEnableCompression devre dışı bırakmak için MSBuild özelliğini uygulamanın proje dosyasına ekleyin ve değerini olarak falseayarlayın:

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

özelliği, BlazorEnableCompression komut kabuğunda dotnet publish aşağıdaki söz dizimiyle komutuna geçirilebilir:

dotnet publish -p:BlazorEnableCompression=false

Doğru yönlendirme için URL'leri yeniden yazma

Bir Blazor WebAssembly uygulamadaki sayfa bileşenleri için yönlendirme istekleri, barındırılan bir Blazor Serveruygulamadaki yönlendirme istekleri kadar basit değildir. İki bileşeni olan bir Blazor WebAssembly uygulamayı göz önünde bulundurun:

• Main.razor: Uygulamanın köküne yüklenir ve bileşene About (href="About") bir bağlantı içerir.
• About.razor: About bileşeni.

Tarayıcının adres çubuğu kullanılarak uygulamanın varsayılan belgesi istendiğinde (örneğin: https://www.contoso.com/

1. Tarayıcı bir istekte bulunur.
2. Varsayılan sayfa döndürülür; bu genellikle index.htmlşeklindedir.
3. index.html uygulamayı bootstraplar.
4. Blazor'nin yönlendiricisi yüklenir ve RazorMain bileşen işlenir.

Ana sayfada, bileşenin bağlantısının About seçilmesi istemcide çalışır çünkü Blazor yönlendirici tarayıcının için İnternet'te istekte bulunmasını www.contoso.comAbout durdurur ve işlenen About bileşenin kendisine hizmet eder. Uygulama içindeki Blazor WebAssembly iç uç noktalara yönelik tüm istekler aynı şekilde çalışır: İstekler, İnternet'te sunucu tarafından barındırılan kaynaklara tarayıcı tabanlı istekler tetiklemez. Yönlendirici istekleri dahili olarak işler.

için tarayıcının adres çubuğu www.contoso.com/Aboutkullanılarak istek yapılırsa istek başarısız olur. Uygulamanın İnternet ana bilgisayarında böyle bir kaynak olmadığından 404 - Bulunamadı yanıtı döndürülür.

Tarayıcılar istemci tarafı sayfalar için İnternet tabanlı konaklara istekte bulunacağından, web sunucularının ve barındırma hizmetlerinin sunucuda fiziksel olarak sayfaya olmayan kaynaklara yönelik tüm istekleri yeniden yazması index.html gerekir. Döndürülürse index.html , uygulamanın yönlendiricisi Blazor bunu devralır ve doğru kaynakla yanıt verir.

IIS sunucusuna dağıtım yaparken url yeniden yazma modülünü uygulamanın yayımlanan web.config dosyasıyla kullanabilirsiniz. Daha fazla bilgi için IIS bölümüne bakın.

ASP.NET Core ile barındırılan dağıtım

BarındırılanBlazor WebAssembly dağıtım, uygulamayı web sunucusunda çalışan bir ASP.NET Core uygulamasından tarayıcılara hizmet eder.

İstemci Blazor WebAssembly uygulaması, sunucu uygulamasının /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot diğer statik web varlıklarıyla birlikte sunucu uygulamasının klasörüne yayımlanır. İki uygulama birlikte dağıtılır. bir ASP.NET Core uygulamasını barındırabilen bir web sunucusu gereklidir. Barındırılan Blazor WebAssembly bir dağıtım için Visual Studio, Uygulama projesi şablonunu (blazorwasmkomutu kullanırken dotnet new şablon) ve seçeneğinin Hosted seçili olduğunu (-ho|--hostedkomutu kullanırkendotnet new) içerir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• ASP.NET Core uygulama barındırma ve dağıtma: ASP.NET Core barındırma ve dağıtma
• Azure App Service dağıtımı: Visual Studio ile ASP.NET Core uygulamasını Azure'da yayımlama
• Blazorproje şablonları: ASP.NET Core Blazor proje yapısı

Belirli bir platform için çerçeveye bağımlı yürütülebilir dosyanın barındırılan dağıtımı

Barındırılan Blazor WebAssembly bir uygulamayı belirli bir platform için (bağımsız olmayan) çerçeveye bağımlı yürütülebilir dosya olarak dağıtmak için, kullanımdaki araçlara bağlı olarak aşağıdaki kılavuzu kullanın.

Visual Studio

Varsayılan olarak, oluşturulan yayımlama profili (.pubxml ) için bağımsız bir dağıtım yapılandırılır. Projenin yayımlama profilinin Server olarak ayarlanmış MSBuild özelliğini içerdiğini <SelfContained>falseonaylayın.

Projenin Properties klasöründeki .pubxmlServer yayımlama profili dosyasında:

<SelfContained>false</SelfContained>

Yayımlama profilinde MSBuild özelliğini oluşturan Yayımlama Kullanıcı Arabiriminin Ayarlar alanındaki Hedef Çalışma Zamanı ayarını kullanarak Çalışma Zamanı Tanımlayıcısı'nı<RuntimeIdentifier> (RID) ayarlayın:

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Server Projeyi Yayın yapılandırmasında yayımlayın.

Not

Yer tutucunun profil olduğu {PROFILE} komutuna geçirerek dotnet publish/p:PublishProfile={PROFILE} .NET CLI kullanarak profil yayımlama ayarlarına sahip bir uygulama yayımlamak mümkündür. Daha fazla bilgi için, ASP.NET Core uygulama dağıtımı için Visual Studio yayımlama profilleri (.pubxml) makalesindeki Profilleri yayımlamaveKlasör yayımlama örneği bölümlerine bakın. RID'yi yayımlama profilinde dotnet publish değil komutunda geçirirseniz, MSBuild özelliğini ()/p:RuntimeIdentifier) seçeneğiyle değil komutuyla -r|--runtime kullanın.

.NET CLI

MSBuild özelliğini projenin proje dosyasında olarak ayarlanmış falsebir <PropertyGroup>Server içine yerleştirerek <SelfContained>bağımsız bir dağıtım yapılandırın:

<SelfContained>false</SelfContained>

Önemli

SelfContained özelliği projenin proje dosyasına yerleştirilmelidirServer. özelliği, seçeneği veya MSBuild özelliği /p:SelfContained=falsekullanılarak --no-self-containedkomutuyladotnet publish doğru ayarlanamaz.

Aşağıdaki yaklaşımlardan birini kullanarak Çalışma Zamanı Tanımlayıcısı'nı (RID) ayarlayın:

• Seçenek 1: Projenin proje dosyasındaki bir <PropertyGroup> içindeki Server RID'yi ayarlayın:

  <RuntimeIdentifier>{RID}</RuntimeIdentifier>
  

  Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

  Uygulamayı projeden Yayın yapılandırmasında Server yayımlayın:

  dotnet publish -c Release
  

• 2. Seçenek: Komutundaki RID'yi dotnet publish şu seçenekle -r|--runtimedeğil MSBuild özelliği ()/p:RuntimeIdentifier olarak geçirin:

  dotnet publish -c Release /p:RuntimeIdentifier={RID}
  

  Yukarıdaki komutta {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• .NET uygulaması yayımlamaya genel bakış
• ASP.NET Core barındırma ve dağıtma

Birden çok uygulamayla barındırılan Blazor WebAssembly dağıtım

Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Tek başına dağıtım

Tek başına dağıtım, uygulamayı doğrudan istemciler Blazor WebAssembly tarafından istenen statik dosyalar kümesi olarak sunar. Herhangi bir statik dosya sunucusu uygulamaya hizmet Blazor yapabilir.

Tek başına dağıtım varlıkları klasörüne /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot yayımlanır.

Azure App Service

Blazor WebAssemblyuygulamalar, uygulamayı IIS'de barındıran Windows Azure Uygulaması Hizmetlerine dağıtılabilir.

Linux için Azure App Service'a tek başına Blazor WebAssembly uygulama dağıtma şu anda desteklenmemekte. Bu senaryoyı destekleyen Azure Static Web Apps kullanarak tek başına Blazor WebAssembly bir uygulama barındırmanızı öneririz.

Azure Statik Web Uygulamaları

Daha fazla bilgi için bkz. Öğretici: Azure Static Web Apps'de ile Blazor statik web uygulaması oluşturma.

IIS

IIS, uygulamalar için Blazor yetenekli bir statik dosya sunucusudur. IIS'yi barındıracak Blazorşekilde yapılandırmak için bkz. IIS'de Statik Web Sitesi Oluşturma.

Yayımlanan varlıklar, SDK'nın hangi sürümünün /bin/Release/{TARGET FRAMEWORK}/publish kullanıldığına ve yer tutucunun hedef çerçeve olduğuna {TARGET FRAMEWORK} bağlı olarak veya bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish klasöründe oluşturulur. Klasörün içeriğini publish web sunucusunda veya barındırma hizmetinde barındırın.

web.config

Bir Blazor proje yayımlandığında, aşağıdaki IIS yapılandırmasıyla bir web.config dosya oluşturulur:

• MIME türleri
• HTTP sıkıştırması aşağıdaki MIME türleri için etkinleştirilir:
  • application/octet-stream
  • application/wasm
• URL Yeniden Yazma Modülü kuralları oluşturulur:
  • Uygulamanın statik varlıklarının (wwwroot/{PATH REQUESTED}) bulunduğu alt dizine hizmet edin.
  • Dosya olmayan varlıklara yönelik isteklerin statik varlıklar klasöründekiwwwroot/index.html ( ) uygulamanın varsayılan belgesine yeniden yönlendirilmesi için SPA geri dönüş yönlendirmesi oluşturun.

Özel kullanım web.config

Özel web.config dosya kullanmak için:

1. Özel web.config dosyayı projenin kök klasörüne yerleştirin. Barındırılan Blazor WebAssembly bir çözüm için dosyayı Server projenin klasörüne yerleştirin.
2. Projeyi yayımlayın. Barındırılan Blazor WebAssembly bir çözüm için çözümü projeden Server yayımlayın. Daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

SDK'nın web.config yayımlama sırasındaki oluşturma veya dönüştürme işlemi, dosyayı klasördeki publish yayımlanmış varlıklara taşımazsa veya özel web.config dosyanızdaki özel yapılandırmayı değiştirirse, işlemin tam denetimini almak için aşağıdaki yaklaşımlardan herhangi birini kullanın:

• SDK dosyayı oluşturmuyorsa( örneğin, SDK'nın hangi sürümünün kullanıldığına ve yer tutucunun hedef çerçeve olduğuna bağlı olarak, veya konumundaki tek başına Blazor WebAssembly bir uygulamadabin\Release\{TARGET FRAMEWORK}\browser-wasm\publish/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot) özelliğini true proje dosyasında ().csproj olarak ayarlayın<PublishIISAssets>.{TARGET FRAMEWORK} Genellikle tek başına WebAssembly uygulamaları için, özel web.config bir dosyayı taşımak ve dosyanın SDK tarafından dönüştürülmesini önlemek için gereken tek ayar budur.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• SDK'nın web.config proje dosyasındaki dönüştürmesini devre dışı bırakın (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Özel bir dosyayı taşımak için proje dosyasına (.csproj) özel web.config bir hedef ekleyin. Aşağıdaki örnekte, özel web.config dosya geliştirici tarafından projenin köküne yerleştirilir. web.config Dosya başka bir yerde bulunuyorsa içinde dosyanın SourceFilesyolunu belirtin. Aşağıdaki örnek, ile klasörünü belirtirpublish, ancak özel çıkış konumu için bir yol DestinationFolder$(PublishDir)sağlar.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

URL Yeniden Yazma Modülünü Yükleme

URL'leri yeniden yazmak için URL Yeniden Yazma Modülü gereklidir. Modül varsayılan olarak yüklenmez ve Web Sunucusu (IIS) rol hizmeti özelliği olarak yüklenebilir. Modülün IIS web sitesinden indirilmesi gerekir. Modülü yüklemek için Web Platformu Yükleyicisi'ni kullanın:

1. Yerel olarak URL Yeniden Yazma Modülü indirmeleri sayfasına gidin. İngilizce sürümü için WebPI yükleyicisini indirmek için WebPI'yi seçin. Diğer diller için, yükleyiciyi indirmek üzere sunucu (x86/x64) için uygun mimariyi seçin.
2. Yükleyiciyi sunucuya kopyalayın. Yükleyiciyi çalıştırın. Yükle düğmesini seçin ve lisans koşullarını kabul edin. Yükleme tamamlandıktan sonra sunucunun yeniden başlatılması gerekmez.

Web sitesini yapılandırma

Web sitesinin Fiziksel yolunu uygulamanın klasörüne ayarlayın. Klasör aşağıdakileri içerir:

• Iis'nin web.config web sitesini yapılandırmak için kullandığı, gerekli yeniden yönlendirme kuralları ve dosya içerik türleri de dahil olmak üzere dosya.
• Uygulamanın statik varlık klasörü.

IIS alt uygulaması olarak barındırma

Tek başına bir uygulama IIS alt uygulaması olarak barındırılıyorsa, aşağıdakilerden birini gerçekleştirin:

• Devralınan ASP.NET Core Modülü işleyicisini devre dışı bırakın.

  Dosyanın bölümüne bir <handlers> bölüm ekleyerek uygulamanın yayımlanan web.config dosyasındaki işleyiciyi Blazor<system.webServer> kaldırın:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• olarak ayarlanmış bir <location> öğe inheritInChildApplications kullanarak kök (üst) uygulamanın <system.webServer> bölümünün devralını falsedevre dışı bırakın:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Not

  Kök (üst) uygulamanın <system.webServer> bölümünün devralını devre dışı bırakmak, .NET SDK'sı kullanılarak yayımlanan uygulamalar için varsayılan yapılandırmadır.

İşleyiciyi kaldırma veya devralmayı devre dışı bırakma işlemi , uygulamanın temel yolunu yapılandırmaya ek olarak gerçekleştirilir. Uygulamanın dosyasındaki uygulama temel yolunu IIS'de index.html alt uygulamayı yapılandırırken kullanılan IIS diğer adıyla ayarlayın.

Brotli ve Gzip sıkıştırması

Bu bölüm yalnızca tek başına Blazor WebAssembly uygulamalar için geçerlidir. Barındırılan Blazor uygulamalar, bu bölümde bağlantılı dosyayı değil, varsayılan ASP.NET Core uygulama web.config dosyasını kullanır.

IIS, tek başına Blazor WebAssembly uygulamalar için Brotli veya Gzip sıkıştırılmış Blazor varlıklarına hizmet vermek üzere aracılığıyla web.config yapılandırılabilir. Örnek bir yapılandırma dosyası için bkz web.config. .

Aşağıdaki senaryolarda örnek web.config dosyanın ek yapılandırması gerekebilir:

• Uygulamanın belirtimi aşağıdakilerden birini çağırır:
  • Örnek web.config dosya tarafından yapılandırılmamış sıkıştırılmış dosyalar sunma.
  • Örnek web.config dosya tarafından yapılandırılan sıkıştırılmış dosyaları sıkıştırılmamış biçimde sunma.
• Sunucunun IIS yapılandırması (örneğin, applicationHost.config) sunucu düzeyinde IIS varsayılanları sağlar. Sunucu düzeyinde yapılandırmaya bağlı olarak, uygulama örnek web.config dosyanın içerdiğinden farklı bir IIS yapılandırması gerektirebilir.

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Sorun giderme

500 - İç Sunucu Hatası alınırsa ve IIS Yöneticisi web sitesinin yapılandırmasına erişmeye çalışırken hatalar oluşturursa, URL Yeniden Yazma Modülü'nin yüklü olduğunu onaylayın. Modül yüklenmediğinde dosya web.config IIS tarafından ayrıştırılamaz. Bu, IIS Yöneticisi'nin web sitesinin yapılandırmasını ve web sitesinin statik dosyaları sunmasını Blazorengeller.

IIS dağıtımlarının sorunlarını giderme hakkında daha fazla bilgi için bkz. Azure App Service ve IIS'de ASP.NET Core sorunlarını giderme.

Azure Depolama

Azure Depolama statik dosya barındırma sunucusuz Blazor uygulama barındırmaya olanak tanır. Özel etki alanı adları, Azure Content Delivery Network (CDN) ve HTTPS desteklenir.

Blob hizmeti bir depolama hesabında statik web sitesi barındırma için etkinleştirildiğinde:

• Dizin belge adını olarak index.htmlayarlayın.
• Hata belgesi yolunu olarak index.htmlayarlayın. Razor bileşenleri ve diğer dosya olmayan uç noktalar blob hizmeti tarafından depolanan statik içerikteki fiziksel yollarda yer almaz. Yönlendiricinin işlemesi gereken bu kaynaklardan birine yönelik bir istek alındığında Blazor , blob hizmeti tarafından oluşturulan 404 - Bulunamadı hatası isteği Hata belge yoluna yönlendirir. index.html Blob döndürülür ve Blazor yönlendirici yolu yükler ve işler.

Dosyaların üst bilgilerindeki uygunsuz MIME türleri nedeniyle dosyalar Content-Type çalışma zamanında yüklenmiyorsa, aşağıdaki eylemlerden birini gerçekleştirin:

• Dosyalar dağıtıldığında doğru MIME türlerini (Content-Type üst bilgiler) ayarlamak için araçlarınızı yapılandırın.

• Uygulama dağıtıldıktan sonra dosyaların MIME türlerini (Content-Type üst bilgileri) değiştirin.

  Her dosya için Depolama Gezgini (Azure portal) içinde:

  1. Dosyaya sağ tıklayın ve Özellikler’i seçin.
  2. ContentType'ı ayarlayın ve Kaydet düğmesini seçin.

Daha fazla bilgi için bkz. Azure Depolama'da statik web sitesi barındırma.

Nginx

Aşağıdaki nginx.conf dosya, diskte karşılık gelen bir dosyayı bulamadan Nginx'in dosyayı gönderecek index.html şekilde nasıl yapılandırıldığını gösterecek şekilde basitleştirilmiştir.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

ile limit_reqBlazor WebAssemblyNGINX seri hız sınırını ayarlarken, uygulamalar bir uygulama tarafından yapılan görece çok sayıda isteği karşılamak için büyük burst bir parametre değeri gerektirebilir. Başlangıçta değeri en az 60 olarak ayarlayın:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Tarayıcı geliştirici araçları veya ağ trafiği aracı isteklerin 503 - Hizmet Kullanılamıyor durum kodu aldığını gösteriyorsa değeri artırın.

Üretim Nginx web sunucusu yapılandırması hakkında daha fazla bilgi için bkz. NGINX Plus ve NGINX Yapılandırma Dosyaları Oluşturma.

Apache

Bir uygulamayı CentOS 7 veya sonraki bir Blazor WebAssembly sürümüne dağıtmak için:

1. Apache yapılandırma dosyasını oluşturun. Aşağıdaki örnek, basitleştirilmiş bir yapılandırma dosyasıdır (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
       AddType application/octet-stream .dll
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
         BrowserMatch ^Mozilla/4 gzip-only-text/html
         BrowserMatch ^Mozilla/4.0[678] no-gzip
         BrowserMatch bMSIE !no-gzip !gzip-only-text/html
     </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

2. Apache yapılandırma dosyasını CentOS 7'deki varsayılan Apache yapılandırma dizini olan dizine /etc/httpd/conf.d/ yerleştirin.

3. Uygulamanın dosyalarını dizinine /var/www/blazorapp (yapılandırma dosyasında belirtilen DocumentRoot konum) yerleştirin.

4. Apache hizmetini yeniden başlatın.

Daha fazla bilgi için mod_mime ve mod_deflate bölümlerine bakın.

GitHub Pages

Sayfaları dağıtan varsayılan GitHub Eylemi, klasör gibi alt çizgiyle başlayan klasörlerin dağıtımını _framework atlar. Alt çizgiyle başlayan klasörleri dağıtmak için Git dalı için boş .nojekyll bir dosya ekleyin.

Git, gibi blazor.webassembly.jsJavaScript (JS) dosyalarını metin olarak ele alır ve satır sonlarını CRLF'den (satır dönüş satırı akışı) dağıtım işlem hattında LF'ye (satır akışı) dönüştürür. Dosyalarda yapılan JS bu değişiklikler, dosyadaki blazor.boot.json istemciye göndermeden Blazor farklı dosya karmaları oluşturur. Uyuşmazlıklar istemcide bütünlük denetimi hatalarına neden olur. Bu sorunu çözmenin bir yaklaşımı, uygulamanın varlıklarını Git dalı'na eklemeden önce satırı olan *.js binary bir .gitattributes dosya eklemektir. satırı Git'i *.js binary dosyaları ikili dosyalar olarak değerlendirecek JS şekilde yapılandırarak dağıtım işlem hattındaki dosyaların işlenmesini önler. İşlenmemiş dosyaların dosya karmaları dosyadaki blazor.boot.json girdilerle eşleşir ve istemci tarafı bütünlük denetimleri geçer. Daha fazla bilgi için Bütünlük denetimi hatalarını çözme bölümüne bakın.

URL yeniden yazma işlemlerini işlemek için, isteği sayfaya index.html yönlendirmeyi işleyen bir betik içeren bir dosya ekleyinwwwroot/404.html. Bir örnek için bkz. SteveSandersonMS/BlazorOnGitHubPages GitHub deposu:

• wwwroot/404.html
• Canlı site

Kuruluş sitesi yerine proje sitesi kullanırken içindeki etiketini wwwroot/index.htmlgüncelleştirin<base>. href Öznitelik değerini, sonunda eğik çizgiyle GitHub deposu adına ayarlayın (örneğin, /my-repository/). SteveSandersonMS/BlazorOnGitHubPages GitHub deposunda, temel hrefyapılandırma dosyası tarafından.github/workflows/main.yml yayımlandığında güncelleştirilir.

Not

SteveSandersonMS/BlazorOnGitHubPages GitHub deposu .NET Foundation veya Microsoft'a ait değildir, korunmaz veya desteklenmez.

Docker ile tek başına

Tek başına Blazor WebAssembly bir uygulama, statik dosya sunucusu tarafından barındırılan statik dosyalar kümesi olarak yayımlanır.

Uygulamayı Docker'da barındırmak için:

• Ngnix veya Apache gibi web sunucusu desteğine sahip bir Docker kapsayıcısı seçin.
• publish Klasör varlıklarını, statik dosyalara hizmet vermek için web sunucusunda tanımlanan bir konum klasörüne kopyalayın.
• Uygulamaya hizmet vermek için gereken ek yapılandırmayı Blazor WebAssembly uygulayın.

Yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Bu makalenin Nginx bölümü veya Apache bölümü
• Docker Belgeleri

Konak yapılandırma değerleri

Blazor WebAssembly uygulamalar , geliştirme ortamında çalışma zamanında komut satırı bağımsız değişkenleri olarak aşağıdaki konak yapılandırma değerlerini kabul edebilir.

İçerik kökü

bağımsız değişkeni, --contentroot uygulamanın içerik dosyalarını (içerik kökü) içeren dizinin mutlak yolunu ayarlar. Aşağıdaki örneklerde uygulamanın /content-root-path içerik kök yolu verilmiştir.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --contentroot=/content-root-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulama Visual Studio Hata Ayıklayıcısı ile çalıştırıldığında ve ile dotnet runbir komut isteminden çalıştırıldığında kullanılır.

  "commandLineArgs": "--contentroot=/content-root-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --contentroot=/content-root-path
  

Yol tabanı

--pathbase bağımsız değişkeni, kök olmayan göreli URL yolu ile yerel olarak çalıştırılacak bir uygulamanın uygulama temel yolunu ayarlar (<base>etiket href hazırlama ve üretim dışında / bir yola ayarlanır). Aşağıdaki örneklerde uygulamanın /relative-URL-path yol tabanı verilmiştir. Daha fazla bilgi için bkz. Uygulama temel yolu.

Önemli

etiketine sağlanan href<base> yoldan farklı olarak, bağımsız değişken değerini geçirirken sondaki eğik çizgi (/) eklemeyin --pathbase . Uygulama temel yolu etiketinde <base> olarak <base href="/CoolApp/"> sağlanıyorsa (sonunda eğik çizgi varsa), komut satırı bağımsız değişken değerini olarak --pathbase=/CoolApp geçirin (sondaki eğik çizgi yok).

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --pathbase=/relative-URL-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --pathbase=/relative-URL-path
  

URL’ler

bağımsız değişkeni, --urls istekleri dinlemek üzere bağlantı noktaları ve protokollerle IP adreslerini veya konak adreslerini ayarlar.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --urls=http://127.0.0.1:0
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --urls=http://127.0.0.1:0
  

Linux'ta barındırılan dağıtım (Nginx)

ara sunucularla ve X-Forwarded-Protoyük dengeleyicilerle çalışmak için ASP.NET Core yapılandırma başlığındaki yönergeleri izleyerek ve üst bilgilerini iletmek X-Forwarded-For için uygulamasını ile ForwardedHeadersOptions yapılandırın.

Alt uygulama yolu yapılandırması da dahil olmak üzere uygulamanın temel yolunu ayarlama hakkında daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

Aşağıdaki değişiklikleri içeren bir ASP.NET Core SignalR uygulamasının yönergelerini izleyin:

• Ayar yalnızca uygulama istemci-sunucu etkileşimleriyle ilgili Blazor olmayan Sunucu Tarafından Gönderilen Olaylar (SSE) için geçerli olduğundan ara sunucu arabelleğe alma (proxy_buffering off;) yapılandırmasını kaldırın.

• location Yolu /hubroute (location /hubroute { ... } ) olan alt uygulama yoluna /{PATH} ()location /{PATH} { ... } değiştirin; burada {PATH} yer tutucu alt uygulama yoludur.

  Aşağıdaki örnekte, kök yolda /isteklere yanıt veren bir uygulama için sunucu yapılandırılır:

  http {
      server {
          ...
          location / {
              ...
          }
      }
  }
  

  Aşağıdaki örnek, uygulamasının alt uygulama yolunu /blazoryapılandırıyor:

  http {
      server {
          ...
          location /blazor {
              ...
          }
      }
  }
  

Daha fazla bilgi ve yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Nginx ile Linux üzerinde ASP.NET Core Barındırma
• Nginx belgeleri:
  • WebSocket Proxy'si olarak NGINX
  • WebSocket proxy'si
• Microsoft dışı destek forumlarında geliştiriciler:
  • Stack Overflow (etiket: blazor)
  • ASP.NET Core Slack Ekibi
  • Blazor Gitter

Kesiciyi yapılandırma

Blazor çıkış derlemelerinden gereksiz IL'yi kaldırmak için her Yayın derlemesinde Ara Dil (IL) kırpması gerçekleştirir. Daha fazla bilgi için bkz. ASP.NET Core için Düzeltici'yi Blazoryapılandırma.

DLL dosyalarının dosya adı uzantısını değiştirme

Uygulamanın yayımlanan .dll dosyalarının dosya adı uzantılarını değiştirmeniz gerekirse, bu bölümdeki yönergeleri izleyin.

Uygulamayı yayımladıktan sonra, bir kabuk betiği veya DevOps derleme işlem hattı kullanarak dosyaları, uygulamanın yayımlanan çıkışının dizininde farklı bir dosya uzantısı kullanacak şekilde yeniden adlandırın .dll .

Aşağıdaki örneklerde:

• Dosya uzantılarını güncelleştirmek için PowerShell (PS) kullanılır.
• .dll dosyaları, komut satırından dosya uzantısını .bin kullanacak şekilde yeniden adlandırılır.
• Yayımlanmış blazor.boot.json dosyada dosya uzantısıyla .dll listelenen dosyalar dosya uzantısına .bin güncelleştirilir.
• Hizmet çalışanı varlıkları da kullanılıyorsa, PowerShell komutu dosyada service-worker-assets.js listelenen dosyaları dosya uzantısına .bin güncelleştirir.dll.

dosyasından .binfarklı bir dosya uzantısı kullanmak için aşağıdaki komutlarda öğesini istediğiniz dosya uzantısıyla değiştirin .bin .

Windows'da:

dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Linux veya macOS'ta:

for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları ele almak için aşağıdaki yaklaşımlardan birini benimseyin:

• Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları kaldırın. Sıkıştırma bu yaklaşımla devre dışı bırakılır.
• Güncelleştirilmiş blazor.boot.json dosyayı yeniden sıkıştırın.

Sıkıştırılmış blazor.boot.json dosya için önceki kılavuz, hizmet çalışanı varlıkları kullanımda olduğunda da geçerlidir. ve service-worker-assets.js.gzöğesini kaldırın veya yeniden sıkıştırabilirsinizservice-worker-assets.js.br. Aksi takdirde, dosya bütünlüğü denetimleri tarayıcıda başarısız olur.

.NET 6.0 için aşağıdaki Windows örneği, projenin köküne yerleştirilen bir PowerShell betiği kullanır. Sıkıştırmayı devre dışı bırakan aşağıdaki betik, dosyayı yeniden sıkıştırmak istiyorsanız, daha fazla değişikliğin blazor.boot.json temelini oluşturur.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br

Hizmet çalışanı varlıkları da kullanılıyorsa aşağıdaki komutları ekleyin:

((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

Proje dosyasında betik, yapılandırma için Release uygulama yayımlandıktan sonra yürütülür:

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

Not

Aynı derlemeleri yeniden adlandırırken ve yavaş yüklerken, ASP.NET Core'daki Blazor WebAssemblygecikmeli yükleme derlemeleri kılavuzuna bakın.

Genellikle, uygulamanın sunucusu güncelleştirilmiş uzantıyla dosyaları sunmak için statik varlık yapılandırması gerektirir. IIS tarafından barındırılan bir uygulama için, özel web.config bir dosyadaki statik içerik bölümünde (<mimeMap>) yeni dosya uzantısı için bir MIME eşleme girdisi (<staticContent>) ekleyin. Aşağıdaki örnekte dosya uzantısının olarak değiştirildiği .dll.binvarsayılır:

<staticContent>
  ...
  <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
  ...
</staticContent>

Sıkıştırma kullanılıyorsa sıkıştırılmış dosyalar için bir güncelleştirme ekleyin:

<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />

Dosya uzantısının girdisini .dll kaldırın:

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

Sıkıştırma kullanılıyorsa sıkıştırılmış .dll dosyaların girdilerini kaldırın:

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Önceki dağıtım bozulması

Genellikle dağıtımda:

• Yalnızca değiştirilen dosyalar değiştirilir ve bu da genellikle daha hızlı bir dağıtıma neden olur.
• Yeni dağıtımın parçası olmayan mevcut dosyalar, yeni dağıtım tarafından kullanılmak üzere yerinde bırakılır.

Nadir durumlarda, önceki bir dağıtımda kalan dosyalar yeni bir dağıtımı bozabilir. Mevcut dağıtımın (veya dağıtımdan önce yerel olarak yayımlanan uygulamanın) tamamen silinmesi, bozuk bir dağıtımla ilgili sorunu çözebilir. Genellikle, var olan dağıtımı bir kez silmek, DevOps derlemesi ve dağıtım işlem hattı dahil olmak üzere sorunu çözmek için yeterlidir.

DevOps derleme ve dağıtım işlem hattı kullanımda olduğunda her zaman önceki bir dağıtımı temizlemenin gerekli olduğunu belirlerseniz, bozulmanın tam nedenini giderene kadar derleme işlem hattına geçici olarak bir adım ekleyerek her yeni dağıtımın önceki dağıtımını silebilirsiniz.

Bütünlük denetimi hatalarını çözme

Bir uygulamanın başlangıç dosyalarını indirdiğinde Blazor WebAssembly , tarayıcıya yanıtlar üzerinde bütünlük denetimleri gerçekleştirmesini emreder. Blazor istemcilerde önbelleğe alınmayan DLL (.dll), WebAssembly (.wasm ) ve dosyadaki blazor.boot.json diğer dosyalar için SHA-256 karma değerlerini gönderir. Önbelleğe alınan dosyaların dosya karmaları, dosyadaki blazor.boot.json karmalarla karşılaştırılır. Eşleşen karma içeren önbelleğe alınmış dosyalar için önbelleğe Blazor alınmış dosyaları kullanır. Aksi takdirde, dosyalar sunucudan istenir. Bir dosya indirildikten sonra karma değeri bütünlük doğrulaması için yeniden denetlenecektir. İndirilen herhangi bir dosyanın bütünlük denetimi başarısız olursa tarayıcı tarafından bir hata oluşturulur.

Blazor'nin dosya bütünlüğünü yönetme algoritması:

• Uygulamanın tutarsız bir dosya kümesini yükleme riskini almamasını sağlar. Örneğin, kullanıcı uygulama dosyalarını indirme aşamasındayken web sunucunuza yeni bir dağıtım uygulanır. Tutarsız dosyalar hatalı çalışan bir uygulamaya neden olabilir.
• Kullanıcının tarayıcısının tutarsız veya geçersiz yanıtları hiçbir zaman önbelleğe almamasını sağlar. Bu, kullanıcı sayfayı el ile yenilese bile uygulamanın başlatılmasını engelleyebilir.
• Beklenen SHA-256 karmaları değişene kadar yanıtları önbelleğe alma ve sunucu tarafı değişikliklerini denetlememeyi güvenli hale getirir, böylece sonraki sayfa yüklemeleri daha az istek içerir ve daha hızlı tamamlanır.

Web sunucusu beklenen SHA-256 karmalarıyla eşleşmeyen yanıtlar döndürürse, tarayıcının geliştirici konsolunda aşağıdaki örneğe benzer bir hata görüntülenir:

'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=' hesaplanan SHA-256 bütünlüğüne sahip 'https://myapp.example.com/_framework/MyBlazorApp.dll' kaynağının 'integrity' özniteliğinde geçerli bir özet bulunamadı. Kaynak engellendi.

Çoğu durumda, uyarı bütünlük denetimiyle ilgili bir sorun olduğunu göstermez. Bunun yerine, uyarı genellikle başka bir sorun olduğu anlamına gelir.

'Blazor WebAssemblynin önyükleme başvuru kaynağı için GitHub deposundaki dosyaya dotnet/aspnetcore bakınBoot.WebAssembly.ts.

Not

.NET başvuru kaynağına yönelik belge bağlantıları genellikle deponun varsayılan dalını yükler ve bu dal .NET'in sonraki sürümü için geçerli geliştirmeyi temsil eder. Belirli bir sürümün etiketini seçmek için Dalları veya etiketleri değiştir açılan listesini kullanın. Daha fazla bilgi için bkz. ASP.NET Core kaynak kodunun sürüm etiketini seçme (dotnet/AspNetCore.Docs #26205).

Bütünlük sorunlarını tanılama

Bir uygulama oluşturulduğunda oluşturulan bildirim, blazor.boot.json derleme çıkışının oluşturulduğu sırada önyükleme kaynaklarının SHA-256 karmalarını açıklar. Içindeki SHA-256 karmaları tarayıcıya teslim edilen dosyalarla blazor.boot.json eşleştiği sürece bütünlük denetimi geçer.

Bunun başarısız olmasının yaygın nedenleri şunlardır:

• Web sunucusunun yanıtı, tarayıcının istediği dosya yerine bir hatadır (örneğin, 404 - Bulunamadı veya 500 - İç Sunucu Hatası). Bu, tarayıcı tarafından bir bütünlük denetimi hatası olarak bildirilir ve yanıt hatası olarak bildirılmaz.
• Dosyaların derlenip tarayıcıya teslim edilmesi arasında dosyaların içeriği bir değişiklik yaptı. Bu durum oluşabilir:
  • Siz veya derleme araçları derleme çıktısını el ile değiştirirseniz.
  • Dağıtım işleminin bazı yönleri dosyaları değiştirdiyse. Örneğin, Git tabanlı dağıtım mekanizması kullanıyorsanız, Windows'da dosya işleyip Bunları Linux'ta kullanıma alırsanız Git'in Windows stili satır sonlarını unix stili satır sonlarına saydam bir şekilde dönüştürdüğünü unutmayın. Dosya satırı sonlarının değiştirilmesi SHA-256 karmalarını değiştirir. Bu sorunu önlemek için derleme yapıtlarını dosya olarak binary işlemeyi kullanmayı .gitattributesgöz önünde bulundurun.
  • Web sunucusu, dosya içeriğini sunmanın bir parçası olarak değiştirir. Örneğin, bazı içerik dağıtım ağları (CDN' ler) HTML'yi otomatik olarak küçültmeyi dener ve bu şekilde değiştirir. Bu tür özellikleri devre dışı bırakmanız gerekebilir.
• Dosya blazor.boot.json düzgün yüklenemedi veya istemcide yanlış önbelleğe alınmış. Yaygın nedenler şunlardan birini içerir:
  • Yanlış yapılandırılmış veya hatalı çalışan özel geliştirici kodu.
  • Bir veya daha fazla yanlış yapılandırılmış ara önbelleğe alma katmanı.

Sizin durumunuzda bunlardan hangisinin geçerli olduğunu tanılamak için:

1. Hata iletisini okuyarak hangi dosyanın hatayı tetiklediğine dikkat edin.
2. Tarayıcınızın geliştirici araçlarını açın ve Ağ sekmesine bakın. Gerekirse, istek ve yanıtların listesini görmek için sayfayı yeniden yükleyin. Bu listede hatayı tetikleyen dosyayı bulun.
3. Yanıttaki HTTP durum kodunu denetleyin. Sunucu 200 - Tamam (veya başka bir 2xx durum kodu) dışında bir şey döndürürse, tanılanabileceğiniz bir sunucu tarafı sorununuz vardır. Örneğin, durum kodu 403 bir yetkilendirme sorunu olduğu, durum kodu 500 ise sunucunun belirlenemeyen bir şekilde başarısız olduğu anlamına gelir. Uygulamayı tanılamak ve düzeltmek için sunucu tarafı günlüklerine başvurun.
4. Kaynak için durum kodu 200 - Tamam ise, tarayıcının geliştirici araçlarında yanıt içeriğine bakın ve içeriğin beklenen verilerle eşleşip eşleşmediğini denetleyin. Örneğin, isteklerin diğer dosyalar için bile verilerinizi index.html döndürmesi için yönlendirmeyi yanlış yapılandırmak yaygın bir sorundur. İsteklere .wasm verilen yanıtların WebAssembly ikilileri olduğundan ve isteklere verilen .dll yanıtların .NET derleme ikilileri olduğundan emin olun. Aksi takdirde, tanılamanız gereken bir sunucu tarafı yönlendirme sorununuz vardır.
5. Bütünlük sorunlarını giderme PowerShell betiğiyle uygulamanın yayımlanan ve dağıtılan çıkışını doğrulamayı arayın.

Sunucunun makul şekilde doğru veriler döndürdüğünü onaylarsanız, dosyanın derlemesi ve teslimi arasında içeriği değiştiren başka bir şey olmalıdır. Bunu araştırmak için:

• Dosyalar oluşturulduktan sonra dosyaları değiştirme olasılığına karşı derleme araç zincirini ve dağıtım mekanizmasını inceleyin. Bunun bir örneği, Git'in daha önce açıklandığı gibi dosya satırı sonlarını dönüştürmesidir.
• Yanıtları dinamik olarak değiştirecek şekilde ayarlanmış olmaları (örneğin, HTML'yi küçültmeye çalışma) durumunda web sunucusu veya CDN yapılandırmasını inceleyin. Web sunucusunun HTTP sıkıştırması (örneğin, döndüren content-encoding: br veya content-encoding: gzip) uygulaması uygundur, çünkü bu, sıkıştırmadan sonraki sonucu etkilemez. Ancak, web sunucusunun sıkıştırılmamış verileri değiştirmesi uygun değildir .

Bütünlük PowerShell betiği sorunlarını giderme

integrity.ps1 Yayımlanan ve dağıtılan Blazor bir uygulamayı doğrulamak için PowerShell betiğini kullanın. Betik, uygulamanın çerçevenin tanımlayabildiği bütünlük sorunları Blazor olduğunda başlangıç noktası olarak PowerShell Core 7 veya üzeri için sağlanır. PowerShell'in 7.2.0 sürümünden sonraki bir sürümde çalışıyor olması da dahil olmak üzere, uygulamalarınız için betiğin özelleştirilmesi gerekebilir.

Betik, bütünlük karmaları içeren farklı bildirimlerdeki publish sorunları algılamak için klasördeki ve dağıtılan uygulamadan indirilen dosyaları denetler. Bu denetimler en yaygın sorunları algılamalıdır:

• Yayımlanan çıktıdaki bir dosyayı fark etmeden değiştirdiniz.
• Uygulama dağıtım hedefine doğru şekilde dağıtılmamış veya dağıtım hedefinin ortamında bir şey değişmiştir.
• Dağıtılan uygulama ile uygulamayı yayımlama çıktısı arasında farklar vardır.

PowerShell komut kabuğunda aşağıdaki komutla betiği çağırın:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

Aşağıdaki örnekte, betik konumunda yerel olarak çalışan bir uygulamada https://localhost:5001/yürütülür:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Yer tutucu:

• {BASE URL}: Dağıtılan uygulamanın URL'si. Sondaki eğik çizgi (/) gereklidir.
• {PUBLISH OUTPUT FOLDER}: Uygulamanın publish dağıtım için yayımlandığı klasörün veya konumun yolu.

Not

GitHub deposunu klonlarken dotnet/AspNetCore.Docs betik Bitdefenderintegrity.ps1 veya sistemde bulunan başka bir virüs tarayıcısı tarafından karantinaya alınmış olabilir. Genellikle, dosya bir virüs tarayıcısının buluşsal tarama teknolojisi tarafından tuzağa düşürülür ve bu teknoloji yalnızca kötü amaçlı yazılımların varlığını gösterebilecek dosyalarda desenleri arar. Virüs tarayıcısının dosyayı hazırlamasını önlemek için, depoyu kopyalamadan önce virüs tarayıcısına bir özel durum ekleyin. Aşağıdaki örnek, Bir Windows sistemindeki betiğin tipik bir yoludur. Yolu diğer sistemler için gerektiği gibi ayarlayın. Yer tutucu {USER} , kullanıcının yol kesimidir.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

Uyarı: Virüs tarayıcısı özel durumları oluşturmak tehlikelidir ve yalnızca dosyanın güvenli olduğundan emin olduğunuzda gerçekleştirilmelidir.

Bir dosyanın sağlama toplamını geçerli bir sağlama toplamı değeriyle karşılaştırmak dosya güvenliğini garanti etmez, ancak dosyayı sağlama toplamı değerini koruyacak şekilde değiştirmek kötü amaçlı kullanıcılar için önemsiz değildir. Bu nedenle sağlama toplamları genel bir güvenlik yaklaşımı olarak yararlıdır. Yerel integrity.ps1 dosyanın sağlama toplamını aşağıdaki değerlerden biriyle karşılaştırın:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Aşağıdaki komutla Windows işletim sistemindeki dosyanın sağlama toplamını alın. Yer tutucunun yolunu ve dosya adını {PATH AND FILE NAME} belirtin ve yer tutucu SHA256 için {SHA512|MD5} üretilmesi gereken sağlama toplamı türünü (veya MD5) belirtin:

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Sağlama toplamı doğrulamasının ortamınızda yeterince güvenli olmadığı konusunda endişeleriniz varsa, rehberlik için kuruluşunuzun güvenlik liderliğine başvurun.

Daha fazla bilgi için bkz. Kötü amaçlı yazılımların & diğer tehditlerini anlama.

PWA olmayan uygulamalar için bütünlük denetimini devre dışı bırakma

Çoğu durumda bütünlük denetimini devre dışı bırakmayın. Bütünlük denetiminin devre dışı bırakılması, beklenmeyen yanıtlara neden olan ve daha önce listelenen avantajların kaybolmasına neden olan temel sorunu çözmez.

Web sunucusunun tutarlı yanıtlar döndürmesine bağımlı olmadığı durumlar olabilir ve temel alınan sorun çözülene kadar bütünlük denetimlerini geçici olarak devre dışı bırakmaktan başka seçeneğiniz olmayabilir.

Bütünlük denetimlerini devre dışı bırakmak için, uygulamanın proje dosyasındaki (.csproj özellik grubuna Blazor WebAssembly aşağıdakileri ekleyin:

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResourcesözelliği, SHA-256 karmalarına Blazordoğruluk için dayanılamadığına işaret ettiğinden , .wasmve diğer dosyaları SHA-256 karmalarına göre önbelleğe .dllalma davranışını da devre dışı bırakır. Bu ayarda bile, tarayıcının normal HTTP önbelleği bu dosyaları önbelleğe almaya devam edebilir, ancak bunun olup olmaması web sunucusu yapılandırmanıza ve cache-control hizmet veren üst bilgilere bağlıdır.

Not

özelliği Aşamalı BlazorCacheBootResourcesWeb Uygulamaları (PWA) için bütünlük denetimlerini devre dışı bırakmaz. PWA'larla ilgili yönergeler için PWA'lar için bütünlük denetimini devre dışı bırakma bölümüne bakın.

Bütünlük denetimini devre dışı bırakmanın gerekli olduğu senaryoların kapsamlı bir listesini sağlayamıyoruz. Sunucular bir isteği çerçeve kapsamı Blazor dışında rastgele yollarla yanıtlayabilir. Çerçeve, uygulamanın sağlayabilecekleri BlazorCacheBootResourcesbütünlük garantisini kaybetme karşılığında uygulamayı çalıştırılabilir hale getirme ayarını sağlar. Yine, özellikle üretim dağıtımları için bütünlük denetimini devre dışı bırakmanızı önermeyiz. Geliştiriciler, bütünlük denetiminin başarısız olmasına neden olan temel bütünlük sorununu çözmeye çalışmalıdır.

Bütünlük sorunlarına neden olabilecek birkaç genel durum şunlardır:

• Bütünlüğün denetlenebildiği HTTP'de çalışıyor.
• Dağıtım işleminiz yayımlama sonrasında dosyaları herhangi bir şekilde değiştirirse.
• Konağınız dosyaları herhangi bir şekilde değiştirirse.

PWA'lar için bütünlük denetimini devre dışı bırakma

Blazor'nin Aşamalı Web Uygulaması (PWA) şablonu, uygulama dosyalarını çevrimdışı kullanım için getirmek ve depolamaktan sorumlu önerilen service-worker.published.js bir dosya içeriyor. Bu, normal uygulama başlatma mekanizmasından ayrı bir işlemdir ve kendi ayrı bütünlük denetimi mantığına sahiptir.

Dosyanın içinde service-worker.published.js aşağıdaki satır bulunur:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Bütünlük denetimini devre dışı bırakmak için, satırı aşağıdaki şekilde değiştirerek parametresini kaldırın integrity :

.map(asset => new Request(asset.url));

Yine bütünlük denetimini devre dışı bırakmak, bütünlük denetimiyle sunulan güvenlik garantilerini kaybedeceğiniz anlamına gelir. Örneğin, yeni bir sürümü dağıttığınız anda kullanıcının tarayıcısı uygulamayı önbelleğe alırsa, eski dağıtımdaki bazı dosyaları ve yeni dağıtımdaki bazı dosyaları önbelleğe alma riski vardır. Böyle bir durumda uygulama, siz daha fazla güncelleştirme dağıtana kadar bozuk durumda takılır.

SignalR yapılandırması

SignalR'nin barındırma ve ölçeklendirme koşulları kullanan SignalRuygulamalar için Blazor geçerlidir.

Taşımalar

Blazordaha düşük gecikme süresi, daha iyi güvenilirlik ve gelişmiş güvenlik nedeniyle WebSockets'i aktarım olarak SignalR kullanırken en iyi sonucu verir. Uzun Yoklama , WebSockets kullanılamadığında veya uygulama Uzun Yoklama kullanacak şekilde açıkça yapılandırıldığında tarafından SignalR kullanılır. Azure App Service dağıtırken, uygulamayı hizmetin Azure portal ayarlarında WebSockets kullanacak şekilde yapılandırın. Uygulamayı Azure App Service için yapılandırma hakkında ayrıntılı bilgi için yayımlama yönergelerineSignalR bakın.

Uzun Yoklama kullanılırsa bir konsol uyarısı görüntülenir:

Uzun Yoklama geri dönüş aktarımı kullanılarak WebSockets aracılığıyla bağlanılamadı. Bunun nedeni bir VPN veya proxy'nin bağlantıyı engellemesi olabilir.

Genel dağıtım ve bağlantı hataları

Coğrafi veri merkezlerine genel dağıtım önerileri:

• Uygulamayı kullanıcıların çoğunun bulunduğu bölgelere dağıtın.
• Kıtalar arasındaki trafik için artan gecikme süresini dikkate alın.
• Azure barındırma için Azure SignalR Hizmeti'ni kullanın.

Dağıtılan bir uygulama İnternet gecikmesinin neden olduğu ping zaman aşımları nedeniyle yeniden bağlantı kullanıcı arabirimini sık sık görüntülüyorsa, sunucu ve istemci zaman aşımlarını uzatın:

• Sunucu

  İstemci ile sunucu arasında beklenen en yüksek gidiş dönüş süresinin en az iki katı. Zaman aşımlarını gerektiği gibi test edin, izleyin ve düzeltin. Hub için SignalR (varsayılan: 30 saniye) ve HandshakeTimeout (varsayılan: 15 saniye) ayarlayın ClientTimeoutInterval . Aşağıdaki örnekte varsayılan 15 saniye değerinin kullanıldığı varsayılır KeepAliveInterval .

  Önemli

  , KeepAliveInterval görüntülenen yeniden bağlantı kullanıcı arabirimiyle doğrudan ilgili değildir. Keep-Alive aralığının değiştirilmesi gerekmez. Yeniden bağlantı kullanıcı arabirimi görünümü sorunu zaman aşımlarından kaynaklanıyorsa ve ClientTimeoutIntervalHandshakeTimeout artırılabilir ve Keep-Alive aralığı aynı kalabilir. Önemli olan, Keep-Alive aralığını değiştirirseniz istemci zaman aşımı değerinin Keep-Alive aralığının değerinin en az iki katı olduğundan ve istemcideki Keep-Alive aralığının sunucu ayarıyla eşleştiğinden emin olmanızdır.

  Aşağıdaki örnekte, ClientTimeoutInterval 60 saniyeye HandshakeTimeout ve 30 saniyeye yükseltilir.

  Projede Program.cs barındırılan Blazor WebAssemblyServer bir uygulama için:

  builder.Services.AddSignalR(options =>
  {
       options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
       options.HandshakeTimeout = TimeSpan.FromSeconds(30);
  });
  

  Daha fazla bilgi için bkz. ASP.NET Core BlazorSignalR kılavuzu.

• İstemci

  Genellikle, istemcinin sunucu zaman aşımı için zaman aşımını ayarlamak için sunucularda KeepAliveInterval kullanılan değerin iki katı (ServerTimeoutvarsayılan: 30 saniye).

  Önemli

  Keep-Alive aralığı (KeepAliveInterval) görüntülenen yeniden bağlantı kullanıcı arabirimiyle doğrudan ilişkili değildir. Keep-Alive aralığının değiştirilmesi gerekmez. Yeniden bağlantı kullanıcı arabirimi görünümü sorunu zaman aşımlarından kaynaklanıyorsa, sunucu zaman aşımı artırılabilir ve Keep-Alive aralığı aynı kalabilir. Önemli nokta, Keep-Alive aralığını değiştirirseniz zaman aşımı değerinin Keep-Alive aralığının değerinin en az iki katı olduğundan ve sunucudaki Keep-Alive aralığının istemci ayarıyla eşleştiğinden emin olmanızdır.

  Aşağıdaki örnekte, sunucu zaman aşımı için 60 saniyelik özel bir değer kullanılmıştır.

  Bir bileşende hub bağlantısı oluştururken, yerleşik HubConnectionüzerinde (varsayılan: 30 saniye) ve HandshakeTimeout (varsayılan: 15 saniye) ayarlayın ServerTimeout .

  Aşağıdaki örnek, ile Blazor öğreticisindekiSignalRIndex bileşeni temel alır. Sunucu zaman aşımı 60 saniyeye yükseltilir ve el sıkışması zaman aşımı 30 saniyeye çıkarılır:

  protected override async Task OnInitializedAsync()
  {
      hubConnection = new HubConnectionBuilder()
          .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
          .Build();
  
      hubConnection.ServerTimeout = TimeSpan.FromSeconds(60);
      hubConnection.HandshakeTimeout = TimeSpan.FromSeconds(30);
  
      hubConnection.On<string, string>("ReceiveMessage", (user, message) => ...
  
      await hubConnection.StartAsync();
  }
  

  Sunucu zaman aşımı (ServerTimeout) veya Keep-Alive aralığının (KeepAliveInterval:

  • Sunucu zaman aşımı, Keep-Alive aralığına atanan değerin en az iki katı olmalıdır.
  • Keep-Alive aralığı, sunucu zaman aşımına atanan değerin yarısından küçük veya buna eşit olmalıdır.

Daha fazla bilgi için bkz. ASP.NET Core BlazorSignalR kılavuzu.

Barındırma modeli ileBlazor WebAssembly:

• Uygulama Blazor , bağımlılıkları ve .NET çalışma zamanı paralel olarak tarayıcıya indirilir.
• Uygulama doğrudan tarayıcı kullanıcı arabirimi iş parçacığında yürütülür.

Aşağıdaki dağıtım stratejileri desteklenir:

• Uygulama Blazor bir ASP.NET Core uygulaması tarafından sunulur. Bu strateji, ASP.NET Core ile barındırılan dağıtım bölümünde ele alınmıştır.
• Uygulama Blazor statik bir barındırma web sunucusuna veya hizmetine yerleştirilir; burada .NET, uygulamayı sunmak Blazor için kullanılmaz. Bu strateji, bir Blazor WebAssembly uygulamayı IIS alt uygulaması olarak barındırmayla ilgili bilgileri içeren Tek başına dağıtım bölümünde ele alınmıştır.
• bir ASP.NET Core uygulaması birden çok Blazor WebAssembly uygulamayı barındırıyor. Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Önceden (AOT) derleme

Blazor WebAssembly , .NET kodunuzu doğrudan WebAssembly'de derleyebileceğiniz önceden (AOT) derlemeyi destekler. AOT derlemesi, daha büyük bir uygulama boyutuna zarar verebilirsiniz.

AOT derlemesini etkinleştirmeden, Blazor WebAssembly uygulamalar WebAssembly'de uygulanan bir .NET Ara Dil (IL) yorumlayıcısını kullanarak tarayıcıda çalışır. .NET kodu yorumlandığından, uygulamalar genellikle sunucu tarafı .NET tam zamanında (JIT) çalışma zamanına göre daha yavaş çalışır. AOT derlemesi, tarayıcı tarafından yerel WebAssembly yürütmesi için uygulamanın .NET kodunu doğrudan WebAssembly'ye derleyerek bu performans sorununu giderir. AOT performans geliştirmesi, YOĞUN CPU kullanan görevleri yürüten uygulamalar için önemli geliştirmeler sağlayabilir. AOT derlemesini kullanmanın dezavantajı, AOT ile derlenen uygulamaların genellikle IL tarafından yorumlanan karşılıklarından daha büyük olmasıdır, bu nedenle ilk istendiğinde istemciye indirilmesi genellikle daha uzun sürer.

.NET WebAssembly derleme araçlarını yüklemeyle ilgili yönergeler için bkz. ASP.NET Core Blazoriçin araç oluşturma.

WebAssembly AOT derlemesini <RunAOTCompilation>true etkinleştirmek için Blazor WebAssembly , özelliğini uygulamanın proje dosyasına ekleyin:

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

Uygulamayı WebAssembly'de derlemek için uygulamayı yayımlayın. Yapılandırmanın yayımlanması Release , yayımlanan uygulamanın boyutunu küçültmek için .NET Ara Dil (IL) bağlamasının da çalıştırılmasını sağlar:

dotnet publish -c Release

WebAssembly AOT derlemesi yalnızca proje yayımlandığında gerçekleştirilir. AOT derlemesi genellikle küçük projelerde birkaç dakika ve büyük projeler için büyük olasılıkla çok daha uzun sürdüğünden, proje geliştirme (Development ortam) sırasında çalıştırıldığında kullanılmaz. AOT derlemesi için derleme süresini kısaltmak, ASP.NET Core'in gelecek sürümleri için geliştirme aşamasındadır.

AOT ile derlenmiş Blazor WebAssembly bir uygulamanın boyutu genellikle .NET IL'de derlenmişse uygulamanın boyutundan daha büyüktür:

• Boyut farkı uygulamaya bağlı olsa da, AOT ile derlenen uygulamaların çoğu IL ile derlenmiş sürümlerinin yaklaşık iki katı boyuttadır. Başka bir deyişle, AOT derlemesi kullanıldığında çalışma zamanı performansı için yük süresi performansından yararlanılır. Bu dezavantajın AOT derlemesini kullanmaya değip değmeyeceği uygulamanıza bağlıdır. Blazor WebAssembly YOĞUN CPU kullanan uygulamalar genellikle AOT derlemesinden en çok yararlanan uygulamalardır.

• AOT ile derlenmiş bir uygulamanın boyutunun büyük olması iki koşuldan kaynaklanır:

  • Yerel WebAssembly'de üst düzey .NET IL yönergelerini göstermek için daha fazla kod gerekir.
  • AOT, uygulama yayımlandığında yönetilen DLL'leri kırpmaz . Blazor yansıma meta verileri için DLL'leri gerektirir ve bazı .NET çalışma zamanı özelliklerini destekler. İstemcide DLL'lerin gerekli hale getirilmesi indirme boyutunu artırır ancak daha uyumlu bir .NET deneyimi sağlar.

Not

Mono/WebAssembly MSBuild özellikleri ve hedefleri için bkz WasmApp.targets . (dotnet/runtime GitHub deposu). Yaygın MSBuild özellikleri için resmi belgeler , Document blazor msbuild yapılandırma seçeneklerine göre planlanmaktadır (dotnet/docs #27395).

Çalışma zamanı yeniden bağlama

Bir Blazor WebAssembly uygulamanın en büyük parçalarından biri, uygulamaya kullanıcının tarayıcısı tarafından ilk kez erişildiğinde tarayıcının indirmesi gereken WebAssembly tabanlı .NET çalışma zamanıdır (dotnet.wasm). .NET WebAssembly çalışma zamanının yeniden bağlanması kullanılmayan çalışma zamanı kodunu kırparak indirme hızını artırır.

Çalışma zamanı yeniden bağlama için .NET WebAssembly derleme araçlarının yüklenmesi gerekir. Daha fazla bilgi için bkz. ASP.NET Core Blazoraraçları.

.NET WebAssembly derleme araçları yüklendiğinde, yapılandırmada Release bir uygulama yayımlandığında çalışma zamanı yeniden bağlama işlemi otomatik olarak gerçekleştirilir. Genelleştirme devre dışı bırakıldığında boyut azaltma özellikle çarpıcıdır. Daha fazla bilgi için bkz. genelleştirme ve yerelleştirme ASP.NET CoreBlazor.

Önyükleme kaynaklarının yüklenme biçimini özelleştirme

API kullanarak önyükleme kaynaklarının nasıl yüklendiğini özelleştirin loadBootResource . Daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırma

Bir Blazor WebAssembly uygulama yayımlandığında, uygulamanın boyutunu azaltmak ve çalışma zamanı sıkıştırma ek yükünü kaldırmak için çıkış yayımlama sırasında statik olarak sıkıştırılır. Aşağıdaki sıkıştırma algoritmaları kullanılır:

• Brotli (en yüksek düzey)
• Gzip

Blazor uygun sıkıştırılmış dosyaları sunmak için konağa dayanır. ASP.NET Core BarındırılanBlazor WebAssembly proje kullanılırken, konak projesi içerik anlaşması gerçekleştirebilir ve statik olarak sıkıştırılmış dosyalara hizmet yapabilir. Tek başına bir Blazor WebAssembly uygulama barındırırken, statik olarak sıkıştırılmış dosyaların sunulduğunda emin olmak için ek çalışma gerekebilir:

• IIS web.config sıkıştırma yapılandırması için IIS: Brotli ve Gzip sıkıştırma bölümüne bakın.

• GitHub Pages gibi statik olarak sıkıştırılmış dosya içeriği anlaşmasını desteklemeyen statik barındırma çözümlerinde barındırırken uygulamayı Brotli sıkıştırılmış dosyalarını getirmek ve kodunu çözmek için yapılandırmayı göz önünde bulundurun:

  • Google/brotli GitHub deposundan JavaScript Brotli kod çözücüsü edinin. Küçültüldü kod çözücü dosyası olarak adlandırılır decode.min.js ve deponun js klasöründe bulunur.

    Not

    Betiğin (decode.min.js) küçültüldü sürümü decode.js başarısız olursa, bunun yerine doğrulanmamış sürümü (decode.js) kullanmayı deneyin.

  • Uygulamayı kod çözücü kullanacak şekilde güncelleştirin.

    wwwroot/index.html dosyasında, 'nin <script> etiketinde falseBlazorolarak ayarlayınautostart:

    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    

    etiketinden <script> sonra Blazorve kapanış </body> etiketinden önce aşağıdaki JavaScript kod <script> bloğunu ekleyin:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            return (async function () {
              const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
              if (!response.ok) {
                throw new Error(response.statusText);
              }
              const originalResponseBuffer = await response.arrayBuffer();
              const originalResponseArray = new Int8Array(originalResponseBuffer);
              const decompressedResponseArray = BrotliDecode(originalResponseArray);
              const contentType = type === 
                'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
              return new Response(decompressedResponseArray, 
                { headers: { 'content-type': contentType } });
            })();
          }
        }
      });
    </script>
    

    Önyükleme kaynaklarını yükleme hakkında daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırmayı BlazorEnableCompression devre dışı bırakmak için MSBuild özelliğini uygulamanın proje dosyasına ekleyin ve değerini olarak falseayarlayın:

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

özelliği, BlazorEnableCompression komut kabuğunda dotnet publish aşağıdaki söz dizimiyle komutuna geçirilebilir:

dotnet publish -p:BlazorEnableCompression=false

Doğru yönlendirme için URL'leri yeniden yazma

Bir Blazor WebAssembly uygulamadaki sayfa bileşenleri için yönlendirme istekleri, barındırılan bir Blazor Serveruygulamadaki yönlendirme istekleri kadar basit değildir. İki bileşeni olan bir Blazor WebAssembly uygulamayı göz önünde bulundurun:

• Main.razor: Uygulamanın köküne yüklenir ve bileşene About (href="About") bir bağlantı içerir.
• About.razor: About bileşeni.

Tarayıcının adres çubuğu kullanılarak uygulamanın varsayılan belgesi istendiğinde (örneğin: https://www.contoso.com/

1. Tarayıcı bir istekte bulunur.
2. Varsayılan sayfa döndürülür; bu genellikle index.htmlşeklindedir.
3. index.html uygulamayı bootstraplar.
4. Blazor'nin yönlendiricisi yüklenir ve RazorMain bileşen işlenir.

Ana sayfada, bileşenin bağlantısının About seçilmesi istemcide çalışır çünkü Blazor yönlendirici tarayıcının için İnternet'te istekte bulunmasını www.contoso.comAbout durdurur ve işlenen About bileşenin kendisine hizmet eder. Uygulama içindeki Blazor WebAssembly iç uç noktalara yönelik tüm istekler aynı şekilde çalışır: İstekler, İnternet'te sunucu tarafından barındırılan kaynaklara tarayıcı tabanlı istekler tetiklemez. Yönlendirici istekleri dahili olarak işler.

için tarayıcının adres çubuğu www.contoso.com/Aboutkullanılarak istek yapılırsa istek başarısız olur. Uygulamanın İnternet ana bilgisayarında böyle bir kaynak olmadığından 404 - Bulunamadı yanıtı döndürülür.

Tarayıcılar istemci tarafı sayfalar için İnternet tabanlı konaklara istekte bulunacağından, web sunucularının ve barındırma hizmetlerinin sunucuda fiziksel olarak sayfaya olmayan kaynaklara yönelik tüm istekleri yeniden yazması index.html gerekir. Döndürülürse index.html , uygulamanın yönlendiricisi Blazor bunu devralır ve doğru kaynakla yanıt verir.

IIS sunucusuna dağıtım yaparken url yeniden yazma modülünü uygulamanın yayımlanan web.config dosyasıyla kullanabilirsiniz. Daha fazla bilgi için IIS bölümüne bakın.

ASP.NET Core ile barındırılan dağıtım

BarındırılanBlazor WebAssembly dağıtım, uygulamayı web sunucusunda çalışan bir ASP.NET Core uygulamasından tarayıcılara hizmet eder.

İstemci Blazor WebAssembly uygulaması, sunucu uygulamasının /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot diğer statik web varlıklarıyla birlikte sunucu uygulamasının klasörüne yayımlanır. İki uygulama birlikte dağıtılır. bir ASP.NET Core uygulamasını barındırabilen bir web sunucusu gereklidir. Barındırılan Blazor WebAssembly bir dağıtım için Visual Studio, Uygulama projesi şablonunu (blazorwasmkomutu kullanırken dotnet new şablon) ve seçeneğinin Hosted seçili olduğunu (-ho|--hostedkomutu kullanırkendotnet new) içerir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• ASP.NET Core uygulama barındırma ve dağıtma: ASP.NET Core barındırma ve dağıtma
• Azure App Service dağıtımı: Visual Studio ile ASP.NET Core uygulamasını Azure'da yayımlama
• Blazorproje şablonları: ASP.NET Core Blazor proje yapısı

Belirli bir platform için çerçeveye bağımlı yürütülebilir dosyanın barındırılan dağıtımı

Barındırılan Blazor WebAssembly bir uygulamayı belirli bir platform için (bağımsız olmayan) çerçeveye bağımlı yürütülebilir dosya olarak dağıtmak için, kullanımdaki araçlara bağlı olarak aşağıdaki kılavuzu kullanın.

Visual Studio

Varsayılan olarak, oluşturulan yayımlama profili (.pubxml ) için bağımsız bir dağıtım yapılandırılır. Projenin yayımlama profilinin Server olarak ayarlanmış MSBuild özelliğini içerdiğini <SelfContained>falseonaylayın.

Projenin Properties klasöründeki .pubxmlServer yayımlama profili dosyasında:

<SelfContained>false</SelfContained>

Yayımlama profilinde MSBuild özelliğini oluşturan Yayımlama Kullanıcı Arabiriminin Ayarlar alanındaki Hedef Çalışma Zamanı ayarını kullanarak Çalışma Zamanı Tanımlayıcısı'nı<RuntimeIdentifier> (RID) ayarlayın:

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Server Projeyi Yayın yapılandırmasında yayımlayın.

Not

Yer tutucunun profil olduğu {PROFILE} komutuna geçirerek dotnet publish/p:PublishProfile={PROFILE} .NET CLI kullanarak profil yayımlama ayarlarına sahip bir uygulama yayımlamak mümkündür. Daha fazla bilgi için, ASP.NET Core uygulama dağıtımı için Visual Studio yayımlama profilleri (.pubxml) makalesindeki Profilleri yayımlamaveKlasör yayımlama örneği bölümlerine bakın. RID'yi yayımlama profilinde dotnet publish değil komutunda geçirirseniz, MSBuild özelliğini ()/p:RuntimeIdentifier) seçeneğiyle değil komutuyla -r|--runtime kullanın.

.NET CLI

MSBuild özelliğini projenin proje dosyasında olarak ayarlanmış falsebir <PropertyGroup>Server içine yerleştirerek <SelfContained>bağımsız bir dağıtım yapılandırın:

<SelfContained>false</SelfContained>

Önemli

SelfContained özelliği projenin proje dosyasına yerleştirilmelidirServer. özelliği, seçeneği veya MSBuild özelliği /p:SelfContained=falsekullanılarak --no-self-containedkomutuyladotnet publish doğru ayarlanamaz.

Aşağıdaki yaklaşımlardan birini kullanarak Çalışma Zamanı Tanımlayıcısı'nı (RID) ayarlayın:

• Seçenek 1: Projenin proje dosyasındaki bir <PropertyGroup> içindeki Server RID'yi ayarlayın:

  <RuntimeIdentifier>{RID}</RuntimeIdentifier>
  

  Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

  Uygulamayı projeden Yayın yapılandırmasında Server yayımlayın:

  dotnet publish -c Release
  

• 2. Seçenek: Komutundaki RID'yi dotnet publish şu seçenekle -r|--runtimedeğil MSBuild özelliği ()/p:RuntimeIdentifier olarak geçirin:

  dotnet publish -c Release /p:RuntimeIdentifier={RID}
  

  Yukarıdaki komutta {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• .NET uygulaması yayımlamaya genel bakış
• ASP.NET Core barındırma ve dağıtma

Birden çok uygulamayla barındırılan Blazor WebAssembly dağıtım

Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Tek başına dağıtım

Tek başına dağıtım, uygulamayı doğrudan istemciler Blazor WebAssembly tarafından istenen statik dosyalar kümesi olarak sunar. Herhangi bir statik dosya sunucusu uygulamaya hizmet Blazor yapabilir.

Tek başına dağıtım varlıkları klasörüne /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot yayımlanır.

Azure App Service

Blazor WebAssemblyuygulamalar, uygulamayı IIS'de barındıran Windows Azure Uygulaması Hizmetlerine dağıtılabilir.

Linux için Azure App Service'a tek başına Blazor WebAssembly uygulama dağıtma şu anda desteklenmemekte. Bu senaryoyı destekleyen Azure Static Web Apps kullanarak tek başına Blazor WebAssembly bir uygulama barındırmanızı öneririz.

Azure Statik Web Uygulamaları

Daha fazla bilgi için bkz. Öğretici: Azure Static Web Apps'de ile Blazor statik web uygulaması oluşturma.

IIS

IIS, uygulamalar için Blazor yetenekli bir statik dosya sunucusudur. IIS'yi barındıracak Blazorşekilde yapılandırmak için bkz. IIS'de Statik Web Sitesi Oluşturma.

Yayımlanan varlıklar, SDK'nın hangi sürümünün /bin/Release/{TARGET FRAMEWORK}/publish kullanıldığına ve yer tutucunun hedef çerçeve olduğuna {TARGET FRAMEWORK} bağlı olarak veya bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish klasöründe oluşturulur. Klasörün içeriğini publish web sunucusunda veya barındırma hizmetinde barındırın.

web.config

Bir Blazor proje yayımlandığında, aşağıdaki IIS yapılandırmasıyla bir web.config dosya oluşturulur:

• MIME türleri
• HTTP sıkıştırması aşağıdaki MIME türleri için etkinleştirilir:
  • application/octet-stream
  • application/wasm
• URL Yeniden Yazma Modülü kuralları oluşturulur:
  • Uygulamanın statik varlıklarının (wwwroot/{PATH REQUESTED}) bulunduğu alt dizine hizmet edin.
  • Dosya olmayan varlıklara yönelik isteklerin statik varlıklar klasöründekiwwwroot/index.html ( ) uygulamanın varsayılan belgesine yeniden yönlendirilmesi için SPA geri dönüş yönlendirmesi oluşturun.

Özel kullanım web.config

Özel web.config dosya kullanmak için:

1. Özel web.config dosyayı projenin kök klasörüne yerleştirin. Barındırılan Blazor WebAssembly bir çözüm için dosyayı Server projenin klasörüne yerleştirin.
2. Projeyi yayımlayın. Barındırılan Blazor WebAssembly bir çözüm için çözümü projeden Server yayımlayın. Daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

SDK'nın web.config yayımlama sırasındaki oluşturma veya dönüştürme işlemi, dosyayı klasördeki publish yayımlanmış varlıklara taşımazsa veya özel web.config dosyanızdaki özel yapılandırmayı değiştirirse, işlemin tam denetimini almak için aşağıdaki yaklaşımlardan herhangi birini kullanın:

• SDK dosyayı oluşturmuyorsa( örneğin, SDK'nın hangi sürümünün kullanıldığına ve yer tutucunun hedef çerçeve olduğuna bağlı olarak, veya konumundaki tek başına Blazor WebAssembly bir uygulamadabin\Release\{TARGET FRAMEWORK}\browser-wasm\publish/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot) özelliğini true proje dosyasında ().csproj olarak ayarlayın<PublishIISAssets>.{TARGET FRAMEWORK} Genellikle tek başına WebAssembly uygulamaları için, özel web.config bir dosyayı taşımak ve dosyanın SDK tarafından dönüştürülmesini önlemek için gereken tek ayar budur.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• SDK'nın web.config proje dosyasındaki dönüştürmesini devre dışı bırakın (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Özel bir dosyayı taşımak için proje dosyasına (.csproj) özel web.config bir hedef ekleyin. Aşağıdaki örnekte, özel web.config dosya geliştirici tarafından projenin köküne yerleştirilir. web.config Dosya başka bir yerde bulunuyorsa içinde dosyanın SourceFilesyolunu belirtin. Aşağıdaki örnek, ile klasörünü belirtirpublish, ancak özel çıkış konumu için bir yol DestinationFolder$(PublishDir)sağlar.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

URL Yeniden Yazma Modülünü Yükleme

URL'leri yeniden yazmak için URL Yeniden Yazma Modülü gereklidir. Modül varsayılan olarak yüklenmez ve Web Sunucusu (IIS) rol hizmeti özelliği olarak yüklenebilir. Modülün IIS web sitesinden indirilmesi gerekir. Modülü yüklemek için Web Platformu Yükleyicisi'ni kullanın:

1. Yerel olarak URL Yeniden Yazma Modülü indirmeleri sayfasına gidin. İngilizce sürüm için WebPI yükleyicisini indirmek için WebPI'yi seçin. Diğer diller için, yükleyiciyi indirmek üzere sunucu (x86/x64) için uygun mimariyi seçin.
2. Yükleyiciyi sunucuya kopyalayın. Yükleyiciyi çalıştırın. Yükle düğmesini seçin ve lisans koşullarını kabul edin. Yükleme tamamlandıktan sonra sunucunun yeniden başlatılması gerekmez.

Web sitesini yapılandırma

Web sitesinin Fiziksel yolunu uygulamanın klasörüne ayarlayın. Klasör aşağıdakileri içerir:

• Iis'nin web.config gerekli yeniden yönlendirme kuralları ve dosya içerik türleri de dahil olmak üzere web sitesini yapılandırmak için kullandığı dosya.
• Uygulamanın statik varlık klasörü.

IIS alt uygulaması olarak barındırma

Tek başına bir uygulama IIS alt uygulaması olarak barındırılıyorsa aşağıdakilerden birini gerçekleştirin:

• Devralınan ASP.NET Core Modülü işleyicisini devre dışı bırakın.

  Dosyanın bölümüne bir <handlers> bölüm ekleyerek uygulamanın yayımlanan web.config dosyasındaki işleyiciyi Blazor<system.webServer> kaldırın:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• olarak ayarlanmış bir <location> öğe inheritInChildApplications kullanarak kök (üst) uygulamanın <system.webServer> bölümünün devralını falsedevre dışı bırakın:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Not

  Kök (üst) uygulamanın <system.webServer> bölümünün devralmayı devre dışı bırakmak, .NET SDK'sı kullanılarak yayımlanan uygulamalar için varsayılan yapılandırmadır.

İşleyiciyi kaldırma veya devralmayı devre dışı bırakma işlemi , uygulamanın temel yolunu yapılandırmaya ek olarak gerçekleştirilir. Uygulamanın dosyasındaki uygulama temel yolunu IIS'de index.html alt uygulamayı yapılandırırken kullanılan IIS diğer adı olarak ayarlayın.

Brotli ve Gzip sıkıştırması

Bu bölüm yalnızca tek başına Blazor WebAssembly uygulamalar için geçerlidir. Barındırılan Blazor uygulamalar, bu bölümdeki bağlantılı dosyayı değil, varsayılan ASP.NET Core uygulama web.config dosyasını kullanır.

IIS, aracılığıyla tek başına Blazor WebAssembly uygulamalar için Brotli veya Gzip sıkıştırılmış Blazor varlıklarına hizmet vermek üzere yapılandırılabilirweb.config. Örnek bir yapılandırma dosyası için bkz web.config. .

Aşağıdaki senaryolarda örnek web.config dosyanın ek yapılandırması gerekebilir:

• Uygulamanın belirtimi aşağıdakilerden birini çağırır:
  • Örnek web.config dosya tarafından yapılandırılmamış sıkıştırılmış dosyalar sunma.
  • Örnek web.config dosya tarafından yapılandırılan sıkıştırılmış dosyaları sıkıştırılmamış biçimde sunma.
• Sunucunun IIS yapılandırması (örneğin, applicationHost.config) sunucu düzeyinde IIS varsayılanları sağlar. Sunucu düzeyinde yapılandırmaya bağlı olarak, uygulama örnek web.config dosyanın içerdiğinden farklı bir IIS yapılandırması gerektirebilir.

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Sorun giderme

500 - İç Sunucu Hatası alınırsa ve IIS Yöneticisi web sitesinin yapılandırmasına erişmeye çalışırken hatalar oluşturursa, URL Yeniden Yazma Modülü'nin yüklü olduğunu onaylayın. Modül yüklenmediğinde dosya web.config IIS tarafından ayrıştırılamaz. Bu, IIS Yöneticisi'nin web sitesinin yapılandırmasını ve web sitesinin statik dosyaları sunmasını Blazorengeller.

IIS dağıtımlarının sorunlarını giderme hakkında daha fazla bilgi için bkz. Azure App Service ve IIS'de ASP.NET Core sorunlarını giderme.

Azure Depolama

Azure Depolama statik dosya barındırma sunucusuz Blazor uygulama barındırmaya olanak tanır. Özel etki alanı adları, Azure Content Delivery Network (CDN) ve HTTPS desteklenir.

Blob hizmeti bir depolama hesabında statik web sitesi barındırma için etkinleştirildiğinde:

• Dizin belge adını olarak index.htmlayarlayın.
• Hata belgesi yolunu olarak index.htmlayarlayın. Razor bileşenleri ve diğer dosya olmayan uç noktalar blob hizmeti tarafından depolanan statik içerikteki fiziksel yollarda yer almaz. Yönlendiricinin işlemesi gereken bu kaynaklardan birine yönelik bir istek alındığında Blazor , blob hizmeti tarafından oluşturulan 404 - Bulunamadı hatası isteği Hata belge yoluna yönlendirir. index.html Blob döndürülür ve Blazor yönlendirici yolu yükler ve işler.

Dosyaların üst bilgilerindeki uygunsuz MIME türleri nedeniyle dosyalar Content-Type çalışma zamanında yüklenmiyorsa, aşağıdaki eylemlerden birini gerçekleştirin:

• Dosyalar dağıtıldığında doğru MIME türlerini (Content-Type üst bilgiler) ayarlamak için araçlarınızı yapılandırın.

• Uygulama dağıtıldıktan sonra dosyaların MIME türlerini (Content-Type üst bilgileri) değiştirin.

  Her dosya için Depolama Gezgini (Azure portal) içinde:

  1. Dosyaya sağ tıklayın ve Özellikler’i seçin.
  2. ContentType'ı ayarlayın ve Kaydet düğmesini seçin.

Daha fazla bilgi için bkz. Azure Depolama'da statik web sitesi barındırma.

Nginx

Aşağıdaki nginx.conf dosya, diskte karşılık gelen bir dosyayı bulamadan Nginx'in dosyayı gönderecek index.html şekilde nasıl yapılandırıldığını gösterecek şekilde basitleştirilmiştir.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

ile limit_reqBlazor WebAssemblyNGINX seri hız sınırını ayarlarken, uygulamalar bir uygulama tarafından yapılan görece çok sayıda isteği karşılamak için büyük burst bir parametre değeri gerektirebilir. Başlangıçta değeri en az 60 olarak ayarlayın:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Tarayıcı geliştirici araçları veya ağ trafiği aracı isteklerin 503 - Hizmet Kullanılamıyor durum kodu aldığını gösteriyorsa değeri artırın.

Üretim Nginx web sunucusu yapılandırması hakkında daha fazla bilgi için bkz. NGINX Plus ve NGINX Yapılandırma Dosyaları Oluşturma.

Apache

Bir uygulamayı CentOS 7 veya sonraki bir Blazor WebAssembly sürümüne dağıtmak için:

1. Apache yapılandırma dosyasını oluşturun. Aşağıdaki örnek, basitleştirilmiş bir yapılandırma dosyasıdır (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
       AddType application/octet-stream .dll
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
         BrowserMatch ^Mozilla/4 gzip-only-text/html
         BrowserMatch ^Mozilla/4.0[678] no-gzip
         BrowserMatch bMSIE !no-gzip !gzip-only-text/html
     </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

2. Apache yapılandırma dosyasını CentOS 7'deki varsayılan Apache yapılandırma dizini olan dizine /etc/httpd/conf.d/ yerleştirin.

3. Uygulamanın dosyalarını dizinine /var/www/blazorapp (yapılandırma dosyasında belirtilen DocumentRoot konum) yerleştirin.

4. Apache hizmetini yeniden başlatın.

Daha fazla bilgi için mod_mime ve mod_deflate bölümlerine bakın.

GitHub Pages

Sayfaları dağıtan varsayılan GitHub Eylemi, klasör gibi alt çizgiyle başlayan klasörlerin dağıtımını _framework atlar. Alt çizgiyle başlayan klasörleri dağıtmak için Git dalı için boş .nojekyll bir dosya ekleyin.

Git, gibi blazor.webassembly.jsJavaScript (JS) dosyalarını metin olarak ele alır ve satır sonlarını CRLF'den (satır dönüş satırı akışı) dağıtım işlem hattında LF'ye (satır akışı) dönüştürür. Dosyalarda yapılan JS bu değişiklikler, dosyadaki blazor.boot.json istemciye göndermeden Blazor farklı dosya karmaları oluşturur. Uyuşmazlıklar istemcide bütünlük denetimi hatalarına neden olur. Bu sorunu çözmenin bir yaklaşımı, uygulamanın varlıklarını Git dalı'na eklemeden önce satırı olan *.js binary bir .gitattributes dosya eklemektir. satırı Git'i *.js binary dosyaları ikili dosyalar olarak değerlendirecek JS şekilde yapılandırarak dağıtım işlem hattındaki dosyaların işlenmesini önler. İşlenmemiş dosyaların dosya karmaları dosyadaki blazor.boot.json girdilerle eşleşir ve istemci tarafı bütünlük denetimleri geçer. Daha fazla bilgi için Bütünlük denetimi hatalarını çözme bölümüne bakın.

URL yeniden yazma işlemlerini işlemek için, isteği sayfaya index.html yönlendirmeyi işleyen bir betik içeren bir dosya ekleyinwwwroot/404.html. Bir örnek için bkz. SteveSandersonMS/BlazorOnGitHubPages GitHub deposu:

• wwwroot/404.html
• Canlı site

Kuruluş sitesi yerine proje sitesi kullanırken içindeki etiketini wwwroot/index.htmlgüncelleştirin<base>. href Öznitelik değerini, sonunda eğik çizgiyle GitHub deposu adına ayarlayın (örneğin, /my-repository/). SteveSandersonMS/BlazorOnGitHubPages GitHub deposunda, temel hrefyapılandırma dosyası tarafından.github/workflows/main.yml yayımlandığında güncelleştirilir.

Not

SteveSandersonMS/BlazorOnGitHubPages GitHub deposu .NET Foundation veya Microsoft'a ait değildir, korunmaz veya desteklenmez.

Docker ile tek başına

Tek başına Blazor WebAssembly bir uygulama, statik dosya sunucusu tarafından barındırılan statik dosyalar kümesi olarak yayımlanır.

Uygulamayı Docker'da barındırmak için:

• Ngnix veya Apache gibi web sunucusu desteğine sahip bir Docker kapsayıcısı seçin.
• publish Klasör varlıklarını, statik dosyalara hizmet vermek için web sunucusunda tanımlanan bir konum klasörüne kopyalayın.
• Uygulamaya hizmet vermek için gereken ek yapılandırmayı Blazor WebAssembly uygulayın.

Yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Bu makalenin Nginx bölümü veya Apache bölümü
• Docker Belgeleri

Konak yapılandırma değerleri

Blazor WebAssembly uygulamalar , geliştirme ortamında çalışma zamanında komut satırı bağımsız değişkenleri olarak aşağıdaki konak yapılandırma değerlerini kabul edebilir.

İçerik kökü

bağımsız değişkeni, --contentroot uygulamanın içerik dosyalarını (içerik kökü) içeren dizinin mutlak yolunu ayarlar. Aşağıdaki örneklerde uygulamanın /content-root-path içerik kök yolu verilmiştir.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --contentroot=/content-root-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulama Visual Studio Hata Ayıklayıcısı ile çalıştırıldığında ve ile dotnet runbir komut isteminden çalıştırıldığında kullanılır.

  "commandLineArgs": "--contentroot=/content-root-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --contentroot=/content-root-path
  

Yol tabanı

--pathbase bağımsız değişkeni, kök olmayan göreli URL yolu ile yerel olarak çalıştırılacak bir uygulamanın uygulama temel yolunu ayarlar (<base>etiket href hazırlama ve üretim dışında / bir yola ayarlanır). Aşağıdaki örneklerde uygulamanın /relative-URL-path yol tabanı verilmiştir. Daha fazla bilgi için bkz. Uygulama temel yolu.

Önemli

etiketine sağlanan href<base> yoldan farklı olarak, bağımsız değişken değerini geçirirken sondaki eğik çizgi (/) eklemeyin --pathbase . Uygulama temel yolu etiketinde <base> olarak <base href="/CoolApp/"> sağlanıyorsa (sonunda eğik çizgi varsa), komut satırı bağımsız değişken değerini olarak --pathbase=/CoolApp geçirin (sondaki eğik çizgi yok).

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --pathbase=/relative-URL-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --pathbase=/relative-URL-path
  

URL’ler

bağımsız değişkeni, --urls istekleri dinlemek üzere bağlantı noktaları ve protokollerle IP adreslerini veya konak adreslerini ayarlar.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --urls=http://127.0.0.1:0
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --urls=http://127.0.0.1:0
  

Linux'ta barındırılan dağıtım (Nginx)

ara sunucularla ve X-Forwarded-Protoyük dengeleyicilerle çalışmak için ASP.NET Core yapılandırma başlığındaki yönergeleri izleyerek ve üst bilgilerini iletmek X-Forwarded-For için uygulamasını ile ForwardedHeadersOptions yapılandırın.

Alt uygulama yolu yapılandırması da dahil olmak üzere uygulamanın temel yolunu ayarlama hakkında daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

Aşağıdaki değişiklikleri içeren bir ASP.NET Core SignalR uygulamasının yönergelerini izleyin:

• Ayar yalnızca uygulama istemci-sunucu etkileşimleriyle ilgili Blazor olmayan Sunucu Tarafından Gönderilen Olaylar (SSE) için geçerli olduğundan ara sunucu arabelleğe alma (proxy_buffering off;) yapılandırmasını kaldırın.

• location Yolu /hubroute (location /hubroute { ... } ) olan alt uygulama yoluna /{PATH} ()location /{PATH} { ... } değiştirin; burada {PATH} yer tutucu alt uygulama yoludur.

  Aşağıdaki örnekte, kök yolda /isteklere yanıt veren bir uygulama için sunucu yapılandırılır:

  http {
      server {
          ...
          location / {
              ...
          }
      }
  }
  

  Aşağıdaki örnek, uygulamasının alt uygulama yolunu /blazoryapılandırıyor:

  http {
      server {
          ...
          location /blazor {
              ...
          }
      }
  }
  

Daha fazla bilgi ve yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Nginx ile Linux üzerinde ASP.NET Core Barındırma
• Nginx belgeleri:
  • WebSocket Proxy'si olarak NGINX
  • WebSocket proxy'si
• Microsoft dışı destek forumlarında geliştiriciler:
  • Stack Overflow (etiket: blazor)
  • ASP.NET Core Slack Ekibi
  • Blazor Gitter

Kesiciyi yapılandırma

Blazor çıkış derlemelerinden gereksiz IL'yi kaldırmak için her Yayın derlemesinde Ara Dil (IL) kırpması gerçekleştirir. Daha fazla bilgi için bkz. ASP.NET Core için Düzeltici'yi Blazoryapılandırma.

DLL dosyalarının dosya adı uzantısını değiştirme

Uygulamanın yayımlanan .dll dosyalarının dosya adı uzantılarını değiştirmeniz gerekirse, bu bölümdeki yönergeleri izleyin.

Uygulamayı yayımladıktan sonra, bir kabuk betiği veya DevOps derleme işlem hattı kullanarak dosyaları, uygulamanın yayımlanan çıkışının dizininde farklı bir dosya uzantısı kullanacak şekilde yeniden adlandırın .dll .

Aşağıdaki örneklerde:

• Dosya uzantılarını güncelleştirmek için PowerShell (PS) kullanılır.
• .dll dosyaları, komut satırından dosya uzantısını .bin kullanacak şekilde yeniden adlandırılır.
• Yayımlanmış blazor.boot.json dosyada dosya uzantısıyla .dll listelenen dosyalar dosya uzantısına .bin güncelleştirilir.
• Hizmet çalışanı varlıkları da kullanılıyorsa, PowerShell komutu dosyada service-worker-assets.js listelenen dosyaları dosya uzantısına .bin güncelleştirir.dll.

dosyasından .binfarklı bir dosya uzantısı kullanmak için aşağıdaki komutlarda öğesini istediğiniz dosya uzantısıyla değiştirin .bin .

Windows'da:

dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Linux veya macOS'ta:

for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net6.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları ele almak için aşağıdaki yaklaşımlardan birini benimseyin:

• Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları kaldırın. Sıkıştırma bu yaklaşımla devre dışı bırakılır.
• Güncelleştirilmiş blazor.boot.json dosyayı yeniden sıkıştırın.

Sıkıştırılmış blazor.boot.json dosya için önceki kılavuz, hizmet çalışanı varlıkları kullanımda olduğunda da geçerlidir. ve service-worker-assets.js.gzöğesini kaldırın veya yeniden sıkıştırabilirsinizservice-worker-assets.js.br. Aksi takdirde, dosya bütünlüğü denetimleri tarayıcıda başarısız olur.

.NET 6.0 için aşağıdaki Windows örneği, projenin köküne yerleştirilen bir PowerShell betiği kullanır. Sıkıştırmayı devre dışı bırakan aşağıdaki betik, dosyayı yeniden sıkıştırmak istiyorsanız, daha fazla değişikliğin blazor.boot.json temelini oluşturur.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br

Hizmet çalışanı varlıkları da kullanılıyorsa aşağıdaki komutları ekleyin:

((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

Proje dosyasında betik, yapılandırma için Release uygulama yayımlandıktan sonra yürütülür:

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

Not

Aynı derlemeleri yeniden adlandırırken ve yavaş yüklerken, ASP.NET Core'daki Blazor WebAssemblygecikmeli yükleme derlemeleri kılavuzuna bakın.

Genellikle, uygulamanın sunucusu güncelleştirilmiş uzantıyla dosyaları sunmak için statik varlık yapılandırması gerektirir. IIS tarafından barındırılan bir uygulama için, özel web.config bir dosyadaki statik içerik bölümünde (<mimeMap>) yeni dosya uzantısı için bir MIME eşleme girdisi (<staticContent>) ekleyin. Aşağıdaki örnekte dosya uzantısının olarak değiştirildiği .dll.binvarsayılır:

<staticContent>
  ...
  <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
  ...
</staticContent>

Sıkıştırma kullanılıyorsa sıkıştırılmış dosyalar için bir güncelleştirme ekleyin:

<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />

Dosya uzantısının girdisini .dll kaldırın:

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

Sıkıştırma kullanılıyorsa sıkıştırılmış .dll dosyaların girdilerini kaldırın:

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Önceki dağıtım bozulması

Genellikle dağıtımda:

• Yalnızca değiştirilen dosyalar değiştirilir ve bu da genellikle daha hızlı bir dağıtıma neden olur.
• Yeni dağıtımın parçası olmayan mevcut dosyalar, yeni dağıtım tarafından kullanılmak üzere yerinde bırakılır.

Nadir durumlarda, önceki bir dağıtımda kalan dosyalar yeni bir dağıtımı bozabilir. Mevcut dağıtımın (veya dağıtımdan önce yerel olarak yayımlanan uygulamanın) tamamen silinmesi, bozuk bir dağıtımla ilgili sorunu çözebilir. Genellikle, var olan dağıtımı bir kez silmek, DevOps derlemesi ve dağıtım işlem hattı dahil olmak üzere sorunu çözmek için yeterlidir.

DevOps derleme ve dağıtım işlem hattı kullanımda olduğunda her zaman önceki bir dağıtımı temizlemenin gerekli olduğunu belirlerseniz, bozulmanın tam nedenini giderene kadar derleme işlem hattına geçici olarak bir adım ekleyerek her yeni dağıtımın önceki dağıtımını silebilirsiniz.

Bütünlük denetimi hatalarını çözme

Bir uygulamanın başlangıç dosyalarını indirdiğinde Blazor WebAssembly , tarayıcıya yanıtlar üzerinde bütünlük denetimleri gerçekleştirmesini emreder. Blazor istemcilerde önbelleğe alınmayan DLL (.dll), WebAssembly (.wasm ) ve dosyadaki blazor.boot.json diğer dosyalar için SHA-256 karma değerlerini gönderir. Önbelleğe alınan dosyaların dosya karmaları, dosyadaki blazor.boot.json karmalarla karşılaştırılır. Eşleşen karma içeren önbelleğe alınmış dosyalar için önbelleğe Blazor alınmış dosyaları kullanır. Aksi takdirde, dosyalar sunucudan istenir. Bir dosya indirildikten sonra karma değeri bütünlük doğrulaması için yeniden denetlenecektir. İndirilen herhangi bir dosyanın bütünlük denetimi başarısız olursa tarayıcı tarafından bir hata oluşturulur.

Blazor'nin dosya bütünlüğünü yönetme algoritması:

• Uygulamanın tutarsız bir dosya kümesini yükleme riskini almamasını sağlar. Örneğin, kullanıcı uygulama dosyalarını indirme aşamasındayken web sunucunuza yeni bir dağıtım uygulanır. Tutarsız dosyalar hatalı çalışan bir uygulamaya neden olabilir.
• Kullanıcının tarayıcısının tutarsız veya geçersiz yanıtları hiçbir zaman önbelleğe almamasını sağlar. Bu, kullanıcı sayfayı el ile yenilese bile uygulamanın başlatılmasını engelleyebilir.
• Beklenen SHA-256 karmaları değişene kadar yanıtları önbelleğe alma ve sunucu tarafı değişikliklerini denetlememeyi güvenli hale getirir, böylece sonraki sayfa yüklemeleri daha az istek içerir ve daha hızlı tamamlanır.

Web sunucusu beklenen SHA-256 karmalarıyla eşleşmeyen yanıtlar döndürürse, tarayıcının geliştirici konsolunda aşağıdaki örneğe benzer bir hata görüntülenir:

'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=' hesaplanan SHA-256 bütünlüğüne sahip 'https://myapp.example.com/_framework/MyBlazorApp.dll' kaynağının 'integrity' özniteliğinde geçerli bir özet bulunamadı. Kaynak engellendi.

Çoğu durumda, uyarı bütünlük denetimiyle ilgili bir sorun olduğunu göstermez. Bunun yerine, uyarı genellikle başka bir sorun olduğu anlamına gelir.

'Blazor WebAssemblynin önyükleme başvuru kaynağı için GitHub deposundaki dosyaya dotnet/aspnetcore bakınBoot.WebAssembly.ts.

Not

.NET başvuru kaynağına yönelik belge bağlantıları genellikle deponun varsayılan dalını yükler ve bu dal .NET'in sonraki sürümü için geçerli geliştirmeyi temsil eder. Belirli bir sürümün etiketini seçmek için Dalları veya etiketleri değiştir açılan listesini kullanın. Daha fazla bilgi için bkz. ASP.NET Core kaynak kodunun sürüm etiketini seçme (dotnet/AspNetCore.Docs #26205).

Bütünlük sorunlarını tanılama

Bir uygulama oluşturulduğunda oluşturulan bildirim, blazor.boot.json derleme çıkışının oluşturulduğu sırada önyükleme kaynaklarının SHA-256 karmalarını açıklar. Içindeki SHA-256 karmaları tarayıcıya teslim edilen dosyalarla blazor.boot.json eşleştiği sürece bütünlük denetimi geçer.

Bunun başarısız olmasının yaygın nedenleri şunlardır:

• Web sunucusunun yanıtı, tarayıcının istediği dosya yerine bir hatadır (örneğin, 404 - Bulunamadı veya 500 - İç Sunucu Hatası). Bu, tarayıcı tarafından bir bütünlük denetimi hatası olarak bildirilir ve yanıt hatası olarak bildirılmaz.
• Dosyaların derlenip tarayıcıya teslim edilmesi arasında dosyaların içeriği bir değişiklik yaptı. Bu durum oluşabilir:
  • Siz veya derleme araçları derleme çıktısını el ile değiştirirseniz.
  • Dağıtım işleminin bazı yönleri dosyaları değiştirdiyse. Örneğin, Git tabanlı dağıtım mekanizması kullanıyorsanız, Windows'da dosya işleyip Bunları Linux'ta kullanıma alırsanız Git'in Windows stili satır sonlarını unix stili satır sonlarına saydam bir şekilde dönüştürdüğünü unutmayın. Dosya satırı sonlarının değiştirilmesi SHA-256 karmalarını değiştirir. Bu sorundan kaçınmak için derleme yapıtlarını dosya olarak binary kabul etmeyi göz önünde bulundurun.gitattributes.
  • Web sunucusu, dosya içeriklerini sunmanın bir parçası olarak değiştirir. Örneğin, bazı içerik dağıtım ağları (CDN'ler) HTML'yi otomatik olarak küçültmeye çalışır ve böylece bunu değiştirir. Bu tür özellikleri devre dışı bırakmanız gerekebilir.
• Dosya blazor.boot.json düzgün yüklenemedi veya istemcide yanlış önbelleğe alınmış. Yaygın nedenler şunlardan birini içerir:
  • Yanlış yapılandırılmış veya hatalı çalışan özel geliştirici kodu.
  • Bir veya daha fazla yanlış yapılandırılmış ara önbelleğe alma katmanı.

Sizin durumunuzda bunlardan hangisinin geçerli olduğunu tanılamak için:

1. Hata iletisini okuyarak hangi dosyanın hatayı tetiklediğine dikkat edin.
2. Tarayıcınızın geliştirici araçlarını açın ve Ağ sekmesine bakın. Gerekirse, istek ve yanıtların listesini görmek için sayfayı yeniden yükleyin. Bu listede hatayı tetikleyen dosyayı bulun.
3. Yanıttaki HTTP durum kodunu denetleyin. Sunucu 200 - Tamam (veya başka bir 2xx durum kodu) dışında bir şey döndürürse, tanılamanız gereken bir sunucu tarafı sorununuz vardır. Örneğin, durum kodu 403 bir yetkilendirme sorunu olduğu, durum kodu 500 ise sunucunun belirtilmemiş bir şekilde başarısız olduğu anlamına gelir. Uygulamayı tanılamak ve düzeltmek için sunucu tarafı günlüklerine başvurun.
4. Kaynak için durum kodu 200 - Tamam ise, tarayıcının geliştirici araçlarında yanıt içeriğine bakın ve içeriğin beklenen verilerle eşleşip eşleşmediğini denetleyin. Örneğin, isteklerin diğer dosyalar için bile verilerinizi index.html döndürmesi için yönlendirmeyi yanlış yapılandırmak yaygın bir sorundur. İsteklere verilen .wasm yanıtların WebAssembly ikilileri olduğundan ve isteklere verilen .dll yanıtların .NET derleme ikili dosyaları olduğundan emin olun. Aksi takdirde, tanılamanız gereken bir sunucu tarafı yönlendirme sorununuz vardır.
5. Bütünlük sorunlarını giderme PowerShell betiğiyle uygulamanın yayımlanan ve dağıtılan çıkışını doğrulamayı deneyin.

Sunucunun makul ölçüde doğru veriler döndürdüğünü onaylarsanız, dosyanın derlemesi ve teslimi arasında içeriği değiştiren başka bir şey olmalıdır. Bunu araştırmak için:

• Derleme araç zincirini ve dağıtım mekanizmasını, dosyalar oluşturulduktan sonra dosyaları değiştiriyor olma ihtimaline karşı inceleyin. Bunun bir örneği, Git'in daha önce açıklandığı gibi dosya satırı sonlarını dönüştürmesidir.
• Yanıtları dinamik olarak değiştirmek için ayarlanmış olma ihtimaline karşı web sunucusunu veya CDN yapılandırmasını inceleyin (örneğin, HTML'yi küçültmeye çalışma). Web sunucusunun HTTP sıkıştırması uygulaması normaldir (örneğin, döndüren content-encoding: br veya content-encoding: gzip), çünkü bu durum sıkıştırmadan sonra sonucu etkilemez. Ancak, web sunucusunun sıkıştırılmamış verileri değiştirmesi uygun değildir .

Bütünlük Sorunlarını Giderme PowerShell betiği

integrity.ps1 Yayımlanmış ve dağıtılmış Blazor bir uygulamayı doğrulamak için PowerShell betiğini kullanın. Betik, powershell core 7 veya üzeri için uygulamanın çerçevenin tanımlayabildiği bütünlük sorunları Blazor olduğunda başlangıç noktası olarak sağlanır. PowerShell'in 7.2.0 sürümünden sonraki bir sürümde çalışıyor olması da dahil olmak üzere, uygulamalarınız için betiğin özelleştirilmesi gerekebilir.

Betik, bütünlük karmaları içeren farklı bildirimlerdeki publish sorunları algılamak için klasördeki ve dağıtılan uygulamadan indirilen dosyaları denetler. Bu denetimler en yaygın sorunları algılamalıdır:

• Yayımlanan çıktıdaki bir dosyayı fark etmeden değiştirdiniz.
• Uygulama dağıtım hedefine doğru dağıtılmadı veya dağıtım hedefinin ortamında bir değişiklik oldu.
• Dağıtılan uygulama ile uygulamayı yayımlama çıktısı arasında farklar vardır.

Betiği bir PowerShell komut kabuğunda aşağıdaki komutla çağırın:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

Aşağıdaki örnekte, betik konumunda yerel olarak çalışan bir uygulamada https://localhost:5001/yürütülür:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Yer tutucu:

• {BASE URL}: Dağıtılan uygulamanın URL'si. Sondaki eğik çizgi (/) gereklidir.
• {PUBLISH OUTPUT FOLDER}: Uygulamanın publish dağıtım için yayımlandığı klasörün veya konumun yolu.

Not

GitHub deposunu dotnet/AspNetCore.Docs kopyalarken betik Bitdefenderintegrity.ps1 veya sistemde bulunan başka bir virüs tarayıcısı tarafından karantinaya alınmış olabilir. Dosya genellikle virüs tarayıcısının buluşsal tarama teknolojisi tarafından tuzağa düşürülür ve bu teknoloji yalnızca kötü amaçlı yazılımların varlığını gösterebilecek dosyalarda desenleri arar. Virüs tarayıcısının dosyayı ayırmasını önlemek için, depoyu kopyalamadan önce virüs tarayıcısına bir özel durum ekleyin. Aşağıdaki örnek, bir Windows sistemindeki betiğin tipik bir yoludur. Yolu diğer sistemler için gerektiği gibi ayarlayın. Yer tutucu {USER} , kullanıcının yol kesimidir.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

Uyarı: Virüs tarayıcısı özel durumlarının oluşturulması tehlikelidir ve yalnızca dosyanın güvenli olduğundan emin olduğunuzda gerçekleştirilmelidir.

Bir dosyanın sağlama toplamını geçerli bir sağlama toplamı değeriyle karşılaştırmak, dosya güvenliğini garanti etmez, ancak dosyayı sağlama toplamı değerini koruyacak şekilde değiştirmek kötü amaçlı kullanıcılar için önemsiz değildir. Bu nedenle sağlama toplamları genel bir güvenlik yaklaşımı olarak yararlıdır. Yerel integrity.ps1 dosyanın sağlama toplamını aşağıdaki değerlerden biriyle karşılaştırın:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Aşağıdaki komutla Windows işletim sisteminde dosyanın sağlama toplamını alın. Yer tutucunun yolunu ve dosya adını {PATH AND FILE NAME} belirtin ve yer tutucu SHA256 için {SHA512|MD5} üretilmesi gereken sağlama toplamı türünü (veya MD5) belirtin:

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Sağlama toplamı doğrulamasının ortamınızda yeterince güvenli olmamasıyla ilgili bir endişeniz varsa, rehberlik için kuruluşunuzun güvenlik liderliğine başvurun.

Daha fazla bilgi için bkz. Kötü amaçlı yazılım & diğer tehditlerini anlama.

PWA olmayan uygulamalar için bütünlük denetimini devre dışı bırakma

Çoğu durumda bütünlük denetimini devre dışı bırakma. Bütünlük denetiminin devre dışı bırakılması, beklenmeyen yanıtlara neden olan ve daha önce listelenen avantajların kaybedilmesine neden olan temel sorunu çözmez.

Tutarlı yanıtlar döndürmek için web sunucusunun bağımlı olmadığı durumlar olabilir ve temel alınan sorun çözülene kadar bütünlük denetimlerini geçici olarak devre dışı bırakmaktan başka seçeneğiniz olmayabilir.

Bütünlük denetimlerini devre dışı bırakmak için, uygulamanın proje dosyasındaki (Blazor WebAssembly.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResourcesayrıca , .wasmve diğer dosyaları SHA-256 karmalarına göre önbelleğe alma .dllişleminin varsayılan davranışını devre dışı bırakır Blazorçünkü özelliği SHA-256 karmalarının doğruluğu için güvenilmediğini gösterir. Bu ayarda bile, tarayıcının normal HTTP önbelleği bu dosyaları önbelleğe almaya devam edebilir, ancak bunun olup olmadığı web sunucusu yapılandırmanıza ve cache-control hizmet veren üst bilgilere bağlıdır.

Not

özelliği Aşamalı BlazorCacheBootResourcesWeb Uygulamaları (PWA) için bütünlük denetimlerini devre dışı bırakmaz. PWA'larla ilgili yönergeler için PWA'lar için bütünlük denetimini devre dışı bırakma bölümüne bakın.

Bütünlük denetimini devre dışı bırakmanın gerekli olduğu senaryoların kapsamlı bir listesini sağlayamıyoruz. Sunucular, isteği çerçeve kapsamı Blazor dışında rastgele yollarla yanıtlayabilir. Çerçeve, uygulamanın sağlayabilecekleri BlazorCacheBootResourcesbütünlük garantisini kaybetme karşılığında uygulamayı çalıştırılabilir hale getirme ayarını sağlar. Yine, özellikle üretim dağıtımları için bütünlük denetimini devre dışı bırakmanızı önermeyiz. Geliştiriciler, bütünlük denetiminin başarısız olmasına neden olan temel bütünlük sorununu çözmeye çalışmalıdır.

Bütünlük sorunlarına neden olabilecek birkaç genel durum şunlardır:

• Bütünlüğün denetlenebildiği HTTP'de çalışıyor.
• Dağıtım işleminiz yayımlama sonrasında dosyaları herhangi bir şekilde değiştirirse.
• Konağınız dosyaları herhangi bir şekilde değiştirirse.

PWA'lar için bütünlük denetimini devre dışı bırakma

Blazor'nin Aşamalı Web Uygulaması (PWA) şablonu, uygulama dosyalarını çevrimdışı kullanım için getirmek ve depolamaktan sorumlu önerilen service-worker.published.js bir dosya içeriyor. Bu, normal uygulama başlatma mekanizmasından ayrı bir işlemdir ve kendi ayrı bütünlük denetimi mantığına sahiptir.

Dosyanın içinde service-worker.published.js aşağıdaki satır bulunur:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Bütünlük denetimini devre dışı bırakmak için, satırı aşağıdaki şekilde değiştirerek parametresini kaldırın integrity :

.map(asset => new Request(asset.url));

Yine bütünlük denetimini devre dışı bırakmak, bütünlük denetimiyle sunulan güvenlik garantilerini kaybedeceğiniz anlamına gelir. Örneğin, yeni bir sürümü dağıttığınız anda kullanıcının tarayıcısı uygulamayı önbelleğe alırsa, eski dağıtımdaki bazı dosyaları ve yeni dağıtımdaki bazı dosyaları önbelleğe alma riski vardır. Böyle bir durumda uygulama, siz daha fazla güncelleştirme dağıtana kadar bozuk durumda takılır.

SignalR yapılandırması

SignalR'nin barındırma ve ölçeklendirme koşulları kullanan SignalRuygulamalar için Blazor geçerlidir.

Aktarım

Blazordaha düşük gecikme süresi, daha iyi güvenilirlik ve gelişmiş güvenlik nedeniyle WebSockets'i aktarım olarak SignalR kullanırken en iyi sonucu verir. Uzun Yoklama , WebSockets kullanılamadığında veya uygulama Uzun Yoklama kullanacak şekilde açıkça yapılandırıldığında tarafından SignalR kullanılır. Azure App Service dağıtırken, uygulamayı hizmetin Azure portal ayarlarında WebSockets kullanacak şekilde yapılandırın. Uygulamayı Azure App Service için yapılandırma hakkında ayrıntılı bilgi için yayımlama yönergelerineSignalR bakın.

Uzun Yoklama kullanılırsa bir konsol uyarısı görüntülenir:

Uzun Yoklama geri dönüş aktarımı kullanılarak WebSockets aracılığıyla bağlanılamadı. Bunun nedeni bir VPN veya proxy'nin bağlantıyı engellemesi olabilir.

Genel dağıtım ve bağlantı hataları

Coğrafi veri merkezlerine genel dağıtım önerileri:

• Uygulamayı kullanıcıların çoğunun bulunduğu bölgelere dağıtın.
• Kıtalar arasındaki trafik için artan gecikme süresini dikkate alın.
• Azure barındırma için Azure SignalR Hizmeti'ni kullanın.

Dağıtılan bir uygulama İnternet gecikmesinin neden olduğu ping zaman aşımları nedeniyle yeniden bağlantı kullanıcı arabirimini sık sık görüntülüyorsa, sunucu ve istemci zaman aşımlarını uzatın:

• Sunucu

  İstemci ile sunucu arasında beklenen en yüksek gidiş dönüş süresinin en az iki katı. Zaman aşımlarını gerektiği gibi test edin, izleyin ve düzeltin. Hub için SignalR (varsayılan: 30 saniye) ve HandshakeTimeout (varsayılan: 15 saniye) ayarlayın ClientTimeoutInterval . Aşağıdaki örnekte varsayılan 15 saniye değerinin kullanıldığı varsayılır KeepAliveInterval .

  Önemli

  , KeepAliveInterval görüntülenen yeniden bağlantı kullanıcı arabirimiyle doğrudan ilgili değildir. Keep-Alive aralığının değiştirilmesi gerekmez. Yeniden bağlantı kullanıcı arabirimi görünümü sorunu zaman aşımlarından kaynaklanıyorsa ve ClientTimeoutIntervalHandshakeTimeout artırılabilir ve Keep-Alive aralığı aynı kalabilir. Önemli olan, Keep-Alive aralığını değiştirirseniz istemci zaman aşımı değerinin Keep-Alive aralığının değerinin en az iki katı olduğundan ve istemcideki Keep-Alive aralığının sunucu ayarıyla eşleştiğinden emin olmanızdır.

  Aşağıdaki örnekte, ClientTimeoutInterval 60 saniyeye HandshakeTimeout ve 30 saniyeye yükseltilir.

  Projede Program.cs barındırılan Blazor WebAssemblyServer bir uygulama için:

  builder.Services.AddSignalR(options =>
  {
       options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
       options.HandshakeTimeout = TimeSpan.FromSeconds(30);
  });
  

  Daha fazla bilgi için bkz. ASP.NET Core BlazorSignalR kılavuzu.

• İstemci

  Genellikle, istemcinin sunucu zaman aşımı için zaman aşımını ayarlamak için sunucularda KeepAliveInterval kullanılan değerin iki katı (ServerTimeoutvarsayılan: 30 saniye).

  Önemli

  Keep-Alive aralığı (KeepAliveInterval) görüntülenen yeniden bağlantı kullanıcı arabirimiyle doğrudan ilişkili değildir. Keep-Alive aralığının değiştirilmesi gerekmez. Yeniden bağlantı kullanıcı arabirimi görünümü sorunu zaman aşımlarından kaynaklanıyorsa, sunucu zaman aşımı artırılabilir ve Keep-Alive aralığı aynı kalabilir. Önemli nokta, Keep-Alive aralığını değiştirirseniz zaman aşımı değerinin Keep-Alive aralığının değerinin en az iki katı olduğundan ve sunucudaki Keep-Alive aralığının istemci ayarıyla eşleştiğinden emin olmanızdır.

  Aşağıdaki örnekte, sunucu zaman aşımı için 60 saniyelik özel bir değer kullanılmıştır.

  Bir bileşende hub bağlantısı oluştururken, yerleşik HubConnectionüzerinde (varsayılan: 30 saniye) ve HandshakeTimeout (varsayılan: 15 saniye) ayarlayın ServerTimeout .

  Aşağıdaki örnek, ile Blazor öğreticisindekiSignalRIndex bileşeni temel alır. Sunucu zaman aşımı 60 saniyeye yükseltilir ve el sıkışması zaman aşımı 30 saniyeye çıkarılır:

  protected override async Task OnInitializedAsync()
  {
      hubConnection = new HubConnectionBuilder()
          .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
          .Build();
  
      hubConnection.ServerTimeout = TimeSpan.FromSeconds(60);
      hubConnection.HandshakeTimeout = TimeSpan.FromSeconds(30);
  
      hubConnection.On<string, string>("ReceiveMessage", (user, message) => ...
  
      await hubConnection.StartAsync();
  }
  

  Sunucu zaman aşımı (ServerTimeout) veya Keep-Alive aralığının (KeepAliveInterval:

  • Sunucu zaman aşımı, Keep-Alive aralığına atanan değerin en az iki katı olmalıdır.
  • Keep-Alive aralığı, sunucu zaman aşımına atanan değerin yarısından küçük veya buna eşit olmalıdır.

Daha fazla bilgi için bkz. ASP.NET Core BlazorSignalR kılavuzu.

Barındırma modeli ileBlazor WebAssembly:

• Uygulama Blazor , bağımlılıkları ve .NET çalışma zamanı paralel olarak tarayıcıya indirilir.
• Uygulama doğrudan tarayıcı kullanıcı arabirimi iş parçacığında yürütülür.

Aşağıdaki dağıtım stratejileri desteklenir:

• Uygulama Blazor bir ASP.NET Core uygulaması tarafından sunulur. Bu strateji, ASP.NET Core ile barındırılan dağıtım bölümünde ele alınmıştır.
• Uygulama Blazor statik bir barındırma web sunucusuna veya hizmetine yerleştirilir; burada .NET, uygulamayı sunmak Blazor için kullanılmaz. Bu strateji, bir Blazor WebAssembly uygulamayı IIS alt uygulaması olarak barındırmayla ilgili bilgileri içeren Tek başına dağıtım bölümünde ele alınmıştır.
• bir ASP.NET Core uygulaması birden çok Blazor WebAssembly uygulamayı barındırıyor. Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Önyükleme kaynaklarının yüklenme biçimini özelleştirme

API kullanarak önyükleme kaynaklarının nasıl yüklendiğini özelleştirin loadBootResource . Daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırma

Bir Blazor WebAssembly uygulama yayımlandığında, uygulamanın boyutunu azaltmak ve çalışma zamanı sıkıştırma ek yükünü kaldırmak için çıkış yayımlama sırasında statik olarak sıkıştırılır. Aşağıdaki sıkıştırma algoritmaları kullanılır:

• Brotli (en yüksek düzey)
• Gzip

Blazor uygun sıkıştırılmış dosyaları sunmak için konağa dayanır. ASP.NET Core BarındırılanBlazor WebAssembly proje kullanılırken, konak projesi içerik anlaşması gerçekleştirebilir ve statik olarak sıkıştırılmış dosyalara hizmet yapabilir. Tek başına bir Blazor WebAssembly uygulama barındırırken, statik olarak sıkıştırılmış dosyaların sunulduğunda emin olmak için ek çalışma gerekebilir:

• IIS web.config sıkıştırma yapılandırması için IIS: Brotli ve Gzip sıkıştırma bölümüne bakın.

• GitHub Pages gibi statik olarak sıkıştırılmış dosya içeriği anlaşmasını desteklemeyen statik barındırma çözümlerinde barındırırken uygulamayı Brotli sıkıştırılmış dosyalarını getirmek ve kodunu çözmek için yapılandırmayı göz önünde bulundurun:

  • Google/brotli GitHub deposundan JavaScript Brotli kod çözücüsü edinin. Küçültüldü kod çözücü dosyası olarak adlandırılır decode.min.js ve deponun js klasöründe bulunur.

    Not

    Betiğin (decode.min.js) küçültüldü sürümü decode.js başarısız olursa, bunun yerine doğrulanmamış sürümü (decode.js) kullanmayı deneyin.

  • Uygulamayı kod çözücü kullanacak şekilde güncelleştirin.

    wwwroot/index.html dosyasında, 'nin <script> etiketinde falseBlazorolarak ayarlayınautostart:

    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    

    etiketinden <script> sonra Blazorve kapanış </body> etiketinden önce aşağıdaki JavaScript kod <script> bloğunu ekleyin:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            return (async function () {
              const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
              if (!response.ok) {
                throw new Error(response.statusText);
              }
              const originalResponseBuffer = await response.arrayBuffer();
              const originalResponseArray = new Int8Array(originalResponseBuffer);
              const decompressedResponseArray = BrotliDecode(originalResponseArray);
              const contentType = type === 
                'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
              return new Response(decompressedResponseArray, 
                { headers: { 'content-type': contentType } });
            })();
          }
        }
      });
    </script>
    

    Önyükleme kaynaklarını yükleme hakkında daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırmayı BlazorEnableCompression devre dışı bırakmak için MSBuild özelliğini uygulamanın proje dosyasına ekleyin ve değerini olarak falseayarlayın:

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

özelliği, BlazorEnableCompression komut kabuğunda dotnet publish aşağıdaki söz dizimiyle komutuna geçirilebilir:

dotnet publish -p:BlazorEnableCompression=false

Doğru yönlendirme için URL'leri yeniden yazma

Bir Blazor WebAssembly uygulamadaki sayfa bileşenleri için yönlendirme istekleri, barındırılan bir Blazor Serveruygulamadaki yönlendirme istekleri kadar basit değildir. İki bileşeni olan bir Blazor WebAssembly uygulamayı göz önünde bulundurun:

• Main.razor: Uygulamanın köküne yüklenir ve bileşene About (href="About") bir bağlantı içerir.
• About.razor: About bileşeni.

Tarayıcının adres çubuğu kullanılarak uygulamanın varsayılan belgesi istendiğinde (örneğin: https://www.contoso.com/

1. Tarayıcı bir istekte bulunur.
2. Varsayılan sayfa döndürülür; bu genellikle index.htmlşeklindedir.
3. index.html uygulamayı bootstraplar.
4. Blazor'nin yönlendiricisi yüklenir ve RazorMain bileşen işlenir.

Ana sayfada, bileşenin bağlantısının About seçilmesi istemcide çalışır çünkü Blazor yönlendirici tarayıcının için İnternet'te istekte bulunmasını www.contoso.comAbout durdurur ve işlenen About bileşenin kendisine hizmet eder. Uygulama içindeki Blazor WebAssembly iç uç noktalara yönelik tüm istekler aynı şekilde çalışır: İstekler, İnternet'te sunucu tarafından barındırılan kaynaklara tarayıcı tabanlı istekler tetiklemez. Yönlendirici istekleri dahili olarak işler.

için tarayıcının adres çubuğu www.contoso.com/Aboutkullanılarak istek yapılırsa istek başarısız olur. Uygulamanın İnternet ana bilgisayarında böyle bir kaynak olmadığından 404 - Bulunamadı yanıtı döndürülür.

Tarayıcılar istemci tarafı sayfalar için İnternet tabanlı konaklara istekte bulunacağından, web sunucularının ve barındırma hizmetlerinin sunucuda fiziksel olarak sayfaya olmayan kaynaklara yönelik tüm istekleri yeniden yazması index.html gerekir. Döndürülürse index.html , uygulamanın yönlendiricisi Blazor bunu devralır ve doğru kaynakla yanıt verir.

IIS sunucusuna dağıtım yaparken url yeniden yazma modülünü uygulamanın yayımlanan web.config dosyasıyla kullanabilirsiniz. Daha fazla bilgi için IIS bölümüne bakın.

ASP.NET Core ile barındırılan dağıtım

BarındırılanBlazor WebAssembly dağıtım, uygulamayı web sunucusunda çalışan bir ASP.NET Core uygulamasından tarayıcılara hizmet eder.

İstemci Blazor WebAssembly uygulaması, sunucu uygulamasının /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot diğer statik web varlıklarıyla birlikte sunucu uygulamasının klasörüne yayımlanır. İki uygulama birlikte dağıtılır. bir ASP.NET Core uygulamasını barındırabilen bir web sunucusu gereklidir. Barındırılan Blazor WebAssembly bir dağıtım için Visual Studio, Uygulama projesi şablonunu (blazorwasmkomutu kullanırken dotnet new şablon) ve seçeneğinin Hosted seçili olduğunu (-ho|--hostedkomutu kullanırkendotnet new) içerir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• ASP.NET Core uygulama barındırma ve dağıtma: ASP.NET Core barındırma ve dağıtma
• Azure App Service dağıtımı: Visual Studio ile ASP.NET Core uygulamasını Azure'da yayımlama
• Blazorproje şablonları: ASP.NET Core Blazor proje yapısı

Belirli bir platform için çerçeveye bağımlı yürütülebilir dosyanın barındırılan dağıtımı

Barındırılan Blazor WebAssembly bir uygulamayı belirli bir platform için (bağımsız olmayan) çerçeveye bağımlı yürütülebilir dosya olarak dağıtmak için, kullanımdaki araçlara bağlı olarak aşağıdaki kılavuzu kullanın.

Visual Studio

Varsayılan olarak, oluşturulan yayımlama profili (.pubxml ) için bağımsız bir dağıtım yapılandırılır. Projenin yayımlama profilinin Server olarak ayarlanmış MSBuild özelliğini içerdiğini <SelfContained>falseonaylayın.

Projenin Properties klasöründeki .pubxmlServer yayımlama profili dosyasında:

<SelfContained>false</SelfContained>

Yayımlama profilinde MSBuild özelliğini oluşturan Yayımlama Kullanıcı Arabiriminin Ayarlar alanındaki Hedef Çalışma Zamanı ayarını kullanarak Çalışma Zamanı Tanımlayıcısı'nı<RuntimeIdentifier> (RID) ayarlayın:

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Server Projeyi Yayın yapılandırmasında yayımlayın.

Not

Yer tutucunun profil olduğu {PROFILE} komutuna geçirerek dotnet publish/p:PublishProfile={PROFILE} .NET CLI kullanarak profil yayımlama ayarlarına sahip bir uygulama yayımlamak mümkündür. Daha fazla bilgi için, ASP.NET Core uygulama dağıtımı için Visual Studio yayımlama profilleri (.pubxml) makalesindeki Profilleri yayımlamaveKlasör yayımlama örneği bölümlerine bakın. RID'yi yayımlama profilinde dotnet publish değil komutunda geçirirseniz, MSBuild özelliğini ()/p:RuntimeIdentifier) seçeneğiyle değil komutuyla -r|--runtime kullanın.

.NET CLI

MSBuild özelliğini projenin proje dosyasında olarak ayarlanmış falsebir <PropertyGroup>Server içine yerleştirerek <SelfContained>bağımsız bir dağıtım yapılandırın:

<SelfContained>false</SelfContained>

Önemli

SelfContained özelliği projenin proje dosyasına yerleştirilmelidirServer. özelliği, seçeneği veya MSBuild özelliği /p:SelfContained=falsekullanılarak --no-self-containedkomutuyladotnet publish doğru ayarlanamaz.

Aşağıdaki yaklaşımlardan birini kullanarak Çalışma Zamanı Tanımlayıcısı'nı (RID) ayarlayın:

• Seçenek 1: Projenin proje dosyasındaki bir <PropertyGroup> içindeki Server RID'yi ayarlayın:

  <RuntimeIdentifier>{RID}</RuntimeIdentifier>
  

  Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

  Uygulamayı projeden Yayın yapılandırmasında Server yayımlayın:

  dotnet publish -c Release
  

• 2. Seçenek: Komutundaki RID'yi dotnet publish şu seçenekle -r|--runtimedeğil MSBuild özelliği ()/p:RuntimeIdentifier olarak geçirin:

  dotnet publish -c Release /p:RuntimeIdentifier={RID}
  

  Yukarıdaki komutta {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• .NET uygulaması yayımlamaya genel bakış
• ASP.NET Core barındırma ve dağıtma

Birden çok uygulamayla barındırılan Blazor WebAssembly dağıtım

Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Tek başına dağıtım

Tek başına dağıtım, uygulamayı doğrudan istemciler Blazor WebAssembly tarafından istenen statik dosyalar kümesi olarak sunar. Herhangi bir statik dosya sunucusu uygulamaya hizmet Blazor yapabilir.

Tek başına dağıtım varlıkları klasörüne /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot yayımlanır.

Azure App Service

Blazor WebAssemblyuygulamalar, uygulamayı IIS'de barındıran Windows Azure Uygulaması Hizmetlerine dağıtılabilir.

Linux için Azure App Service'a tek başına Blazor WebAssembly uygulama dağıtma şu anda desteklenmemekte. Bu senaryoyı destekleyen Azure Static Web Apps kullanarak tek başına Blazor WebAssembly bir uygulama barındırmanızı öneririz.

Azure Statik Web Uygulamaları

Daha fazla bilgi için bkz. Öğretici: Azure Static Web Apps'de ile Blazor statik web uygulaması oluşturma.

IIS

IIS, uygulamalar için Blazor yetenekli bir statik dosya sunucusudur. IIS'yi barındıracak Blazorşekilde yapılandırmak için bkz. IIS'de Statik Web Sitesi Oluşturma.

Yayımlanan varlıklar, SDK'nın hangi sürümünün /bin/Release/{TARGET FRAMEWORK}/publish kullanıldığına ve yer tutucunun hedef çerçeve olduğuna {TARGET FRAMEWORK} bağlı olarak veya bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish klasöründe oluşturulur. Klasörün içeriğini publish web sunucusunda veya barındırma hizmetinde barındırın.

web.config

Bir Blazor proje yayımlandığında, aşağıdaki IIS yapılandırmasıyla bir web.config dosya oluşturulur:

• MIME türleri
• HTTP sıkıştırması aşağıdaki MIME türleri için etkinleştirilir:
  • application/octet-stream
  • application/wasm
• URL Yeniden Yazma Modülü kuralları oluşturulur:
  • Uygulamanın statik varlıklarının (wwwroot/{PATH REQUESTED}) bulunduğu alt dizine hizmet edin.
  • Dosya olmayan varlıklara yönelik isteklerin statik varlıklar klasöründekiwwwroot/index.html ( ) uygulamanın varsayılan belgesine yeniden yönlendirilmesi için SPA geri dönüş yönlendirmesi oluşturun.

Özel kullanım web.config

Özel web.config dosya kullanmak için:

1. Özel web.config dosyayı projenin kök klasörüne yerleştirin. Barındırılan Blazor WebAssembly bir çözüm için dosyayı Server projenin klasörüne yerleştirin.
2. Projeyi yayımlayın. Barındırılan Blazor WebAssembly bir çözüm için çözümü projeden Server yayımlayın. Daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

SDK'nın web.config yayımlama sırasındaki oluşturma veya dönüştürme işlemi, dosyayı klasördeki publish yayımlanmış varlıklara taşımazsa veya özel web.config dosyanızdaki özel yapılandırmayı değiştirirse, işlemin tam denetimini almak için aşağıdaki yaklaşımlardan herhangi birini kullanın:

• SDK dosyayı oluşturmuyorsa( örneğin, SDK'nın hangi sürümünün kullanıldığına ve yer tutucunun hedef çerçeve olduğuna bağlı olarak, veya konumundaki tek başına Blazor WebAssembly bir uygulamadabin\Release\{TARGET FRAMEWORK}\browser-wasm\publish/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot) özelliğini true proje dosyasında ().csproj olarak ayarlayın<PublishIISAssets>.{TARGET FRAMEWORK} Genellikle tek başına WebAssembly uygulamaları için, özel web.config bir dosyayı taşımak ve dosyanın SDK tarafından dönüştürülmesini önlemek için gereken tek ayar budur.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• SDK'nın web.config proje dosyasındaki dönüştürmesini devre dışı bırakın (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Özel bir dosyayı taşımak için proje dosyasına (.csproj) özel web.config bir hedef ekleyin. Aşağıdaki örnekte, özel web.config dosya geliştirici tarafından projenin köküne yerleştirilir. web.config Dosya başka bir yerde bulunuyorsa içinde dosyanın SourceFilesyolunu belirtin. Aşağıdaki örnek, ile klasörünü belirtirpublish, ancak özel çıkış konumu için bir yol DestinationFolder$(PublishDir)sağlar.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

URL Yeniden Yazma Modülünü Yükleme

URL'leri yeniden yazmak için URL Yeniden Yazma Modülü gereklidir. Modül varsayılan olarak yüklenmez ve Web Sunucusu (IIS) rol hizmeti özelliği olarak yüklenebilir. Modülün IIS web sitesinden indirilmesi gerekir. Modülü yüklemek için Web Platformu Yükleyicisi'ni kullanın:

1. Yerel olarak URL Yeniden Yazma Modülü indirmeleri sayfasına gidin. İngilizce sürümü için WebPI yükleyicisini indirmek için WebPI'yi seçin. Diğer diller için, yükleyiciyi indirmek üzere sunucu (x86/x64) için uygun mimariyi seçin.
2. Yükleyiciyi sunucuya kopyalayın. Yükleyiciyi çalıştırın. Yükle düğmesini seçin ve lisans koşullarını kabul edin. Yükleme tamamlandıktan sonra sunucunun yeniden başlatılması gerekmez.

Web sitesini yapılandırma

Web sitesinin Fiziksel yolunu uygulamanın klasörüne ayarlayın. Klasör aşağıdakileri içerir:

• Iis'nin web.config gerekli yeniden yönlendirme kuralları ve dosya içerik türleri de dahil olmak üzere web sitesini yapılandırmak için kullandığı dosya.
• Uygulamanın statik varlık klasörü.

IIS alt uygulaması olarak barındırma

Tek başına bir uygulama IIS alt uygulaması olarak barındırılıyorsa aşağıdakilerden birini gerçekleştirin:

• Devralınan ASP.NET Core Modülü işleyicisini devre dışı bırakın.

  Dosyanın bölümüne bir <handlers> bölüm ekleyerek uygulamanın yayımlanan web.config dosyasındaki işleyiciyi Blazor<system.webServer> kaldırın:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• olarak ayarlanmış bir <location> öğe inheritInChildApplications kullanarak kök (üst) uygulamanın <system.webServer> bölümünün devralını falsedevre dışı bırakın:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Not

  Kök (üst) uygulamanın <system.webServer> bölümünün devralmayı devre dışı bırakmak, .NET SDK'sı kullanılarak yayımlanan uygulamalar için varsayılan yapılandırmadır.

İşleyiciyi kaldırma veya devralmayı devre dışı bırakma işlemi , uygulamanın temel yolunu yapılandırmaya ek olarak gerçekleştirilir. Uygulamanın dosyasındaki uygulama temel yolunu IIS'de index.html alt uygulamayı yapılandırırken kullanılan IIS diğer adı olarak ayarlayın.

Brotli ve Gzip sıkıştırması

Bu bölüm yalnızca tek başına Blazor WebAssembly uygulamalar için geçerlidir. Barındırılan Blazor uygulamalar, bu bölümdeki bağlantılı dosyayı değil, varsayılan ASP.NET Core uygulama web.config dosyasını kullanır.

IIS, aracılığıyla tek başına Blazor WebAssembly uygulamalar için Brotli veya Gzip sıkıştırılmış Blazor varlıklarına hizmet vermek üzere yapılandırılabilirweb.config. Örnek bir yapılandırma dosyası için bkz web.config. .

Aşağıdaki senaryolarda örnek web.config dosyanın ek yapılandırması gerekebilir:

• Uygulamanın belirtimi aşağıdakilerden birini çağırır:
  • Örnek web.config dosya tarafından yapılandırılmamış sıkıştırılmış dosyalar sunma.
  • Örnek web.config dosya tarafından yapılandırılan sıkıştırılmış dosyaları sıkıştırılmamış biçimde sunma.
• Sunucunun IIS yapılandırması (örneğin, applicationHost.config) sunucu düzeyinde IIS varsayılanları sağlar. Sunucu düzeyinde yapılandırmaya bağlı olarak, uygulama örnek web.config dosyanın içerdiğinden farklı bir IIS yapılandırması gerektirebilir.

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Sorun giderme

500 - İç Sunucu Hatası alınırsa ve IIS Yöneticisi web sitesinin yapılandırmasına erişmeye çalışırken hatalar oluşturursa, URL Yeniden Yazma Modülü'nin yüklü olduğunu onaylayın. Modül yüklenmediğinde dosya web.config IIS tarafından ayrıştırılamaz. Bu, IIS Yöneticisi'nin web sitesinin yapılandırmasını ve web sitesinin statik dosyaları sunmasını Blazorengeller.

IIS dağıtımlarının sorunlarını giderme hakkında daha fazla bilgi için bkz. Azure App Service ve IIS'de ASP.NET Core sorunlarını giderme.

Azure Depolama

Azure Depolama statik dosya barındırma sunucusuz Blazor uygulama barındırmaya olanak tanır. Özel etki alanı adları, Azure Content Delivery Network (CDN) ve HTTPS desteklenir.

Blob hizmeti bir depolama hesabında statik web sitesi barındırma için etkinleştirildiğinde:

• Dizin belge adını olarak index.htmlayarlayın.
• Hata belgesi yolunu olarak index.htmlayarlayın. Razor bileşenleri ve diğer dosya olmayan uç noktalar blob hizmeti tarafından depolanan statik içerikteki fiziksel yollarda yer almaz. Yönlendiricinin işlemesi gereken bu kaynaklardan birine yönelik bir istek alındığında Blazor , blob hizmeti tarafından oluşturulan 404 - Bulunamadı hatası isteği Hata belge yoluna yönlendirir. index.html Blob döndürülür ve Blazor yönlendirici yolu yükler ve işler.

Dosyaların üst bilgilerindeki uygunsuz MIME türleri nedeniyle dosyalar Content-Type çalışma zamanında yüklenmiyorsa, aşağıdaki eylemlerden birini gerçekleştirin:

• Dosyalar dağıtıldığında doğru MIME türlerini (Content-Type üst bilgiler) ayarlamak için araçlarınızı yapılandırın.

• Uygulama dağıtıldıktan sonra dosyaların MIME türlerini (Content-Type üst bilgileri) değiştirin.

  Her dosya için Depolama Gezgini (Azure portal) içinde:

  1. Dosyaya sağ tıklayın ve Özellikler’i seçin.
  2. ContentType'ı ayarlayın ve Kaydet düğmesini seçin.

Daha fazla bilgi için bkz. Azure Depolama'da statik web sitesi barındırma.

Nginx

Aşağıdaki nginx.conf dosya, diskte karşılık gelen bir dosyayı bulamadan Nginx'in dosyayı gönderecek index.html şekilde nasıl yapılandırıldığını gösterecek şekilde basitleştirilmiştir.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

ile limit_reqBlazor WebAssemblyNGINX seri hız sınırını ayarlarken, uygulamalar bir uygulama tarafından yapılan görece çok sayıda isteği karşılamak için büyük burst bir parametre değeri gerektirebilir. Başlangıçta değeri en az 60 olarak ayarlayın:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Tarayıcı geliştirici araçları veya ağ trafiği aracı isteklerin 503 - Hizmet Kullanılamıyor durum kodu aldığını gösteriyorsa değeri artırın.

Üretim Nginx web sunucusu yapılandırması hakkında daha fazla bilgi için bkz. NGINX Plus ve NGINX Yapılandırma Dosyaları Oluşturma.

Apache

Bir uygulamayı CentOS 7 veya sonraki bir Blazor WebAssembly sürümüne dağıtmak için:

1. Apache yapılandırma dosyasını oluşturun. Aşağıdaki örnek, basitleştirilmiş bir yapılandırma dosyasıdır (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
       AddType application/octet-stream .dll
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
         BrowserMatch ^Mozilla/4 gzip-only-text/html
         BrowserMatch ^Mozilla/4.0[678] no-gzip
         BrowserMatch bMSIE !no-gzip !gzip-only-text/html
     </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

2. Apache yapılandırma dosyasını CentOS 7'deki varsayılan Apache yapılandırma dizini olan dizine /etc/httpd/conf.d/ yerleştirin.

3. Uygulamanın dosyalarını dizinine /var/www/blazorapp (yapılandırma dosyasında belirtilen DocumentRoot konum) yerleştirin.

4. Apache hizmetini yeniden başlatın.

Daha fazla bilgi için mod_mime ve mod_deflate bölümlerine bakın.

GitHub Pages

Sayfaları dağıtan varsayılan GitHub Eylemi, klasör gibi alt çizgiyle başlayan klasörlerin dağıtımını _framework atlar. Alt çizgiyle başlayan klasörleri dağıtmak için Git dalı için boş .nojekyll bir dosya ekleyin.

Git, gibi blazor.webassembly.jsJavaScript (JS) dosyalarını metin olarak ele alır ve satır sonlarını CRLF'den (satır dönüş satırı akışı) dağıtım işlem hattında LF'ye (satır akışı) dönüştürür. Dosyalarda yapılan JS bu değişiklikler, dosyadaki blazor.boot.json istemciye göndermeden Blazor farklı dosya karmaları oluşturur. Uyuşmazlıklar istemcide bütünlük denetimi hatalarına neden olur. Bu sorunu çözmenin bir yaklaşımı, uygulamanın varlıklarını Git dalı'na eklemeden önce satırı olan *.js binary bir .gitattributes dosya eklemektir. satırı Git'i *.js binary dosyaları ikili dosyalar olarak değerlendirecek JS şekilde yapılandırarak dağıtım işlem hattındaki dosyaların işlenmesini önler. İşlenmemiş dosyaların dosya karmaları dosyadaki blazor.boot.json girdilerle eşleşir ve istemci tarafı bütünlük denetimleri geçer. Daha fazla bilgi için Bütünlük denetimi hatalarını çözme bölümüne bakın.

URL yeniden yazma işlemlerini işlemek için, isteği sayfaya index.html yönlendirmeyi işleyen bir betik içeren bir dosya ekleyinwwwroot/404.html. Bir örnek için bkz. SteveSandersonMS/BlazorOnGitHubPages GitHub deposu:

• wwwroot/404.html
• Canlı site)

Kuruluş sitesi yerine proje sitesi kullanırken içindeki etiketini wwwroot/index.htmlgüncelleştirin<base>. href Öznitelik değerini, sonunda eğik çizgiyle GitHub deposu adına ayarlayın (örneğin, /my-repository/). SteveSandersonMS/BlazorOnGitHubPages GitHub deposunda, temel hrefyapılandırma dosyası tarafından.github/workflows/main.yml yayımlandığında güncelleştirilir.

Not

SteveSandersonMS/BlazorOnGitHubPages GitHub deposu .NET Foundation veya Microsoft'a ait değildir, korunmaz veya desteklenmez.

Docker ile tek başına

Tek başına Blazor WebAssembly bir uygulama, statik dosya sunucusu tarafından barındırılan statik dosyalar kümesi olarak yayımlanır.

Uygulamayı Docker'da barındırmak için:

• Ngnix veya Apache gibi web sunucusu desteğine sahip bir Docker kapsayıcısı seçin.
• publish Klasör varlıklarını, statik dosyalara hizmet vermek için web sunucusunda tanımlanan bir konum klasörüne kopyalayın.
• Uygulamaya hizmet vermek için gereken ek yapılandırmayı Blazor WebAssembly uygulayın.

Yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Bu makalenin Nginx bölümü veya Apache bölümü
• Docker Belgeleri

Konak yapılandırma değerleri

Blazor WebAssembly uygulamalar , geliştirme ortamında çalışma zamanında komut satırı bağımsız değişkenleri olarak aşağıdaki konak yapılandırma değerlerini kabul edebilir.

İçerik kökü

bağımsız değişkeni, --contentroot uygulamanın içerik dosyalarını (içerik kökü) içeren dizinin mutlak yolunu ayarlar. Aşağıdaki örneklerde uygulamanın /content-root-path içerik kök yolu verilmiştir.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --contentroot=/content-root-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulama Visual Studio Hata Ayıklayıcısı ile çalıştırıldığında ve ile dotnet runbir komut isteminden çalıştırıldığında kullanılır.

  "commandLineArgs": "--contentroot=/content-root-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --contentroot=/content-root-path
  

Yol tabanı

--pathbase bağımsız değişkeni, kök olmayan göreli URL yolu ile yerel olarak çalıştırılacak bir uygulamanın uygulama temel yolunu ayarlar (<base>etiket href hazırlama ve üretim dışında / bir yola ayarlanır). Aşağıdaki örneklerde uygulamanın /relative-URL-path yol tabanı verilmiştir. Daha fazla bilgi için bkz. Uygulama temel yolu.

Önemli

etiketine sağlanan href<base> yoldan farklı olarak, bağımsız değişken değerini geçirirken sondaki eğik çizgi (/) eklemeyin --pathbase . Uygulama temel yolu etiketinde <base> olarak <base href="/CoolApp/"> sağlanıyorsa (sonunda eğik çizgi varsa), komut satırı bağımsız değişken değerini olarak --pathbase=/CoolApp geçirin (sondaki eğik çizgi yok).

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --pathbase=/relative-URL-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --pathbase=/relative-URL-path
  

URL’ler

bağımsız değişkeni, --urls istekleri dinlemek üzere bağlantı noktaları ve protokollerle IP adreslerini veya konak adreslerini ayarlar.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --urls=http://127.0.0.1:0
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --urls=http://127.0.0.1:0
  

Kesiciyi yapılandırma

Blazor çıkış derlemelerinden gereksiz IL'yi kaldırmak için her Yayın derlemesinde Ara Dil (IL) kırpması gerçekleştirir. Daha fazla bilgi için bkz. ASP.NET Core için Düzeltici'yi Blazoryapılandırma.

DLL dosyalarının dosya adı uzantısını değiştirme

Uygulamanın yayımlanan .dll dosyalarının dosya adı uzantılarını değiştirmeniz gerekirse, bu bölümdeki yönergeleri izleyin.

Uygulamayı yayımladıktan sonra, bir kabuk betiği veya DevOps derleme işlem hattı kullanarak dosyaları, uygulamanın yayımlanan çıkışının dizininde farklı bir dosya uzantısı kullanacak şekilde yeniden adlandırın .dll .

Aşağıdaki örneklerde:

• Dosya uzantılarını güncelleştirmek için PowerShell (PS) kullanılır.
• .dll dosyaları, komut satırından dosya uzantısını .bin kullanacak şekilde yeniden adlandırılır.
• Yayımlanmış blazor.boot.json dosyada dosya uzantısıyla .dll listelenen dosyalar dosya uzantısına .bin güncelleştirilir.
• Hizmet çalışanı varlıkları da kullanılıyorsa, PowerShell komutu dosyada service-worker-assets.js listelenen dosyaları dosya uzantısına .bin güncelleştirir.dll.

dosyasından .binfarklı bir dosya uzantısı kullanmak için aşağıdaki komutlarda öğesini istediğiniz dosya uzantısıyla değiştirin .bin .

Windows'da:

dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net5.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Linux veya macOS'ta:

for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan _framework klasörün yoludur (örneğin, .\bin\Release\net5.0\browser-wasm\publish\wwwroot\_framework projenin kök klasöründen).

Hizmet çalışanı varlıkları da kullanılıyorsa:

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

Yukarıdaki komutta {PATH} yer tutucu, yayımlanan service-worker-assets.js dosyanın yoludur.

Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları ele almak için aşağıdaki yaklaşımlardan birini benimseyin:

• Sıkıştırılmış blazor.boot.json.gz ve blazor.boot.json.br dosyaları kaldırın. Sıkıştırma bu yaklaşımla devre dışı bırakılır.
• Güncelleştirilmiş blazor.boot.json dosyayı yeniden sıkıştırın.

Sıkıştırılmış blazor.boot.json dosya için önceki kılavuz, hizmet çalışanı varlıkları kullanımda olduğunda da geçerlidir. ve service-worker-assets.js.gzöğesini kaldırın veya yeniden sıkıştırabilirsinizservice-worker-assets.js.br. Aksi takdirde, dosya bütünlüğü denetimleri tarayıcıda başarısız olur.

.NET 6.0 için aşağıdaki Windows örneği, projenin köküne yerleştirilen bir PowerShell betiği kullanır. Sıkıştırmayı devre dışı bırakan aşağıdaki betik, dosyayı yeniden sıkıştırmak istiyorsanız, daha fazla değişikliğin blazor.boot.json temelini oluşturur.

ChangeDLLExtensions.ps1::

param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br

Hizmet çalışanı varlıkları da kullanılıyorsa aşağıdaki komutları ekleyin:

((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

Proje dosyasında betik, yapılandırma için Release uygulama yayımlandıktan sonra yürütülür:

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

Not

Aynı derlemeleri yeniden adlandırırken ve yavaş yüklerken, ASP.NET Core'daki Blazor WebAssemblygecikmeli yükleme derlemeleri kılavuzuna bakın.

Genellikle, uygulamanın sunucusu güncelleştirilmiş uzantıyla dosyaları sunmak için statik varlık yapılandırması gerektirir. IIS tarafından barındırılan bir uygulama için, özel web.config bir dosyadaki statik içerik bölümünde (<mimeMap>) yeni dosya uzantısı için bir MIME eşleme girdisi (<staticContent>) ekleyin. Aşağıdaki örnekte dosya uzantısının olarak değiştirildiği .dll.binvarsayılır:

<staticContent>
  ...
  <mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
  ...
</staticContent>

Sıkıştırma kullanılıyorsa sıkıştırılmış dosyalar için bir güncelleştirme ekleyin:

<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />

Dosya uzantısının girdisini .dll kaldırın:

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

Sıkıştırma kullanılıyorsa sıkıştırılmış .dll dosyaların girdilerini kaldırın:

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Önceki dağıtım bozulması

Genellikle dağıtımda:

• Yalnızca değiştirilen dosyalar değiştirilir ve bu da genellikle daha hızlı bir dağıtıma neden olur.
• Yeni dağıtımın parçası olmayan mevcut dosyalar, yeni dağıtım tarafından kullanılmak üzere yerinde bırakılır.

Nadir durumlarda, önceki bir dağıtımda kalan dosyalar yeni bir dağıtımı bozabilir. Mevcut dağıtımın (veya dağıtımdan önce yerel olarak yayımlanan uygulamanın) tamamen silinmesi, bozuk bir dağıtımla ilgili sorunu çözebilir. Genellikle, var olan dağıtımı bir kez silmek, DevOps derlemesi ve dağıtım işlem hattı dahil olmak üzere sorunu çözmek için yeterlidir.

DevOps derleme ve dağıtım işlem hattı kullanımda olduğunda her zaman önceki bir dağıtımı temizlemenin gerekli olduğunu belirlerseniz, bozulmanın tam nedenini giderene kadar derleme işlem hattına geçici olarak bir adım ekleyerek her yeni dağıtımın önceki dağıtımını silebilirsiniz.

Bütünlük denetimi hatalarını çözme

Bir uygulamanın başlangıç dosyalarını indirdiğinde Blazor WebAssembly , tarayıcıya yanıtlar üzerinde bütünlük denetimleri gerçekleştirmesini emreder. Blazor istemcilerde önbelleğe alınmayan DLL (.dll), WebAssembly (.wasm ) ve dosyadaki blazor.boot.json diğer dosyalar için SHA-256 karma değerlerini gönderir. Önbelleğe alınan dosyaların dosya karmaları, dosyadaki blazor.boot.json karmalarla karşılaştırılır. Eşleşen karma içeren önbelleğe alınmış dosyalar için önbelleğe Blazor alınmış dosyaları kullanır. Aksi takdirde, dosyalar sunucudan istenir. Bir dosya indirildikten sonra karma değeri bütünlük doğrulaması için yeniden denetlenecektir. İndirilen herhangi bir dosyanın bütünlük denetimi başarısız olursa tarayıcı tarafından bir hata oluşturulur.

Blazor'nin dosya bütünlüğünü yönetme algoritması:

• Uygulamanın tutarsız bir dosya kümesini yükleme riskini almamasını sağlar. Örneğin, kullanıcı uygulama dosyalarını indirme aşamasındayken web sunucunuza yeni bir dağıtım uygulanır. Tutarsız dosyalar hatalı çalışan bir uygulamaya neden olabilir.
• Kullanıcının tarayıcısının tutarsız veya geçersiz yanıtları hiçbir zaman önbelleğe almamasını sağlar. Bu, kullanıcı sayfayı el ile yenilese bile uygulamanın başlatılmasını engelleyebilir.
• Beklenen SHA-256 karmaları değişene kadar yanıtları önbelleğe alma ve sunucu tarafı değişikliklerini denetlememeyi güvenli hale getirir, böylece sonraki sayfa yüklemeleri daha az istek içerir ve daha hızlı tamamlanır.

Web sunucusu beklenen SHA-256 karmalarıyla eşleşmeyen yanıtlar döndürürse, tarayıcının geliştirici konsolunda aşağıdaki örneğe benzer bir hata görüntülenir:

'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=' hesaplanan SHA-256 bütünlüğüne sahip 'https://myapp.example.com/_framework/MyBlazorApp.dll' kaynağının 'integrity' özniteliğinde geçerli bir özet bulunamadı. Kaynak engellendi.

Çoğu durumda, uyarı bütünlük denetimiyle ilgili bir sorun olduğunu göstermez. Bunun yerine, uyarı genellikle başka bir sorun olduğu anlamına gelir.

'Blazor WebAssemblynin önyükleme başvuru kaynağı için GitHub deposundaki dosyaya dotnet/aspnetcore bakınBoot.WebAssembly.ts.

Not

.NET başvuru kaynağına yönelik belge bağlantıları genellikle deponun varsayılan dalını yükler ve bu dal .NET'in sonraki sürümü için geçerli geliştirmeyi temsil eder. Belirli bir sürümün etiketini seçmek için Dalları veya etiketleri değiştir açılan listesini kullanın. Daha fazla bilgi için bkz. ASP.NET Core kaynak kodunun sürüm etiketini seçme (dotnet/AspNetCore.Docs #26205).

Bütünlük sorunlarını tanılama

Bir uygulama oluşturulduğunda oluşturulan bildirim, blazor.boot.json derleme çıkışının oluşturulduğu sırada önyükleme kaynaklarınızın SHA-256 karmalarını açıklar. Içindeki SHA-256 karmaları tarayıcıya teslim edilen dosyalarla blazor.boot.json eşleştiği sürece bütünlük denetimi geçer.

Bunun başarısız olmasının yaygın nedenleri şunlardır:

• Web sunucusunun yanıtı, tarayıcının istediği dosya yerine bir hatadır (örneğin, 404 - Bulunamadı veya 500 - İç Sunucu Hatası). Bu, tarayıcı tarafından bir bütünlük denetimi hatası olarak bildirilir ve yanıt hatası olarak bildirılmaz.
• Dosyaların derlenip tarayıcıya teslim edilmesi arasında dosyaların içeriği bir değişiklik yaptı. Bu durum oluşabilir:
  • Siz veya derleme araçları derleme çıktısını el ile değiştirirseniz.
  • Dağıtım işleminin bazı yönleri dosyaları değiştirdiyse. Örneğin, Git tabanlı dağıtım mekanizması kullanıyorsanız, Windows'da dosya işleyip Bunları Linux'ta kullanıma alırsanız Git'in Windows stili satır sonlarını unix stili satır sonlarına saydam bir şekilde dönüştürdüğünü unutmayın. Dosya satırı sonlarının değiştirilmesi SHA-256 karmalarını değiştirir. Bu sorundan kaçınmak için derleme yapıtlarını dosya olarak binary kabul etmeyi göz önünde bulundurun.gitattributes.
  • Web sunucusu, dosya içeriklerini sunmanın bir parçası olarak değiştirir. Örneğin, bazı içerik dağıtım ağları (CDN'ler) HTML'yi otomatik olarak küçültmeye çalışır ve böylece bunu değiştirir. Bu tür özellikleri devre dışı bırakmanız gerekebilir.
• Dosya blazor.boot.json düzgün yüklenemedi veya istemcide yanlış önbelleğe alınmış. Yaygın nedenler şunlardan birini içerir:
  • Yanlış yapılandırılmış veya hatalı çalışan özel geliştirici kodu.
  • Bir veya daha fazla yanlış yapılandırılmış ara önbelleğe alma katmanı.

Sizin durumunuzda bunlardan hangisinin geçerli olduğunu tanılamak için:

1. Hata iletisini okuyarak hangi dosyanın hatayı tetiklediğine dikkat edin.
2. Tarayıcınızın geliştirici araçlarını açın ve Ağ sekmesine bakın. Gerekirse, istek ve yanıtların listesini görmek için sayfayı yeniden yükleyin. Bu listede hatayı tetikleyen dosyayı bulun.
3. Yanıttaki HTTP durum kodunu denetleyin. Sunucu 200 - Tamam (veya başka bir 2xx durum kodu) dışında bir şey döndürürse, tanılamanız gereken bir sunucu tarafı sorununuz vardır. Örneğin, durum kodu 403 bir yetkilendirme sorunu olduğu, durum kodu 500 ise sunucunun belirtilmemiş bir şekilde başarısız olduğu anlamına gelir. Uygulamayı tanılamak ve düzeltmek için sunucu tarafı günlüklerine başvurun.
4. Kaynak için durum kodu 200 - Tamam ise, tarayıcının geliştirici araçlarında yanıt içeriğine bakın ve içeriğin beklenen verilerle eşleşip eşleşmediğini denetleyin. Örneğin, isteklerin diğer dosyalar için bile verilerinizi index.html döndürmesi için yönlendirmeyi yanlış yapılandırmak yaygın bir sorundur. İsteklere verilen .wasm yanıtların WebAssembly ikilileri olduğundan ve isteklere verilen .dll yanıtların .NET derleme ikili dosyaları olduğundan emin olun. Aksi takdirde, tanılamanız gereken bir sunucu tarafı yönlendirme sorununuz vardır.
5. Bütünlük sorunlarını giderme PowerShell betiğiyle uygulamanın yayımlanan ve dağıtılan çıkışını doğrulamayı deneyin.

Sunucunun makul ölçüde doğru veriler döndürdüğünü onaylarsanız, dosyanın derlemesi ve teslimi arasında içeriği değiştiren başka bir şey olmalıdır. Bunu araştırmak için:

• Derleme araç zincirini ve dağıtım mekanizmasını, dosyalar oluşturulduktan sonra dosyaları değiştiriyor olma ihtimaline karşı inceleyin. Bunun bir örneği, Git'in daha önce açıklandığı gibi dosya satırı sonlarını dönüştürmesidir.
• Yanıtları dinamik olarak değiştirmek için ayarlanmış olma ihtimaline karşı web sunucusunu veya CDN yapılandırmasını inceleyin (örneğin, HTML'yi küçültmeye çalışma). Web sunucusunun HTTP sıkıştırması uygulaması normaldir (örneğin, döndüren content-encoding: br veya content-encoding: gzip), çünkü bu durum sıkıştırmadan sonra sonucu etkilemez. Ancak, web sunucusunun sıkıştırılmamış verileri değiştirmesi uygun değildir .

Bütünlük Sorunlarını Giderme PowerShell betiği

integrity.ps1 Yayımlanmış ve dağıtılmış Blazor bir uygulamayı doğrulamak için PowerShell betiğini kullanın. Betik, powershell core 7 veya üzeri için uygulamanın çerçevenin tanımlayabildiği bütünlük sorunları Blazor olduğunda başlangıç noktası olarak sağlanır. PowerShell'in 7.2.0 sürümünden sonraki bir sürümde çalışıyor olması da dahil olmak üzere, uygulamalarınız için betiğin özelleştirilmesi gerekebilir.

Betik, bütünlük karmaları içeren farklı bildirimlerdeki publish sorunları algılamak için klasördeki ve dağıtılan uygulamadan indirilen dosyaları denetler. Bu denetimler en yaygın sorunları algılamalıdır:

• Yayımlanan çıktıdaki bir dosyayı fark etmeden değiştirdiniz.
• Uygulama dağıtım hedefine doğru dağıtılmadı veya dağıtım hedefinin ortamında bir değişiklik oldu.
• Dağıtılan uygulama ile uygulamayı yayımlama çıktısı arasında farklar vardır.

Betiği bir PowerShell komut kabuğunda aşağıdaki komutla çağırın:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

Aşağıdaki örnekte, betik konumunda yerel olarak çalışan bir uygulamada https://localhost:5001/yürütülür:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Yer tutucu:

• {BASE URL}: Dağıtılan uygulamanın URL'si. Sondaki eğik çizgi (/) gereklidir.
• {PUBLISH OUTPUT FOLDER}: Uygulamanın publish dağıtım için yayımlandığı klasörün veya konumun yolu.

Not

GitHub deposunu dotnet/AspNetCore.Docs kopyalarken betik Bitdefenderintegrity.ps1 veya sistemde bulunan başka bir virüs tarayıcısı tarafından karantinaya alınmış olabilir. Dosya genellikle virüs tarayıcısının buluşsal tarama teknolojisi tarafından tuzağa düşürülür ve bu teknoloji yalnızca kötü amaçlı yazılımların varlığını gösterebilecek dosyalarda desenleri arar. Virüs tarayıcısının dosyayı ayırmasını önlemek için, depoyu kopyalamadan önce virüs tarayıcısına bir özel durum ekleyin. Aşağıdaki örnek, bir Windows sistemindeki betiğin tipik bir yoludur. Yolu diğer sistemler için gerektiği gibi ayarlayın. Yer tutucu {USER} , kullanıcının yol kesimidir.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

Uyarı: Virüs tarayıcısı özel durumlarının oluşturulması tehlikelidir ve yalnızca dosyanın güvenli olduğundan emin olduğunuzda gerçekleştirilmelidir.

Bir dosyanın sağlama toplamını geçerli bir sağlama toplamı değeriyle karşılaştırmak, dosya güvenliğini garanti etmez, ancak dosyayı sağlama toplamı değerini koruyacak şekilde değiştirmek kötü amaçlı kullanıcılar için önemsiz değildir. Bu nedenle sağlama toplamları genel bir güvenlik yaklaşımı olarak yararlıdır. Yerel integrity.ps1 dosyanın sağlama toplamını aşağıdaki değerlerden biriyle karşılaştırın:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Aşağıdaki komutla Windows işletim sisteminde dosyanın sağlama toplamını alın. Yer tutucunun yolunu ve dosya adını {PATH AND FILE NAME} belirtin ve yer tutucu SHA256 için {SHA512|MD5} üretilmesi gereken sağlama toplamı türünü (veya MD5) belirtin:

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Sağlama toplamı doğrulamasının ortamınızda yeterince güvenli olmamasıyla ilgili bir endişeniz varsa, rehberlik için kuruluşunuzun güvenlik liderliğine başvurun.

Daha fazla bilgi için bkz. Kötü amaçlı yazılım & diğer tehditlerini anlama.

PWA olmayan uygulamalar için bütünlük denetimini devre dışı bırakma

Çoğu durumda bütünlük denetimini devre dışı bırakma. Bütünlük denetiminin devre dışı bırakılması, beklenmeyen yanıtlara neden olan ve daha önce listelenen avantajların kaybedilmesine neden olan temel sorunu çözmez.

Tutarlı yanıtlar döndürmek için web sunucusunun bağımlı olmadığı durumlar olabilir ve temel alınan sorun çözülene kadar bütünlük denetimlerini geçici olarak devre dışı bırakmaktan başka seçeneğiniz olmayabilir.

Bütünlük denetimlerini devre dışı bırakmak için, uygulamanın proje dosyasındaki (Blazor WebAssembly.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResourcesayrıca , .wasmve diğer dosyaları SHA-256 karmalarına göre önbelleğe alma .dllişleminin varsayılan davranışını devre dışı bırakır Blazorçünkü özelliği SHA-256 karmalarının doğruluğu için güvenilmediğini gösterir. Bu ayarda bile, tarayıcının normal HTTP önbelleği bu dosyaları önbelleğe almaya devam edebilir, ancak bunun olup olmadığı web sunucusu yapılandırmanıza ve cache-control hizmet veren üst bilgilere bağlıdır.

Not

özelliği Aşamalı BlazorCacheBootResourcesWeb Uygulamaları (PWA) için bütünlük denetimlerini devre dışı bırakmaz. PWA'larla ilgili yönergeler için PWA'lar için bütünlük denetimini devre dışı bırakma bölümüne bakın.

Bütünlük denetimini devre dışı bırakmanın gerekli olduğu senaryoların kapsamlı bir listesini sağlayamıyoruz. Sunucular, isteği çerçeve kapsamı Blazor dışında rastgele yollarla yanıtlayabilir. Çerçeve, uygulamanın sağlayabilecekleri bütünlük garantisini kaybetme karşılığında uygulamayı çalıştırılabilir hale getirme ayarını sağlarBlazorCacheBootResources. Yine, özellikle üretim dağıtımları için bütünlük denetimini devre dışı bırakmanızı önermiyoruz. Geliştiriciler, bütünlük denetiminin başarısız olmasına neden olan temel bütünlük sorununu çözmeye çalışmalıdır.

Bütünlük sorunlarına neden olabilecek birkaç genel durum şunlardır:

• Bütünlüğün denetlenemez olduğu HTTP'de çalışıyor.
• Dağıtım işleminiz herhangi bir şekilde yayımlandıktan sonra dosyaları değiştirirse.
• Konağınız dosyaları herhangi bir şekilde değiştirirse.

PWA'lar için bütünlük denetimini devre dışı bırakma

Blazor'nin Aşamalı Web Uygulaması (PWA) şablonu, uygulama dosyalarını çevrimdışı kullanım için getirmek ve depolamaktan sorumlu önerilen service-worker.published.js bir dosya içeriyor. Bu, normal uygulama başlatma mekanizmasından ayrı bir işlemdir ve kendi ayrı bütünlük denetimi mantığına sahiptir.

Dosyanın içinde service-worker.published.js aşağıdaki satır bulunur:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Bütünlük denetimini devre dışı bırakmak için, satırı aşağıdaki şekilde değiştirerek parametresini kaldırın integrity :

.map(asset => new Request(asset.url));

Yine bütünlük denetimini devre dışı bırakmak, bütünlük denetimi tarafından sunulan güvenlik garantilerini kaybetmeniz anlamına gelir. Örneğin, yeni bir sürümü dağıttığınız anda kullanıcının tarayıcısı uygulamayı önbelleğe alırsa, eski dağıtımdaki bazı dosyaları ve yeni dağıtımdaki bazı dosyaları önbelleğe alma riski vardır. Böyle bir durumda, siz daha fazla güncelleştirme dağıtana kadar uygulama bozuk durumda takılır.

Barındırma modeli ileBlazor WebAssembly:

• Uygulama Blazor , bağımlılıkları ve .NET çalışma zamanı paralel olarak tarayıcıya indirilir.
• Uygulama doğrudan tarayıcı kullanıcı arabirimi iş parçacığında yürütülür.

Aşağıdaki dağıtım stratejileri desteklenir:

• Uygulama Blazor bir ASP.NET Core uygulaması tarafından sunulur. Bu strateji, ASP.NET Core ile barındırılan dağıtım bölümünde ele alınmıştır.
• Uygulama Blazor statik bir barındırma web sunucusuna veya hizmetine yerleştirilir; burada .NET, uygulamayı sunmak Blazor için kullanılmaz. Bu strateji, bir Blazor WebAssembly uygulamayı IIS alt uygulaması olarak barındırma hakkında bilgi içeren Tek başına dağıtım bölümünde ele alınmıştır.
• bir ASP.NET Core uygulaması birden çok Blazor WebAssembly uygulama barındırıyor. Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Önyükleme kaynaklarının nasıl yüklendiğini özelleştirme

API kullanarak önyükleme kaynaklarının nasıl yüklendiğini özelleştirin loadBootResource . Daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırma

Bir Blazor WebAssembly uygulama yayımlandığında, uygulamanın boyutunu azaltmak ve çalışma zamanı sıkıştırma ek yükünü kaldırmak için çıkış yayımlama sırasında statik olarak sıkıştırılır. Aşağıdaki sıkıştırma algoritmaları kullanılır:

• Brotli (en yüksek düzey)
• Gzip

Blazor uygun sıkıştırılmış dosyaları sunmak için konağa dayanır. ASP.NET Core BarındırılanBlazor WebAssembly proje kullanılırken, konak projesi içerik anlaşması gerçekleştirebilir ve statik olarak sıkıştırılmış dosyalara hizmet yapabilir. Tek başına bir Blazor WebAssembly uygulama barındırırken, statik olarak sıkıştırılmış dosyaların sunulduğunda emin olmak için ek çalışma gerekebilir:

• IIS web.config sıkıştırma yapılandırması için IIS: Brotli ve Gzip sıkıştırma bölümüne bakın.

• GitHub Pages gibi statik olarak sıkıştırılmış dosya içeriği anlaşmasını desteklemeyen statik barındırma çözümlerinde barındırırken uygulamayı Brotli sıkıştırılmış dosyalarını getirmek ve kodunu çözmek için yapılandırmayı göz önünde bulundurun:

  • Google/brotli GitHub deposundan JavaScript Brotli kod çözücüsü edinin. Küçültüldü kod çözücü dosyası olarak adlandırılır decode.min.js ve deponun js klasöründe bulunur.

    Not

    Betiğin (decode.min.js) küçültüldü sürümü decode.js başarısız olursa, bunun yerine doğrulanmamış sürümü (decode.js) kullanmayı deneyin.

  • Uygulamayı kod çözücü kullanacak şekilde güncelleştirin.

    wwwroot/index.html dosyasında, 'nin <script> etiketinde falseBlazorolarak ayarlayınautostart:

    <script src="_framework/blazor.webassembly.js" autostart="false"></script>
    

    etiketinden <script> sonra Blazorve kapanış </body> etiketinden önce aşağıdaki JavaScript kod <script> bloğunu ekleyin:

    <script type="module">
      import { BrotliDecode } from './decode.min.js';
      Blazor.start({
        loadBootResource: function (type, name, defaultUri, integrity) {
          if (type !== 'dotnetjs' && location.hostname !== 'localhost') {
            return (async function () {
              const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
              if (!response.ok) {
                throw new Error(response.statusText);
              }
              const originalResponseBuffer = await response.arrayBuffer();
              const originalResponseArray = new Int8Array(originalResponseBuffer);
              const decompressedResponseArray = BrotliDecode(originalResponseArray);
              const contentType = type === 
                'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
              return new Response(decompressedResponseArray, 
                { headers: { 'content-type': contentType } });
            })();
          }
        }
      });
    </script>
    

    Önyükleme kaynaklarını yükleme hakkında daha fazla bilgi için bkz. ASP.NET Core Blazor başlatma.

Sıkıştırmayı BlazorEnableCompression devre dışı bırakmak için MSBuild özelliğini uygulamanın proje dosyasına ekleyin ve değerini olarak falseayarlayın:

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

özelliği, BlazorEnableCompression komut kabuğunda dotnet publish aşağıdaki söz dizimiyle komutuna geçirilebilir:

dotnet publish -p:BlazorEnableCompression=false

Doğru yönlendirme için URL'leri yeniden yazma

Bir Blazor WebAssembly uygulamadaki sayfa bileşenleri için yönlendirme istekleri, barındırılan bir Blazor Serveruygulamadaki yönlendirme istekleri kadar basit değildir. İki bileşeni olan bir Blazor WebAssembly uygulamayı göz önünde bulundurun:

• Main.razor: Uygulamanın köküne yüklenir ve bileşene About (href="About") bir bağlantı içerir.
• About.razor: About bileşeni.

Tarayıcının adres çubuğu kullanılarak uygulamanın varsayılan belgesi istendiğinde (örneğin: https://www.contoso.com/

1. Tarayıcı bir istekte bulunur.
2. Varsayılan sayfa döndürülür; bu genellikle index.htmlşeklindedir.
3. index.html uygulamayı bootstraplar.
4. Blazor'nin yönlendiricisi yüklenir ve RazorMain bileşen işlenir.

Ana sayfada, bileşenin bağlantısının About seçilmesi istemcide çalışır çünkü Blazor yönlendirici tarayıcının için İnternet'te istekte bulunmasını www.contoso.comAbout durdurur ve işlenen About bileşenin kendisine hizmet eder. Uygulama içindeki Blazor WebAssembly iç uç noktalara yönelik tüm istekler aynı şekilde çalışır: İstekler, İnternet'te sunucu tarafından barındırılan kaynaklara tarayıcı tabanlı istekler tetiklemez. Yönlendirici istekleri dahili olarak işler.

için tarayıcının adres çubuğu www.contoso.com/Aboutkullanılarak istek yapılırsa istek başarısız olur. Uygulamanın İnternet ana bilgisayarında böyle bir kaynak olmadığından 404 - Bulunamadı yanıtı döndürülür.

Tarayıcılar istemci tarafı sayfalar için İnternet tabanlı konaklara istekte bulunacağından, web sunucularının ve barındırma hizmetlerinin sunucuda fiziksel olarak sayfaya olmayan kaynaklara yönelik tüm istekleri yeniden yazması index.html gerekir. Döndürülürse index.html , uygulamanın yönlendiricisi Blazor bunu devralır ve doğru kaynakla yanıt verir.

IIS sunucusuna dağıtım yaparken url yeniden yazma modülünü uygulamanın yayımlanan web.config dosyasıyla kullanabilirsiniz. Daha fazla bilgi için IIS bölümüne bakın.

ASP.NET Core ile barındırılan dağıtım

BarındırılanBlazor WebAssembly dağıtım, uygulamayı web sunucusunda çalışan bir ASP.NET Core uygulamasından tarayıcılara hizmet eder.

İstemci Blazor WebAssembly uygulaması, sunucu uygulamasının /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot diğer statik web varlıklarıyla birlikte sunucu uygulamasının klasörüne yayımlanır. İki uygulama birlikte dağıtılır. bir ASP.NET Core uygulamasını barındırabilen bir web sunucusu gereklidir. Barındırılan Blazor WebAssembly bir dağıtım için Visual Studio, Uygulama projesi şablonunu (blazorwasmkomutu kullanırken dotnet new şablon) ve seçeneğinin Hosted seçili olduğunu (-ho|--hostedkomutu kullanırkendotnet new) içerir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• ASP.NET Core uygulama barındırma ve dağıtma: ASP.NET Core barındırma ve dağıtma
• Azure App Service dağıtımı: Visual Studio ile ASP.NET Core uygulamasını Azure'da yayımlama
• Blazorproje şablonları: ASP.NET Core Blazor proje yapısı

Belirli bir platform için çerçeveye bağımlı yürütülebilir dosyanın barındırılan dağıtımı

Barındırılan Blazor WebAssembly bir uygulamayı belirli bir platform için (bağımsız olmayan) çerçeveye bağımlı yürütülebilir dosya olarak dağıtmak için, kullanımdaki araçlara bağlı olarak aşağıdaki kılavuzu kullanın.

Visual Studio

Varsayılan olarak, oluşturulan yayımlama profili (.pubxml ) için bağımsız bir dağıtım yapılandırılır. Projenin yayımlama profilinin Server olarak ayarlanmış MSBuild özelliğini içerdiğini <SelfContained>falseonaylayın.

Projenin Properties klasöründeki .pubxmlServer yayımlama profili dosyasında:

<SelfContained>false</SelfContained>

Yayımlama profilinde MSBuild özelliğini oluşturan Yayımlama Kullanıcı Arabiriminin Ayarlar alanındaki Hedef Çalışma Zamanı ayarını kullanarak Çalışma Zamanı Tanımlayıcısı'nı<RuntimeIdentifier> (RID) ayarlayın:

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Server Projeyi Yayın yapılandırmasında yayımlayın.

Not

Yer tutucunun profil olduğu {PROFILE} komutuna geçirerek dotnet publish/p:PublishProfile={PROFILE} .NET CLI kullanarak profil yayımlama ayarlarına sahip bir uygulama yayımlamak mümkündür. Daha fazla bilgi için, ASP.NET Core uygulama dağıtımı için Visual Studio yayımlama profilleri (.pubxml) makalesindeki Profilleri yayımlamaveKlasör yayımlama örneği bölümlerine bakın. RID'yi yayımlama profilinde dotnet publish değil komutunda geçirirseniz, MSBuild özelliğini ()/p:RuntimeIdentifier) seçeneğiyle değil komutuyla -r|--runtime kullanın.

.NET CLI

MSBuild özelliğini projenin proje dosyasında olarak ayarlanmış falsebir <PropertyGroup>Server içine yerleştirerek <SelfContained>bağımsız bir dağıtım yapılandırın:

<SelfContained>false</SelfContained>

Önemli

SelfContained özelliği projenin proje dosyasına yerleştirilmelidirServer. özelliği, seçeneği veya MSBuild özelliği /p:SelfContained=falsekullanılarak --no-self-containedkomutuyladotnet publish doğru ayarlanamaz.

Aşağıdaki yaklaşımlardan birini kullanarak Çalışma Zamanı Tanımlayıcısı'nı (RID) ayarlayın:

• Seçenek 1: Projenin proje dosyasındaki bir <PropertyGroup> içindeki Server RID'yi ayarlayın:

  <RuntimeIdentifier>{RID}</RuntimeIdentifier>
  

  Önceki yapılandırmada {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

  Uygulamayı projeden Yayın yapılandırmasında Server yayımlayın:

  dotnet publish -c Release
  

• 2. Seçenek: Komutundaki RID'yi dotnet publish şu seçenekle -r|--runtimedeğil MSBuild özelliği ()/p:RuntimeIdentifier olarak geçirin:

  dotnet publish -c Release /p:RuntimeIdentifier={RID}
  

  Yukarıdaki komutta {RID} yer tutucu Çalışma Zamanı Tanımlayıcısı (RID) şeklindedir.

Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

• .NET uygulaması yayımlamaya genel bakış
• ASP.NET Core barındırma ve dağıtma

Birden çok uygulamayla barındırılan Blazor WebAssembly dağıtım

Daha fazla bilgi için bkz. Birden çok barındırılan Blazor WebAssembly ASP.NET Core uygulaması.

Tek başına dağıtım

Tek başına dağıtım, uygulamayı doğrudan istemciler Blazor WebAssembly tarafından istenen statik dosyalar kümesi olarak sunar. Herhangi bir statik dosya sunucusu uygulamaya hizmet Blazor yapabilir.

Tek başına dağıtım varlıkları klasörüne /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot yayımlanır.

Azure App Service

Blazor WebAssemblyuygulamalar, uygulamayı IIS'de barındıran Windows Azure Uygulaması Hizmetlerine dağıtılabilir.

Linux için Azure App Service'a tek başına Blazor WebAssembly uygulama dağıtma şu anda desteklenmemekte. Bu senaryoyı destekleyen Azure Static Web Apps kullanarak tek başına Blazor WebAssembly bir uygulama barındırmanızı öneririz.

Azure Statik Web Uygulamaları

Daha fazla bilgi için bkz. Öğretici: Azure Static Web Apps'de ile Blazor statik web uygulaması oluşturma.

IIS

IIS, uygulamalar için Blazor yetenekli bir statik dosya sunucusudur. IIS'yi barındıracak Blazorşekilde yapılandırmak için bkz. IIS'de Statik Web Sitesi Oluşturma.

Yayımlanan varlıklar, SDK'nın hangi sürümünün /bin/Release/{TARGET FRAMEWORK}/publish kullanıldığına ve yer tutucunun hedef çerçeve olduğuna {TARGET FRAMEWORK} bağlı olarak veya bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish klasöründe oluşturulur. Klasörün içeriğini publish web sunucusunda veya barındırma hizmetinde barındırın.

web.config

Bir Blazor proje yayımlandığında, aşağıdaki IIS yapılandırmasıyla bir web.config dosya oluşturulur:

• MIME türleri
• HTTP sıkıştırması aşağıdaki MIME türleri için etkinleştirilir:
  • application/octet-stream
  • application/wasm
• URL Yeniden Yazma Modülü kuralları oluşturulur:
  • Uygulamanın statik varlıklarının (wwwroot/{PATH REQUESTED}) bulunduğu alt dizine hizmet edin.
  • Dosya olmayan varlıklara yönelik isteklerin statik varlıklar klasöründeki (wwwroot/index.html ) uygulamanın varsayılan belgesine yeniden yönlendirilmesi için SPA geri dönüş yönlendirmesi oluşturun.

Özel kullanım web.config

Özel web.config dosya kullanmak için:

1. Özel web.config dosyayı projenin kök klasörüne yerleştirin. Barındırılan Blazor WebAssemblybir çözüm için dosyayı Server projenin klasörüne yerleştirin.
2. Projeyi yayımlayın. Barındırılan Blazor WebAssembly bir çözüm için çözümü projeden Server yayımlayın. Daha fazla bilgi için bkz. ASP.NET Core Blazorbarındırma ve dağıtma.

SDK'nın web.config yayımlama sırasındaki oluşturma veya dönüştürme işlemi, dosyayı klasördeki publish yayımlanmış varlıklara taşımazsa veya özel web.config dosyanızdaki özel yapılandırmayı değiştirmiyorsa, işlemin tam denetimini almak için aşağıdaki yaklaşımlardan herhangi birini kullanın:

• SDK dosyayı oluşturmuyorsa( örneğin, SDK'nın hangi sürümünün kullanıldığına ve yer tutucunun hedef çerçeve olduğuna bağlı olarak veya üzerindeki tek başına Blazor WebAssembly bir uygulamadabin\Release\{TARGET FRAMEWORK}\browser-wasm\publish/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot) özelliğini true proje dosyasında ().csproj olarak ayarlayın<PublishIISAssets>.{TARGET FRAMEWORK} Genellikle tek başına WebAssembly uygulamaları için, özel web.config bir dosyayı taşımak ve dosyanın SDK tarafından dönüştürülmesini önlemek için gereken tek ayar budur.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• Sdk'nın web.config proje dosyasındaki dönüştürmesini devre dışı bırakın (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Özel bir dosyayı taşımak için proje dosyasına (.csproj) özel web.config bir hedef ekleyin. Aşağıdaki örnekte özel web.config dosya, geliştirici tarafından projenin köküne yerleştirilir. web.config Dosya başka bir yerde bulunuyorsa dosyasında dosyanın SourceFilesyolunu belirtin. Aşağıdaki örnek ile $(PublishDir)klasörünü belirtirpublish, ancak özel çıkış konumu için bir yol DestinationFolder sağlar.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

URL Yeniden Yazma Modülünü Yükleme

URL'leri yeniden yazmak için URL Yeniden Yazma Modülü gereklidir. Modül varsayılan olarak yüklenmez ve Web Sunucusu (IIS) rol hizmeti özelliği olarak yüklenemez. Modülün IIS web sitesinden indirilmesi gerekir. Modülü yüklemek için Web Platformu Yükleyicisi'ni kullanın:

1. Yerel olarak URL Yeniden Yazma Modülü indirmeleri sayfasına gidin. İngilizce sürüm için WebPI yükleyicisini indirmek için WebPI'yi seçin. Diğer diller için, yükleyiciyi indirmek üzere sunucu (x86/x64) için uygun mimariyi seçin.
2. Yükleyiciyi sunucuya kopyalayın. Yükleyiciyi çalıştırın. Yükle düğmesini seçin ve lisans koşullarını kabul edin. Yükleme tamamlandıktan sonra sunucunun yeniden başlatılması gerekmez.

Web sitesini yapılandırma

Web sitesinin Fiziksel yolunu uygulamanın klasörüne ayarlayın. Klasör aşağıdakileri içerir:

• Iis'nin web.config gerekli yeniden yönlendirme kuralları ve dosya içerik türleri de dahil olmak üzere web sitesini yapılandırmak için kullandığı dosya.
• Uygulamanın statik varlık klasörü.

IIS alt uygulaması olarak barındırma

Tek başına bir uygulama IIS alt uygulaması olarak barındırılıyorsa aşağıdakilerden birini gerçekleştirin:

• Devralınan ASP.NET Core Modülü işleyicisini devre dışı bırakın.

  Dosyanın bölümüne bir <handlers> bölüm ekleyerek uygulamanın yayımlanan web.config dosyasındaki işleyiciyi Blazor<system.webServer> kaldırın:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• olarak ayarlanmış bir <location> öğe inheritInChildApplications kullanarak kök (üst) uygulamanın <system.webServer> bölümünün devralını falsedevre dışı bırakın:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Not

  Kök (üst) uygulamanın <system.webServer> bölümünün devralmayı devre dışı bırakmak, .NET SDK'sı kullanılarak yayımlanan uygulamalar için varsayılan yapılandırmadır.

İşleyiciyi kaldırma veya devralmayı devre dışı bırakma işlemi , uygulamanın temel yolunu yapılandırmaya ek olarak gerçekleştirilir. Uygulamanın dosyasındaki uygulama temel yolunu IIS'de index.html alt uygulamayı yapılandırırken kullanılan IIS diğer adı olarak ayarlayın.

Brotli ve Gzip sıkıştırması

Bu bölüm yalnızca tek başına Blazor WebAssembly uygulamalar için geçerlidir. Barındırılan Blazor uygulamalar, bu bölümdeki bağlantılı dosyayı değil, varsayılan ASP.NET Core uygulama web.config dosyasını kullanır.

IIS, aracılığıyla tek başına Blazor WebAssembly uygulamalar için Brotli veya Gzip sıkıştırılmış Blazor varlıklarına hizmet vermek üzere yapılandırılabilirweb.config. Örnek bir yapılandırma dosyası için bkz web.config. .

Aşağıdaki senaryolarda örnek web.config dosyanın ek yapılandırması gerekebilir:

• Uygulamanın belirtimi aşağıdakilerden birini çağırır:
  • Örnek web.config dosya tarafından yapılandırılmamış sıkıştırılmış dosyalar sunma.
  • Örnek web.config dosya tarafından yapılandırılan sıkıştırılmış dosyaları sıkıştırılmamış biçimde sunma.
• Sunucunun IIS yapılandırması (örneğin, applicationHost.config) sunucu düzeyinde IIS varsayılanları sağlar. Sunucu düzeyinde yapılandırmaya bağlı olarak, uygulama örnek web.config dosyanın içerdiğinden farklı bir IIS yapılandırması gerektirebilir.

Özel web.config dosyalar hakkında daha fazla bilgi için Özel web.configdosya kullanma bölümüne bakın.

Sorun giderme

500 - İç Sunucu Hatası alınırsa ve IIS Yöneticisi web sitesinin yapılandırmasına erişmeye çalışırken hatalar oluşturursa, URL Yeniden Yazma Modülü'nin yüklü olduğunu onaylayın. Modül yüklenmediğinde dosya web.config IIS tarafından ayrıştırılamaz. Bu, IIS Yöneticisi'nin web sitesinin yapılandırmasını ve web sitesinin statik dosyaları sunmasını Blazorengeller.

IIS dağıtımlarının sorunlarını giderme hakkında daha fazla bilgi için bkz. Azure App Service ve IIS'de ASP.NET Core sorunlarını giderme.

Azure Depolama

Azure Depolama statik dosya barındırma sunucusuz Blazor uygulama barındırmaya olanak tanır. Özel etki alanı adları, Azure Content Delivery Network (CDN) ve HTTPS desteklenir.

Blob hizmeti bir depolama hesabında statik web sitesi barındırma için etkinleştirildiğinde:

• Dizin belge adını olarak index.htmlayarlayın.
• Hata belgesi yolunu olarak index.htmlayarlayın. Razor bileşenleri ve diğer dosya olmayan uç noktalar blob hizmeti tarafından depolanan statik içerikteki fiziksel yollarda yer almaz. Yönlendiricinin işlemesi gereken bu kaynaklardan birine yönelik bir istek alındığında Blazor , blob hizmeti tarafından oluşturulan 404 - Bulunamadı hatası isteği Hata belge yoluna yönlendirir. index.html Blob döndürülür ve Blazor yönlendirici yolu yükler ve işler.

Dosyaların üst bilgilerindeki uygunsuz MIME türleri nedeniyle dosyalar Content-Type çalışma zamanında yüklenmiyorsa, aşağıdaki eylemlerden birini gerçekleştirin:

• Dosyalar dağıtıldığında doğru MIME türlerini (Content-Type üst bilgiler) ayarlamak için araçlarınızı yapılandırın.

• Uygulama dağıtıldıktan sonra dosyaların MIME türlerini (Content-Type üst bilgileri) değiştirin.

  Her dosya için Depolama Gezgini (Azure portal) içinde:

  1. Dosyaya sağ tıklayın ve Özellikler’i seçin.
  2. ContentType'ı ayarlayın ve Kaydet düğmesini seçin.

Daha fazla bilgi için bkz. Azure Depolama'da statik web sitesi barındırma.

Nginx

Aşağıdaki nginx.conf dosya, diskte karşılık gelen bir dosyayı bulamadan Nginx'in dosyayı gönderecek index.html şekilde nasıl yapılandırıldığını gösterecek şekilde basitleştirilmiştir.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

ile limit_reqBlazor WebAssemblyNGINX seri hız sınırını ayarlarken, uygulamalar bir uygulama tarafından yapılan görece çok sayıda isteği karşılamak için büyük burst bir parametre değeri gerektirebilir. Başlangıçta değeri en az 60 olarak ayarlayın:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Tarayıcı geliştirici araçları veya ağ trafiği aracı isteklerin 503 - Hizmet Kullanılamıyor durum kodu aldığını gösteriyorsa değeri artırın.

Üretim Nginx web sunucusu yapılandırması hakkında daha fazla bilgi için bkz. NGINX Plus ve NGINX Yapılandırma Dosyaları Oluşturma.

Apache

Bir uygulamayı CentOS 7 veya sonraki bir Blazor WebAssembly sürümüne dağıtmak için:

1. Apache yapılandırma dosyasını oluşturun. Aşağıdaki örnek, basitleştirilmiş bir yapılandırma dosyasıdır (blazorapp.config):

   <VirtualHost *:80>
       ServerName www.example.com
       ServerAlias *.example.com
   
       DocumentRoot "/var/www/blazorapp"
       ErrorDocument 404 /index.html
   
       AddType application/wasm .wasm
       AddType application/octet-stream .dll
   
       <Directory "/var/www/blazorapp">
           Options -Indexes
           AllowOverride None
       </Directory>
   
       <IfModule mod_deflate.c>
           AddOutputFilterByType DEFLATE text/css
           AddOutputFilterByType DEFLATE application/javascript
           AddOutputFilterByType DEFLATE text/html
           AddOutputFilterByType DEFLATE application/octet-stream
           AddOutputFilterByType DEFLATE application/wasm
           <IfModule mod_setenvif.c>
         BrowserMatch ^Mozilla/4 gzip-only-text/html
         BrowserMatch ^Mozilla/4.0[678] no-gzip
         BrowserMatch bMSIE !no-gzip !gzip-only-text/html
     </IfModule>
       </IfModule>
   
       ErrorLog /var/log/httpd/blazorapp-error.log
       CustomLog /var/log/httpd/blazorapp-access.log common
   </VirtualHost>
   

2. Apache yapılandırma dosyasını CentOS 7'deki varsayılan Apache yapılandırma dizini olan dizine /etc/httpd/conf.d/ yerleştirin.

3. Uygulamanın dosyalarını dizinine /var/www/blazorapp (yapılandırma dosyasında belirtilen DocumentRoot konum) yerleştirin.

4. Apache hizmetini yeniden başlatın.

Daha fazla bilgi için mod_mime ve mod_deflate bölümlerine bakın.

GitHub Pages

Sayfaları dağıtan varsayılan GitHub Eylemi, klasör gibi alt çizgiyle başlayan klasörlerin dağıtımını _framework atlar. Alt çizgiyle başlayan klasörleri dağıtmak için Git dalı için boş .nojekyll bir dosya ekleyin.

Git, gibi blazor.webassembly.jsJavaScript (JS) dosyalarını metin olarak ele alır ve satır sonlarını CRLF'den (satır dönüş satırı akışı) dağıtım işlem hattında LF'ye (satır akışı) dönüştürür. Dosyalarda yapılan JS bu değişiklikler, dosyadaki blazor.boot.json istemciye göndermeden Blazor farklı dosya karmaları oluşturur. Uyuşmazlıklar istemcide bütünlük denetimi hatalarına neden olur. Bu sorunu çözmenin bir yaklaşımı, uygulamanın varlıklarını Git dalı'na eklemeden önce satırı olan *.js binary bir .gitattributes dosya eklemektir. satırı Git'i *.js binary dosyaları ikili dosyalar olarak değerlendirecek JS şekilde yapılandırarak dağıtım işlem hattındaki dosyaların işlenmesini önler. İşlenmemiş dosyaların dosya karmaları dosyadaki blazor.boot.json girdilerle eşleşir ve istemci tarafı bütünlük denetimleri geçer. Daha fazla bilgi için Bütünlük denetimi hatalarını çözme bölümüne bakın.

URL yeniden yazma işlemlerini işlemek için, isteği sayfaya index.html yönlendirmeyi işleyen bir betik içeren bir dosya ekleyinwwwroot/404.html. Bir örnek için bkz. SteveSandersonMS/BlazorOnGitHubPages GitHub deposu:

• wwwroot/404.html
• Canlı site)

Kuruluş sitesi yerine proje sitesi kullanırken içindeki etiketini wwwroot/index.htmlgüncelleştirin<base>. href Öznitelik değerini, sonunda eğik çizgiyle GitHub deposu adına ayarlayın (örneğin, /my-repository/). SteveSandersonMS/BlazorOnGitHubPages GitHub deposunda, temel hrefyapılandırma dosyası tarafından.github/workflows/main.yml yayımlandığında güncelleştirilir.

Not

SteveSandersonMS/BlazorOnGitHubPages GitHub deposu .NET Foundation veya Microsoft'a ait değildir, korunmaz veya desteklenmez.

Docker ile tek başına

Tek başına Blazor WebAssembly bir uygulama, statik dosya sunucusu tarafından barındırılan statik dosyalar kümesi olarak yayımlanır.

Uygulamayı Docker'da barındırmak için:

• Ngnix veya Apache gibi web sunucusu desteğine sahip bir Docker kapsayıcısı seçin.
• publish Klasör varlıklarını, statik dosyalara hizmet vermek için web sunucusunda tanımlanan bir konum klasörüne kopyalayın.
• Uygulamaya hizmet vermek için gereken ek yapılandırmayı Blazor WebAssembly uygulayın.

Yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Bu makalenin Nginx bölümü veya Apache bölümü
• Docker Belgeleri

Konak yapılandırma değerleri

Blazor WebAssembly uygulamalar , geliştirme ortamında çalışma zamanında komut satırı bağımsız değişkenleri olarak aşağıdaki konak yapılandırma değerlerini kabul edebilir.

İçerik kökü

bağımsız değişkeni, --contentroot uygulamanın içerik dosyalarını (içerik kökü) içeren dizinin mutlak yolunu ayarlar. Aşağıdaki örneklerde uygulamanın /content-root-path içerik kök yolu verilmiştir.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --contentroot=/content-root-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulama Visual Studio Hata Ayıklayıcısı ile çalıştırıldığında ve ile dotnet runbir komut isteminden çalıştırıldığında kullanılır.

  "commandLineArgs": "--contentroot=/content-root-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --contentroot=/content-root-path
  

Yol tabanı

--pathbase bağımsız değişkeni, kök olmayan göreli URL yolu ile yerel olarak çalıştırılacak bir uygulamanın uygulama temel yolunu ayarlar (<base>etiket href hazırlama ve üretim dışında / bir yola ayarlanır). Aşağıdaki örneklerde uygulamanın /relative-URL-path yol tabanı verilmiştir. Daha fazla bilgi için bkz. Uygulama temel yolu.

Önemli

etiketine sağlanan href<base> yoldan farklı olarak, bağımsız değişken değerini geçirirken sondaki eğik çizgi (/) eklemeyin --pathbase . Uygulama temel yolu etiketinde <base> olarak <base href="/CoolApp/"> sağlanıyorsa (sonunda eğik çizgi varsa), komut satırı bağımsız değişken değerini olarak --pathbase=/CoolApp geçirin (sondaki eğik çizgi yok).

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --pathbase=/relative-URL-path
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --pathbase=/relative-URL-path
  

URL’ler

bağımsız değişkeni, --urls istekleri dinlemek üzere bağlantı noktaları ve protokollerle IP adreslerini veya konak adreslerini ayarlar.

• Uygulamayı bir komut isteminde yerel olarak çalıştırırken bağımsız değişkenini geçirin. Uygulamanın dizininden şu komutu yürütebilirsiniz:

  dotnet run --urls=http://127.0.0.1:0
  

• IIS Express profilinde uygulamanın launchSettings.json dosyasına bir giriş ekleyin. Bu ayar, uygulamayı Visual Studio Hata Ayıklayıcısı ile çalıştırırken ve ile dotnet runkomut isteminden kullanılır.

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• Visual Studio'da, Özellikler> HataAyıklama>Uygulaması bağımsız değişkenlerinde bağımsız değişkenini belirtin. Visual Studio özellik sayfasında bağımsız değişkenin ayarlanması, bağımsız değişkeni dosyaya launchSettings.json ekler.

  --urls=http://127.0.0.1:0
  

Bağlayıcıyı yapılandırma

Blazor çıkış derlemelerinden gereksiz IL'yi kaldırmak için her Yayın derlemesinde Ara Dil (IL) bağlantısı gerçekleştirir. Daha fazla bilgi için bkz. Bağlayıcıyı ASP.NET Core Blazoriçin yapılandırma.

Önceki dağıtım bozulması

Genellikle dağıtımda:

• Yalnızca değiştirilen dosyalar değiştirilir ve bu da genellikle daha hızlı bir dağıtıma neden olur.
• Yeni dağıtımın parçası olmayan mevcut dosyalar, yeni dağıtım tarafından kullanılmak üzere yerinde bırakılır.

Nadir durumlarda, önceki bir dağıtımda kalan dosyalar yeni bir dağıtımı bozabilir. Mevcut dağıtımın (veya dağıtımdan önce yerel olarak yayımlanan uygulamanın) tamamen silinmesi, bozuk bir dağıtımla ilgili sorunu çözebilir. Genellikle, var olan dağıtımı bir kez silmek, DevOps derlemesi ve dağıtım işlem hattı dahil olmak üzere sorunu çözmek için yeterlidir.

DevOps derleme ve dağıtım işlem hattı kullanımda olduğunda her zaman önceki bir dağıtımı temizlemenin gerekli olduğunu belirlerseniz, bozulmanın tam nedenini giderene kadar derleme işlem hattına geçici olarak bir adım ekleyerek her yeni dağıtımın önceki dağıtımını silebilirsiniz.

Bütünlük denetimi hatalarını çözme

Bir uygulamanın başlangıç dosyalarını indirdiğinde Blazor WebAssembly , tarayıcıya yanıtlar üzerinde bütünlük denetimleri gerçekleştirmesini emreder. Blazor istemcilerde önbelleğe alınmayan DLL (.dll), WebAssembly (.wasm ) ve dosyadaki blazor.boot.json diğer dosyalar için SHA-256 karma değerlerini gönderir. Önbelleğe alınan dosyaların dosya karmaları, dosyadaki blazor.boot.json karmalarla karşılaştırılır. Eşleşen karma içeren önbelleğe alınmış dosyalar için önbelleğe Blazor alınmış dosyaları kullanır. Aksi takdirde, dosyalar sunucudan istenir. Bir dosya indirildikten sonra karma değeri bütünlük doğrulaması için yeniden denetlenecektir. İndirilen herhangi bir dosyanın bütünlük denetimi başarısız olursa tarayıcı tarafından bir hata oluşturulur.

Blazor'nin dosya bütünlüğünü yönetme algoritması:

• Uygulamanın tutarsız bir dosya kümesini yükleme riskini almamasını sağlar. Örneğin, kullanıcı uygulama dosyalarını indirme aşamasındayken web sunucunuza yeni bir dağıtım uygulanır. Tutarsız dosyalar hatalı çalışan bir uygulamaya neden olabilir.
• Kullanıcının tarayıcısının tutarsız veya geçersiz yanıtları hiçbir zaman önbelleğe almamasını sağlar. Bu, kullanıcı sayfayı el ile yenilese bile uygulamanın başlatılmasını engelleyebilir.
• Beklenen SHA-256 karmaları değişene kadar yanıtları önbelleğe alma ve sunucu tarafı değişikliklerini denetlememeyi güvenli hale getirir, böylece sonraki sayfa yüklemeleri daha az istek içerir ve daha hızlı tamamlanır.

Web sunucusu beklenen SHA-256 karmalarıyla eşleşmeyen yanıtlar döndürürse, tarayıcının geliştirici konsolunda aşağıdaki örneğe benzer bir hata görüntülenir:

'IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=' hesaplanan SHA-256 bütünlüğüne sahip 'https://myapp.example.com/_framework/MyBlazorApp.dll' kaynağının 'integrity' özniteliğinde geçerli bir özet bulunamadı. Kaynak engellendi.

Çoğu durumda, uyarı bütünlük denetimiyle ilgili bir sorun olduğunu göstermez. Bunun yerine, uyarı genellikle başka bir sorun olduğu anlamına gelir.

'Blazor WebAssemblynin önyükleme başvuru kaynağı için GitHub deposundaki dosyaya dotnet/aspnetcore bakınBoot.WebAssembly.ts.

Not

.NET başvuru kaynağına yönelik belge bağlantıları genellikle deponun varsayılan dalını yükler ve bu dal .NET'in sonraki sürümü için geçerli geliştirmeyi temsil eder. Belirli bir sürümün etiketini seçmek için Dalları veya etiketleri değiştir açılan listesini kullanın. Daha fazla bilgi için bkz. ASP.NET Core kaynak kodunun sürüm etiketini seçme (dotnet/AspNetCore.Docs #26205).

Bütünlük sorunlarını tanılama

Bir uygulama oluşturulduğunda oluşturulan bildirim, blazor.boot.json derleme çıkışının oluşturulduğu sırada önyükleme kaynaklarınızın SHA-256 karmalarını açıklar. Içindeki SHA-256 karmaları tarayıcıya teslim edilen dosyalarla blazor.boot.json eşleştiği sürece bütünlük denetimi geçer.

Bunun başarısız olmasının yaygın nedenleri şunlardır:

• Web sunucusunun yanıtı, tarayıcının istediği dosya yerine bir hatadır (örneğin, 404 - Bulunamadı veya 500 - İç Sunucu Hatası). Bu, tarayıcı tarafından bir bütünlük denetimi hatası olarak bildirilir ve yanıt hatası olarak bildirılmaz.
• Dosyaların derlenip tarayıcıya teslim edilmesi arasında dosyaların içeriği bir değişiklik yaptı. Bu durum oluşabilir:
  • Siz veya derleme araçları derleme çıktısını el ile değiştirirseniz.
  • Dağıtım işleminin bazı yönleri dosyaları değiştirdiyse. Örneğin, Git tabanlı dağıtım mekanizması kullanıyorsanız, Windows'da dosya işleyip Bunları Linux'ta kullanıma alırsanız Git'in Windows stili satır sonlarını unix stili satır sonlarına saydam bir şekilde dönüştürdüğünü unutmayın. Dosya satırı sonlarının değiştirilmesi SHA-256 karmalarını değiştirir. Bu sorundan kaçınmak için derleme yapıtlarını dosya olarak binary kabul etmeyi göz önünde bulundurun.gitattributes.
  • Web sunucusu, dosya içeriklerini sunmanın bir parçası olarak değiştirir. Örneğin, bazı içerik dağıtım ağları (CDN'ler) HTML'yi otomatik olarak küçültmeye çalışır ve böylece bunu değiştirir. Bu tür özellikleri devre dışı bırakmanız gerekebilir.
• Dosya blazor.boot.json düzgün yüklenemedi veya istemcide yanlış önbelleğe alınmış. Yaygın nedenler şunlardan birini içerir:
  • Yanlış yapılandırılmış veya hatalı çalışan özel geliştirici kodu.
  • Bir veya daha fazla yanlış yapılandırılmış ara önbelleğe alma katmanı.

Sizin durumunuzda bunlardan hangisinin geçerli olduğunu tanılamak için:

1. Hata iletisini okuyarak hangi dosyanın hatayı tetiklediğine dikkat edin.
2. Tarayıcınızın geliştirici araçlarını açın ve Ağ sekmesine bakın. Gerekirse, istek ve yanıtların listesini görmek için sayfayı yeniden yükleyin. Bu listede hatayı tetikleyen dosyayı bulun.
3. Yanıttaki HTTP durum kodunu denetleyin. Sunucu 200 - Tamam (veya başka bir 2xx durum kodu) dışında bir şey döndürürse, tanılamanız gereken bir sunucu tarafı sorununuz vardır. Örneğin, durum kodu 403 bir yetkilendirme sorunu olduğu, durum kodu 500 ise sunucunun belirtilmemiş bir şekilde başarısız olduğu anlamına gelir. Uygulamayı tanılamak ve düzeltmek için sunucu tarafı günlüklerine başvurun.
4. Kaynak için durum kodu 200 - Tamam ise, tarayıcının geliştirici araçlarında yanıt içeriğine bakın ve içeriğin beklenen verilerle eşleşip eşleşmediğini denetleyin. Örneğin, isteklerin diğer dosyalar için bile verilerinizi index.html döndürmesi için yönlendirmeyi yanlış yapılandırmak yaygın bir sorundur. İsteklere verilen .wasm yanıtların WebAssembly ikilileri olduğundan ve isteklere verilen .dll yanıtların .NET derleme ikili dosyaları olduğundan emin olun. Aksi takdirde, tanılamanız gereken bir sunucu tarafı yönlendirme sorununuz vardır.
5. Bütünlük sorunlarını giderme PowerShell betiğiyle uygulamanın yayımlanan ve dağıtılan çıkışını doğrulamayı deneyin.

Sunucunun makul ölçüde doğru veriler döndürdüğünü onaylarsanız, dosyanın derlemesi ve teslimi arasında içeriği değiştiren başka bir şey olmalıdır. Bunu araştırmak için:

• Derleme araç zincirini ve dağıtım mekanizmasını, dosyalar oluşturulduktan sonra dosyaları değiştiriyor olma ihtimaline karşı inceleyin. Bunun bir örneği, Git'in daha önce açıklandığı gibi dosya satırı sonlarını dönüştürmesidir.
• Yanıtları dinamik olarak değiştirmek için ayarlanmış olma ihtimaline karşı web sunucusunu veya CDN yapılandırmasını inceleyin (örneğin, HTML'yi küçültmeye çalışma). Web sunucusunun HTTP sıkıştırması uygulaması normaldir (örneğin, döndüren content-encoding: br veya content-encoding: gzip), çünkü bu durum sıkıştırmadan sonra sonucu etkilemez. Ancak, web sunucusunun sıkıştırılmamış verileri değiştirmesi uygun değildir .

Bütünlük Sorunlarını Giderme PowerShell betiği

integrity.ps1 Yayımlanmış ve dağıtılmış Blazor bir uygulamayı doğrulamak için PowerShell betiğini kullanın. Betik, powershell core 7 veya üzeri için uygulamanın çerçevenin tanımlayabildiği bütünlük sorunları Blazor olduğunda başlangıç noktası olarak sağlanır. PowerShell'in 7.2.0 sürümünden sonraki bir sürümde çalışıyor olması da dahil olmak üzere, uygulamalarınız için betiğin özelleştirilmesi gerekebilir.

Betik, bütünlük karmaları içeren farklı bildirimlerdeki publish sorunları algılamak için klasördeki ve dağıtılan uygulamadan indirilen dosyaları denetler. Bu denetimler en yaygın sorunları algılamalıdır:

• Yayımlanan çıktıdaki bir dosyayı fark etmeden değiştirdiniz.
• Uygulama dağıtım hedefine doğru dağıtılmadı veya dağıtım hedefinin ortamında bir değişiklik oldu.
• Dağıtılan uygulama ile uygulamayı yayımlama çıktısı arasında farklar vardır.

Betiği bir PowerShell komut kabuğunda aşağıdaki komutla çağırın:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

Aşağıdaki örnekte, betik konumunda yerel olarak çalışan bir uygulamada https://localhost:5001/yürütülür:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Yer tutucu:

• {BASE URL}: Dağıtılan uygulamanın URL'si. Sondaki eğik çizgi (/) gereklidir.
• {PUBLISH OUTPUT FOLDER}: Uygulamanın publish dağıtım için yayımlandığı klasörün veya konumun yolu.

Not

GitHub deposunu dotnet/AspNetCore.Docs kopyalarken betik Bitdefenderintegrity.ps1 veya sistemde bulunan başka bir virüs tarayıcısı tarafından karantinaya alınmış olabilir. Dosya genellikle virüs tarayıcısının buluşsal tarama teknolojisi tarafından tuzağa düşürülür ve bu teknoloji yalnızca kötü amaçlı yazılımların varlığını gösterebilecek dosyalarda desenleri arar. Virüs tarayıcısının dosyayı ayırmasını önlemek için, depoyu kopyalamadan önce virüs tarayıcısına bir özel durum ekleyin. Aşağıdaki örnek, bir Windows sistemindeki betiğin tipik bir yoludur. Yolu diğer sistemler için gerektiği gibi ayarlayın. Yer tutucu {USER} , kullanıcının yol kesimidir.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

Uyarı: Virüs tarayıcısı özel durumlarının oluşturulması tehlikelidir ve yalnızca dosyanın güvenli olduğundan emin olduğunuzda gerçekleştirilmelidir.

Bir dosyanın sağlama toplamını geçerli bir sağlama toplamı değeriyle karşılaştırmak, dosya güvenliğini garanti etmez, ancak dosyayı sağlama toplamı değerini koruyacak şekilde değiştirmek kötü amaçlı kullanıcılar için önemsiz değildir. Bu nedenle sağlama toplamları genel bir güvenlik yaklaşımı olarak yararlıdır. Yerel integrity.ps1 dosyanın sağlama toplamını aşağıdaki değerlerden biriyle karşılaştırın:

• SHA256: 32c24cb667d79a701135cb72f6bae490d81703323f61b8af2c7e5e5dc0f0c2bb
• MD5: 9cee7d7ec86ee809a329b5406fbf21a8

Aşağıdaki komutla Windows işletim sisteminde dosyanın sağlama toplamını alın. Yer tutucunun yolunu ve dosya adını {PATH AND FILE NAME} belirtin ve yer tutucu SHA256 için {SHA512|MD5} üretilmesi gereken sağlama toplamı türünü (veya MD5) belirtin:

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Sağlama toplamı doğrulamasının ortamınızda yeterince güvenli olmamasıyla ilgili bir endişeniz varsa, rehberlik için kuruluşunuzun güvenlik liderliğine başvurun.

Daha fazla bilgi için bkz. Kötü amaçlı yazılım & diğer tehditlerini anlama.

PWA olmayan uygulamalar için bütünlük denetimini devre dışı bırakma

Çoğu durumda bütünlük denetimini devre dışı bırakma. Bütünlük denetiminin devre dışı bırakılması, beklenmeyen yanıtlara neden olan ve daha önce listelenen avantajların kaybedilmesine neden olan temel sorunu çözmez.

Tutarlı yanıtlar döndürmek için web sunucusunun bağımlı olmadığı durumlar olabilir ve temel alınan sorun çözülene kadar bütünlük denetimlerini geçici olarak devre dışı bırakmaktan başka seçeneğiniz olmayabilir.

Bütünlük denetimlerini devre dışı bırakmak için, uygulamanın proje dosyasındaki (Blazor WebAssembly.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResourcesayrıca , .wasmve diğer dosyaları SHA-256 karmalarına göre önbelleğe alma .dllişleminin varsayılan davranışını devre dışı bırakır Blazorçünkü özelliği SHA-256 karmalarının doğruluğu için güvenilmediğini gösterir. Bu ayarda bile, tarayıcının normal HTTP önbelleği bu dosyaları önbelleğe almaya devam edebilir, ancak bunun olup olmadığı web sunucusu yapılandırmanıza ve cache-control hizmet veren üst bilgilere bağlıdır.

Not

özelliği Aşamalı BlazorCacheBootResourcesWeb Uygulamaları (PWA) için bütünlük denetimlerini devre dışı bırakmaz. PWA'larla ilgili yönergeler için PWA'lar için bütünlük denetimini devre dışı bırakma bölümüne bakın.

Bütünlük denetimini devre dışı bırakmanın gerekli olduğu senaryoların kapsamlı bir listesini sağlayamıyoruz. Sunucular, isteği çerçeve kapsamı Blazor dışında rastgele yollarla yanıtlayabilir. Çerçeve, uygulamanın sağlayabilecekleri bütünlük garantisini kaybetme karşılığında uygulamayı çalıştırılabilir hale getirme ayarını sağlarBlazorCacheBootResources. Yine, özellikle üretim dağıtımları için bütünlük denetimini devre dışı bırakmanızı önermiyoruz. Geliştiriciler, bütünlük denetiminin başarısız olmasına neden olan temel bütünlük sorununu çözmeye çalışmalıdır.

Bütünlük sorunlarına neden olabilecek birkaç genel durum şunlardır:

• Bütünlüğün denetlenemez olduğu HTTP'de çalışıyor.
• Dağıtım işleminiz herhangi bir şekilde yayımlandıktan sonra dosyaları değiştirirse.
• Konağınız dosyaları herhangi bir şekilde değiştirirse.

PWA'lar için bütünlük denetimini devre dışı bırakma

Blazor'nin Aşamalı Web Uygulaması (PWA) şablonu, uygulama dosyalarını çevrimdışı kullanım için getirmek ve depolamaktan sorumlu önerilen service-worker.published.js bir dosya içeriyor. Bu, normal uygulama başlatma mekanizmasından ayrı bir işlemdir ve kendi ayrı bütünlük denetimi mantığına sahiptir.

Dosyanın içinde service-worker.published.js aşağıdaki satır bulunur:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Bütünlük denetimini devre dışı bırakmak için, satırı aşağıdaki şekilde değiştirerek parametresini kaldırın integrity :

.map(asset => new Request(asset.url));

Yine bütünlük denetimini devre dışı bırakmak, bütünlük denetimi tarafından sunulan güvenlik garantilerini kaybetmeniz anlamına gelir. Örneğin, yeni bir sürümü dağıttığınız anda kullanıcının tarayıcısı uygulamayı önbelleğe alırsa, eski dağıtımdaki bazı dosyaları ve yeni dağıtımdaki bazı dosyaları önbelleğe alma riski vardır. Böyle bir durumda, siz daha fazla güncelleştirme dağıtana kadar uygulama bozuk durumda takılır.