2009-03-12 22 views
7

Gần đây tôi đã phải đấu tranh với một dự án cài đặt (sử dụng sản phẩm phổ biến nhất để tạo cài đặt: InstallShield) để làm cho nó hoạt động để nâng cấp sản phẩm (di chuyển từ phiên bản này sang phiên bản khác). Cuối cùng hóa ra tôi cần sử dụng một mã gói dài nhưng đã sử dụng một số mã khác. Nó lãng phí 8 giờ của tôi (thử nghiệm và gỡ lỗi trình cài đặt là một nỗi đau).Bạn có nghĩ rằng việc viết chương trình cài đặt có thể/nên đơn giản hơn không?

Bây giờ nếu tôi nghĩ về nó, một khi bạn đã hoàn thành phần cứng của mã hóa, tất cả những gì bạn muốn là các ứng dụng chính xác, thư viện được sao chép vào máy tính đích và người dùng chỉ cần chạy nó. Giai đoạn. Nhiệm vụ dường như đơn giản này thường trở thành một công việc khó khăn và "bị đóng cửa để kết thúc ngày" làm cho khó khăn hơn nữa.

  1. Đừng nghĩ rằng bạn triển khai một sản phẩm được làm chết tiệt khó khăn trên cửa sổ mà cần phải có được đơn giản hơn? (hoặc trình cài đặt thực sự xứng đáng với nhiều sự chú ý và tôi chỉ phát điên vì điều đó?)

  2. Bạn đã từng sử dụng các sơ đồ triển khai đơn giản hơn như "sao chép thư mục đến bất cứ nơi nào bạn muốn và chạy exe. Khi bạn muốn xóa nó, chỉ cần xóa thư mục! "? Nó có hiệu quả và làm mọi thứ đơn giản hơn?

+1

8 giờ? Đó là khá nhanh chóng! Mã hóa cài đặt InnoSetup cuối cùng của tôi mất TEN DAYS, và nó vẫn không hoạt động ngay trên Vista. Nó đã cài đặt thư viện ứng dụng, một số ứng dụng mẫu, tạo cơ sở dữ liệu, cài đặt và bắt đầu dịch vụ 2 cửa sổ và xuất bản trang web nhưng 10 ngày vẫn còn quá dài ... –

Trả lời

7

Đau đớn vì bạn cần phải vật lộn với trình cài đặt cửa sổ vì lợi ích của khách hàng của bạn. Nếu không, bạn sẽ cần phải làm nhiều việc hơn nữa để

  1. Xử lý các tình huống xảy ra lỗi trong khi cài đặt. Bạn sẽ làm gì tiếp theo?
  2. Xử lý các vấn đề như bảo mật. Điều gì sẽ xảy ra nếu người dùng cài đặt không có quyền đối với các thư mục/khóa đăng ký cụ thể?
  3. đúng dọn dẹp sau khi cài đặt
  4. Patching và quản lý bản vá
  5. Performing thêm nhiệm vụ - đăng ký các đối tượng COM, tạo cơ sở dữ liệu, tạo phím tắt, tạo ra một shotcut bỏ cài đặt và vân vân
  6. Cài đặt điều kiện tiên quyết
  7. phép người dùng chọn các tính năng để cài đặt

Kịch bản tùy chỉnh của riêng bạn để giải quyết tất cả những vấn đề này cuối cùng trở thành vấn đề lớn hơn bản thân cài đặt!

Tôi khuyên bạn nên xem Wix. Nó không chính xác là trò chơi của trẻ nhưng nó được hoàn thành công việc. Nếu bạn cài đặt Votive như một phòng thu trực quan, bạn sẽ có được intelliSense để giúp bạn xây dựng các thẻ một cách chính xác. Với tệp trợ giúp, bạn có thể tạo các cài đặt linh hoạt khá chức năng

+1

Tôi đã sử dụng cả trình xây dựng cài đặt WiX và GUI. Tôi thấy WiX dễ sử dụng hơn nhiều vì kịch bản cài đặt trở thành một đoạn mã khác được viết bằng ngôn ngữ khai báo. Bạn có thể thấy logic ở một nơi thay vì liên tục điều hướng một cấu trúc cây cố gắng ghép mảnh logic lại với nhau – Ferruccio

+0

Tất cả với Ferruccio trên cái này. WIX là phương pháp triển khai của nhà phát triển. MSI không, và sẽ không có ý nghĩa với hầu hết các nhà phát triển. Triển khai là một lĩnh vực nằm giữa phát triển và quản trị hệ thống. Như vậy nó là "vượt qua vực thẳm" giữa thế giới của người dùng cuối và của các nhà phát triển ứng dụng. WIX được "viết dưới dạng mã nguồn" (nếu chúng ta có thể gọi nguồn XML) và sau đó được biên dịch và liên kết theo cách "nhà phát triển" bình thường. Nó cũng rất ổn định và được viết tốt. Nếu bạn là một nhà phát triển và cần phải triển khai và bạn có một sự lựa chọn, không có sự lựa chọn, đó là WIX. –

0

Đối với chính xác lý do bạn nêu, chúng tôi đã thực hiện phát hành nội bộ, xử lý bởi các đội dev bằng cách sao chép các tập tin cần thiết, và sau đó thực hiện phần còn lại của thiết lập sử dụng kịch bản và các tiện ích riêng của chúng tôi.

Tuy nhiên, đối với người dùng cuối, bạn phải có một số loại trình hướng dẫn nắm giữ tay, tôi đã sử dụng trình cài đặt MS từ bên trong VS và thấy nó khó hiểu và clunky. Sau trải nghiệm đó tôi đã tránh được nỗi đau bằng cách khiến người khác thực hiện bước cài đặt. Bất cứ ai có thể giới thiệu một trình cài đặt Net tốt.

0

Tôi sử dụng Installshield và nếu bạn không cố gắng làm bất cứ điều gì quá lạ mắt (tại sao bạn) sau đó nó khá thẳng thắn - thiết lập cài đặt ban đầu, chọn tệp, thiết lập phím tắt và tạo setup.exe.

Tất cả các bản cập nhật trong tương lai tôi xử lý bên trong mã của tôi - nhiều thuận hơn cho người dùng

+0

Vì vậy, nếu phiên bản 1.0 được cài đặt trên máy của người dùng và bây giờ anh ấy muốn cài đặt phiên bản 2.0. anh cần phải thực hiện những bước nào trong trường hợp của mình? (Tôi tin rằng anh ta sẽ cần phải gỡ bỏ cài đặt phiên bản 1.0 đầu tiên nếu bạn không sử dụng nâng cấp trình cài đặt) – Hemant

+0

Không hoạt động trên Vista. Không giống như trình cài đặt, ứng dụng của riêng bạn không thể (và không nên) ghi trong \ Program Files \ – MSalters

+0

@MSalters: Hoạt động tốt trên Vista (và tất cả các phiên bản khác của NT khi không phải là Quản trị viên) - bạn nên cung cấp cài đặt/cập nhật của mình.exe một biểu hiện UAC để nói "tôi cần độ cao" để được tốt đẹp cho người sử dụng, mặc dù. Tự cập nhật chỉ cần sử dụng một quy trình bên ngoài (* sau * kiểm tra phiên bản mới!). –

3

Vâng, nó dễ dàng hơn nhiều nếu bạn xây dựng trình cài đặt của bạn đầu tiên, làm cho nó một phần của hệ thống xây dựng của bạn, và để cho nó phát triển với bạn dự án.

Tôi đồng ý, trình cài đặt cửa sổ làm tôi phát điên. Nhưng có rất nhiều tình huống mà xcopy không giải quyết được. Đôi khi bạn muốn cài đặt cho nhiều người dùng, không chỉ người dùng hiện tại. Đôi khi bạn phải đăng ký các đối tượng COM. Đôi khi bạn phải thực hiện toàn bộ các thay đổi đối với hệ thống, chẳng hạn như đăng ký dịch vụ để chạy khi khởi động, kết nối với máy chủ mạng, vv Đôi khi bạn có người dùng không thể sử dụng dấu nhắc lệnh. Và bạn luôn muốn có thể đóng vai trò toàn bộ trở lại khi một cái gì đó thất bại nửa chừng.

Toàn bộ cơ sở dữ liệu MSI có tiếp cận cách tốt nhất để thực hiện không? Tôi không chắc. Tôi có thọc đinh vào đầu mình hơn là viết một dòng mã WiX khác không? Có lẽ. Nhưng bạn phải thừa nhận, nó làm một công việc tốt để làm mọi thứ bạn có thể muốn. Và khi không có tùy chọn CustomAction.

Thực sự, những gì tôi muốn thấy, là tài liệu tốt hơn (thực sự, hành động loại 50 là gì? Làm cách nào để đặt tên cho nó?) Và nhiều mẫu dễ sử dụng hơn.

Và bí danh nhóm người dùng WiX thực hiện tốt công việc trả lời câu hỏi.

Bạn nên đọc số blog của RobMen. Anh ấy làm tốt công việc giải thích tại sao mọi thứ lại như vậy. Anh ấy đã làm rất nhiều suy nghĩ (nhiều hơn bất kỳ con người nào) về các vấn đề của thiết lập.

+0

Bạn có quyền làm cho phần cài đặt của hệ thống xây dựng nhưng khi tôi nói "gần hơn đến ngày kết thúc", tôi có nghĩa là "gần với ngày kết thúc phát triển" có nghĩa là trước khi xây dựng bản thử nghiệm đầu tiên. Gần đây tôi đã nghe nói về WiX. Nó đơn giản hay minh bạch hơn? Tôi có nên cho nó đi không? – Hemant

+0

Vâng, bạn nên đọc hướng dẫn và tự quyết định. Xem: http://www.tramontana.co.hu/wix/ –

+0

Cá nhân tôi nghĩ InnoSetup dễ sử dụng hơn: http://www.innosetup.com/isinfo.php –

1

"Một khi bạn đã thực hiện tất cả các phần cứng của mã hóa", bạn đã không làm một điều nếu tất cả các công việc khó khăn của bạn không cài đặt. Trình cài đặt cần được xây dựng và thử nghiệm trên mỗi bản dựng hàng đêm, mỗi đêm, hầu như từ ngày đầu tiên. Bạn cần kiểm tra xem trình cài đặt có thể được xây dựng và chạy hay không và bạn cần phải xác minh việc cài đặt.

Nếu không, ai quan tâm bạn đã thực hiện bao nhiêu công việc khó khăn - không ai sẽ thấy công việc của bạn nếu nó không cài đặt!

Lưu ý rằng điều này cũng áp dụng cho XCOPY.

Một điều nữa: thử nghiệm QA của bạn là gì nếu chúng không kiểm tra những gì trình cài đặt của bạn cài đặt? Bạn phải kiểm tra những gì khách hàng sẽ nhận được!

+0

Tôi không chắc chắn những gì mang đến cho bạn một ấn tượng rằng * thử nghiệm QA * của chúng tôi không liên quan đến việc thử nghiệm trình cài đặt. Khi tôi nói "gần đến ngày kết thúc", tôi có nghĩa là "gần ngày kết thúc phát triển" được theo sau bởi giai đoạn xác nhận sản phẩm mà thực hiện chính xác điều này "" thử nghiệm những gì khách hàng nhận được "! – Hemant

+2

Thú vị. Tôi quen với việc thử nghiệm trong suốt chu kỳ phát triển; không chờ đợi cho đến khi phát triển là "hoàn thành" để bắt đầu tìm lỗi. –

2

Cá nhân, tôi chủ yếu đồng ý với @Conrad và @John Saunders. Tôi đã viết về chủ đề này một thời gian dài trước đây trên old blog của tôi. Tôi nghĩ @jeffamaphone có một điểm về sự phức tạp của Windows Installer (và sự chú ý của tôi để thiết lập, nói chung) nhưng tôi tin rằng Windows Installer vẫn là lựa chọn tốt nhất cho tất cả các cài đặt trên Windows.

4

Tôi không nghĩ rằng bạn sẽ thấy quá nhiều bất đồng ở đây, đặc biệt là về MSI. Tôi nghĩ rằng một điều cần lưu ý là để xem cách nhiều chương trình đang sử dụng các tập tin MSI những ngày này. Hiển thị hộp thoại giao diện người dùng và thực hiện các lựa chọn cấu hình phức tạp với MSI rất yếu do cách cài đặt Windows Installer, vì vậy tôi đã nhận thấy rất nhiều chương trình được chia thành một loạt các MSI con được cài đặt với giao diện người dùng tối thiểu chương trình cài đặt gốc. Trình hướng dẫn thiết lập SQL Server 2008 thực hiện việc này. UPS WorldShip thực hiện việc này. Và Sơn.NET này cũng vậy - wizard bạn thấy là một ứng dụng Windows Forms, và nó tự khởi chạy msiexec (bạn có thể thấy giao diện người dùng tối thiểu của Windows Installer bật lên trên đầu cửa sổ thuật sĩ trắng), truyền bất kỳ tham số cấu hình nào như thuộc tính đối số cho msiexec.

Một trường hợp phổ biến mà điều này xuất hiện là nơi ai đó được giao nhiệm vụ xây dựng trình cài đặt cho ứng dụng có cả máy chủ và máy khách. Nếu người dùng chọn tùy chọn máy chủ, thì họ có thể hoặc không muốn cơ sở dữ liệu mới được cài đặt, có nghĩa là cài đặt SQL Server. Nhưng bạn không thể chỉ cần cài đặt SQL Server trong khi bạn đang ở giữa cài đặt của riêng bạn bởi vì Windows Installer sẽ không cho phép bạn làm điều đó. Vì vậy, một giải pháp thường xuyên là viết một ứng dụng hiển thị trình hướng dẫn cho phép người dùng định cấu hình tất cả các tùy chọn thiết lập và sau đó ứng dụng của bạn khởi chạy tệp MSI khi cần cho SQL Server, ứng dụng máy chủ và ứng dụng khách của bạn ở mức tối thiểu Chế độ giao diện người dùng; về cơ bản, tránh các khía cạnh "tính năng" của Windows Installer hoàn toàn và di chuyển nó lên đến mức MSI. Cài đặt nhiều gói của 4.5 có vẻ là một bước xa hơn theo hướng này. Định dạng này cũng đặc biệt hữu ích nếu bạn cũng cần lặp trong trình cài đặt không phải của MSI từ bên thứ ba như một phần của quá trình cài đặt, như cài đặt trình điều khiển máy in cho một số máy in bán kỳ lạ.

Tôi cũng đồng ý rằng Windows Installer thiếu hỗ trợ tích hợp cho các tình huống triển khai chung. Nó có nghĩa là cho khi thiết lập không phải là XCOPY, nhưng họ dường như bỏ lỡ một thực tế là thiết lập thường không chỉ là "tập tin + phím tắt + khóa registry," một trong hai. Không có các hành động tích hợp để thiết lập các trang Web IIS, đăng ký chứng chỉ, tạo và cập nhật cơ sở dữ liệu, thêm các assembly vào GAC, v.v. Tôi đoán họ đưa ra ý kiến ​​rằng một số điều này sẽ xảy ra trong lần chạy đầu tiên thay vì là một phần giao dịch của quá trình cài đặt. Các công cụ và tài liệu có sẵn miễn phí đã trở nên khủng khiếp - hoàn toàn kinh khủng - cho phần tốt hơn của một thập kỷ. Cả hai vấn đề này phần lớn được giải quyết bởi dự án WiX và DTF (cho phép bạn cuối cùng sử dụng các hành động tùy chỉnh mã được quản lý), đó là lý do tại sao chúng tôi rất biết ơn Rob Mensching và công việc của người khác về dự án đó.

Tôi đã có cùng trải nghiệm. Cài đặt có thể nhanh chóng hút thời gian của bạn khi bạn đi xuống hố thỏ "Ôi Chúa ơi, tôi đoán tôi phải trở thành một chuyên gia trong số điều này cũng có nghĩa là". Tôi thứ hai ý tưởng đó là tốt nhất để giải quyết nó sớm trong dự án của bạn và giữ nó được duy trì như là một phần của quá trình xây dựng của bạn. Bằng cách này, bạn có thể giúp tránh tình huống đó khi phát triển một sản phẩm có thể gỡ cài đặt thực tế. (Trac là một ví dụ về điều này trong một thời gian, đòi hỏi phải theo dõi các phiên bản cụ thể của các thư viện Python lạ.)

(Tôi có thể đi về cách Windows Installer đôi khi quyết định sử dụng ổ đĩa USB chậm, bên ngoài của tôi như một nơi để giải nén các tập tin của nó, làm thế nào nó có vẻ ngồi ở đó không làm gì trong vài phút khi kết thúc trên các máy tính đã cài đặt nhiều MSI, và thanh tiến trình đó tự cài đặt lại bao nhiêu lần trong một lần cài đặt là điều ngu ngốc nhất mà tôi có đã từng thấy, nhưng tôi sẽ tiết kiệm những số tiền đó trong một ngày khác. =)

Hai xu của tôi; xin lưu ý rằng tôi thực sự chỉ biết đủ về Windows Installer để làm thiệt hại, nhưng đây là đánh giá của tôi đến từ một nhà phát triển kinh doanh nhỏ chỉ cố gắng sử dụng nó. Chúc may mắn!

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