2009-02-04 21 views
5

Tôi đang trong quá trình di chuyển máy chủ SQL sang một máy riêng biệt. Hiện tại chúng tôi đang chạy máy chủ web và máy chủ sql của chúng tôi trên cùng một hộp. Vì vậy, chúng tôi có một máy chủ sản xuất với IIS và SQLServer và sau đó một máy chủ phát triển riêng biệt phản ánh thiết lập này.Phát triển và sản xuất: Các chuỗi kết nối

Khi nói đến app.config của asp.net và web.config của trang web, điều này đã hoạt động tốt vì chúng tôi có thể sử dụng "Initial Catalog = MyDB; ..." và nó hoạt động vì tên DB là tương tự trên cả hai máy.

Bây giờ tôi đang xem xét chạy cả hai DB trên cùng một hộp (MyDB, MyDB-Dev). Có một cách dễ dàng để làm điều này mà không cần phải chỉnh sửa web.config và app.config mỗi khi chúng tôi triển khai hoặc biên dịch? Đây có phải là thứ gì đó mà Visual Source Safe có thể xử lý không?

Trả lời

7

Đây là giải pháp tôi sử dụng. Trong Web.Config, đặt sau "bao gồm" dòng:

<connectionStrings configSource="WebCS.config"/> 

Sau đó, tạo file WebCS.config và nhập như sau:

<connectionStrings> 
<add name="ConnString" 
    connectionString="Data Source=YourServer;Initial Catalog=YourDB;etc.. 
    providerName="System.Data.SqlClient"/> 
</connectionStrings> 

Sau đó, sau khi xuất bản trang web của bạn trong VS, loại bỏ các WebCS. tập tin cấu hình (Tôi có một tập tin thực thi để thực hiện việc này) trước khi đóng gói mọi thứ khác để chuyển sang máy mới. Sau đó bạn sẽ được đảm bảo rằng tất cả các thiết lập tập tin Web.Config đi với bạn mà không gây rối với chuỗi kết nối của bạn.

+0

Cảm ơn bạn đã chấp nhận câu trả lời của tôi. Tôi hy vọng nó hoạt động tốt cho bạn vì nó có cho tôi! –

1

Tôi có thể không hoàn toàn hiểu câu hỏi của bạn ở đây, nhưng có vẻ như khi bạn triển khai ứng dụng, bạn có thể không triển khai lại web.config trừ khi có thay đổi trong web.config . Nói cách khác, sao chép tất cả các tệp vào thư mục ngoại trừ tệp web.config.

Nếu bạn phải thay đổi tệp web.config giữa các lần triển khai, bạn sẽ cần chỉnh sửa web.config cho mỗi máy chủ.

Hoặc, bạn có thể tìm một vị trí khác trên mỗi máy để lưu trữ các chuỗi kết nối khác với web.config.

4

Triển khai web.config gần như không bao giờ là trường hợp sao chép tệp từ dev sang sản phẩm. Việc có các mục nhập khác nhau là bình thường, ví dụ: trang web dev của bạn trỏ đến một cơ sở dữ liệu địa phương hoặc một hộp cơ sở dữ liệu dev và trang web prod của bạn thường phải trỏ đến hộp cơ sở dữ liệu prod của bạn.

Khi triển khai, web.config sản xuất của bạn thường chỉ cần thay đổi nếu bạn đã thực hiện thay đổi kiến ​​trúc trong ứng dụng yêu cầu cấu phần mới hoặc bạn muốn xóa các phần thừa.

Với kiểm soát nguồn, thực hành thông thường là loại trừ web.config và có tệp mẫu có thể được sử dụng làm cơ sở để tạo tệp cấu hình, ví dụ: web.config.template. Khi thực hiện các thay đổi về cấu trúc cho web.config, bạn nên thực hiện các thay đổi đối với web.config.template, sau đó tạo các bản sao của nó cho dev và prod, và áp dụng các thiết lập dev và prod cho phù hợp.

2

Tôi sử dụng NAnt để xây dựng và triển khai. Tôi tạo các tệp .config của mình thành các khuôn mẫu bằng cách sử dụng quy ước đặt tên .config.template. Tôi có một tài sản NAnt tên là "môi trường" mà tôi đã đặt từ lệnh gọi đến NAnt. Ở đầu tệp build.xml của tôi, tôi thiết lập thuộc tính "db.connectionstring" dựa trên thuộc tính "môi trường" (như một câu lệnh chuyển đổi). Trong nhiệm vụ xây dựng, tôi sử dụng grep để đẩy chuỗi "db.connectionstring" vào vị trí trong khuôn mẫu cho đầu ra thư mục xây dựng. Bằng cách đó, tôi chỉ cần gọi:

nant -D:environment=dev 

Điều này có tập hợp các tệp .config dành riêng cho từng nhà phát triển.

Nếu bạn không thích grep, hãy làm theo này:

http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/

chỉ này hoạt động cho các tập tin XML. Grep là chung chung hơn. Tôi thực sự có các tên cơ sở dữ liệu khác nhau dựa trên môi trường triển khai và grep cho phép tôi chèn các tên cơ sở dữ liệu khác nhau vào các kịch bản SQL dựa trên môi trường.

0

kiểm tra ra các thuộc tính của phần tử configSource connectionStrings trong web.config

rằng nên làm cho nó dễ dàng đủ

0

Chỉ cần để tôi rõ ràng, môi trường hiện tại của bạn là hai máy chủ, tức là

Dev App/DB server
sản xuất ứng dụng/DB server

và bạn đang nghĩ đến việc làm cho nó một cái gì đó giống như

này

App Server (dev + sản ​​xuất)
DB Server (dev + sản ​​xuất)

Nếu đó là trường hợp, tôi khen bạn đã cô lập các DB và ứng dụng vào hai máy chủ riêng - khi di chuyển từ một môi trường máy chủ duy nhất đó là bước đầu tiên vì nó cho phép nâng cấp dễ dàng sau này nếu bạn cần cụm nhiều máy chủ DB hoặc (thường gặp hơn) cân bằng tải nhiều máy chủ web trước một máy chủ DB để giúp hiệu suất ứng dụng.

Có nói rằng, tôi không đề nghị chạy các môi trường dev và sản xuất cạnh nhau như thế này trên cùng một máy chủ. Trong khi nó có thể có ý nghĩa về mặt tài chính, mục đích của môi trường dev riêng biệt là giữ 'sai lầm' từ chảy máu sang sản xuất, và làm như thế có thể dẫn đến thời gian chết nếu bạn có một số mã xấu bị đẩy vào môi trường dev.

0

Bạn có thể đặt tất cả các chuỗi kết nối trong web.config và sau đó tại một điểm chính trong ứng dụng xác định cái nào để sử dụng dựa trên máy chủ ứng dụng?

0

Để phát triển, hãy sử dụng tệp Web.Debug.config và để sản xuất, sử dụng Web.Release.config. Mỗi cái có thể định nghĩa chuỗi kết nối riêng của nó.