Visual Studio'da geliştiriciye özel app.config / web.config dosyaları


94

Yapılandırma dosyalarında belirli ayarları sakladığımız birkaç .NET projemiz var.

Artık her geliştiricinin biraz farklı olan kendi yapılandırma dosyaları olacak (yerel veritabanlarına bağlanmak için farklı bağlantı dizeleri, farklı WCF uç noktaları vb.)

Şu anda app / web.config dosyalarını kontrol etme ve ihtiyaçlarımıza uyacak şekilde değiştirme eğilimindeyiz.

En son sürümü alırken beri zaman birinden zaman pek çok sorunun bu potansiyel müşteriler kendi ayarlarından veya gevşek özel yapılandırmasında kontrol edecektir TFS .

Böyle durumlarla nasıl başa çıkarsınız? Yoksa bu problemin yok mu?


10
Bu görsel stüdyo geliştiricileri için yaygın bir sorundur ve geliştiricilerin kullandığı araçları doğrudan içerdiğinden, yeniden açmayı oyluyorum. (dolayısıyla oylar)
Christian Gollhardt

Kabul edildi, ekibimiz büyüdükçe ve çeşitli çözme girişimleri tatmin edici olmadığından bu kalıcı bir sorundur.
DiskJunky

Yanıtlar:


66

Bu sayfadaki mevcut cevapların birkaçını birleştiren ve ayrıca Scott Hanselman'ın bu önerisinden yararlanan bir sistem kullanıyoruz .

Kısacası, yaptığımız şey ortak bir app.config / web.config'e sahip olmak ve buradaki diğer yanıtların önerdiği gibi belirli ayarların çoğunu tek tek dosyalarda yapmaktı. örneğin SMTP ayarlarımız için app.config şunları içerir:

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

Bu dosya olan kaynak denetiminde. Ancak, bunun gibi tek tek dosyalar:

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

Yine de hikayenin bittiği yer burası değil. Peki ya yeni geliştiriciler veya yeni bir kaynak kurulumu? Yapılandırmanın büyük kısmı artık kaynak denetiminde değildir ve ihtiyaç duydukları tüm .config dosyalarını manuel olarak oluşturmak çok zordur. En azından kutudan çıkar çıkmaz derleyebilecek bir kaynağa sahip olmayı tercih ederim.

Bu nedenle, .config dosyalarının bir sürümünü .config.default dosyaları olarak adlandırılan kaynak denetiminde tutuyoruz . Bu nedenle taze bir kaynak ağacı şuna benzer:

alternatif metin

Yine de geliştiricinin herhangi bir faydası yoktur, çünkü Visual Studio için bunlar anlamsız metin dosyalarıdır. Bu nedenle toplu iş dosyası, copy_default_config.bat.config.default dosyalarından bir başlangıç ​​.config dosyaları kümesi oluşturmaya özen gösterir:

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

Komut dosyası güvenli bir şekilde yeniden çalıştırılabilir, çünkü .config dosyalarına zaten sahip olan geliştiriciler bunların üzerine yazılmaz. Bu nedenle, bu toplu iş dosyasını bir ön oluşturma olayı olarak çalıştırabiliriz. .Default dosyalarındaki değerler yeni bir kurulum için tam olarak doğru olmayabilir, ancak bunlar makul bir başlangıç ​​noktasıdır.

Nihayetinde, her geliştiricinin elde ettiği şey şuna benzer bir yapılandırma dosyası klasörüdür:

alternatif metin

Biraz kıvrımlı görünebilir, ancak kesinlikle geliştiricilerin birbirlerinin ayak parmaklarına basması güçlüğüne tercih edilir.


Neden depoda doğrudan main .config değil de bireysel olanlar olmasın?
graffic

6
Ne acı, bunun için daha iyi bir çözüme ihtiyacımız var. Benzer bir yöntem kurdum ve bu kadar kırılgan olmasından ve hala yeni geliştiricilere açıklamaya ihtiyaç duymasından bıktım.
jpierson

@Gavin, özetlediğiniz yarasa dosyasını çalıştırmaya çalışırsam bir hata alıyorum: '∩╗┐ @ echo' dahili veya harici bir komut, çalıştırılabilir program veya toplu iş dosyası olarak tanınmıyor.
Austin

2
@Austin, '@echo' dan önce yazdırılamayan bazı çöpleriniz var gibi görünüyor, bunun bir kısmı Unicode bayt sırası işareti olabilir mi? Kopyalama / yapıştırma işleminde bir şeyler ters gitmiş olabilir veya toplu iş dosyası, düzgün okunamayan bir kodlamayla kaydedilmiştir.
Gavin

21

Web.config dosyanızda diğer dosyalardan kaynak kullanın

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

Web.config'i sürüm denetiminde tutun ve bunu ConnectionStrings.config için yapmayın. Artık tüm geliştiricilerin bağlantı dizesi için bir dosyası var.

Bunu yerel bağımlı tüm ayarlar için yapabilirsiniz.


1
Bu benim için iyi çalıştı. Ayrıca bkz .: davidgiard.com/2012/05/25/… ConnectionStrings.config dosyası, uygulama veya web yapılandırması ile aynı klasörde olmalıdır. Ayrıca, çıktı almak için özelliklerini 'daha yeniyse kopyala' olarak değiştirmelisiniz. Ve ConnectionStrings.config dosyası, açma ve kapama öğeleriyle tam bölüme ihtiyaç duyar. Ayrıca, her biri kullanıcıya özel olacak şekilde dosyayı yok sayacak şekilde sürüm kontrolünü ayarlamanız gerekir.
Jeffrey Roughgarden

1
Ayarları birleştirmem gerektiğinden <appSettings file = ".."> seçeneğini kullandım
Spikolynn

1
@JeffreyRoughgarden ConnectionStrings.config dosyasını Solution Explorer'a eklerseniz, dosyanın filesysterm'de bulunması gerekmez mi? Ve eğer öyleyse, bu, onu kaynak kontrolüne koyduğunuz anlamına gelir. Uzaklaşmaya çalıştığımız ilk sorun da bu.
Jez

20

Burada web.config dosyaları ve Visual Studio 2010 için bir çözüm:

1) Aşağıdaki AfterBuildgibi bir Hedef eklemek için web uygulamanızı .csproj dosyanızı manuel olarak düzenleyin :

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

Bu hedef, oturum açmış olan mevcut geliştiriciye karşılık gelen Web.config dosyasını - dolayısıyla $(USERNAME)değişken -, 1) 'de oluşturulan karşılık gelen dosya ile dönüştürecektir. Yerel Web.config'i yalnızca içerik her derlemede değiştiyse (yeniden başlatmayı önlemek için), yerel Web.config kaynak kontrollü olsa bile, bu nedenle OverwriteReadOnlyFilesTrue olarak ayarlanmıştır. Aslında bu nokta tartışılabilir.

2) Web.[developer windows login].configProjedeki her geliştirici için bir dosya oluşturun . (örneğin aşağıdaki ekran görüntülerinde smo ve smo2 adında iki geliştiricim var):

görüntü açıklamasını buraya girin

Bu dosyalar (geliştirici başına 1) kaynak kontrollü olabilir / olmalıdır. Ana Web.config dosyasına bağımlı olarak işaretlenmemelidir çünkü onları tek tek kontrol edebilmek istiyoruz.

Bu dosyanın her biri, ana Web.Config dosyasına uygulanacak bir dönüşümü temsil eder. Dönüşüm sözdizimi burada açıklanmıştır: Web Uygulaması Proje Dağıtımı için Web.config Dönüşüm Sözdizimi . Kutudan çıkar çıkmaz gelen bu harika Xml dosya dönüştürme görevini Visual Studio ile yeniden kullanıyoruz. Bu görevin amacı , tüm dosyanın üzerine yazmak yerine Xml öğelerini ve özniteliklerini birleştirmektir .

Örneğin web.[dev login].config, Web.config dosyasının geri kalanından bağımsız olarak 'MyDB' adlı bir bağlantı dizesini değiştiren bir örnek aşağıda verilmiştir:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

Şimdi, bu çözüm mükemmel değil çünkü:

  • geliştiriciler oluşturduktan sonra yerel olarak kaynak denetim sistemindekinden farklı bir Web.Config'e sahip olabilir
  • kaynak kontrol sisteminden yeni bir Web.Config alırken yerel yazmayı zorlamaları gerekebilir
  • geliştiriciler ana web.config dosyasını kontrol etmemelidir. Birkaç kişiye ayrılmalıdır.

Ancak en azından, benzersiz bir ana web.config ve her geliştirici için bir dönüşüm dosyası tutmanız gerekir.

App.config (web değil) dosyaları için benzer bir yaklaşım benimsenebilirdi, ancak daha fazla detaylandırmadım.


Web.config'imi Web.base.config olarak yeniden adlandırdım, yeni bir Web.config dosyası oluşturdum, ardından 1. adımda <Copy SourceFiles = "web.config"> yerine <Copy SourceFiles = "web.base.config" olarak değiştirdim. Bunu yaparak, kaynak kontrolünde göz ardı edilebilecek yerel bir web.config alabilirim.
S. Baggy

Bu hala ideal değil ama ben diğer çözüme tercih ederim
JMK

Eğer bunun bir kullanmak mümkündür sizce web.default.configne zaman web.$(USERNAME).configyok? Bu harika cevap için teşekkür ederim.
Christian Gollhardt

2

Ortamlar arasında web.config'de farklılıklar olmasını önlemek için machine.config kullanıyoruz.


14
machine.config
twarz01

0

Dosyayı görmezden gelmeye ne dersiniz, böylece asla teslim edilmez? Benzer bir sorunla karşılaştım ve Subversion'daki yok sayma listesine web.config ekledim.

TFS'de biraz daha zor olsa da, nasıl yapılacağına dair bu yazıya bakın .


0

Başa çıkmanın bir yolu, belirteçli bir sisteme sahip olmak ve değerleri değiştirmek için bir komisyon komut dosyası kullanmaktır.

Daha temel bir yöntem, web.config'inizdeki (bağlantılara benzer) tüm AppSettings için bir AppSettings.config dosyasına bir bağlantıya sahip olmak olabilir.

<appSettings configSource="_configs/AppSettings.config" />

Ardından, geliştiricilerinizin her birinin bir alt klasörde bir sürümüne sahip olduğu bir klasöre sahip olun (yani / _configs / dave /). Daha sonra, bir geliştirici kendi kodu üzerinde çalışırken, alt klasörden bağlantılı klasörün köküne kopyalar.

Bu dosyalardaki değişiklikleri ilettiğinizden emin olmanız gerekir (belirtmediğiniz sürece). AppSettings.config dosyasını kaynak kontrolünün dışında tutarsanız ve yalnızca devs klasörlerini (tümü) kontrol ederseniz, doğru olanı kopyalamaya zorlanırlar.

Simgeleştirmeyi tercih ederim, ancak bunun hızlı bir çözüm olması gerekiyorsa, ayağa kalkmak ve çalıştırmak daha zor olabilir.


0

Dosyaları yoksayın ve bir Commom_Web.Config ve Common_App.Config. Yapı sunucusunun işini yapabilmesi için bu ikisini normal adlarla yeniden adlandıran oluşturma görevlerine sahip sürekli bir tümleştirme oluşturma sunucusu kullanma.


bunun sunucu oluşturmadan önce geliştirici makinelerde yapılması gerekiyor
twarz01

Bu yeniden adlandırma, yapı sunucusunda olmamalıdır. Subversion'da depolanan ortak yapılandırma dosyaları, belirli bir geliştiriciden bağımsızdır. Oysa her geliştirici kendi makinesinde geliştirmek için kendi kişisel yapılandırma dosyalarını çalıştırır ve yıkımın bir parçası olmadığı için göndermekle ilgilenmez.
Arthis

Bunun desteklemediği şey, geliştiricilerin uygulamada hata ayıklamasıdır. web.configKaynak klasördeki kök , hata ayıklama sırasında kullanılır. Eğer, örneğin, ilave web.configetmek .gitignoreve ya kopyalamak için kullanıcılara gerekli Commom_Web.Configiçin web.configorada yol ediyoruz parçası, onların fantezi için ve düzenle. Ancak, geliştiricinin tüm makinelerinde aynı olan bir şeyi düzenlemeniz gerektiğinde, her yerde aynı olması gereken system.web/compilationbölüm veya belirli bir şey gibi appSettings, bu şema parçalanır.
binki

0

Aynı problemimiz var ve yaptığımız şey

  • Web.config dosyasını test sunucusu / üretim değerleri ile kontrol edin
  • Geliştirici Windows gezginine gider ve dosyanın salt okunur modunu değiştirir
  • Yapılandırmayı ortamlarına uyacak şekilde düzenleyin.
  • Web.config'e giriş, yalnızca dağıtım değerleri değiştiğinde veya herhangi bir yapılandırma girişi eklendiğinde veya silindiğinde gerçekleşir.
  • Bu, her geliştirici tarafından değiştirilmesi gerektiğinden, her yapılandırma girişi için iyi miktarda yorum gerektirir.

1
Bu, kullandığınız kaynak kontrolünün alanları varsayılan olarak Salt Okunur olarak ayarladığı mağazalarda daha iyi çalışabilir, ancak Subversion kullanan diğerleri için de çalışmayabilir. Depoda işlenmesini önlemek için salt okunur izinler ayarlayabilirdik, ancak bunun her dal için her yapılandırma dosyasında ayarlanması gerekir.
jpierson

TFS gibi bir şey kullanmayanlarımız için, bu çözümün nasıl işe yarayacağı açık değil. Biraz daha bilgi verebilir misin? Ayrıca, geliştiricilerin dikkatli olmasını ve dosyayı yanlışlıkla teslim almamasını gerektirmiyor mu?
binki

-1

Visual Studio kullandığınızı varsayarsak, neden farklı Çözüm Yapılandırmaları kullanmıyorsunuz? Örneğin: Web.config.debug kullanan bir Debug yapılandırmasına ve Web.config.release kullanan bir Release yapılandırmasına sahip olabilirsiniz. Web.config.debug aşağıdaki gibi bir şeye sahip olmalıdır:

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

Web.config.release her zaman üretim ayarlarına sahipken, tüm kişisel geliştirici ayarlarını alan Standard_Name_For_Config.config dosyasıyla. Varsayılan yapılandırmaları bazı kaynak kontrollü klasörlerde saklayabilir ve yeni bir kullanıcının bunları oradan almasını sağlayabilirsiniz.


Daha sonra projeye katkıda bulunacak her bir kullanıcının kendi yapı yapılandırmasına sahip olması gerekir. Bu ölçeklendirilmiş gibi görünmüyor ve katkı kabul eden projeleri desteklemiyor.
binki
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.