Tôi có nên biên dịch trước các trang ASP.NET 2.0 trước khi triển khai hay không?

Question

Nơi tôi làm việc, chúng tôi thực hiện một số lượng rất lớn các ứng dụng ASP.NET rất nhỏ và đã xảy ra một vài lần các trang web đã được triển khai ở định dạng được biên dịch trước và ứng dụng cần được thay đổi, nhưng phiên bản của mã có sẵn trong kiểm soát nguồn đã lỗi thời và nhà phát triển không có sẵn. Dll của ứng dụng phải được biên dịch và tấn công lại với nhau. Lý tưởng nhất, nó sẽ không bao giờ xảy ra khi một người phát triển vội vã thay đổi thông qua thử nghiệm và sản xuất và bỏ qua kiểm tra trong thay đổi, chúng tôi đã thực hiện thay đổi chính sách của chúng tôi để giữ điều này xảy ra, nhưng tôi tự hỏi liệu chi phí biên dịch trang web trên máy chủ bất cứ khi nào khởi động lại ứng dụng trong hồ bơi là vấn đề đủ lớn nên chúng tôi nên tránh tải lên mã của chúng tôi trực tiếp lên máy chủ. Sẽ dễ dàng hơn khi kiểm tra phiên bản trong kiểm soát nguồn so với phiên bản thực tế trực tiếp nếu chúng tôi có thể tải xuống nguồn trực tiếp.

Ưu điểm của việc biên dịch trước VS tải lên tệp cs trực tiếp lên máy chủ và khiến chúng được biên dịch ở đó là gì?

Answer 1

Nó sẽ phụ thuộc vào kích thước của ứng dụng và tần suất sử dụng. Nếu nó được sử dụng thường xuyên đủ để các hồ bơi ứng dụng chỉ được tái chế vào cuối ngày, một sự chờ đợi ngắn trên khởi động đầu tiên vào buổi sáng có thể đáng giá. Nếu nó chỉ nhận được nhấn một lần mỗi 30 phút, buộc phải biên dịch lại mỗi lần, nó có thể là giá trị biên dịch trước.

Tất nhiên, nếu đó là một ứng dụng rất lớn cần một thời gian để biên dịch vào lần chạy đầu tiên, tôi sẽ nghiêng về phía trước, đặc biệt nếu nó không được sử dụng liên tục.

Answer 2

Lợi thế chính là biên dịch hiệu suất trên máy chủ web. Ngoài ra nó bảo vệ mã của bạn, bởi vì khó đọc mã từ assembly :-)

Answer 3

Từ hoàn toàn dễ sử dụng, tôi chỉ đơn giản là tải các tệp nguồn lên máy chủ và quên việc biên dịch trước.

Đây là những gì tôi làm cho tất cả các trang web mà tôi quản lý, ngay cả những trang web lớn. Tôi cố gắng tạo thói quen nhấn các phần quan trọng của ứng dụng để đảm bảo mọi thứ hoạt động (và biên dịch chúng trong khi tôi đang ở đó).

Và đây là một suy nghĩ khác. Nếu trang web ở chế độ công khai, bạn có thể để mất w3c link checker trên đó. Điều này sẽ có tác dụng biên dịch mọi trang mà nó truy cập. Và đó là một điều tốt đẹp để làm anyway để đảm bảo bạn không có bất kỳ liên kết bị hỏng.

Nói một cách đơn giản, tôi cho rằng các kiểm tra định kỳ này gần như loại bỏ vấn đề biên dịch truy cập lần đầu chậm từ người dùng của bạn. Và vì nó là một thói quen tốt để làm theo anyway, nó đã làm việc ra tốt cho tôi.

Answer 4

tôi tải lên tập tin mà không precompiling: theo cách này, vì mã của tôi là rất buggy, tôi có thể sửa chữa nó bằng Notepad ++ trực tiếp từ máy chủ

Ngoài ra, Visual Web Developer 2008 (miễn phí một) không có tùy chọn biên dịch :-P

Answer 5

Tôi không đồng ý với hầu hết các câu trả lời được đưa ra cho điểm này. Có nhiều ưu điểm để biên dịch trước việc đăng các tệp tin đặc biệt, không phải là ít nhất là mã trong môi trường sản xuất và thử nghiệm ở lại đồng bộ nhiều hơn hoặc ít hơn. Biên dịch trước làm cho nó chắc chắn rằng mã bạn đã thử nghiệm là mã sẽ sản xuất mỗi lần.

Sự cố bạn đang gặp phải không phải là một trong những biên dịch trước khi biên dịch đầu tiên. Thay vào đó, nó xuất phát từ loại điều khiển nguồn bạn đang sử dụng. Nếu tôi phải đoán (và tôi làm), tôi sẽ nói rằng bạn đang chạy Visual SourceSafe.Nếu bạn chuyển sang hệ thống kiểm soát nguồn đã tạo phân nhánh và hợp nhất tầm thường thì bạn có thể tách mã của mình thành các chi nhánh stable và development. Sửa lỗi xảy ra với các chi nhánh dev (sau đó được sáp nhập trở lại chi nhánh stable khi đã được xác thực). Bằng cách đó, mã chưa được kiểm tra hoặc không sẵn sàng cho thời gian nguyên tố không kết thúc trên máy chủ sản xuất và bạn luôn có một bản sao của stable được thiết lập để hoạt động.

Answer 6

Việc đầu tiên mà nói đến cái tâm là:

1. bí mật kinh doanh vấn đề
2. vấn đề an ninh
3. Sloppy Joe Moe sự (Lazy, muốn Careless và đáng thương được phát triển)

4. Ad Hoc Hacking the Code không thể kiểm soát được.

   • PreCompiled Mã an toàn và hiệu quả chạy trên .Net Framework ở định dạng được quản lý.
   • UnCompiled Mã được triển khai bởi các tân binh không dành thời gian để xem xét nhiều vấn đề liên quan đến mã không an toàn chạy ít hiệu quả hơn cho người dùng cuối.

Người dùng cuối là bên liên quan và là đối tượng của Trách nhiệm trách nhiệm tài chính của một nhà phát triển. Nhà phát triển nên tận dụng mọi cơ hội để cải thiện hiệu quả sản phẩm của họ.

TUYÊN BỐ TỪ CHỐI: Các nhận xét này được ghi là "nguyên trạng" và tôi không đưa ra cảnh báo nếu bạn đánh vần kiểm tra tôi.

Trân trọng,

DrFunkie

Bad Speller, nhưng nhà phát triển damn tốt. :)