Software Deployment

why not just create a feature for each package and set the package 3 as its parent.. that way you wouldnt come into any problems when upgrading the applications

I really don't know, that's why I ask you the question :-)

I think you're right, but... could you explain me what are the merge module for ? Can't we all replace merge modules by features ?

I'm new in packaging, and I have a lot of problems to understand that... :-(

Thx rikx2


Ben

http://sqljunkies.com/How%20To/484612DD-0416-42C8-9695-9572CA762ED6.scuk
or better yet go to msdn and search for merge modules

Thx, I know what is a Merge module (I'm reading all the MSDN MSI examples) but I have some problems to understand WHEN it's good to use them :-/

But I can precise more my question :

What sort of package would you build in this case :

I don't want to build patchs or updates. I just want 3 Packages (Package1, 2 and... 3) and if I have some modifications, I re-build my packages.

For example, I have 3 packages : Pack1_v1.msi, Pack2_v1.msi and Pack3_v1.msi.
(Pack1 and 2 are included in Pack3).

I install the Pack3_v1.msi.

Then, I modify something in the pack1 -> Pack1_v2.msi, Pack2_v2.msi and Pack3_v2.msi

Now, I want to upgrade the version I have installed :
I have 3 choices, install the Pack1_v2.msi, Pack2_v2.msi or Pack3_v2.msi. (Pack1_v2 is included in each ones).

What should I use ? What should be the package's type of my 3 packages ?
Major Upgrade packages ? Merge modules ? That's my question in fact :-)

Thx if you can explain me how to choose it...


Ben

Can these packages run indenpently?
Would there be a case in which you would only install pack1 or pack2?

I would suggest taking rixk2's advice on creating one feature for each. This will allow for an eaiser update and organization of the install, as well as seperate sections for repair. I may be missing it, but I do not see the need to create 3 seperate MSI files if you intend for all of them to always be on the machine at the same time.

When updating you will then have the option of creating a MSP or creating a new MSI with the updates and then using the UpgradeTable to uninstall the old version and install the new just by running the install of the new app.

Ok, I didn't precise well :-)

First of all, I create 3 packages (which can be used INDEPENDENTLY) :
Pack1_v1
Pack2_v1 (which includes Pack1_v1)
Pack3_v1 (which includes Pack2_v1 - and consequently Pack1_v1)

HOWEVER
- Pack1 MUST be installed if you want to use apps included in Pack2 or 3 (That's why Pack2 & 3 include Pack1 !)
- Pack2 CAN be very usefull if you use apps included in Pack3 (That's why Pack3 includes Pack2)

For example :
- Pack1 is drivers for your video card (You need it if you want to use your video card)
- Pack2 is tools for your video card (°C, °F, fan control, etc...) (You need drivers if you want to control your card, so you need Pack1, which is include in the toolPack == Pack2)
- Pack3 is a game, you need drivers (Pack1) and Tools can be very useful, so they are included with the game (Pack2).

M1 : Just want to use Pack1_v1 (He just needs that because, for example, he is a game developper)
M2 : Just want to use Pack2_v1 (He is an overclocker)
M3 : Just want to use Pack3_v1 (He is a gamer, but maybe he would like to use the tools)

BUT, actually, these men don't want to have to find the last update-file or something else. They want to go to a website, look for the package they are using or they would like to use now, run it, and be sure they have the last version. That's why, at this day, I just want 3 packages, and NOT 3 packages + 3 upgrades/updates packages. (But maybe this could change in 1 or 2 years).

For example, Pack3 is less than 20MB, so the user could dl the last version without using to much bandwidth...

MOREOVER, if M1 installs the Pack1, and then the Pack2, and finally uninstall the Pack2 (or Pack1) I Want that the Pack1 (or Pack2) runs without problems.


Hope that you understand me :-)

Whatever, Thx for your help !

Hi,

I'm reading "The Definitive Guide to Windows Installer" (Phil Wilson) and I just saw his "Merge module" description. He says :

"[...]because sharing is something that happens at the component level, developers need some way to build shareable components instead of simply replicating all the settings for a shared component over and over again into a collection of packages. The package of reusable components that is designed to be shared by multiple products is called a Merge Module."

And I think that could be what I need, no ? Indeed, Pack1 is used in Pack2 which is used in Pack3. So if upgrade Pack1, I would just have to rebuild Pack2 and 3 with the new Pack1MergeModule ?

What do you think about it ?

Thx

Merge Modules aren't the solution you're looking for. Merge Modules are designed to manage runtime components that consist of multiple parts, i.e. ActiveX controls, VB Controls, OLE DLLs, etc. A classic example would be if your application uses the Windows Common Controls ActiveX Control. Instead of adding the group of DLLs/OCXs & regkeys to your install, it's much easier to include the appropriate version of the standard Comctl32.msm merge module. It also helps keep the group of components organized, at the same version level. It's for the component level, not the feature or application level.

The term you're looking for is "Pre-requisite Application". That is when you have one stand-alone application that relies on another stand-alone application in order to function (or a driver, in your case). In your example you have:

Pack1_v1 (No Pre-requisite)
Pack2_v1 (with Pack1_v1 as Pre-requisite)
Pack3_v1 (with Pack1_v1 as Pre-requisite)
From what I see, Pack2_v1 isn't technically a pre-requisite for Pack3_v1 (since Pack3_v1 can run without Pack2_v1) but it may be enough of a "nice to have" that it can be defined as a pre-requisite if you want.

I'm assuming you aren't deploying through a corporate distribution system (which easily handles this), but instead through a web download / CD install. This is more challenging because managing pre-requisites becomes DIY. There may be a web-install utility that will help with that, but I never looked into it. First of all, if each "pack" can be individually upgradeable, then you must have one MSI package for each "pack". You'll paint yourself into a corner if you combine them.

Now what to do about this...
It is possible to imbed MSIs inside of an MSI (via the Binary Table) and have the main MSI check for product/upgrade codes and call the imbedded MSI(s) if appropriate. I'm not sure if this is ideal for you though. It could lead to a lot of unneccary downloading and might not be versatile enough for you.

I think what you really want is some kind of Install Launcher. You can find installed products & versions by Product Code & Upgrade Code, gather version info and make the logic for determining if launching an upgrading MSI is appropriate. You can write your own using WMI calls to search for Product/Upgrade Codes and version. An off-the-shelf utility may also be available but again, I never looked into that.

Then there is also your upgrading strategy. Research that now!! There are several strategies you can use and changing it midstream is a real bear. Look on MSDN, "Definitive Guide", etc for all info about MSI Major Upgrade & Minor Upgrade, and make sure you completely understand the use of Product Codes, Upgrade Codes and Version. Compare the MSI Upgrade Table (for Major Upgrades) vs .msp (for minor upgrades / patches).

...I hope you weren't looking for a simple answer! [:D]

First, thank you VikingLoki, interesting answer ! I understood why the merge modules wasn't the good solution :-)

Then, sorry, but I don't speak and undertand english very well, and I didn't catch what you meant by :

some kind of Install Launcher [...] An off-the-shelf utility [] ?


Moreover, you are talking to me about upgrades. But I don't want upgrade's packs. I just want 3 Packs, and if people want to upgrade, they have to dowload the entire pack. So, I need a pack which can be an installer OR an upgrade (It depends on the fact that we already have or not an old version running).

For example :

Pack1_v1 : App1_v1
Pack2_v1 : App2_v1
Pack3_v1 : App1_v1 App2_v1 App3_v1

(Don't be surprised that App1_v1 is not include in Pack2_v1, my team decided it last night... :-( )

M1 dl the pack3_v1 and runs it. So He has App1_v1, App2_v1 and App3_v1 on his computer.

2 month later, the App1_v2 is released :

Pack1_v2 : App1_v2
Pack2_v1 : App2_v1
Pack3_v2 : App1_v2 App2_v1 App3_v1

2 solutions :
dl and install Pack1_v2 or Pack3_v2.

4 months later, the App3_v2 is released :

Pack1_v2 : App1_v2
Pack2_v1 : App2_v1
Pack3_v3 : App1_v2 App2_v1 App3_v2

1 solution :
dl and install Pack3_v3.


IMPORTANT : If someone installs on a clean system the Pack3_v1, and then Pack3_v2, and then UNinstall Pack3_v2, his system must be clear of all. (So in this case, Pack3_v2 must be considered as an upgrade, and NOT as another installation)

(Detailed evolution :
( 1*/ Clean system
( 2*/ App1_v1 App2_v1 App3_v1
( 3*/ App1_v2 App2_v1 App3_v1
( 4*/ Clean System
)

BUT If somenone installs on a clean system the Pack1_v1, and then Pack3_v2, and then UNinstall Pack3_v2, the App1_v2 (YES, because it has be upgraded by the Pack3_v2 !!!!!) must be able to run. (So in this case, Pack3_v2 must be considered as another installation

(Detailed evolution :
( 1*/ Clean system
( 2*/ App1_v1
( 3*/ App1_v2 App2_v1 App3_v1
( 4*/ App1_v2
)

But maybe you were talking to me about that, and I didn't understand. In this case, I'm sorry, but could you explain it to me in other words ?

Whatever, thank a lot for your help !


EDIT : I'm reading MSDN about nested installations (MSIs included in another MSI), and it looks, as you said, not really versatile. I'm not sure it could run with what I explained... ?-/

some kind of Install Launcher [...] An off-the-shelf utility [] ?
off-the-shelf means retail software you can buy.

I'm getting confused when you say Pack1_v1 and App1_v1. I think you may be trying to do something you shouldn't. I'm assuming that Pack means an MSI package, and App is an installed application. A Pack should never contain multiple apps. Think of an MSI as a database defining how a single application should exist on a machine. Once given your the "definition" of your application, Windows Installer will how how to install, remove, patch, upgrade and automatically repair it. If you put multiple apps in an MSI, then they are considered a single application and you cannot upgrade its parts. You can only Patch, and your patching options will be limited.

Start out by making 3 MSIs. 1 for App1_v1, 1 for App2_v1 and 1 for App3_v1. Get to the point where you have a stable installation for each, with no Validation errors. At this point you can link them up.

Since you don't want to use .MSP patches, make sure you understand the following:

• Product Code, Upgrade Code, and Version properties. You'll use these to quickly reference installations of AppX_vX in future upgrades.
  
• How to use the AppSearch Table. You will use this to search for related Apps and set a propety if they need to be installed and/or upgraded.
  
• How to use the Upgrade Table. You will use this to define which Apps should be uninstalled before installing the new MSI. (reference "Major Upgrade")

Here's some examples.

When you upgrade from App3_v1 to App3_v2, defining App3_v1's Upgrade Code in the Upgrade Table of App3_v2 will cause App3_v1 to be removed before App3_v2 is installed. Only define previous versions of the same App in the Upgrade Table. Don't put App1_v1 and App3_v1 in App3_v2's upgrade table. Remove old versions of App1 from App1 installs, App2 from App2 installs, App3 from App3 installs. Crossing it up will cause problems.

Using the AppSearch Table, you can search for app2, check the version level and set a property called STARTAPP2INSTALL to either 0 (False) or 1 (true).

In your MSI Script, you add an IF STARTAPP2INSTALL [Retrieve & install App2_vX].

There will probably be more checking you need to do, but using the techniques above within each App you should be able to achieve all that you need. Just remember to focus on the App you're installing and don't have it do any more than that specific app needs. App3 only removes old App3's and checks if a new App1 needs to be launched. Let the App1 install remove old App1's and checks if the App2 install needs to be launched. Let the App2 install remove old App2's... etc.

WOW.

Thank you for your very detailed answer. Really insteresting. You explained it very well, so I think I understood (I think...).

Simplifying, I wanted :

Package1_v1 : Component1_v1 (I said Apps, but it's not really an application...)
Package2_v1 : Component1_v1 Component2_v1
Package1_v2 : Component1_v2
Package2_v2 : Component1_v2 Component2_v1
Package2_v3 : Component1_v2 Component2_v2

(Different packages are considered as different products, so their Product and Package code are differents, but their Upgrade code could be the same.... MUST be the same ? I think so...)

Example (In brackets, the state of the installation counter... (1) means that the next uninstallation of this component will delete it, (2) means that the next uninstallation will down it to (1), etc....):

1*/ Package1_v1 > Component1_v1 (1)
2*/ Package2_v1 > Component1_v1 (2) Component2_v1 (1)
3*/ Package1_v2 > Component1_v2 (2) Component2_v1 (1)
4*/ Package2_v2 > Component1_v2 (2) Component2_v1 (1)
5*/ Package2_v3 > Component1_v2 (2) Component2_v2 (1)
5*/ Package1_v2 (uninstall mode) > Component1_v2 (1) Component2_v2 (1)
6*/ Package2_v1 > Nothing changes, maybe a dialog box could say it's an old version
7*/ Package2_v3 (uninstall mode) > All the files have been deleted.


But what I understood from your answer is that I can't have Component1 and Component2 in the same package, if I want to upgrade them separatly.

So your solution is to separate them into 2 Packages :

Package1 : Component1
Package2 : Component2

And if the Component2 needs the Component1 to run (That's my problem : Components2 needs the Component1, but the Component1 don't need the Component2 to run), A custom action calls the installation of the Package1 during the Package2 installation. (But this needs the Package1 being on the hard disk).


Am I right or not ?
Do you think there is another solution which could allow me to include all the components in need in the same package ?


P.S : I'm currently thinking about games which need DirectX version XXXX to run. Some of them tell us that they will install the last version because our is not the good one. According to you, DirectX is not included in the same package that the game, but in is own one ?

DirectX is a 3rd party product, and they need to be handled differently. Using DirectX as an example, you do not want to modify Microsoft's DirectX MSI beyond basic configuring. DEFINITELY do not alter the MSI's codes because future DirectX releases will be looking for those codes. That will cause a lot of problems for your customers later on.

For DirectX, you should determine a minimum required version and obtain Microsoft's MSI for that version. Imbed Microsoft's MSI (or vendor provided single file install) in your application's binary table. Then you can use the AppSearch Table to set a value such as MINVERDIRECTXFOUND. In the MSI Script, IF NOT MINVERDIRECTXFOUND then [Launch DirectX install imbedded in Binary table]. That's it. If DirectX is not at or above the minimum required version, the minimum version will install. If your customers want to upgrade DirectX, they're free to do so. All you're doing is helping them along by launching the MS install to bring them up to the minimum version if need be.

Also, from the Packaging perspective, DirectX is an application. Yes, you would never "run" DirectX on its own, but it is considered a separate application because:

• It's not part of any other single application, it's just referenced by other applications.
  
• It distributed by 3rd party vendor with its own Install, with its own Product & Upgrade codes.
  
• It can be upgraded, removed and/or reinstalled without altering any other application which may reference it.
  

Removing DirectX will break other apps that rely on it, but technically it does not alter the other applications when it's removed. That defines it as a "prerequisite application", a separate application that an other application relies on in order to function.

Components are single files/reg keys. Your use of Component here would end up being confusing in the Packaging world.

So if Package1 is DirectX, then yes you would imbed it (unaltered) into the MSI package for your product. This is getting confusing, let's get specific. Package 1 is DirectX? What's Package 2 & 3?

(DirectX was an example.... my english is poor and I surely used the bad words... I DON'T want to modify a product, but build my own package with my own product :-) )

I will be more specific :

Package1 are 3 DLLs (API) and 1 Driver (*.bat to launch automatically at the end of the install)
Package2 are Apps using the API.

API are useful even if the Package2 is not installed.
Package2 needs the API, so it's useful to include API in it.

But to simplify, we could say that :

Package1 :
Component1 : 1 DLL

Package2 :
Component1 : 1 DLL (the same that in Package1)
Component2 : 1 EXE (Appication using the DLL)

My team don't want people have to launch more than 1 Package to use what they need (So I can't build a Package1 for the API and a Package2 for the Apps)

They WANT 2 packages including what I specified... :-/

So now I think my last example is more comprehensible.

(But if it works, I can build Package1 : DLLs, Package2 : EXE + imbed Package1, but ONLY if this works with the specifications I wrote 2 posts before)


Thanks !

(If this can help you, look at this picture which represents the product my team is developping : http://img315.imageshack.us/my.php?image=specnet4eo.gif )

My team don't want people have to launch more than 1 Package to use what they need (So I can't build a Package1 for the API and a Package2 for the Apps)
I think you can! Maybe it's the English, but you seem to be saying the requirement is for users to LAUNCH only 1 install. I don't see a reason why that 1 install launched by the user can't launch many other package installs! Package1 can check if Package 2 exists and if it is at a minimum version level. If that check fails, Package 1 can launch Package 2. Other packages can be added as well. For your users, they only launched 1 install. For you, you have a bunch of separate packages that can be individually upgraded. Lots of options.
(If this can help you, look at this picture which represents the product my team is developping : http://img315.imageshack.us/my.php?image=specnet4eo.gif )
This did help. That diagram really looks like a single MSI with several features, because all these other packages look like they just contain .dlls. With proper versioning of Package 3, Package 1&2 could be quite happy being features within Package 3.

To determine if Package 1 & 2 should be their own MSI or Features of Package 3 is if Package 1 and/or Package 2 can be installed on their own and if it is possible for another application to use Package 1 and Package 2 in a manner similar to how Package 3 uses it. If the answer to all those questions is NO, then Package 3 should have 2 main features (Server & Client) and the Server Feature should have two sub-features (Package 2 and Package 1).
If the answer to any of those question is YES in regard to Package 1, then Package 1 needs its own separate MSI which should be launched by Package 3 if necessary.
If the answer to any of those question is YES in regard to Package 2, then Package 2 needs its own separate MSI which should be launched by Package 3 if necessary.

Does that cover it for you?

Ok, I didn't precise important things :

They are different users :

Mister1 : He just uses the API (so the package1)
Mister2 : He just uses the API at his job, but at home, he uses API + Developper's interface (so the pakage1 at work, and Package1 + 2 at home)
Mister3 : Hardcore user, he uses all our products. (so the package3)

We can see different profiles. Packages are not really very big (a few Mb), but we don't want users have to download things they won't use.

MOREOVER, my team wants that people just have to download ONE file (package) to install the product they want (so I can't build a package3 who calls for another package (package1 for example) EXCEPT IF the other package is INCLUDED (nested install ?) in the main package)

SO, we have to offer 3 differents packages :

1 with the API for Mister1
1 with the Developper's Interface for Mister2 (this one doesn't include the API for some reasons, but according to me, it should)
1 with all for Mister3 (as you can see, this one includes the API because it needs them)


That's why I can't build 1 package which calls another one !
(If Package2 bothers you, don't think about it)

I have to do what my team wants if I can do it, because that's what users want.
1 product = 1 download (except of the package2 which needs the package1, but there is a reason) = 1 file = 1 action to be installed. (Mmmmh I'm wondering why not an auto-extractible zip file with all the msi files I need ? That's MIGHT be good, but I would prefer only one package)


Do you think it is possible (Of course, I would like that my example 4 posts before runs well with it...)


Thank you for your efforts !

They are different users :

Mister1 : He just uses the API (so the package1)
Mister2 : He just uses the API at his job, but at home, he uses API + Developper's interface (so the pakage1 at work, and Package1 + 2 at home)
Mister3 : Hardcore user, he uses all our products. (so the package3)
Would any other application (other than Packages 1, 2 or 3) ever install or use the components of Package 1 or Package 2? If the answer is no, then the solution is simple. Make a single MSI with three features. One feature contains all the components of Package 1, another feature contains the components of Package 2, the third contains the features of Package 3. During install the user can select which one(s) they do and do not want installed. If they want to install something later, they can select Modify at the Modify/Repair/Move window via Add/Remove Programs. When you issue future upgrades, you can migrate Feature state so the new version will retain the Feature settings from the previous install.

If you can't do that, then compromises need to be made.

MOREOVER, my team wants that people just have to download ONE file (package) to install the product they want (so I can't build a package3 who calls for another package (package1 for example) EXCEPT IF the other package is INCLUDED (nested install ?) in the main package)
If your users have internet access, they can download the main package which can download additional packages if necessary. That will keep downloading to a minimum, but that will make internet access a MUST. Strictly a Web based install. If any of your customers distribute your product over a corporate network, this setup will give them a headache.
1 product = 1 download (except of the package2 which needs the package1, but there is a reason) = 1 file = 1 action to be installed. (Mmmmh I'm wondering why not an auto-extractible zip file with all the msi files I need ? That's MIGHT be good, but I would prefer only one package)
Putting 3 MSI's in a ZIP .exe file that self-extracts and launches the primary MSI is an option. The downside is that Package 1 and 2 will sometimes be downloaded when it is not needed.

ORIGINAL: VikingLoki

Would any other application (other than Packages 1, 2 or 3) ever install or use the components of Package 1 or Package 2? If the answer is no, then the solution is simple. Make a single MSI with three features. One feature contains all the components of Package 1, another feature contains the components of Package 2, the third contains the features of Package 3. During install the user can select which one(s) they do and do not want installed. If they want to install something later, they can select Modify at the Modify/Repair/Move window via Add/Remove Programs. When you issue future upgrades, you can migrate Feature state so the new version will retain the Feature settings from the previous install.



This solution implies that users download a all-in-one package even if they don't need all its features... I don't understand your answer, because you say next :


The downside is that Package 1 and 2 will sometimes be downloaded when it is not needed.


So you seem to have understood what I want, but you give me a wrong solution...
I think my english is guilty... :-)

What I'm saying is that if what you call Package 1 and Package 2 isn't used or installed by other applications, then they are normally included in what you call Package 3 as user selectable features. But with that approach, if a user only wants to install Package 1, then they end up downloading Package 2 and 3 in the process.

What I'm hearing is that you want users to have a single install, but not download portions that they don't want to install. That will end up being a packaging & administrative headache because you are going to end up with 4 or more downloads for the same stuff. Package 3 w/ imbedded Package 1, Package 3 w/ imbedded Package 1 & 2, Package 2 w/ imbedded Package 1, and Package 1. This is also if there is only one version of each part. Put multiple versions into the scenario and you'll end up with a big mess. You'll also have to make sure that you get the Product & Upgrade codes in order or you'll made upgrading difficult.

Ultimately, there is no perfect soluion. You'll need to decide for yourself which direction has the smallest downside. Personally, I would go with creating a single package with user selectable features. It will keep everyone with current versions of the components, upgrade paths are simpler (both for you and your customers), versioning is easier to manage. The downside of having to download a few unneeded files is a small price to pay, because it's easier to understand. They also don't seem to be extremely big.

Besides, that's the approach that most of the industry takes. Can you imagine how confusing MS Office would be if you had one download for Word & Excel, one for Word/Excel/Outlook, one for Excel/Powerpoint/Outlook, one for Excel(XP)/Powerpoint(2003)/Outlook(XP)... etc.

ORIGINAL: VikingLoki

The downside of having to download a few unneeded files is a small price to pay, because it's easier to understand. They also don't seem to be extremely big.


Yes I agree with you on this point, but some customers don't want to dowload some useless parts... and what the purchasers want is what I am supposed to want [8|]

But now, I think you answered all my questions. I will try to build what I want, and if I don't succeed in, I will choose your way...

Thanks for your efforts !

See you for another strange questions in a strange english...