I have a Basic MSI project. I am in the process of testing to ensure the product can be properly patched from the current version to some future version. For the purposes of this example, the files in each installer are identical. Note: I am using Dynamic file linking, and have best practices turned ON. I have tried it with Best Practices turned off and have similar results.
When Generating a Patch.msp file I get the following Error:
ISDEV : warning Val0015: The Font table contains new content. Therefore, if you are packaging this upgrade as a patch, you will not be able to make it an uninstallable patch.
Since the files between these two installers are identical, This error should not happen. Digging into the tables I have the following:
Original Installer:
Font Table: File: _CFE6EE577FE7F0A4589340FBD573ECB9
Note how the File ID in the File name does not correspond with the file name listed in the Font Table? Also, the original file ID _CFE6EE577FE7F0A4589340FBD573ECB9 cannot be found in the File table of the Upgrade Install.
Has the build source path to the file changed since the base MSI was built? This would cause the file key to change and the previous package sync process at build would not be able to use the old file key.
joshstechnij wrote: Has the build source path to the file changed since the base MSI was built? This would cause the file key to change and the previous package sync process at build would not be able to use the old file key.
Yes and No. In the Project file, I have a single source path which dynamically includes all build files under this directory. The problem font can be found in /runtime/lib/font/LucidaSansRegular.ttf This path does not change between builds.
However, the value of changes slightly with every build because the build number has incremented. For example build #1 might have the path: C:\build\0001 and build #2 would have the path C:\build\0002. I don' think this could be the problem. Otherwise, wouldn't more than just the Font table have problems with file paths being changed?
Using a path variable is the correct method for including files in a dynamic file link (or in general) instead of hard coded paths. As you have your project set up, this should not be causing any issues.
Can you reproduce this issue in a sample project that includes a small number of files and a font file?
I created a test installer. With the test installer I am able to repeat the problem only if my source build files directory changes between builds. The Path Variable is the same in both builds, it just changes what directory it points to during the build.
Eg. build #1 Has the path C:\build\Test1 Build #2 has the source path C:\build\Test2. If Build #2 has the same path as build #1 the problem does not occur.
Also, a new piece of information: When I build the base installer within IS2k9 I get the following warning from Windows Validation: [CODE] ICE07 is only encountered during validation and is displayed in the following format: ICE07 Warning [FONTFILE] is a Font and must be installed to the FontsFolder. Current Install Directory: [DIRECTORY]. [/CODE] But since I am using Dynamic file linking, why is InstallShield 2k9 unable to populate the FontsFolder properly?
Finally, I am able to bypass the patching problem entirely by telling my dynamic link to exclude fonts (*.ttf) and manually create an entry for the font file. While this method works, I am not happy with it. I would much rather let dynamic file linking maintain which files are including in my build.
Can you try building your project again after replacing ISWiBuild.dll in C:\Program Files\InstallShield\2009\System with the attached copy (make a backup copy of the original first)? Does this resolve the Font table issues?
Regarding the ICE07 validator, we include files from dynamic file links and add them to components targeting relative paths from the component's root destination path. If your component that includes dynamically linked files is not installing to FontsFolder, any files in the dynamic link (and subfolder in the link) will not be installed to FontsFolder, even if there are font files in the dynamic link.
The fix you provided works. Is this upgraded file appropriate for use on production builds (e.g what I would ship to customers)? Or will you be issuing a separate hot fix of some kind?
The fix should be fine for production use as the only code changes included affect the previous package file key synchronization performed at build time. If you do encounter any issues, please let us know.
The same DLL will be provided in a hotfix KB article in the near future.
The attached copy of ISWiBuild.dll will only work with IS 2009 since it is intended to fix the original issue with dynamic file key synchronization originally reported in this thread (which should not be an issue in IS X since the "previous package" functionality was broken due to a change made in IS 2009).
