Nhà phát triển tệp app.config / web.config cụ thể trong Visual Studio


93

Chúng tôi có một số dự án .NET nơi chúng tôi lưu trữ các cài đặt nhất định trong các tệp cấu hình.

Giờ đây, mỗi nhà phát triển sẽ có các tệp cấu hình của riêng họ khác nhau một chút (các chuỗi kết nối khác nhau để kết nối với cơ sở dữ liệu cục bộ, các điểm cuối WCF khác nhau , v.v.)

Hiện tại, chúng tôi có xu hướng kiểm tra các tệp app / web.config và sửa đổi chúng cho phù hợp với nhu cầu của mình.

Điều này dẫn đến nhiều vấn đề vì thỉnh thoảng ai đó sẽ kiểm tra cài đặt của riêng họ hoặc cấu hình tùy chỉnh lỏng lẻo khi tải phiên bản mới nhất từ TFS .

Làm thế nào để bạn đối phó với những tình huống như thế này? Hoặc bạn không có vấn đề này ở tất cả?


10
Tôi đang biểu quyết để mở lại, vì đây là vấn đề chung của các nhà phát triển studio trực quan và liên quan trực tiếp đến các công cụ mà các nhà phát triển đang sử dụng. (do đó số phiếu)
Christian Gollhardt

Đồng ý, đây là một vấn đề dai dẳng vì quy mô nhóm của chúng tôi đã phát triển và nhiều nỗ lực giải quyết không đạt yêu cầu.
DiskJunky

Câu trả lời:


66

Chúng tôi sử dụng một hệ thống kết hợp một số câu trả lời hiện có trên trang này, đồng thời dựa trên gợi ý này của Scott Hanselman .

Nói tóm lại, những gì chúng tôi đã làm là có một app.config / web.config chung và có hầu hết các cài đặt cụ thể trong các tệp riêng lẻ, như được đề xuất bởi các câu trả lời khác ở đây. ví dụ: đối với cài đặt SMTP của chúng tôi, app.config chứa

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

Tệp này nằm trong kiểm soát nguồn. Tuy nhiên, các tệp riêng lẻ, như thế này, không phải là:

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

Đó không hoàn toàn là nơi câu chuyện kết thúc. Điều gì về các nhà phát triển mới hoặc cài đặt nguồn mới? Phần lớn cấu hình không còn nằm trong quyền kiểm soát nguồn và việc tạo thủ công tất cả các tệp .config mà chúng cần. Tôi thích có nguồn ít nhất sẽ biên dịch ngay lập tức.

Do đó, chúng tôi giữ một phiên bản của tệp .config trong kiểm soát nguồn, có tên là tệp .config.default . Do đó, một cây nguồn tươi sẽ trông như thế này:

văn bản thay thế

Tuy nhiên, không thực sự có ích cho nhà phát triển, vì đối với Visual Studio, chúng chỉ là những tệp văn bản vô nghĩa. Do đó, tệp batch copy_default_config.batsẽ đảm nhận việc tạo một tập hợp các tệp .config ban đầu từ các tệp .config.default:

@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.

Tập lệnh có thể chạy lại một cách an toàn, trong đó các nhà phát triển đã có tệp .config của họ sẽ không bị ghi đè chúng. Do đó, người ta có thể hình dung việc chạy tệp loạt này như một sự kiện tạo trước. Các giá trị trong tệp .default có thể không chính xác cho một cài đặt mới, nhưng chúng là một điểm khởi đầu hợp lý.

Cuối cùng những gì mỗi nhà phát triển kết thúc với là một thư mục tệp cấu hình trông giống như sau:

văn bản thay thế

Nó có vẻ hơi phức tạp, nhưng nó chắc chắn thích hợp hơn với sự rắc rối của các nhà phát triển giẫm lên ngón chân của nhau.


Tại sao không có trực tiếp .config chính trong kho lưu trữ mà không có các tệp riêng lẻ?
gra chính thức

6
Thật là đau khổ, chúng ta cần một giải pháp tốt hơn cho việc này. Tôi đã thiết lập một phương pháp tương tự và cảm thấy mệt mỏi vì nó quá mỏng manh và vẫn cần giải thích cho các nhà phát triển mới.
jpierson

@Gavin, tôi gặp lỗi nếu cố chạy tệp dơi mà bạn đã phác thảo: '∩╗┐ @ echo' không được nhận dạng là lệnh nội bộ hoặc lệnh bên ngoài, chương trình có thể hoạt động hoặc tệp hàng loạt.
Austin

2
@Austin, bạn dường như có một số rác không in được trước '@echo', một phần có thể là dấu thứ tự byte Unicode? Có thể đã xảy ra lỗi trong quá trình sao chép / dán hoặc tệp hàng loạt được lưu trong một bảng mã không thể đọc đúng cách.
Gavin

21

Trong Web.config của bạn sử dụng nguồn từ các tệp khác

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

Giữ web.config trong quyền kiểm soát phiên bản và không làm điều đó cho ConnectionStrings.config. Giờ đây, tất cả các nhà phát triển đều có một tệp cho chuỗi kết nối.

Bạn có thể thực hiện việc này cho tất cả các cài đặt phụ thuộc cục bộ.


1
Điều này làm việc tốt cho tôi. Xem thêm: davidgiard.com/2012/05/25/… Tệp ConnectionStrings.config phải nằm trong cùng thư mục với ứng dụng hoặc cấu hình web. Ngoài ra, bạn phải thay đổi thuộc tính của nó thành 'sao chép nếu mới hơn' để xuất. Và tệp ConnectionStrings.config cần có phần đầy đủ với các phần tử mở và đóng. Bạn cũng phải đặt kiểm soát phiên bản để bỏ qua tệp để mỗi tệp là dành riêng cho người dùng.
Jeffrey Roughgarden

1
Tôi đã sử dụng tùy chọn <appSettings file = ".."> vì tôi phải hợp nhất cài đặt
Spikolynn

1
@JeffreyRoughgarden Nếu bạn bao gồm tệp ConnectionStrings.config trong Giải pháp Explorer, tệp không cần phải tồn tại trên tệp tin? Và nếu có, nghĩa là bạn đã kiểm tra nguồn. Đó là vấn đề ban đầu mà chúng tôi đang cố gắng giải quyết.
Jez

20

Đây là giải pháp cho tệp web.config và Visual Studio 2010:

1) Chỉnh sửa thủ công tệp .csproj của ứng dụng web của bạn để thêm AfterBuildMục tiêu như sau:

  <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>

Mục tiêu này sẽ biến đổi tệp Web.config tương ứng với nhà phát triển hiện tại đã đăng nhập - do đó là $(USERNAME)biến -, với tệp tương ứng được tạo trong 1). Nó sẽ thay thế Web.config cục bộ chỉ khi nội dung đã thay đổi (để tránh khởi động lại) ở mỗi bản dựng, ngay cả khi Web.config cục bộ được kiểm soát nguồn, đó là lý do tại sao nó OverwriteReadOnlyFilesđược đặt thành True. Điểm này trên thực tế là điều đáng bàn cãi.

2) Tạo một tệp có tên Web.[developer windows login].configcho mỗi nhà phát triển trong dự án. (ví dụ: trong các ảnh chụp màn hình sau đây, tôi có hai nhà phát triển tên là Smoke và Smo2):

nhập mô tả hình ảnh ở đây

Các tệp này (1 cho mỗi nhà phát triển) có thể / nên được kiểm soát nguồn. Chúng không nên được đánh dấu là phụ thuộc vào Web.config chính vì chúng tôi muốn có thể kiểm tra chúng một cách riêng lẻ.

Mỗi tệp này đại diện cho một chuyển đổi để áp dụng cho tệp Web.Config chính. Cú pháp chuyển đổi được mô tả ở đây: Cú pháp chuyển đổi Web.config để triển khai dự án ứng dụng web . Chúng tôi sử dụng lại tác vụ chuyển đổi tệp Xml thú vị này có sẵn với Visual Studio. Mục đích của tác vụ này là hợp nhất các phần tử và thuộc tính Xml thay vì ghi đè toàn bộ tệp.

Ví dụ: đây là một mẫu web.[dev login].configthay đổi chuỗi kết nối có tên 'MyDB', bất kể phần còn lại của tệp Web.config:

<?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>

Bây giờ, giải pháp này không hoàn hảo vì:

  • sau khi xây dựng, các nhà phát triển có thể có một Web.Config cục bộ khác với trong hệ thống điều khiển nguồn
  • họ có thể phải buộc ghi cục bộ khi tải một Web mới.
  • nhà phát triển không nên đăng xuất / trong web.config chính. Nó nên được dành cho ít người.

Nhưng ít nhất, bạn chỉ phải duy trì một web.config chính duy nhất cộng với một tệp chuyển đổi cho mỗi nhà phát triển.

Một cách tiếp cận tương tự có thể được thực hiện cho các tệp App.config (không phải web) nhưng tôi không nói rõ thêm.


Tôi đã đổi tên Web.config của mình thành Web.base.config, tạo tệp Web.config mới, sau đó thay đổi từ <Copy SourceFiles = "web.config"> thành <Copy SourceFiles = "web.base.config" ở bước 1. Làm điều này, tôi có thể có một web.config cục bộ có thể bị bỏ qua trong kiểm soát nguồn.
S. Baggy

Điều này vẫn không lý tưởng nhưng tôi thích nó hơn giải pháp khác
JMK

Bạn có nghĩ rằng nó có thể sử dụng một web.default.configkhi web.$(USERNAME).configkhông tồn tại? Nhân tiện, cảm ơn bạn vì câu trả lời tuyệt vời này.
Christian Gollhardt

2

Chúng tôi đang sử dụng machine.config để tránh có sự khác biệt về web.config giữa các môi trường.


14
thà muốn tránh phải Machine.config thay đổi
twarz01

0

Làm thế nào về việc bỏ qua tệp để nó không bao giờ được đăng ký? Tôi đã gặp sự cố tương tự và đã thêm web.config vào danh sách bỏ qua trong Subversion.

Tuy nhiên, trong TFS, nó khó hơn một chút, hãy xem bài đăng này để biết cách thực hiện.


0

Một cách bạn có thể đối phó là có một hệ thống mã hóa và sử dụng tập lệnh rake để thay đổi các giá trị.

Một phương pháp thô sơ hơn có thể là tạo liên kết đến tệp AppSettings.config cho tất cả các AppSettings trong web.config của bạn (tương tự với các kết nối) tức là

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

Sau đó, có một thư mục với mỗi nhà phát triển của bạn có một phiên bản trong một thư mục con (tức là / _configs / dave /). Sau đó, khi một nhà phát triển đang làm việc trên mã của riêng họ, họ sao chép từ thư mục con vào thư mục gốc của thư mục được liên kết.

Bạn sẽ cần phải đảm bảo rằng bạn thông báo các thay đổi đối với các tệp này (trừ khi bạn đăng nhập). Nếu bạn giữ tệp AppSettings.config ngoài quyền kiểm soát nguồn và chỉ kiểm tra trong các thư mục riêng lẻ của nhà phát triển (tất cả chúng) thì chúng sẽ buộc phải sao chép đúng.

Tôi thích mã hóa nhưng có thể khó khăn hơn để bắt đầu và chạy nếu điều này chỉ nhằm mục đích sửa chữa nhanh chóng.


0

Bỏ qua các tệp và có Commom_Web.Config và Common_App.Config. Sử dụng máy chủ xây dựng tích hợp liên tục với các tác vụ xây dựng đổi tên hai tác vụ này thành tên bình thường để máy chủ xây dựng có thể thực hiện công việc của nó.


nhu cầu này được thực hiện trên máy dev, trước khi nó đi vào xây dựng máy chủ
twarz01

Không, việc đổi tên này sẽ xảy ra trên máy chủ xây dựng. Các tệp cấu hình chung đang được lưu trữ trên bản lật đổ, chúng độc lập với một nhà phát triển cụ thể. Trong khi đó mọi nhà phát triển đều chạy các tệp cấu hình cá nhân của mình để phát triển trên máy của mình và không quan tâm đến việc gửi tệp đó vì nó không phải là một phần của lật đổ.
Arthis 14/09/10

Điều này không hỗ trợ các nhà phát triển gỡ lỗi ứng dụng. Gốc web.configtrong thư mục nguồn được sử dụng trong quá trình gỡ lỗi. Nếu bạn, ví dụ, thêm web.configvào .gitignorevà một trong hai yêu cầu người dùng sao chép Commom_Web.Configtới web.configvà chỉnh sửa nó để ưa thích của họ, bạn phần đang trong những cách đó. Nhưng sau đó khi bạn cần chỉnh sửa thứ gì đó giống nhau trên tất cả các máy của nhà phát triển, chẳng hạn như system.web/compilationphần hoặc cụ thể appSettingsphải giống nhau ở mọi nơi, sơ đồ này sẽ bị phá vỡ.
binki 20/09/18

0

Chúng tôi có cùng một vấn đề và những gì chúng tôi đang làm là

  • Kiểm tra trong web.config với các giá trị testerver / production
  • Nhà phát triển truy cập windows explorer và thay đổi chế độ chỉ đọc của tệp
  • Chỉnh sửa cấu hình cho phù hợp với môi trường của họ.
  • Đăng nhập vào web.config chỉ xảy ra khi các giá trị triển khai thay đổi hoặc bất kỳ mục cấu hình nào được thêm vào hoặc xóa.
  • Điều này cần một lượng bình luận tốt cho mỗi mục nhập cấu hình vì nó cần được thay đổi bởi mỗi nhà phát triển

1
Điều này có thể hoạt động tốt hơn trong các cửa hàng nơi điều khiển nguồn mà bạn sử dụng đặt các trường là Chỉ đọc theo mặc định nhưng đối với những người khác sử dụng Subversion, nó cũng có thể không hoạt động. Chúng tôi có thể đặt các quyền chỉ đọc trong kho lưu trữ để ngăn nó được cam kết, tuy nhiên, điều đó sẽ cần được đặt trên mỗi tệp cấu hình cho mỗi nhánh.
jpierson

Đối với những người trong chúng ta không sử dụng thứ gì đó như TFS, không rõ giải pháp này có thể hoạt động như thế nào. Bạn có thể cung cấp thêm một chút nền tảng? Ngoài ra, nó không yêu cầu các nhà phát triển phải cẩn thận và không vô tình kiểm tra tệp sao?
binki 20/09/18

-1

Giả sử bạn đang sử dụng Visual Studio, tại sao bạn không sử dụng các Cấu hình Giải pháp khác nhau? Ví dụ: bạn có thể có cấu hình Gỡ lỗi sử dụng Web.config.debug và cấu hình Phát hành sử dụng Web.config.release. Web.config.debug phải có một cái gì đó như

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

với tệp Standard_Name_For_Config.config chứa tất cả cài đặt nhà phát triển cá nhân, trong khi Web.config.release luôn có cài đặt sản xuất. Bạn có thể lưu trữ các cấu hình mặc định trong một số thư mục được kiểm soát nguồn và yêu cầu người dùng mới lấy chúng từ đó.


Sau đó, mỗi người dùng cá nhân đã từng đóng góp cho dự án sẽ cần phải có cấu hình xây dựng của riêng họ. Điều này dường như không quy mô và không hỗ trợ các dự án chấp nhận đóng góp.
binki 20/09/18
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.