.NET 3.5 SP1 and its language pack are offline msi installers indeed. They are different than regular installers therefore once you use "msiexec.exe /a" to deploy it, the output dir is much bigger than before and both msi and cab files are still there. Even updated files are useless as the msi file is totally same as before so it only regard the cab file as a valid source.
This fact is severe.
1. you can't get patches applied because updated files are ignored by the msi file.(you can try installing user_hidden's dotnet 3.5 and check file version of %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\NetFX3.5InstallPath_GAC\System.Data.Services.Client.dll, it should have been 3.5.30729.196 if updated, but in reality it is 3.5.30729.1)
2. size is bumped. the original msi and cab is still there, and new files are in, so the final size increases.
3. If you just keep the original msi and cab, without attempting administrative install, you should have all patches applied later by starting msp files. this will still result a big 7zipped file.
So finding a way to make it administrative-deployable is very helpful for reducing package size.
**** This part needs some basic msi knowledges ****
To work out a solution, we must first understand how is an offline msi installer different from a regular one.
When I'm paying effort on removing the msi itself and source cab from the msi's file table, I find that no matter how "clean" I think I have done, the modified msi still doesn't work. So I realized the copying of the msi and the cab must play a very important role during the installation, there a thought of "offline installer" rose.
Actually, I'm correct. As there is no document describing how to run the 2nd-step installation of an msi file, I decide to strip out the first step and then it works!
Open vs_setup.msi(comes from .NET 3.5 SP1) with orca, move to "Feature" table, you'll see a feature named "NetFX35_EXP_enu_x86_net_SETUP" with a level flag of 2, whereas most others are with a level flag of 1. So yes, this the "first step" which I want to strip out! To totally remove it, "Feature" "FeatureComponent" "Component" "Files" "Registry" and some more related tables(such as msifilehash, not necessary for a working msi) should be modified.
In next part I'll introduce with detailed steps for how to do it.
Before we start, I recommend that you use InstEd to edit the msi file. It really has saved me a lot of time, so the steps below are all following InstEd.
1. make a copy of vs_setup.msi, for example here: vs_setup_org.msi. This copy is used for acquiring info for removed entries in progress.
2. open vs_setup.msi and vs_setup_org.msi in 2 windows of InstEd. Although InstEd allows you to open multiple msi files in one window, here we start 2 windows because once there is a dialog over it, you can't switch to a nother tab.
3. switch to vs_setup.msi, go to feature table, remove NetFX35_EXP_enu_x86_net_SETUP by selecting it and hitting delete key. InstEd pops a dialog prompting you for deleting related entries, click OK.
4. switch to vs_setup_org.msi, go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component.
5. switch to vs_setup.msi, go to component table, sorting entries by first column, then remove all components obtained in the previous point. Every time InstED pops a dialog, click OK directly.
6. go to FeatureExtensionData table, remove NetFX35_EXP_enu_x86_net_SETUP. (don't know if this step is necessary)
7. go to Property table, remove 2 entries: INSTALLLEVEL and ARPSYSTEMCOMPONENT.
8. save it, now you can deploy it!
strel (one of Silent .NET Maker synthesized authors), who helped me realize how to make the installer uninstallable and shown in ARP. He also pointed that some steps are verbose and unnecessary, so I removed them.
there is no issue currently. .
Example (.NET 3.5 SP1):
visit http://www.ryanvm.ne...opic.php?t=7696 to get more info.
This post has been edited by YumeYao: 30 September 2009 - 05:33 AM