Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

Points to Remember While Packaging

Updated: 12 Sep 2007 | 5 comments
R-Vijay's picture
+1 1 Vote
Login to vote

Here are some rules I picked up through my time spent packaging software.

I live by them. Your mileage may vary.

  • Don't exclude any file from Setup capture Inclusion List.
  • Keep the default directory immediate to the Program Files.
  • In Merge module dialogue, uncheck all the merge modules and proceed.
    Adding Merge module should be done to a particular feature, but modifying or deleting have to done keeping all features into constraint.
    WFP Files will never be replaced.
  • When assigning key Path, avoid keeping it as ODBC, Its preferable to have it as a File Key path.
  • When a key path is missing for a component, it turns to be a broken component.
  • It's preferable to use installation expert to delete the file.
  • Always create a "shared" folder in local directory, to have the collection of all merge modules related to the application.
  • Usually .isu files are unwanted, so while editing it can be removed.
  • All class tables will have one Prog Id.
  • All the register able dll's will have clsId.
    If ClsId is already known, then it is a non advertisable file.
  • Self Heal works only if shortcut is advertised.
    Public Property value can be changed in the command line, but cannot be done for Private property.
    Usually any .ini files under _"directory name" or tmp directory are unwanted, so while editing it can be removed.
  • There should not be any self Reg entry for a package, because it gets into registry while installation but doesn't remove it while un-installation. It remains as Junk entry.

Comments

Harsh Mokal's picture
17
Sep
2007
0 Votes 0
Login to vote

Need some clarification

Hi,
I am not agree with some points.
1. Don't exclude any file from Setup capture Inclusion List -
I guess fair chance,if you confident enough you can remove garbage entries, so that will save compilation time at the time of snapshot process and WSM building.
Enable the Report mechanism that will give you the complete listing of files.

2.Keep the default directory immediate to the Program Files - yes it is highly recommended but
it is not applicable for each and every software. This should be depends on software. If Execuable of software is hardcoded to run through systemDrive then? In That aren't we going to package that application?

3.When assigning key Path, avoid keeping it as ODBC, Its preferable to have it as a File Key path -
Then what is use of ODBC Tables and its related entries in MSI database structure? why we need to avoid it?

Thanks

R-Vijay's picture
17
Sep
2007
0 Votes 0
Login to vote

Reply: Need some Clarification

Hi Harsh,

These instructions were mentioned for the people who are in thier early days of packaging.

The points put by you are very valid. Well, to answer your questions.,

1. Its always better advisable to edit the file entry during the editing phase of packaging, because, any wanted file when deleted can be revoked by the Raw captured WSI.
Yes., once when you know about the files and its existance properly, you can very well exclude them in the Setup Capture Inclusion list. This will also help in avoiding the same file's occurances in future captures.

2. As you say its purely application specific. However, the mail idea of giving this sort of idea was to avoid chaos when the package undergoes repair or a selfheal.

3. If the component has anyother file/registry along with the ODBC entry, then its advisable to set the File key path. There wont be any problem assgning a ODBC key path on other cases.
However, setting a .mdb or such user related files as a key path is not correct.

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

Harsh Mokal's picture
17
Sep
2007
0 Votes 0
Login to vote

Ok Can you explain me

Ok
Can you explain me briefly what is relationship between self healing and directory structure?
I am still confuse what you stated with avoiding chaos when the package undergoes repair or a selfheal?

If you are following Microsoft componentization rules (can be found on microsoft site).Then definatly ODBC component will be differant from file or registry component.

If you talking about user componet then this componet will be completly treated differantly while packaging. you need to set HKCU registry key path for every user component for self healing.

Correct me if I am wrong.

Please refer
Application Packaging Best Practices for Windows XP
Filed under: Best Practices Submitted by Scott Hardie on juice.
Is one of the best article I ever come across for Packaging on Juice.
It will give you wider aspect of best practices for packaging.

R-Vijay's picture
17
Sep
2007
0 Votes 0
Login to vote

Thanks for correcting me...

I just had a look through the document which you had mentioned, which clearly states about the rules.

Well, This point of having a default directory next to the programfiles one is for the template which we follow out here.
Its becuase, we have a standard property which modifies the INSTALLDIR which installation...

Thanks for correcting me.

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

Harsh Mokal's picture
18
Sep
2007
0 Votes 0
Login to vote

Yeaha may be the standards

Yeaha may be the standards for packaging varies and that even varies with organization to organization.
You can not say it is best practice to keep it under programfiles.
INSTALLDIR is proprty which you can set using Directory Table.
You can modify it using directory table as per need.