VMware Horizon Community
VIrtuallyJason
Contributor
Contributor

File Type Icon Associations in an "Open" Dialogue Box

One of my customers pointed out an interesting (albeit cosmetic) bug in our Office 2010 ThinApp package.  Whenever he is in the "Open" dialogue box of an Office Application, his Office files (.docx, .xlsx, etc.) do not show the proper icons (although, as you can see, the "Type" column correctly shows the association and other ThinApps' files show entirely correctly).  Within Windows Explorer (the lower window in this screenshot), the File Type Associations are working great.  Within the "Open" dialog box of other ThinApps, browsing the same directory shows all of the Office icons correctly.

file-types.png

Has anyone else come across this behavior and, if so, how did you resolve it?  Thanks.

Reply
0 Kudos
14 Replies
Lakshman
Champion
Champion

Seems like the file association is not proper. How did the customer deploy Office 2010? MSI or EXE?

If it is EXE, its worth trying out the ThinReg again to re-registering the ThinApp.

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

Thanks for the swift reply - we are deploying by simply storing the EXE files on a file share and using ThinReg at logon.  We have tried reregistering with thinreg /r <path to exe files> and it has not changed the results.

In case someone might find it helpful (or it clarifies what we're doing), here is the "MS Word" section of my package.ini

[Microsoft Word 2010.exe]
Source=%ProgramFilesDir%\Microsoft Office\Office14\WINWORD.EXE
Shortcut=Microsoft Office 2010.dat
FileTypes=.doc.dochtml.docm.docx.dot.dothtml.dotm.dotx.odt.rtf.wbk
Comment=Create and edit professional-looking documents such as letters, papers, reports, and booklets by using Microsoft Word.
ObjectTypes=Word.Application;Word.Application.14;Word.Application.8;Word.Backup.8;Word.Basic;Word.Basic.8;Word.Basic.9;Word.Document;Word.Document.12;Word.Document.8;Word.DocumentMacroEnabled;Word.DocumentMacroEnabled.12;Word.OpenDocumentText;Word.OpenDocumentText.12;Word.Picture;Word.Picture.8;Word.RTF.8;Word.Template;Word.Template.12;Word.Template.8;Word.TemplateMacroEnabled;Word.TemplateMacroEnabled.12;Word.Wizard.8
Shortcuts=%Programs%\Microsoft Office;%Desktop%

Reply
0 Kudos
Lakshman
Champion
Champion

If you have registered the package with /a parameter, you must use /a when reregistering the package along with /r parameter.

thinreg.exe /r /a *.exe

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

Thanks, but we're not using /a since we have a floating pool and have no need of it (nor do we want to deal with the permissions issues that can come with that switch).

Reply
0 Kudos
Lakshman
Champion
Champion

Strange behaviour. Is the behaviour same when you unregister the package first and then register again?

You may try out the latest 4.6.2 release having more enhancements to ThinReg.

Is it just happening on one machine or many?

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

We are using 4.6.2 and it happens when I manually unregister and reregister.  It happens on all of the Windows 7 Desktops from which I've tried it and I do not have an XP desktop from which to test it.

Reply
0 Kudos
Pankaj11
Hot Shot
Hot Shot

Hi,

Can you please try 4.6.1 and see if this used to work with it or not?

Have you tried any other apps, which display the same behavior after using ThinReg?

I would say you should file a support ticket with VMware and we will look into it, as I think this would be the only way to move forward.

Thanks.

Reply
0 Kudos
TobyFruthParson
Enthusiast
Enthusiast

There are a few icon considerations to be made within ThinApp.

There's the icon folks will see in the "Add/Remove Programs" or "Programs & Features" list.  This is known as the

MSIArpProductIcon

and an entry for it should appear in the MSI portion of Package.INI.

There's the icon someone might see when working with software inventory.  This is known as the

InventoryIcon

and an entry for it should appear in the General Purpose Parameters portion of Package.INI, just below the SandboxName.

Then there's the entry points.  Assuming your virtualized Word is the only Word on the system, and assuming that there's only one entry point for winword.exe in your Package.INI, then you should expect to see the correct icon.

Using an example from one of our Acrobat captures, here's the Package.INI entry for Adobe LiveCycle Designer 8:

[Adobe LiveCycle Designer 8.0.exe]
Source=%ProgramFilesDir%\Adobe\Acrobat 8.0\Designer 8.0\FormDesigner.exe
Shortcut=Adobe Acrobat 8.2.6 Professional.dat
Icon=%ProgramFilesDir%\Adobe\Acrobat 8.0\Designer 8.0\FormDesigner.exe
FileTypes=.tds
ObjectTypes=

Shortcuts=%Programs%\Adobe

On some occasions, I have noticed that an application has two entry points in Package.INI, one that is enabled and another that is disabled.  If you are like me, you delete the %SystemRoot%\Installer directories from your packages prior to build.  Do you also, like me, occasionally forget to delete the %SystemRoot%\Installer entries in Package.INI?  I have done so in times past, and the result is, despite the fact the file is not in the project folder and the entry point is disabled, Package.INI makes a reference to a non-existent file.  Perhaps this is the root cause of the icon issue.  You see, sometimes, the Icon= entry points to a %SystemRoot%\Installer entry, rather than directly at the installed application EXE.

Toby Fruth, Sr. Specialist, The Parsons Corporation
Reply
0 Kudos
TobyFruthParson
Enthusiast
Enthusiast

Icon

The Icon parameter specifies the icon file to associate with the generated executable file. This icon appears in the application, such as Microsoft Word, and in the files associated with the application, such as .doc files.  Each application includes its own icon stored as a .ico file, within the .exe file of the application, or within a .dll file. The capture process attaches the icons to the executable files. The application uses the main group icon from the executable file in the Source parameter and the individual icon resource that the group icon points to.

Examples

You can modify the Icon parameter to use an alternative icon by specifying an executable file that is different from the executable file in the Source parameter. Alternative icons might be useful for third-party companies.

[<my_app>.exe]
Source=%ProgramFilesDir%\<my_app>\app.exe
Icon=%ProgramFilesDir%\<my_app>\app2.exe

You can specify an icon set by appending ,1 ,2 to the end of the icon path.

[<my_app>.exe]
Source=%ProgramFilesDir%\<my_app>\<app>.exe
Icon=%ProgramFilesDir%\<my_app>\<app2>.exe,1


You can use a .ico file to specify the application icon.

[<my_app>.exe]
Source=%ProgramFilesDir%\<my_app>\<app>.exe
Icon=%ProgramFilesDir%\<my_app>\<my_icon>.ico

Toby Fruth, Sr. Specialist, The Parsons Corporation
VIrtuallyJason
Contributor
Contributor

Thanks for your advice Toby, but the file icons are still not appearing correctly from within my packages (and I've tried packaging on 4.7 as well).  I haven't opened a ticket with VMware on this yet (file icons are a lot lower priority than other applications completely failing to run), but I did try removing the %systemroot%\Installer entry points (I do indeed delete that folder and, since the entry points are disabled, I have never bothered cleaning them up) as well as manually specifying the icon to use.  I also removed the disabled "winword.exe" entry point (leaving the "Microsoft Word 2010.exe" entry point as the only one for that application (it is the one that has all of the shortcuts/file type associations).  I've also verified that there are no other registrations for .docx files in my package.ini.

I've awarding you a "helpful" since you've given me some good info regarding icons (I only knew about the per exe icon specifications) and some more good "housekeeping" advice around the %systemroot%\installer entry points.

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

Is anyone familiar with how ThinReg does its magic?  I've checked "assoc" and "ftype" on my desktop and do not see any evidence of any ThinApp file associations.  The GUI in windows shows the associates correctly (and "assoc" and "ftype" show correctly when I open a cmd prompt within the bubble).  I've figured out how to use those commands to manually register a file type, but it does not seem to set an icon; if I can figure out how to properly set the icons via the CLI, I can just use a FirstRun script and be done with it.

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

I think that you have directed me to the solution.  Opening up RegEdit within my package and examining this key:

HKEY_CLASSES_ROOT\Word.Document.12\DefaultIcon

shows that it is pulling the default icon from C:\Windows\Installer...

Some quick googling has revealed that hkey_classes_root is actually a combination of data from hkey_local_machine and hkey_current_user.  I'm going through those two reistry files right now and am replacing the paths with valid ones.  I'll let you know if it resolves my problem.

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

There are a lot of registry changes to do, so in the end I just copied all of the *icons.exe and *icon.exe files from %systemroot%\Installer back into place.  If anyone's intesested, I did it with robocopy using the following command:

robocopy "Original Capture %systemroot%\Installer" "C:\TempInstaller" /IF *icons.exe /IF *icon.exe /S /LOG:C:\Installer.log /NP /FP

I then deleted the original %systemroot%\Installer folder's contents and copied the contents from my C:\TempInstaller into that location.  After repackaging, my applications are showing their icons correctly.

Reply
0 Kudos
VIrtuallyJason
Contributor
Contributor

It turns out that my cleanup was a little too aggressive - MSOffice 2010 uses exe files stored under %systemroot%\installer to generate those icons.

Reply
0 Kudos