2009-09-10 65 views
32

Bất kỳ ai cũng có bất kỳ mẹo hay nào về xử lý sự khác biệt trong cài đặt web.config giữa các môi trường? Tôi đã xem xét việc tạo một thư mục 'config' trong hệ thống kiểm soát nguồn của chúng tôi nhưng bên ngoài hệ thống phân cấp web và có quá trình triển khai sao chép các tệp cấu hình thích hợp (web.dev.config, web.staging.config, web.production.config) vào thư mục web khi triển khai. Tôi cũng đã nhìn thấy các bài viết về cách lập trình thay đổi các thiết lập cấu hình (WCF thiết bị đầu cuối, dây kết nối, vv) khi ứng dụng bắt đầu.Phân biệt web.config giữa môi trường dev, dàn dựng và môi trường sản xuất

Thực tiễn tốt nhất được xem là gì ở đây và trải nghiệm nào mà mọi người đã có với các phương pháp này hoặc các phương pháp tiếp cận khác?

Cập nhật Sep 2010

Nó đáng chú ý là Visual Studio 2010 cho biết thêm khả năng này thông qua web.config transforms. Khi bạn sử dụng trình quản lý cấu hình xây dựng (Build | Configuration Manager ...) để tạo các cấu hình khác nhau cho dự án của bạn (ví dụ, Debug, Dev, Staging and Release), VS thêm các tệp. *. Config vào giải pháp. Web.config mặc định chứa các thiết lập cơ sở mà bạn sẽ sử dụng để gỡ lỗi. web.release.config, web.staging.config, v.v. chứa các phép biến đổi XSLT sẽ được áp dụng bất cứ khi nào bạn xuất bản dự án của mình dựa trên cấu hình xây dựng đang hoạt động.

+2

Xem http://stackoverflow.com/questions/305447/using-different-web-config-in-development-and-production-environment/305498#305498 – PhilPursglove

+0

@PhilPursglove thật tuyệt vời cho cấu hình thư viện doanh nghiệp, nhưng không trợ giúp với các cài đặt cấu hình khác như tôi có thể nói. Có nhiều thay đổi hơn giữa các môi trường so với các chuỗi kết nối và các thuộc tính liên quan đến db. –

Trả lời

13

Với VS mới, bạn có thể sử dụng chuyển đổi cấu hình web.

đọc thêm ở đây: http://msdn.microsoft.com/en-us/library/dd465326.aspx

+0

Tôi đã cập nhật câu hỏi của mình để bao gồm một vài ngày trước. –

+1

Tôi tin rằng đây là một trong đó nên được sử dụng – Ravia

+0

Tôi luôn luôn tìm thấy nó tốt để một thời điểm bạn nhận ra bạn không muốn lưu trữ mật khẩu là repo của bạn. Tóm lại - không đi. – mayu

9

Tôi sử dụng CruiseControl.NET/NAnt và NAnt có nhiệm vụ XMLPoke cho phép bạn vào khi bạn đang xây dựng và thay đổi bất kỳ cài đặt cấu hình nào bằng truy vấn XPath.

Vì vậy, trong mỗi mục tiêu xây dựng của mình (DEV, UAT, STAGING, v.v ...), tôi đặt một nhóm thuộc tính và sau đó gọi đích xây dựng chính. Các mục tiêu xây dựng tổng thể mất các giá trị của tất cả các thuộc tính và XMLPokes chúng vào cấu hình và xây dựng.

+1

Đây là những gì tôi làm nhưng thay vì NAnt tôi sử dụng MSBuild và MSBuild Community Tasks để chỉnh sửa XML –

8

Một phương pháp tôi đã xem và sử dụng là nơi bạn thiết lập các khóa trong web.config để phân biệt các máy tính theo tên.

Vì vậy, ví dụ:

<add key="comp1.Environment"  value="DEV"/> 
<add key="compdb1.Environment"  value="PROD"/> 
<add key="compstage.Environment" value="STAGE"/> 

Rõ ràng COMP1, compdb1 là tên máy tính thực tế.

Bạn sẽ sau đó thiết lập một cái gì đó như:

<add key="KeyName,DEV" value="DevEnvironmentValue"/> 

Trong mã của bạn, bạn sẽ cần phải kiểm tra những gì môi trường ứng dụng đang chạy trên và sau đó nhận được chìa khóa thích hợp, vì vậy ví dụ.

private string GetKeyValue() { 
    string machineName = String.Concat(System.Environment.MachineName, ".Environment"); 
    string environment = ConfigurationManager.AppSettings[machineName]; 
    string key   = String.Concat("KeyName", ",", environment); 
    string keyValue  = ConfigurationManager.AppSettings[key]; 

    return keyValue; 
} 
3

Có loại dự án có tên Web Deployment project, được cung cấp miễn phí từ Microsoft cho phép bạn thực hiện chính xác điều đó. Bạn có thể thay thế các phần của web.config của bạn, tùy thuộc vào cấu hình giải pháp của bạn (gỡ lỗi, phát hành, vv) Chúng tôi sử dụng nó trong hơn một năm và nó hoạt động tốt. Nó có sẵn cho VS2005 và VS2008.

Hy vọng điều này sẽ giúp

+0

Điểm tốt. Tuy nhiên - điều này có giúp ích cho các ứng dụng dịch vụ winform và cửa sổ (ví dụ: tệp app.config) không? – rohancragg

+0

Có lẽ không phải vì loại dự án này sử dụng trình biên dịch ASP.Net và bị ràng buộc vào một dự án ứng dụng web. –

16

Cách tiếp cận của tôi là có nhiều tệp cấu hình. Tôi đặt tất cả các công cụ bất khả tri về môi trường (tức là không quan trọng nếu dev, dàn dựng hoặc sản xuất) trong tệp web.config. Bất cứ điều gì cụ thể cho môi trường (tức là thông tin kết nối cơ sở dữ liệu, ghi nhật ký, cài đặt gỡ lỗi, v.v.) Tôi đưa vào tệp local.config cụ thể với môi trường. Sau đó, bạn có thể bao gồm các cài đặt local.config trong web.config bằng cách sử dụng configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

Web.config sau đó có thể được kiểm tra vào kiểm soát nguồn.Không kiểm tra các tệp local.config - buộc bạn triển khai đúng tệp trong các tập lệnh triển khai của bạn.

3

Trong khi một số các câu trả lời khác có thể phù hợp hơn tôi sẽ chỉ thêm rằng Matt Berseth rolled his own method trở lại trong năm 2007 ...

Nói tóm lại ông giữ tất cả các giá trị mà khác nhau giữa môi trường trong một file văn bản độc quyền và sử dụng một công cụ tùy chỉnh trong quá trình xây dựng để hợp nhất các giá trị vào các tệp .config.

Trong một bình luận trên bài đăng đó Doron Yaacoby cũng bình luận:

"có một nhiệm vụ trong MSBuild Cộng đồng Nhiệm vụ có thể đạt được điều này (và nhiều hơn nữa) cho bạn, được gọi là XmlMassUpdate Ive written about it in my blog. "

1

Bạn cần cài đặt cho một môi trường, không xây dựng cho một. Trong thế giới thực, bạn phải cài đặt trong sản xuất những gì đã được thử nghiệm trong QA, không xây dựng lại được cho phép. Ít nhất trong thế giới của tôi, đó là trường hợp.

+0

Về lý thuyết, có. Trong thực tế, hay "thế giới thực", có sự khác biệt giữa QA và sản xuất. Ngay cả một cái gì đó đơn giản như một chuỗi kết nối đòi hỏi một cấu hình khác nhau do một tên máy chủ khác nhau và thông tin đăng nhập. Chuyển đổi cấu hình có lý do. Bản dựng là, tốt, * được xây dựng * ngoại tuyến, nhưng nó vẫn được thiết kế riêng cho môi trường đích. –

3

Dưới đây là làm thế nào để thêm configs khác nhau có thể được tùy biến cho môi trường triển khai của bạn trong VS2012

  1. click chuột phải vào người quản lý giải pháp và chọn cấu hình
  2. Nhấp vào nút Configuration Manager
  3. Dưới Configuration hộp chọn cột kết hợp với dự án mà bạn muốn thêm cấu hình vào và chọn
  4. Tạo cấu hình mới có tên như TEST và cài đặt sao chép từ phát hành và kiểm tra Tạo mới cấu hình giải pháp hộp kiểm
  5. click chuột phải vào Web.config
  6. Thêm Config Chuyển
  7. Sau đó, bạn nhận được một web.config thêm Ví dụ web.TEST.config

Sau này, bạn cần phải sửa đổi web.TEST.config với một số biến đổi đặc trưng cho môi trường thử nghiệm của bạn

0
Easy way to have that is having an Enumeration , then having a switch statement based on the server name (if its stable name) . 
Call GetURIPath() where ever you require to fetch details , here I given the examples for url's used 


public class StaticData 
{ 
    public enum enumEnvironment 
    { 
     envNONE = 0, 
     envLOC = 1, 
     envDEV = 2, 
     envTEST = 3, 
     envPROD = 4 
    } 
    private static enumEnvironment GetCurrentEnv() 
    { 
     if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null) 
     { 
      return enumEnvironment.envLOC; 
     } 
     else 
     { 
      NameValueCollection NVCollection = new NameValueCollection(); 
      NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings"); 
      if(NVCollection == null) 
      { 
       NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings"); 
      } 

      string sEnv = NVCollection.GetValues("serverrole").ToString(); 

      switch (sEnv.ToUpper()) 
      { 
       case "DEV-ISOLATED": 
        return enumEnvironment.envDEV; 
       case "DEVELOPMENT": 
        return enumEnvironment.envDEV; 
       case "TEST": 
        return enumEnvironment.envTEST; 
       case "PRODUCTION": 
        return enumEnvironment.envPROD; 
       default: 
        return enumEnvironment.envNONE; 
      } 
     } 
    } 
    public static string GetURIPath() 
    { 
     switch (GetCurrentEnv()) 
     { 
      case enumEnvironment.envPROD: 
       return "http://produrl/yourapp/api/"; 
      case enumEnvironment.envTEST: 
       return "http://testurl/yourapp/api/"; 
      case enumEnvironment.envDEV: 
       return "http://devurl/yourapp/api/"; 
      default: 
       return "http://localhost/yourapp/api/"; 
     } 
    } 

}

Các vấn đề liên quan