次の方法で共有

App-V 5: On Virtual Fonts

  • [アーティクル]

App-V has many virtualization subsystems that make up how App-V isolates itself from other applications. Often I, and others have discussed virtual COM, virtual kernel objects, virtual services, etc. when discussing App-V in depth. Until now, one virtual subsystem that has not been discussed much in the context of App-V 5 is the virtual fonts subsystem. That is usually because you don’t really have to deal with it unless something has gone wrong.

Fonts are installed on-demand at process runtime in App-V 5. This is pretty much similar to the method used in previous versions of App-V with some technical-specific details. (Font information pulled from the AppX Manifest inside APPV package file instead of from .CP file as in previous releases.)

This font information is stored as an extension point (AppV.Fonts) with the fonts designated with the direct path within the AppV package of where the fonts are stored.

By default, the fonts will be deployed during the publishing process. If the fonts are loaded on demand at runtime, then the path will also be specified with the DelayLoad="true” value:

        <appv:Font Path="[{ProgramFilesX86}]\NetManage\RUMBA\AS400\RUMBA400.FON" DelayLoad="true"></appv:Font>

Missing Fonts

If fonts have been designated inside the manifest but for some reason are missing in the package, this can be problematic and will cause a package launch to fail as the VFonts subsystem is unable to initialize the fonts properly. When would you see something like this? Well, as you may have figured out by now, any time an application has failed to launch, a generic error message is thrown to the user:

The application failed to launch

This may be due to a network failure

 

When this occurs, you have to go to the AppV-specific logs in the Event Viewer to get a more component-specific error code. Often, it is not a network failure. Let’s say you are missing font files inside the package.

You may receive a more specific error code: 0x83401D2A-80070490

(This happened to an MVP friend of mine with Office as a matter of fact - https://rorymon.com/blog/index.php/app-v-sequencing-visio-2010-and-visio-2013-with-app-v-5-0/ )

If you are noticing that certain applications may be causing increases to the publishing process (especially when using a publishing server) fonts could be a factor. If there are many fonts specified in a package that do *NOT* have the Delayload=true option, then they could be a contributing factor.

Excluding Fonts from a Virtual Package

If you are encountering a publishing delay issue with a specific package, or are encountering an issue similar to the above scenario (where missing fonts are causing packages to fail top launch) you can disable the virtual fonts subsystem by utilizing a deployment or user dynamic configuration file which best suits the user targeting.

To disable the virtual fonts subsystem using via XML configuration of the DeploymentConfig.XML or UserConfig.XML file, utilize the following syntax:

Fonts     

      -->

      <Fonts Enabled="false" />

      <!--