2009-09-04 37 views
5

Chúng tôi đang sử dụng đề xuất của Scott Hansleman cho nhiều web.configs từ bài đăng của mình here. Vấn đề chúng ta có là chúng ta phải kiểm tra Web.Config. Nếu chúng tôi xóa nó khỏi dự án, khi chúng tôi xuất bản, không có web.config nào được đẩy. Vì vậy, chúng tôi cần phải loại bỏ các ràng buộc kiểm soát nguồn chỉ từ web.config, nhưng để nó trong dự án, và có phần còn lại của dự án vẫn được tổ chức dưới sự kiểm soát nguồn.TFS 2008, xóa tệp khỏi điều khiển nguồn nhưng để tệp đó trong dự án

Vấn đề là kiểm soát nguồn làm cho tệp chỉ đọc cho đến khi bạn kiểm tra. Chúng ta cần có khả năng ghi đè lên nó với các sự kiện prebuild, tốt nhất là không cần phải kiểm tra nó. Có cách nào để loại bỏ các ràng buộc từ tập tin đó chỉ, và vẫn để nó như là một phần của dự án?

Cảm ơn.

Trả lời

8

Bằng cách thêm tệp mới vào trình khám phá giải pháp, bạn sẽ nhận được dấu cộng nhỏ cho biết nó được thêm vào điều khiển nguồn. Sau đó, nhấp chuột phải và chọn "hoàn tác thay đổi đang chờ xử lý". Điều này sẽ hủy bỏ thêm nhưng để lại các tập tin trong dự án của bạn.

Nếu điều đó không làm việc, tôi đề nghị một trong những phương pháp sau đây:

  • Sử dụng các nhiệm vụ Attrib từ dự án MSBuild Community Tasks để loại bỏ các chỉ đọc lá cờ.
  • Sử dụng Exec task trong MSBuild để gọi tf.exe và kiểm tra tệp.
+0

vì vậy, tôi cần xóa tệp, kiểm tra tệp, thêm web.config mới và sau đó hoàn tác? – Josh

+0

Vâng, tôi khuyên bạn nên xoá tệp khỏi điều khiển nguồn trước. –

+0

Đừng làm điều này. Nó đánh bại toàn bộ vấn đề. –

3

Bạn nên để tệp trong điều khiển nguồn. Nếu không, bạn sẽ gặp phải một số vấn đề:

  • thay đổi sẽ không được phiên bản. 'nuf nói.
  • không thể phân nhánh hoặc sáp nhập, mặc dù web.config là một trong những tệp có nhiều khả năng thay đổi nhất giữa môi trường sản xuất/thử nghiệm/sản xuất song song
  • thay đổi bạn thực hiện cục bộ sẽ không lan truyền cho đồng nghiệp workarounds
  • nhà phát triển thiết lập môi trường lần đầu tiên sẽ không tải tệp ở tất cả
  • Xây dựng nhóm sẽ không chứa tệp, do đó sẽ không triển khai của bạn. (chắc chắn bạn không triển khai trực tiếp từ máy tính để bàn ?!)

Lưu ý rằng trạng thái của các tệp riêng lẻ được lưu trữ hoàn toàn trên máy chủ TFS. ('tf tài sản' bãi siêu dữ liệu này nếu bạn đang tò mò) Chỉ có dự án & giải pháp có bindings thực sự được ghi vào tập tin. Và ngay cả đó là những mục giả mạo nói với VS "đừng lo lắng về tôi, chỉ cần hỏi TFSProvider, nó sẽ biết tôi là ai và tôi đang ở đâu." Trong khi có nhiều quirks khác trong hệ thống dự án VS cho tôi đau đầu vô tận, trong trường hợp này đó là bạn của bạn. Đừng phá hỏng nó.

tùy chọn xuất sắc nhất:

  1. Sửa xây dựng kịch bản của bạn để chuyển đổi các thuộc tính chỉ đọc trước/sau khi chỉnh sửa. Nếu bạn đang sử dụng tập lệnh "copyifnewer.bat" từ bài đăng trên blog được liên kết, nó phải là một dòng phụ. Thậm chí nếu bạn muốn giữ cho mọi thứ hoàn toàn khai báo trong tệp tạo MSBuild, nó hầu như không làm việc với sự giúp đỡ của 3rd party tasks.

  2. Sử dụng tính năng Tệp -> Kiểm soát nguồn -> Loại trừ. Sau khi áp dụng cài đặt này, tệp vẫn nằm dưới sự kiểm soát nguồn, nhưng sẽ không còn chịu sự kiểm tra tự động/kiểm tra bằng giải pháp hoạt động nữa. Nói cách khác, bạn có thể chỉnh sửa tệp cục bộ thành nội dung trái tim mà không ảnh hưởng đến bất kỳ ai khác, nhưng nếu bạn muốn cam kết (hoặc thay đổi) các thay đổi bạn cần thực hiện từ Source Control Explorer hoặc dòng lệnh.

Tùy chọn # 1 có lợi thế là sửa chữa rất nhanh cho thiết lập hiện tại của bạn. * Cùng một lý do tại sao sao chép/dán mã là xấu: nếu bạn thay đổi một, bạn phải đi thay đổi tất cả những người khác - hoặc tệ hơn, quên và để cho họ trôi ra khỏi đồng bộ cho đến khi các lỗi lạ buộc bạn phải truy cập lại vấn đề. Điều này có thể được cải thiện bằng cách thay đổi quy trình sao cho chỉ có 1 web.config "" chính và các bản sao bổ sung chỉ chứa các khác biệt (thông qua một công cụ tìm kiếm văn bản, XSLT biến đổi, thao tác có lập trình trong Powershell, v.v.). Tất nhiên, đó là công việc nhiều hơn.

Tùy chọn # 2 tránh các vấn đề của # 1 với rất ít chi phí. (quá trình kỹ thuật chính nó là không thay đổi, chỉ có sự khác biệt là cách Visual Studio UI cư xử) Lợi thế này là rất quan trọng nếu bạn thực hiện thay đổi cho web.config ở tất cả thường xuyên. Nhược điểm là không có cách tích hợp để theo dõi các biến thể trên tệp "chính". Nếu khác biệt duy nhất là bẩn đơn giản, ví dụ như một chuỗi kết nối hoặc hai, bạn có thể tìm thấy nó dễ dàng nhất để gắn bó với chỉ một "bậc thầy" và cho phép mọi người thực hiện thay đổi quảng cáo trên máy dev của họ. Thậm chí còn có các công cụ để thực hiện việc này cho bạn, chẳng hạn như Web Deployment Projects (dễ) và IIS Deployment Tool (phức tạp). Trong mọi trường hợp, triển khai thực tế của bạn nên được tự động và kiểm soát nguồn, tất nhiên! Nếu các tùy chỉnh nặng hơn được yêu cầu hơn so với các công cụ này có khả năng, thì có thể bạn sẽ muốn cách tiếp cận lai + biến đổi được mô tả trước đó.

+1

Tôi hiểu quan điểm của bạn, Richard, nhưng web.config chỉ đơn thuần là một bản sao của 1 trong 4 tệp khác trong dự án, đã được kiểm soát nguồn. Tệp chỉ đơn giản là hoán đổi cho mỗi môi trường tùy thuộc vào cấu hình xây dựng. Có nó trong TFS là không cần thiết vì nó chỉ là một bản sao của những gì đã được bảo vệ với kiểm soát phiên bản, và đau đầu. Cảm ơn bạn đã nhập liệu! – Josh

+0

Không có prob. Tôi muốn kiểm tra tùy chọn # 2 anyway - đó là một trong những tính năng ít được biết đến VS một khi bạn biết nó, bạn sẽ tìm thấy vô giá - ngay cả khi không cho web.config cụ thể. –

+1

Loại trừ không hoạt động, vì khi tôi xuất bản, web.config không được đẩy. Nó phải là một phần của dự án, nhưng không phải trong kiểm soát nguồn để tôi có thể ghi đè lên nó. – Josh

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