2012-12-31 20 views
6

Tôi đã gặp rất nhiều vấn đề khi xuất bản như khi bạn cần thực hiện các thay đổi nhỏ trên mã, đôi khi tệp DLL được tạo ra (tệp dll ví dụ: default.aspx.CS khi được xuất bản) không thể được IIS nhận ra rằng codebehind là sai hoặc một cái gì đó. Xin lỗi vì đã không nhớ chính xác thông báo lỗi. Tôi hy vọng bạn biết những gì tôi có ý nghĩa vào thời điểm này.Xuất bản ASP.NET WebSite so với Sao chép?

Do đó, tôi thường thực hiện thao tác đơn giản Copy Paste thay vì Xuất bản.

Bạn có thể cho tôi biết tôi thiếu gì bằng cách KHÔNG sử dụng phương thức Xuất bản không? Làm cách nào để xuất bản tốt hơn? Hoặc bạn thích cái nào hơn, tại sao?

Về cơ bản, đây là tình huống ưu và nhược điểm.

Thankyou

+0

Xuất bản cũng bị ảnh hưởng bởi loại ứng dụng bạn chọn triển khai; một ứng dụng trang web cho phép bạn chỉ xuất bản một vài tệp, so với Ứng dụng web, nơi bạn thường cần triển khai ASPX và DLL thích hợp vào các thư mục chính xác. Đọc http://stackoverflow.com/questions/398037/asp-net-web-site-or-web-application để biết thêm thông tin. – dash

+0

Cảm ơn bạn đã bình luận. Nhưng điều này không giúp tôi chính xác. Ví dụ, có sự khác biệt nào về hiệu suất không? Có lẽ, nó có thể được mùa hè là "Làm ứng dụng web thay vì xuất bản một trang web" –

Trả lời

13

Vâng, nó phụ thuộc vào những gì bạn có ý nghĩa bởi "bản sao":

Với Publishing bạn có các tùy chọn để pre-compile toàn bộ hoặc một phần của ứng dụng của bạn. Bạn có thể publish vào thư mục cục bộ trong hệ thống tệp của mình (thay vì mục tiêu/máy chủ lưu trữ) và sau đó sao chép (các) tệp được cập nhật. Nếu bạn đang thực hiện thay đổi "mã sau" (C#/vb code), điều này có nghĩa là bạn có thể chỉ cần "sao chép"/ghi đè dlls. Đi mà không nói rằng nếu bạn đã thực hiện thay đổi "nội dung" (html/dao cạo/script/etc), thì bạn cũng cần sao chép/ghi đè lên những thay đổi đó.

Nếu bạn mới triển khai, bạn có thể thấy mình chỉ cần sao chép/ghi đè "mọi thứ" là cách an toàn nhất để đi. Khi bạn nhận được nhiều kinh nghiệm hơn, bạn sẽ "nhận ra" tài sản nào bạn chỉ cần cập nhật (một hoặc một vài mã dlls và hoặc nội dung, thay vì "mọi thứ"). Không có phép thuật cho điều này, thông thường, chỉ là nhìn vào dấu thời gian của dll/file sau khi bạn đã published (cục bộ) hoặc rebuild ứng dụng web của bạn.

Tôi khuyên bạn nên thực hiện local publish để bạn có thể xem những gì thực sự cần thiết trên máy chủ của mình. Các tệp được xuất bản lên hệ thống tệp/thư mục cục bộ của bạn là những gì cần phải có trên máy chủ/máy chủ của bạn. Làm như vậy sẽ hình dung và loại bỏ bất cứ điều gì "bí ẩn" có là Publishing:

  • bạn sẽ thấy những gì đang thực sự cần thiết (trên máy chủ của bạn) so với những gì không
  • bạn sẽ thấy timesstamps tập tin mà sẽ giúp bạn nhận ra những tệp nào đã thực sự thay đổi so với những tệp không phải (và do đó không cần phải cập nhật).
  • khi bạn bị treo, bạn sẽ không cần phải "sao chép"/ftp "mọi thứ" và chỉ cập nhật các tệp đã thực sự được sửa đổi (chỉ).

Vì vậy, "bản sao" có thể có nghĩa là ở trên, hoặc nếu bạn đang nói rằng bạn chỉ đơn giản là sẽ sao chép tất cả các mã phát triển của bạn (nguyên (vb/cs)html/cs/vb) đến máy chủ của bạn, sau đó có nghĩa là trang web của bạn sẽ dynamically compiled vì mỗi nguồn là cần thiết/yêu cầu (không có gì là pre-compiled). Cũng "dễ" nhưng bạn mất pre-compilation có nghĩa là có sự chậm trễ khi mỗi trang web của bạn được yêu cầu/cần thiết (ASP.net cần phải biên dịch động). Ngoài ra, bạn cũng đang hiển thị mã nguồn của mình trên máy chủ. Nó có thể không có ý nghĩa nhiều tùy thuộc vào tình hình của bạn, nhưng nó là một điều nữa để xem xét.

Dưới đây là thêm info on pre-compilation and options.

+0

câu trả lời của bạn là một câu trả lời rất chi tiết, mà nói với tôi rằng bạn hiểu rõ quá trình triển khai. Tuy nhiên, có một điều tôi muốn làm rõ: Tôi nghĩ rằng nó là tốt đẹp để biết những tập tin thực sự cần thiết để được cập nhật; tuy nhiên, khi nhóm của tôi cập nhật một trang web, tôi sẽ cập nhật toàn bộ trang web, chứ không chỉ thay thế một số tệp DLL ... Cách này hoạt động, nhưng dễ bị lỗi của con người. Tôi muốn tải lên toàn bộ ứng dụng đã thử nghiệm lên IIS, giải nén nó, sau đó trỏ IIS vào thư mục mới. Bạn nghĩ như thế nào? –

+0

@ Hoàng Long IMHO, giống như "mọi thứ". Ftp mọi thứ sẽ ít bị các vấn đề khác - ví dụ cho phép ứng dụng trên các thư mục _new_, các vấn đề về trang trại/sao chép, vv Ngoài ra, cách tiếp cận đó dường như chỉ khả thi/khả thi nếu bạn có quyền truy cập trực tiếp/trần kim loại vào máy chủ. Một cách tiếp cận khác là 'WebDeploy' làm mọi thứ theo cách thông minh cho bạn (tìm ra những thay đổi cho bạn). Nếu nó có sẵn cho bạn, đó là một cái gì đó đáng xem xét. – EdSF

+0

có, nó gần giống như "ftp tất cả mọi thứ" (ngoại trừ việc nó sẽ không có tập tin dư thừa, vì toàn bộ thư mục ứng dụng web được thay thế). WebDeploy có vẻ là một sự lựa chọn thú vị mặc dù ... Tôi sẽ chơi với nó –

6

Giả sử chúng ta xem xét một trang aspx và mã aspx.cs của nó đằng sau tập tin, có ba cách khác để triển khai trang web của bạn:

  1. Bạn có thể sao chép cả hai để IIS. Aspx sẽ được biên dịch thành .cs theo yêu cầu đầu tiên và sau đó cả hai .cses sẽ được biên dịch thành một temp .dll
  2. Bạn có thể "xuất bản" lên iis, điều này sẽ biên dịch mã đằng sau lớp thành .dll nhưng sẽ sao chép aspx bị ảnh hưởng. Các aspx sẽ được dịch sang .cs và sau đó để .dll theo yêu cầu đầu tiên
  3. Bạn có thể "xuất bản" trang web và sau đó tự biên dịch trước nó bằng aspnet_compiler. Xuất bản sẽ biên dịch mã phía sau để .dll như trước đây nhưng sau đó biên dịch trước sẽ xóa các tệp .aspx của bạn bằng cách xóa nội dung của chúng và di chuyển mã đã biên dịch sang một .dll khác.

Cả ba mô hình đều có ưu và khuyết điểm của chúng.

Đầu tiên là cách dễ dàng nhất để cập nhật dần dần nhưng đồng thời là phần mở rộng nhất để sửa đổi không mong muốn.

Thứ hai cũng rất dễ dàng, có thể được gọi từ vs, nó đóng cửa khả năng một số sửa đổi không mong muốn tại máy chủ nhưng .aspxses vẫn cần thời gian để biên dịch theo yêu cầu đầu tiên

Thứ ba mất thời gian và một số thao tác thủ công nhưng ngăn chặn bất kỳ thay đổi nào và cũng tăng tốc độ hâm nóng của trang web vì việc biên soạn tài sản là không cần thiết. Nó là tuyệt vời cho môi trường chia sẻ.

+0

Cảm ơn bạn rất nhiều. –

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