Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Generating an Installation Manifest


7 replies to this topic

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 20 January 2004 - 22:02

I am looking for a way to generate and insstallation manifest of all features, components, files, registry entries, shortcuts, etc. during the installation.

I would like to include the following for each:

Features: (I am not as concerned about including the features, but it would be nice to have). List of all features, the feature install state and possibly a list of components for each feature.

Components: A list of all components, the component install state and fully qualified destination path, a list of files in the component including the file date and time, size and version, a list of registry entries in the component and a list of shortcuts in the component.

This information will be used in a "System Information" type utility that our Tech Support department would use to help them troubleshoot customer issues. I also thought this manifest could be used to quickly and easily document all the files, registry entries and shortcuts installed by a particular build of our installation(s).

Has anyone done something similar or have any suggesstions on how this could be accomplished?

One idea I had is to parse the MSI log file. This appears to be a daunting task and I am not sure that I could guarantee it would be available.

Another is to parse the DevStudio 9 build log file. The con to this is that I would not be able to get registry or shortcut information or the fully qualified destination path for the component.

The last idea is to query the MSI database directly. I could do this at runtime and probably get all the information I need. However, I wasn't sure if I would be able to easily get the components fully qualified destination path with the way the directory table is designed. I also wasn't sure if I would have to do a seperate query for merge modules included in the installation.

I would appreciate any additional suggestions, advice, or personal experience anyone has to offer.

Thanks,
Shane Jimmerson

Edited by sjimmerson, 20 January 2004 - 22:05.


Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 20 January 2004 - 22:48

I maintain an Excel spreadsheet with the list of all components and their installation paths. I update the sheet during the auto build process.

This should get you started: http://www.installsi...ps.htm#Manifest
Regards
-Stein Åsmul

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 20 January 2004 - 23:33

That's not a bad idea. I could easily modify any of those samples to include any additional information I need. The only thing that this would not provide is the fully qualified destination path for each component.

Is there any easy way to query the install (during the installation) to get the fully qualified destination path for the paths that are defined during installation development? Some specific examples would be TARGETDIR, SystemFolder, WindowsFolder, CommonFilesFolder, etc. and any installation defined folders that are children of the folders I just named.

I could just parse these folders with our Tech Support utility to determine the fully quailified path for most of the directories and set a registry key or read the AppPaths registry entry, but I would prefer to do it at install time unless it is really complex and thus too time consuming to do right now.

Thanks for the suggestion!

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 21 January 2004 - 09:54

I think these utilities are meant for system administrators who want to know in advance what files, registry keys etc. they will get.

I understand you want to know where the files went after they were installed. You could write a small program, that call enumerates all components of you product (MsiEnumComponents & MsiEnumClients), and looks up their installation states and paths (MsiGetComponentPath).


sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 22 January 2004 - 19:32

Glytzhkof,
If I use the utilities that you suggested and run the utility on an InstallShidld project (ISM) file it doesn't pull the file information for any of my merge modules. But, I found that if I run the utility on the MSI file that InstallShield builds it pulls all the files including the ones in the merge modules. I still don't see any functions to get the registry entries so it looks like I will have to use a query to get those which should be fairly easy. If I have overlooked any registry functions please let me know. If I run it on the MSI file I just need to find a way to add it to the installation so it will be copied the the end-user's PC. Have any suggestions here? I could leave it on the CD, but I would prefer to copy it to the end user's PC.

Zweitze,

I looked into using the MSI automation interface to get the same info I could get from the InstallShield automation interface but I did not see a way to accomplish it using the MSI interface. I would actually prefer to use the MSI interface so I am not tied to a particular tool, but it doesn't look possible right know. I may still query the MSI interface during the installation to get the destination directories and then write those directories to the manifest that we generate in-house for this particular build, probably using one of the manifest utilities suggested by Glytzhkof.

Thanks again!

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 22 January 2004 - 19:57

Hi sjimmerson. Yes, merge modules end up in the MSI file only after build since they are merged into the project at build time - hence the term "merge module". I actually wrote the maifest tool that imports components to Excel, but I don't recall any way to put the registry entries in there as well.

Here is a short sample of how to run an MSI automation interface query:

CODE

' Update the "Update" table in the MSI database file
Set oneWindowsInstaller = CreateObject("WindowsInstaller.Installer")
Set oneInstallerDatabase = oneWindowsInstaller.OpenDatabase( "C:\Test.ism" , 1)

' Set up SQL query for the upgrade table - DETECT NEWER VERSION INSTALLED
Set oneView = oneInstallerDatabase.OpenView ("SELECT * FROM Upgrade WHERE ActionProperty = 'CHECKCURRENTINSTALL'")
   ' Execute the view, so its methods can be used.
   oneView.Execute
   'Fetch records
   Set oneRecordObject = oneView.Fetch

  ' Assign new values to recordset
  oneRecordObject.StringData (2) = V_MAJOR & "." & V_MINOR  & "." & V_BUILD
  oneView.Modify 4, oneRecordObject
  oneView.Close

Set oneRecordObject = Nothing

Regards
-Stein Åsmul

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 22 January 2004 - 23:17

I think I got the merge module thing down now tongue.gif . My point was that these manifest utilities don't give you the whole picture if you include merge modules in your project unless you know that you can also run the utilities on the MSI.

Thanks for the code sample.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 23 January 2004 - 00:50

biggrin.gif - sorry if I keep stating the obvious.
Regards
-Stein Åsmul