Geliştirme ile Üretim Arasındaki Yaygın Yapılandırma Farklılıkları (C#)

  • Makale

tarafından Scott Mitchell

PDF’yi İndir

Önceki öğreticilerde, geliştirme ortamındaki tüm ilgili dosyaları üretim ortamına kopyalayarak web sitemizi dağıtmıştık. Ancak, ortamlar arasında yapılandırma farklılıkları olması nadir değildir ve bu da her ortamın benzersiz bir Web.config dosyasına sahip olmasını gerektirir. Bu öğreticide tipik yapılandırma farklılıkları incelenerek ayrı yapılandırma bilgilerinin korunmasına yönelik stratejiler ele alınıyor.

Giriş

Son iki öğreticide basit bir web uygulaması dağıtma adımlarını izleyin. Sitenizi FTP İstemcisi Kullanarak Dağıtma öğreticisi, geliştirme ortamından üretime kadar gerekli dosyaları kopyalamak için tek başına ftp istemcisinin nasıl kullanılacağını gösterdi. Önceki öğretici olan Sitenizi Visual Studio Kullanarak Dağıtma öğreticisinde, Visual Studio'nun Web Sitesini Kopyala aracı ve Yayımla seçeneği kullanılarak dağıtıma bakılırdı. Her iki öğreticide de üretim ortamındaki her dosya geliştirme ortamındaki bir dosyanın kopyasıydı. Ancak, üretim ortamındaki yapılandırma dosyalarının geliştirme ortamındakilerden farklı olması yaygın değildir. Web uygulamasının yapılandırması dosyada Web.config depolanır ve genellikle veritabanı, web ve e-posta sunucuları gibi dış kaynaklar hakkındaki bilgileri içerir. Ayrıca, işlenmeyen bir özel durum oluştuğunda gerçekleştirilecek eylem seyri gibi belirli durumlarda uygulamanın davranışını da açıklar.

Bir web uygulamasını dağıtırken, doğru yapılandırma bilgilerinin üretim ortamında olması önemlidir. Çoğu Web.config durumda geliştirme ortamındaki dosya olduğu gibi üretim ortamına kopyalanamaz. Bunun yerine, özelleştirilmiş bir sürümünün Web.config üretime yüklenmesi gerekir. Bu öğretici, daha yaygın yapılandırma farklarından bazılarını kısaca inceler; Ayrıca, ortamlar arasında farklı yapılandırma bilgilerini korumaya yönelik bazı teknikleri de özetler.

Geliştirme ve Üretim Ortamları Arasındaki Tipik Yapılandırma Farklılıkları

Dosya, Web.config ASP.NET bir uygulama için çeşitli yapılandırma bilgileri içerir. Bu yapılandırma bilgilerinden bazıları ortamdan bağımsız olarak aynıdır. Örneğin, dosyanın <authentication> ve öğelerinin içinde yazılmış Web.config kimlik doğrulama ayarları ve <authorization> URL yetkilendirme kuralları genellikle ortamdan bağımsız olarak aynıdır. Ancak dış kaynaklar hakkındaki bilgiler gibi diğer yapılandırma bilgileri genellikle ortama bağlı olarak farklılık gösterir.

Veritabanı bağlantı dizeleri, ortama göre farklılık gösteren yapılandırma bilgilerinin temel bir örneğidir. Bir web uygulaması bir veritabanı sunucusuyla iletişim kurduğunda, önce bir bağlantı kurması gerekir ve bu bir bağlantı dizesi aracılığıyla oluşturulduğunda. Veritabanı bağlantı dizesi doğrudan web sayfalarında veya veritabanına bağlanan kodda sabit kod oluşturmak mümkün olsa da, bağlantı dizesi bilgilerin tek bir merkezi konumda olması için öğesini yerleştirmek Web.config<connectionStrings> en iyisidir. Genellikle geliştirme sırasında üretimde kullanılandan farklı bir veritabanı kullanılır; sonuç olarak, bağlantı dizesi bilgileri her ortam için benzersiz olmalıdır.

Not

Gelecekteki öğreticilerde veri temelli uygulamaların dağıtılması incelenir. Bu noktada veritabanı bağlantı dizelerinin yapılandırma dosyasında nasıl depolandığına ilişkin ayrıntıları inceleyeceğiz.

Geliştirme ve üretim ortamlarının hedeflenen davranışı önemli ölçüde farklılık gösterir. Geliştirme ortamındaki bir web uygulaması küçük bir geliştirici grubu tarafından oluşturuluyor, test ediliyor ve hata ayıklanıyor. Üretim ortamında aynı uygulama birçok farklı eşzamanlı kullanıcı tarafından ziyaret ediliyor. ASP.NET, geliştiricilerin bir uygulamayı test etmelerine ve hata ayıklamalarına yardımcı olan bir dizi özellik içerir, ancak bu özelliklerin üretim ortamında performans ve güvenlik nedenleriyle devre dışı bırakılması gerekir. Şimdi bu tür birkaç yapılandırma ayarına göz atalım.

Performansı Etkileyen Yapılandırma Ayarları

bir ASP.NET sayfası ilk kez ziyaret edildiğinde (veya değiştirildikten sonra ilk kez), bildirim temelli işaretlemesinin bir sınıfa dönüştürülmesi ve bu sınıfın derlenmiş olması gerekir. Web uygulaması otomatik derleme kullanıyorsa, sayfanın arkadaki kod sınıfının da derlenmesi gerekir. Dosyanın <compilation> öğesi aracılığıyla Web.config çeşitli derleme seçenekleri yapılandırabilirsiniz.

debug özniteliği, öğesindeki en önemli özniteliklerden <compilation> biridir. debug Öznitelik "true" olarak ayarlanırsa derlenen derlemeler, Visual Studio'da bir uygulamada hata ayıklarken gereken hata ayıklama simgelerini içerir. Ancak hata ayıklama sembolleri derlemenin boyutunu artırır ve kodu çalıştırırken ek bellek gereksinimleri uygular. Ayrıca, debug özniteliği "true" olarak ayarlandığında tarafından WebResource.axd döndürülen herhangi bir içerik önbelleğe alınmaz; başka bir deyişle, bir kullanıcı bir sayfayı her ziyaret ettiğinde tarafından WebResource.axddöndürülen statik içeriği yeniden indirmesi gerekir.

Not

WebResource.axd , sunucu denetimlerinin betik dosyaları, görüntüler, CSS dosyaları ve diğer içerik gibi ekli kaynakları almak için kullandığı ASP.NET 2.0'da kullanıma sunulan yerleşik bir HTTP İşleyicisidir. Nasıl çalıştığı ve özel sunucu denetimlerinizden eklenmiş kaynaklara erişmek için bunu nasıl kullanabileceğiniz hakkında daha fazla bilgi WebResource.axd için bkz. Kullanarak WebResource.axdBir URL Aracılığıyla Katıştırılmış Kaynaklara Erişme.

Öğesinin <compilation>debug özniteliği genellikle geliştirme ortamında "true" olarak ayarlanır. Aslında, bir web uygulamasında hata ayıklamak için bu özniteliğin "true" olarak ayarlanması gerekir; Visual Studio'dan bir ASP.NET uygulamasında hata ayıklamaya çalışırsanız ve debug özniteliği "false" olarak ayarlanırsa, Visual Studio özniteliği "true" olarak ayarlanana kadar debug uygulamanın hata ayıklanamayacağını açıklayan bir ileti görüntüler ve bu değişikliği sizin için yapmayı teklif eder.

Performans üzerindeki etkisi nedeniyle bir üretim ortamında özniteliğini hiçbir zamandebug "true" olarak ayarlamamalısınız. Bu konu hakkında daha ayrıntılı bir tartışma için Scott Guthrie'ninÜretim ASP.NET Uygulamaları debug="true" Etkin Olarak Çalıştırma adlı blog gönderisine bakın.

Özel Hatalar ve İzleme

bir ASP.NET uygulamasında işlenmeyen bir özel durum oluştuğunda, üç şeyden birinin gerçekleştiği çalışma zamanına kadar kabarır:

  • Genel bir çalışma zamanı hata iletisi görüntülenir. Bu sayfa kullanıcıya çalışma zamanı hatası olduğunu bildirir, ancak hata hakkında herhangi bir ayrıntı sağlamaz.
  • Yeni oluşan özel durumla ilgili bilgileri içeren bir özel durum ayrıntıları iletisi görüntülenir.
  • Oluşturduğunuz ve istediğiniz iletiyi görüntüleyen bir ASP.NET sayfası olan özel bir hata sayfası görüntülenir.

İşlenmeyen bir özel durum karşısında ne olacağı dosyanın <customErrors> bölümüne bağlıdırWeb.config.

Bir uygulamayı geliştirirken ve test ederken, tarayıcıda herhangi bir özel durumun ayrıntılarını görmenize yardımcı olur. Ancak, üretimdeki bir uygulamada özel durum ayrıntılarının gösterilmesi olası bir güvenlik riskidir. Ayrıca, bu yanılıcı ve web sitenizin profesyonel görünmemesini sağlar. İdeal olarak, işlenmeyen bir özel durum olması durumunda geliştirme ortamındaki bir web uygulaması özel durumun ayrıntılarını gösterirken üretimdeki aynı uygulama özel bir hata sayfası gösterir.

Not

Varsayılan <customErrors> bölüm ayarı, yalnızca sayfa localhost üzerinden ziyaret edildiğinde özel durum ayrıntıları iletisini gösterir ve aksi takdirde genel çalışma zamanı hata sayfasını gösterir. Bu ideal değildir, ancak varsayılan davranışın yerel olmayan ziyaretçilere özel durum ayrıntılarını göstermediğini bilmek önemlidir. Gelecekteki bir öğretici, bölümü daha ayrıntılı olarak inceler <customErrors> ve üretimde bir hata oluştuğunda özel bir hata sayfasının nasıl gösterileceğini gösterir.

Geliştirme sırasında yararlı olan bir diğer ASP.NET özelliği de izlemedir. İzleme etkinse, gelen her istekle ilgili bilgileri kaydeder ve en son istek ayrıntılarını görüntülemek için özel bir web sayfası Trace.axdsağlar. içindeki öğesi Web.configaracılığıyla <trace> izlemeyi açabilir ve yapılandırabilirsiniz.

İzlemeyi etkinleştirirseniz üretimde devre dışı bırakıldıkdan emin olun. İzleme bilgileri tanımlama bilgileri, oturum verileri ve diğer hassas olabilecek bilgileri içerdiğinden, üretimde izlemeyi devre dışı bırakmak önemlidir. İyi haber, varsayılan olarak izlemenin devre dışı bırakılması ve dosyaya Trace.axd yalnızca localhost üzerinden erişilebilir olmasıdır. Geliştirme aşamasında bu varsayılan ayarları değiştirirseniz, bunların üretimde kapatıldığından emin olun.

Ayrı Yapılandırma Bilgilerini Koruma Teknikleri

Geliştirme ve üretim ortamlarında farklı yapılandırma ayarlarına sahip olmak, dağıtım sürecini karmaşıklaştırır. Önceki iki öğreticide dağıtım işlemi, tüm gerekli dosyaların geliştirme aşamasından üretim ortamına kopyalanmasını içeriyor ancak bu yaklaşım yalnızca yapılandırma bilgileri her iki ortamda da aynıysa çalışıyor. Bir uygulamayı farklı yapılandırma bilgileriyle dağıtmak için çeşitli teknikler vardır. Barındırılan web uygulamaları için bu seçeneklerden bazılarını kataloglayalım.

Üretim Ortamı Yapılandırma Dosyasını El ile Dağıtma

En basit yaklaşım dosyanın iki sürümünü Web.config korumaktır: biri geliştirme ortamı için, diğeri üretim ortamı için. Bir sitenin üretime dağıtılması için, dosya dışındaki tüm dosyaların geliştirme ortamındaki üretim sunucusuna Web.config kopyalanması gerekir. Bunun yerine, üretim ortamına özgü Web.config dosya üretime kopyalanır.

Bu yaklaşım çok karmaşık değildir, ancak yapılandırma bilgileri seyrek değiştiği için uygulanması kolaydır. Tek bir web sunucusunda barındırılan ve yapılandırma bilgileri seyrek değiştirilen küçük bir geliştirme ekibine sahip uygulamalar için en iyi sonucu verir. Tek başına FTP istemcisi kullanarak uygulama dosyalarını el ile dağıtırken en uygun olan bu durumdur. Visual Studio'nun Web Sitesini Kopyala aracını veya Yayımla seçeneğini kullanırken, dağıtmadan önce dağıtıma özgü dosyayı üretime özgü Web.config dosyayla değiştirmeniz ve dağıtım tamamlandıktan sonra yeniden değiştirmeniz gerekir.

Derleme veya Dağıtım İşlemi Sırasında Yapılandırmayı Değiştirme

Tartışmalarda şimdilik geçici bir derleme ve dağıtım süreci olduğu varsayılmıştır. Daha büyük yazılım projelerinin çoğunda açık kaynak, evde yetiştirilen veya üçüncü taraf araçlardan yararlanan daha resmi süreçler vardır. Bu tür projeler için büyük olasılıkla derleme veya dağıtım işlemini üretime gönderilmeden önce yapılandırma bilgilerini uygun şekilde değiştirecek şekilde özelleştirebilirsiniz. Web uygulamanızı MSBuild, NAnt veya başka bir derleme aracı kullanarak derliyorsanız, büyük olasılıkla dosyayı üretime özgü ayarları içerecek şekilde değiştirmek Web.config için bir derleme adımı ekleyebilirsiniz. Veya dağıtım iş akışınız program aracılığıyla kaynak denetim sunucusuna bağlanabilir ve uygun Web.config dosyayı alabilir.

Üretime uygun yapılandırma bilgilerini almak için gerçek yaklaşım, araçlarınıza ve iş akışınıza göre büyük ölçüde farklılık gösterir. Bu nedenle, bu konuyu daha fazla araştırmayacağız. MSBuild veya NAnt gibi popüler bir derleme aracı kullanıyorsanız, bir web araması aracılığıyla bu araçlara özgü dağıtım makalelerini ve öğreticilerini bulabilirsiniz.

Web Dağıtım Projesi Add-In Aracılığıyla Yapılandırma Farklarını Yönetme

2006'da Microsoft, Visual Studio 2005 için Web Geliştirme Projesi Add-In yayımladı. Visual Studio 2008 için bir Add-In 2008'de yayımlandı. Bu Add-In, ASP.NET geliştiricilerin web uygulaması projesiyle birlikte web uygulamasını açıkça derleyen ve dosyaları yerel bir çıkış dizinine dağıtmak üzere kopyalayan ayrı bir Web Dağıtım Projesi oluşturmasına olanak tanır. Web Uygulaması Projesi arka planda MSBuild kullanır.

Varsayılan olarak, geliştirme ortamının Web.config dosyası çıkış dizinine kopyalanır, ancak Web Dağıtım Projesi'ni

bu dizine aşağıdaki yollarla kopyalanan yapılandırma bilgileri:

  • Değiştirilecek Web.config bölümü ve değiştirme metnini içeren bir XML dosyasını belirttiğiniz dosya bölümü değiştirme yoluyla.
  • Dış yapılandırma kaynak dosyasının yolunu sağlayarak. Bu seçenek seçiliyken, Web Dağıtım Projesi belirli Web.config bir dosyayı çıkış dizinine kopyalar (geliştirme ortamında kullanılan dosya yerine Web.config ).
  • Web Dağıtım Projesi tarafından kullanılan MSBuild dosyasına özel kurallar ekleyerek.

Web uygulamasını dağıtmak için Web Dağıtım Projesi'ni oluşturun ve sonra projenin çıkış klasöründeki dosyaları üretim ortamına kopyalayın.

Web Dağıtım Projesi'ni kullanma hakkında daha fazla bilgi edinmek için MSDN Dergisi'nin Nisan 2007 sayısında yer alan bu Web Dağıtım Projeleri makalesine göz atın veya bu öğreticinin sonundaki Daha Fazla Okuma bölümündeki bağlantılara bakın.

Not

Web Dağıtım Projesi Visual Studio Add-In olarak uygulandığından ve Visual Studio Express Sürümleri (Visual Web Geliştiricisi dahil) Eklentileri desteklemediğinden, Web Dağıtım Projesi'ni Visual Web Geliştiricisi ile kullanamazsınız.

Özet

Geliştirme aşamasındaki bir web uygulamasının dış kaynakları ve davranışı genellikle aynı uygulamanın üretim aşamasında olduğundan farklıdır. Örneğin, veritabanı bağlantı dizeleri, derleme seçenekleri ve işlenmeyen bir özel durum oluştuğunda oluşan davranış ortamlar arasında yaygın olarak farklılık gösterir. Dağıtım işlemi bu farklılıkları karşılamalıdır. Bu öğreticide ele aldığımız gibi en basit yaklaşım, alternatif bir yapılandırma dosyasını üretim ortamına el ile kopyalamaktır. Web Dağıtım Projesi Add-In kullanırken veya bu tür özelleştirmelere uyum sağlayabilen daha resmi bir derleme veya dağıtım işlemiyle daha zarif çözümler mümkündür.

Mutlu Programlama!

Daha Fazla Bilgi

Bu öğreticide ele alınan konular hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

ÖncekiSonraki