2012-02-28 9 views
8

Tôi có một trình cài đặt WiX hợp lý lớn (250 Mb cộng) và tôi đang cố gắng tìm ra một chiến lược nâng cấp phù hợp.Tôi nên xử lý các nâng cấp sản phẩm trong trình cài đặt WiX như thế nào?

Hầu hết các tệp trong trình cài đặt sẽ không thay đổi và chúng tôi không muốn phân phối toàn bộ gói khi chỉ có một hoặc hai tệp đã thay đổi.

Tôi đã xem xét các nâng cấp lớn và nhỏ và sự hiểu biết của tôi là nâng cấp lớn sẽ xảy ra nếu ID sản phẩm thay đổi, miễn là ID nâng cấp vẫn giữ nguyên và các bản vá nâng cấp nhỏ có thể được sử dụng nếu cả hai giá trị này ở lại giống nhau.

Cảm giác của tôi là nâng cấp nhỏ bằng bản vá sẽ là tùy chọn tốt nhất để xử lý các trường hợp chỉ có một vài tệp thay đổi và chỉ để xây dựng lại toàn bộ trình cài đặt khi số lượng tệp thay đổi đáng kể.

Tôi đã thử nghiệm điều này bằng cách sử dụng "ngọn đuốc" để tạo tệp "wixmst" dựa trên sự khác biệt giữa hai tệp "wixpdb", sau đó tạo bản vá từ đó. Tuy nhiên, tôi thấy rằng tôi chỉ có thể vá từ phiên bản này sang phiên bản khác (ví dụ: từ 1.0.0 đến 1.0.1, sau đó là 1.0.1 đến 1.0.2 nhưng không phải là từ 1.0.0 đến 1.0.2). Có thể nhắm mục tiêu phiên bản tối thiểu cho bản vá và hỗ trợ mọi phiên bản ở trên không?

Trả lời

8

Vá là một nỗi đau để sẵn sàng cho rất nhiều khi bạn học cách làm chủ nó. Đây là một chiến lược khác có thể phù hợp với bạn. Chia MSI của bạn thành 2 MSI (Microsoft gọi Micropackages này). Có một cơ sở MSI có chứa số lượng lớn nội dung của bạn mà dự kiến ​​sẽ không thay đổi và MSI thứ hai nhỏ hơn nhiều có chứa các tệp của bạn mà bạn mong đợi có khả năng khuấy động cao.

Sau đó, sử dụng Burn là trình khởi động để xử lý các chuỗi này lại với nhau và gỡ cài đặt chúng lại với nhau. Điều này tương tự như những gì Visual Studio làm.

Bây giờ bạn chỉ có thể gửi các bản nâng cấp lớn cho chiếc MSI thứ hai của mình.

+0

Tôi đã suy nghĩ về việc tạo các MSI riêng biệt để có thể chuyển tiếp. Cảm ơn lời khuyên của bạn. –

2

Tôi tin rằng có thể vá trong kịch bản bạn đã mô tả ở trên, miễn là các bản vá có thể gỡ cài đặt. Một kịch bản ví dụ sẽ là:

  1. Cài đặt msi (v1.0)
  2. Install MSP (v1.0 - v1.1)
  3. Uninstall MSP (trở lại v1.0) sau đó cài đặt MSP (v1 .0 - v1.2)

Để biết thêm thông tin về các bản vá lỗi uninstallable, xem tài liệu wix: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm và tài liệu Windows: http://msdn.microsoft.com/en-us/library/aa372102.aspx.

Lưu ý rằng để tạo các bản vá có thể gỡ cài đặt, có một số hạn chế nhất định và bạn phải ở WiX 3.0 trở lên.

Giống như Christopher đã đề cập, việc vá có thể là một nỗi đau. Tôi đã thấy rằng trong nhiều trường hợp, người quản lý của tôi có thể yêu cầu khả năng nâng cấp bản vá khi tất cả những gì họ thực sự có ý nghĩa là người dùng có thể nâng cấp mà không cần cài đặt thủ công trước, có thể được thực hiện bằng nâng cấp lớn.

Điều đó nói rằng, nếu bạn có khách hàng yêu cầu nhiều bản cập nhật nhỏ được tải xuống thường xuyên, thì việc vá có thể đáng để nỗ lực thêm.

+0

Một cái gì đó khác tôi chỉ nghĩ đến là bạn phải xem xét quá trình xây dựng của bạn. Các nhà quản lý có thể yêu cầu một bản vá đơn giản chỉ vì họ không nghĩ rằng họ phải làm nhiều thử nghiệm hồi quy nếu chỉ có một vài tệp thay đổi. Tuy nhiên nếu bạn phiên bản dll của bạn với mọi bản dựng và cố gắng tạo bản vá giữa hai bản dựng, sau khi cài đặt bản vá, bạn sẽ thấy thay đổi phiên bản trên mỗi dll, mặc dù kích thước bản vá có thể nhỏ. Khi người quản lý và người kiểm tra thấy điều này, điều đó có thể gây bất ngờ cho họ. – BryanJ

+0

Cảm ơn bạn đã trả lời. Chúng tôi đã có một cái gì đó làm việc với các bản vá mà sẽ đủ cho bây giờ. Tuy nhiên, về lâu dài, tôi nghĩ tôi đang hướng tới đề xuất của Christopher về việc tạo ra hai MSI. –

0

Trong khi Christophers trả lời là tuyệt vời ở chỗ anh ta gợi ý bootixpper wix, tôi sẽ không khuyến khích con đường thực hiện cập nhật lớn cho gói "high-churn".Vấn đề là sau khi bạn đã thực hiện bản vá bootstrapping của bạn mà nội bộ thực hiện một nâng cấp lớn của libs dễ bay hơi của bạn trong HighChurn.msi từ phiên bản v1.0 đến v1.1, bootstrapper sẽ không, theo kiến ​​thức của tôi, cài đặt lại trước đó gói HighChurn.msi trong v1.0.

Có một đường dẫn khác: bạn chắc chắn có thể tạo ra các bản vá nhằm nhắm mục tiêu phát hành gói chính của bạn. Với những gì bạn viết Tôi không hoàn toàn chắc chắn, nhưng nếu bản vá 1.2 của bạn chỉ có thể được áp dụng cho 1.1, thì có lẽ bạn đã phân biệt 1.2 của bạn chỉ với 1.1 và không phải là 1.0.

Đây là hướng dẫn gọn gàng như thế nào để tạo ra các bản vá lỗi: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/

Thực hiện theo hướng dẫn đó, làm thay các bản vá lỗi ([PatchFamily/@ thay thế], nó sẽ làm mất hiệu lực của tất cả mọi thứ mà v1.2 v1.1 vận chuyển, vì vậy bạn về cơ bản buộc phải tạo v1.2 vá v1.0 và không v1.1), và thêm cờ này vào phần tử bản vá để nhắm mục tiêu bản phát hành chính, mặc dù các phiên bản cao hơn có mặt: Patch/@MinorUpdateTargetRTM="yes". Luôn luôn phân biệt các bản vá lỗi của bạn với trình cài đặt bản phát hành (HighChurn.msi v1.0), không bao giờ chống lại trình cài đặt bạn đã sử dụng cho bản vá (HighChurn.msi v1.1).

Có một số trường hợp bạn có thể muốn yêu cầu nâng cấp nhất định cho các bản vá: Ví dụ, bản vá 1.1.1 yêu cầu gói dịch vụ 1.1 được cài đặt trên bản phát hành 1.0.

Một từ cuối cùng về vá dữ liệu dễ bay hơi của bạn (Tôi giả sử các thư viện được phiên bản ở đây): Bạn có thể muốn để mắt đến các thư viện mà bạn có thể thay thế trong bản vá. Sau đó, bạn có thể tạo các bản vá với rất ít dữ liệu, bằng cách chỉ cho các thư viện thay đổi một phiên bản cao hơn. Nếu bạn tăng phiên bản trên tất cả các thư viện của mình, tất cả các thư viện sẽ được vá, dẫn đến các bản vá lớn hơn. Điều này có thể đòi hỏi một công việc xây dựng phức tạp hơn một chút (Thiên Chúa biết nó đã làm cho chúng ta).