The SWV Layer Definition Tool allows administrators to export Virtual Application (i.e. layer) information to a “Layer Definition File” (LDF file) and to create or modify a layer from a layer definition file. This article highlights how to create a virtual application package for Internet Explorer using the new SWV Layer Definition Tool.
Symantec Workspace Virtualization provides the capability to capture an application installation to a redirected area (i.e. sub-layer) in which all of the files, folders and registry information that comprise the application are stored. After the application has been captured, it can be exported to a package (VSA file) that can be deployed to endpoints. While this is the typical case for creating a virtual application, there are scenarios where it might be useful, or even necessary, to have a mechanism to reliably create virtual applications where capturing the application installation is not possible.
For example, suppose you want to create a virtual application package for Internet Explorer 6 (IE6). Because IE6 is included with Windows XP, it is not well suited for the capture mechanism described above. To virtualize this application, the Layer Definition tool lets us handcraft an IE6 layer using the SWV Administration tool, and then export the definition to a layer definition file, which can later be used to re-create the virtual application layer in a reliable way. Some might question why Symantec doesn’t just package Internet Explorer 6 and make the package available for download. The answer lies in the fact that an IE6 virtual package is comprised of Microsoft system files that can’t just be packaged up and made available to customers due to file redistribution restrictions. Therefore, the Layer Definition Tool tool was created to ensure that customers could reliably create virtual applications where installation capturing is not feasible.
To capture IE6, we need the ability to supply a layer definition file that contains all the information required to create an IE6 virtual application layer, without including the vendor-owned files. Enter the Layer Definition tool. Let’s take a closer look at how this tool can help us address this problem.
Creating a Layer Definition File
The Layer Definition tool is a command-line driven application that performs two operations: 1) Exports a virtual application package to a layer definition file and 2) Creates or Modifies a virtual application layer using a layer definition file. If the Layer Definition tool is invoked from a command prompt with no parameters, the following usage information is printed to the screen:
Usage: swvldf.exe [-x <ldf file> | -i <ldf file> ]
Export Layer Definition: swvldf.exe -x <ldf file> -l <layer name or ID> options -[rwRWmoeLF]
l = Layer name or ID of the layer whose definition is to be exported.
r = Include RO Sub-layer files in layer definition file.
w = Include RW Sub-layer files in layer definition file.
R = Include RO Sub-layer registry entries in layer definition file.
W = Include RW Sub-layer registry in layer definition file.
m = Include Sub-layer meta registry in layer definition file.
o = Overwrite layer definition file if it exists.
e = Embed all export data in single ldf file.
L = Turn on Logging. Must be followed by log level (0-3) (e.g. -L 3).
F = Log to file (e.g. -F c:\logfile.log). Ignored if -L is not specified.
Create or Modify Layer: swvldf -i <ldf file> [-MlnvsopkLF]
M = Modify Existing Layer. Note: -l <layer guid> must be specified.
l = Layer name or ID of the layer to be modified. Ignored if -M is not specified.
n = Create using new layer ID. If not set, Layer ID from ldf definition file used.
v = Turn off file version checking.
s = Only process <file-source> tags within the layer definition file.
o = Overwrite package file if it exists. Ignored if -p is not specified.
p = Export Layer to package file (e.g. -p c:\package.vsa)
k = Keep layer when creating a package. Ignored if -p is not specified.
L = Turn on Logging. Must be followed by log level (0-3) (e.g. -L 3).
F = Log to file (e.g. -F c:\logfile.log). Ignored if -L is not specified.
At first glance, considering all the parameters that can be passed to swvldf.exe, it might appear to be a complicated tool to use. Fortunately, most of the parameters simply provide a way to customize the import and export LDF file operations.
The minimal command-line syntax for creating a LDF file from an existing virtual application layer is as follows:
Swvldf.exe –x c:\myfiles\IE6v1.ldf –l “Internet Explorer 6”
The “-x” parameter specifies the command (export) and must be followed by the path to the LDF file to be created. The “-l” parameter specifies the layer name and must be followed by the target layer name (the layer ID can also be specified) for the operation. By default, all layer information is saved to the specified LDF file. The additional flags provide the option to filter what layer information is exported to the LDF file. For example, the “r, w, R, W, m” flags, if specified, constrain the LDF to include only the data specified by the flag. For example, consider the following command-line:
Swvldf.exe –rwx c:\myfiles\IE6v1.ldf –l “Internet Explorer 6”
Notice the addition of the “rw” parameter flags. This causes swvldf.exe to generate only the RO and RW sub-layer file information to the specified LDF file.
As a brief aside, just a word on how command-line parameters are handled. The parameters can be coupled with “-x”, or can be placed separately on the command-line. For example, the following command-line syntax is equivalent:
Swvldf.exe –x c:\myfiles\IE6v1.ldf –l “Internet Explorer 6” -rw
Be careful to follow the instructions outlined on the help screen. Some parameters must be followed by additional information, as is the case with the “-x” and “-l” parameters. If a parameter associated with the import operation (“-i”) is included with the export (“-x”) operation, it is simply ignored. The parameters can be specified in any order on the command-line, so long as valid parameters are specified and parameters that require data to follow them (such as -i, -x, -l, -p, -L and –F) are specified properly. If an unsupported parameter is specified, swvldf.exe displays the help screen to the console and exits. Parameters are case-sensitive. Ensure that you specify the proper case when passing parameters to swvldf.exe.
Let’s get back to taking closer look at some of the other parameters associated with the LDF export operation. The “–L” and “–F” parameters control logging. The “-L” parameter turns on logging and must be followed by an integer between 0-3, which defines the level of logging. The log level values have the following meanings:
0 – Errors. Only errors are captured in the log.
1 – Warnings. Errors and Warnings are captured to the log.
2 – Information – Errors, warnings and informational messages are captured to the log.
3 – Trace – Verbose logging – all levels of log information are captured to log plus more granular tracing of what is taking place during each operation.
The “-F” enables logging to a file and must be followed by the path to the log file.
The final parameter we’ll discuss as part of the LDF file creation operation is “-e”. This parameter controls how registry and file ACL information is stored. If “-e” is specified, then all registry and file/folder ACL information is embedded within the LDF file. If “-e” is omitted, then two directories are created in the directory where the LDF file is created: “regs” and “dacls”. The “regs” directory might contain two files, one for the RW sub-layer, and another for the RO sub-layer. These files contain all of the registry information for the specified sub-layers in “regedit.exe” textual format. Allowing these files to be referenced outside the LDF file enables other tools to be used to generate, edit, or modify these files if required without parsing the LDF file itself. The “dacls” directory contains all of the file and directory ACL information stored in a textual format. If the registry and ACL information is not embedded in the LDF file, it is important to remember that these directories need to be distributed with the LDF file. The easy route is to always specify the “-e” parameter to ensure that the registry and file/folder ACL information is embedded in the LDF file.
Invoking swvldf.exe with the “-x” parameter reads all of the specified layer information and outputs an LDF file. A natural question at this point is “What is contained within the LDF file”? To answer that question, let’s take a closer look at the contents of the generated LDF file.
What’s an LDF file?
The simple answer to the question is that it’s an XML file that contains four categories of information:
- Folder information
- Registry information
- Layer Settings information
The top-level hierarchical organization within the LDF file is as follows:
<pkg-config version="1" name="Package Name">
<reg-import sublayer=”ro|rw” />
<!—Contains layer settings à
A detailed description of the LDF file format is found in the appendix of this article so we’ll not cover this in detail here, but each top-level category contains child categories that are containers for all of the virtual application files, folders, registry entries and layer settings.
The good news is that unless you are interested in modifying or handcrafting LDF files to be consumed by swvldf.exe, it isn’t necessary to know anything about the contents of this file, except for perhaps the <file-sources> tags (more on this later).
A final note on generating LDF files with swvldf.exe concerns the possible use of a “merge” directory that can be created in the same directory as the LDF file for the purpose of merging LDF content when generating an LDF file. The purpose of this “merge” directory is to allow content for the LDF file to be merged from external files. Why might this be useful? There are cases where you might want to define default content that can’t be defined in the virtual application layer that you’d like merged into the LDF each time it is generated. The supported tags for merge files are for defining shortcuts, file sources and for creating files at layer creation time. Following is an example of a merge file that shows the use of all the supported tags (see appendix for detailed description of the tags and attributes):
<pkg-config version="1" name="Internet Explorer 8" tool-version="188.8.131.52">
<created-file name="iexplore.exe.local" version="0.0.0.0" sublayer="ro" encoding="Ansi" destpath="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8"/>
<shortcut target-file="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\iexplore.exe" target-args="" link-file="[_B_]COMMONDESKTOP[_E_]\Internet Explorer 8" desc="Internet Explorer 8" show-mode="" curr-dir="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\" icon-file="[_B_]PROGRAMFILES[_E_]\Internet Explorer 8\iexplore.exe" icon-index="0" />
<file-source name="IE8-WindowsXP-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\IE8-WindowsXP-x86-ENU" search-paths=".;support" dwnload-dir="%cfgpath%\downloads" />
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU" search-paths="" dwnload-dir="" />
Virtual application layers that are created using the “installation capture” mechanism create or copy files and create shortcuts as part of the installation. Virtual application layers that are generated using swvldf.exe and a LDF must have a way to define the source for files to be copied to the layer, to create text files and the ability to create file shortcuts (*.lnk files) at the time the layer is created. These tags provide a mechanism for doing this and the “merge” directory proves a means for ensure that this content is added to the LDF each time it is generated. If the “merge” directory is not used, these tags must be added “by hand” to the LDF before an attempt to create a virtual application layer is made. Otherwise, the attempt to create the layer will fail because the required files cannot be found.
The “merge” files must be formatted according to the <pkg-config> XML format (described briefly above and in detail in the appendix). The names of the files do not matter, however, they must have an “.ldf” extension or they will be ignored by swvldf.exe. All files found in the “merge” directory are processed and merged in to the LDF file.
Creating a Layer with an LDF File
Creating an IE6 virtual application layer from an LDF file is accomplished by invoking swvldf.exe with the following command-line syntax:
Swvldf.exe –i c:\myfiles\IE6v1.ldf
This command causes swvldf.exe to parse each section of the LDF file and add the files, folders, registry, and layer setting information to a new layer. The “-i” parameter identifies the operation as “import”, followed by the LDF file to import.
It is also possible to modify an existing layer by using the following command-line syntax:
Swvldf.exe –i c:\myfiles\IE6v1.ldf –M –l “Internet Explorer 6”
The “-M” indicates that the LDF file should be used to modify an existing layer. The “-l” parameter identities the virtual application layer to modify.
A brief discussion of the other parameters associated with the LDF file import follows:
-n – This parameter, if specified, creates a new layer ID for the created layer. If not specified, the Layer ID found in the layer settings within the LDF file (under <settings> tag) is used.
- v – This parameter, if specified, turns off file version checking when copying files to the created layer. File checking ensures that the proper files are copied from the file repository to the layer.
-p – This parameter specifies to create a package from the layer in addition to creating the layer. The –p parameter must be followed by the path to the package file to be created (file should have .VSA extension).
-k – This parameter specifies that when creating a package (-p must be set) to keep the layer. Otherwise, it is removed after creating a package.
-o – This parameter specifies whether a package file should be overwritten if it exists. This parameter is ignored unless –p accompanies it on the command-line.
-s – This parameter specifies that only the <file-source> tags should be processed when processing the LDF file. This is useful when building a file repository and testing it before processing the other tags within the LDF file.
The “-L” and “-F” parameters have already been described in the section on exporting an LDF file. They operate in identical fashion as the import operations.
If you have been following closely you might be wondering where swvldf.exe retrieves the files required to create a virtual application layer. The answer lies within the content that resides beneath the “<file-sources>” tags within the LDF file. These tags instruct swvldf.exe to create a file repository from which the required files can be copied to the layer.
Creating a File Repository
The LDF file would be of little value if the files defined within it can’t be referenced when building the layer. The <file-source> tags provide a very powerful mechanism for instructing swvldf.exe to download, copy, or reference existing file paths to access files during the layer creation process. The best way to tackle understanding how this is done is by looking at an example. Following are the <file-sources> tags used to create the Internet Explorer 6 virtual application layer:
<file-source name="Cab Extraction Tool" srcpath="http://download.microsoft.com/download/win2000platform/extract/1.00.0.1/nt5/en-us/" type="http" file-repo="" search-paths="" dwnload-dir="%cfgpath%\downloads">
<src-file name="extract_setup.exe" type="cust" cmd-line="%src-file-path% /Q /C /T:%dwnload-dir%" />
<src-file name="extract.msi" copy=”false” type="cust" cmd-line="msiexec /a %src-file-path% /qn TARGETDIR=%tools-dir%" />
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="http://download.microsoft.com/download/d/3/0/d30e32d8-418a-469d-b600-f32ce3edf42d/" type="http" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU" search-paths="" dwnload-dir="%cfgpath%\downloads">
<src-file name="WindowsXP-KB936929-SP3-x86-ENU.exe" type="mssp" />
<file-source name="KB976325" srcpath="http://download.microsoft.com/download/E/9/8/E98E984B-4069-4D62-9107-32E5488E5AFA/" type="http" file-repo="%cfgpath%\filerepo\KB976325" search-paths="SP2GDR;SP3GDR" dwnload-dir="%cfgpath%\downloads">
<src-file name="WindowsXP-KB976325-x86-ENU.exe" type="mssetup" />
<file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" dwnload-dir="%cfgpath%\downloads" />
These tags reside beneath the <pkg-files> tag within the LDF file. Before we look closely at the example, let’s take a look at the meaning of the <file-source> and it’s child <src-file> tags and associated attributes:
<file-source> element attribute descriptions:
name – Describes the file source purpose.
srcpath – location of a file. This can be a file path or location on the Web (http URL).
type – defines the type of file source. The value of this attribute determines how the file is acted upon. Following are the support values:
http – srcpath points to an http URL.
- path – srcpath attribute points to a path in the local file system from which to copy files. Useful if a file repository of required files already exists. Files in the “srcpath” are not copied to the path specified by “dwnload-dir”.
- drive – srcpath attribute points a path in the local file system from where files should be copied to local file repository. This differs from the “path” attribute in that files are copied from the srcpath to the path specified by “dwnload-dir”.
file-repo – defines a file repository location. Swvldf.exe builds a list of all “file-repo” attributes that together comprise the “file repository” when processing <dest-file> tags (which are used to identify the files to be copied to the layer). It might be blank in the case where the file is used as a tool, not a source of files for a layer.
search-paths – defines paths beneath the “file-repo” to reference for files. Each path should be separated by a semi-colon “;” delimiter. Each path must reside beneath the “file-repo” path.
skip-existing – specifies whether child <src-file> tags should be copied if they already exist in the “dwnload-dir”. If not specified, the default is “true”. Supported values: “true”, “false”.
dwnload-dir – defines the location to where files are to be downloaded and/or copied (depending on the value of the “type” attribute).
<src-file> element attribute descriptions:
name – The name of the file. If its parent <file-source> tag has a “type” value of “http”, the <src-file> tag defines the file to be downloaded. Files are always initially copied to the path specified by “dwnload-dir”.
copy - specifies whether the source file (<src-file name=”filename”>) should be copied from the srcpath (defined on its parent <source-file> element). If not specified, this defaults to “true”. Supported values: “true”, “false”.
type – defines how the file should be operated on. Based on this type, the file might need to be extracted to the file repository. The supported values are:
cust – custom operation. The “cmd-line” attribute must also be defined as it defines the operation to be taken on the file.
- cab – the file is a Microsoft “Cab” file.
- zip – the file is a zip archive.
- self – file is a self-extracting archive.
- mssetup – file is Microsoft setup file.
- mssp – file is Microsoft service pack file.
As you look at the Internet Explorer 6 example you’ll notice several attribute values that are surrounded by % characters. These are macros that are expanded by swvldf.exe to their associated values. Following are the supported macros and their meanings:
%cfgpath% - expands to the path where the LDF file is located.
%ENV_VAR% - expands to the system %ENV_VAR% (only supported when used in the “file-repo” attribute value). Example: %windir% expands to c:\windows.
%dwnload-dir% - expands to the value of the “dwnload-dir” attribute. (Only supported when used in <src-file> element attributes).
%src-file-path% - expands to the path of the <src-file>. (Supported only when used in <src-file> element attributes).
%src-file% - expands to the name of the <src-file>. (supported only when used in <src-file> element attributes).
%tools-dir% - expands to the path of the “tools” dir. By default this “tools” directory resides in the directory where the LDF file resides.
Now that we have a handle on these tags and their associated attributes. let’s look at the specific example of the Internet Explorer 6 <file-sources> tags.
Each <file-source> tag identifies a source for files that comprise part of the file repository that is used as a source for files to be copied to a new or modified virtual application layer. These tags can also be used to download tools that won’t be included in the layer, but are required to extract files that are part of a file repository.
Let’s look at each tag:
<file-source name = “Cab Extraction Tool” … >
The “Cab Extraction Tool” is not intended to be part of the file repository. Its purpose is to download the “Cab Extraction Tool” from a public Microsoft site, extract it, and then place the extract.exe binary into a “Tools” directory that resides in the same directory as the LDF file. The <src-file> elements coupled with its “type=cust” and “cmd-line=…” attributes define how to extract the files to the proper locations.
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" …>
The “WindowsXP-KB936929-SP3-x86-ENU” file source defines the location from which to download the Windows XP SP3. The type of the <src-file> tag is “mssp” which means it is a Microsoft Service Pack file and must be handled as such.
<file-source name="KB976325" …>
The “KB976325” file source defines the location from which to download the KB976325 hotfix. The type of the <src-file> is “mssetup” which means the file is a Microsoft setup file and must be handled as such (the syntax for expanding an Microsoft Setup file is specific to that type. Set the log level to 3 and then look at the log file to see the command-line syntax used to expand these file types).
<file-source name=”Manually Generated Files” …>
The “Manually Generated Files” file source defines a path where files that are manually generated are made available in a local path (“type” attribute = “path”). For example, a shortcut file (.LNK) for Internet Explorer is placed in this path so it can be found and made available during creation of the layer.
If the <source-file> tags are defined properly, then once they are processed, there should exist a local file repository that contains all the files required to create a layer with the corresponding LDF file. Once the <file-source> tags have been processed, it is much more efficient to change the <file-source> tags to point to local paths where the files exist to make creating a layer much faster on subsequent invocations of swvldf.exe.
For example, once the LDF file for creating the Internet Explorer 6 has been run for the first time, the content within <file-sources> tags could be changed to the following:
<file-source name="WindowsXP-KB936929-SP3-x86-ENU" srcpath="" type="path" file-repo="%cfgpath%\filerepo\WindowsXP-KB936929-SP3-x86-ENU />
<file-source name="KB976325" srcpath="" type="path" file-repo="%cfgpath%\filerepo\KB976325" search-paths="SP2GDR;SP3GDR" />
<file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" />
These tags simply point at existing paths where the files already exist. The point is that the file repository needs to be created only once. After it exists, the LDF can simply point to the existing files.
The capability to point to existing files to create a virtual application layer makes it possible to create a virtual application layer from an application that is already installed on the system. This capability is used to virtualize Internet Explorer 8 on Windows 7. Internet Explorer 8 is installed by default on Windows 7, so there is no installation whichinstallation, which can be used to capture IE8. Following are the <file-sources> tags from an LDF file that is used to create a virtualized version of IE8 on Windows 7:
<file-source name="IE8 Windows System32 Files" srcpath="" type="path" file-repo="%windir%\system32" search-paths=".;en-US" dwnload-dir="" />
<file-source name="IE8 Program Files" srcpath="" type="path" file-repo="%programfiles%\Internet Explorer" search-paths=".;en-US;" dwnload-dir="" />
<file-source name="Windows Help Files" srcpath="" type="path" file-repo="%windir%\help" search-paths="" dwnload-dir="" />
<file-source name="Manually Generated Files" srcpath="" type="path" file-repo="%cfgpath%\filerepo\manual" search-paths="" dwnload-dir =”" />
Notice that all files are referenced from the local system. This, of course, implies that when building this package that swvldf.exe must be run on a Windows 7 system with Internet Explorer 8 installed.
The ability to create a local repository from an LDF file makes it possible to generate virtual application layers and packages simply by supplying an LDF file and the swvldf.exe utility. A very powerful capability!
The Value of swvldf.exe and LDF Files
We’ve already discussed the fact that using swvldf.exe and LDF files provides a mechanism to create virtual application layers where capturing is not possible. However, there are other uses for LDF files that are interesting to consider.
The use of LDF files can also provide a solution for cases where capturing an application on different systems yields inconsistent packages. This can happen due to differences in software that is installed on systems when capturing. Using swvldf.exe and LDF files ensures that identical layers get created each time. To ensure that customers can generate consistent layers and packages, the workflow can change to the following: Capture a virtual application layer. Ensure it works, and then use swvldf.exe to generate an LDF file. Handcraft the <file-sources> tags to create a local file repository from the application installation file. Make the LDF file available to creating a consistent package. The virtual application layer can then be created by anyone, on any system.
Generating an LDF file of a virtual application layer in an original state and then again after an upgrade, can provide a quick mechanism to discover differences between versions. You might update an application using a service pack, and then generate an updated LDF for the updated state. You can then use any text “diff-ing” tool to look at the changes between the original and updated versions of the LDF files. This can be a very handy troubleshooting technique when an application upgrade causes problems.
You could also create a library of LDF files that can be used by an on-line community. Application packaging can be part art and part science. Imagine the benefit of having a library of “tested”, “tried” and “true” LDF files that contain all of the necessary tweaks and modifications to generate rock-solid virtual application layers.
The SWV Layer Definition Tool provides a mechanism to create virtual application layers from a textual definition of a layer coupled with a file repository in cases where capturing a layer is not possible or proves not to be feasible. It includes the capability to create, on the fly, a local file repository by downloading files from public Web sites or by retrieving them from a local drive, network share, or local DVD drive. The key benefit is the ability to generate consistent virtual application layers on any system.
Download The SWV Layer Definition tool from the following link:
Download IE6 for Windows XP LDF from the following link: http://www.symantec.com/connect/downloads/internet-explorer-6-windows-xp-layer-definition-file
Download IE7 for Windows XP LDF from the following link: http://www.symantec.com/connect/downloads/internet-explorer-7-windows-xp-layer-definition-file
Download IE8 for Windows XP LDF from the following link: http://www.symantec.com/connect/downloads/internet-explorer-8-windows-xp-layer-definition-file
Download IE8 for Windows 7 LDF from the following link: http://www.symantec.com/connect/downloads/internet-explorer-8-windows-7-layer-definition-file
Error Codes returned by SWVLDF.EXE
6000 Invalid LDF File – XML file format is not valid.
6001 Invalid XML attribute was specified on an element.
6002 Package name attribute missing.
6003 Package element missing.
6004 Failure during attempt to invoke external process.
6005 Package type attribute not defined.
6006 Required file attribute not defined.
6007 Invalid virtual application sublayer defined.
6008 Import file not found.
6009 No meta-data substitute value found.
6010 Invalid source file.
6011 Invalid file version.
6012 Source file not found in any file repository.
6013 Error during copy file.
6014 Attempt to save temporary import registry file failed.
6015 Attempt to save substituted import registry file failed.
6016 Package action not defined.
6017 Invalid layer ID specified.
6018 Download type not defined.
6019 Source path attribute not defined.
6020 File repository path attribute not defined.
6021 Download directory attribute not defined.
6022 Source file name not defined.
6023 Source type not defined.
6025 Http file download failed.
6026 Copy download failed.
6027 Invalid download type.
6028 Run expand failed.
6029 Run mssetup failed.
6030 Run custom failed.
6031 Unzip failed.
6032 Open zip failed.
6033 Invalid download type specified.
6034 Move file failed.
6035 Specified download directory does not exists.
6036 Unknown source type.
6037 Invalid copy file specified.
6038 File sources not defined.
6039 Invalid attribute value.
6040 Missing registry file attribute.
6041 Missing destination layer attribute.
6042 Missing destination path attribute.
6043 Missing acl file attribute.
6044 Acl file not found.
6045 Config file exists.
6046 Invalid directory.
6047 Failure during load file.
6048 Failure during save file.
6049 Invalid registry value: hex7
6050 Invalid registry type for value.
6051 File name not defined.
6052 Missing content value.
6053 Failure during processing multi-value reg string.
6054 Failure during processing string reg value.
6055 Failure during processing dword reg value.
6056 Failure during processing binary value.
6057 Failure during process excludes.
6058 Failure during run of mssp type.
6059 Layer ID not found in LDF file.
6060 Error layer already exists.
6061 Failure during retrieve event string.
6062 Required version attribute no present.
6063 Failure attempting to add version info to layer settings.
6064 Required file shortcut tag attribute missing.
6065 Failure during attempt to expand varialized path.
6066 Failure during attempt to create shortcut file.
6067 Failure attempting to expand macro.
6068 Failure during attempt to create file.
6069 Failure during attempt to create directory.
Layer Definition File XML Tags and Attributes Description
|<pkg-config>||Child of: None. Root tag.|
|name||Name of the virtual application layer.|
|version||Version of the LDF file.|
|tool-version||Version of tool used to create the LDF. The tool-version and LDF version information is added to the layer settings metadata as LDFToolVersion and LDFVersion respectively when creating a layer.|
|<pkg-files>||Child of: <pkg-config>. Contains definitions for source files, destination files, file shortcuts, created files and file/folder ACLs.|
|<file-destinations>||Child of:<pkg-files>. Contains definition tags for all files destined for the layer.|
|<dest-file>||Child of: <file-destinations>. Defines a file to be copied to the layer.|
|name||Name of the file.|
|version||Version of the file. Used to ensure proper version of file is copied to layer. May be set to “0.0.0.0” for undefined. The –v parameter can be passed to swvldf.exe to have the tool ignore file versions when creating a layer.|
|sublayer||Specifies the sub-layer in which the <dest-file> will be copied.|
|scrpath||Location from which to copy file.|
Defines how to operate on srcpath if value exists. Supported values are:
- abs = srcpath points to an absolute path.
- srch = use search paths to find the source file in a file repository.
- xlate = Expand the variablized path to use as the source for the local file. (Used for Physical to Virtual)
|<file-acl-entries>||Child of: <pkg-files>. Defines the file and folder ACLs within the layer.|
|<file-acl-entry>||Child of: <file-acl-entries>. Contains the text-based ACL definitions for layer files and folders. Used if –e param is passed to swvldf.exe with –x param.|
|sublayer||Defines the sub-layer to which the ACLs apply.|
|<file-acl-imports>||Child of: <pkg-files>. Contains definitions that point to external ACL import files.|
|<file-acl-import>||Child of: <file-acl-imports>. Defines the location of an externa ACL file that contains all sub-layer file and folder ACL definitions.|
|sublayer||Defines the sub-layer to which the ACLs apply|
|aclfile||Path relative to the LDF file that contains an external export of the file and folder ACL definitions. If swvsdf.exe –x is invoked without the –e flag, then the ACL file export is found in %cfgpath%\dacls.|
|<file-sources>||Child of: <pkg-files>. Contains <file-source> elements.|
|enabled||Defines whether contained <file-source> tags should be processed.|
Child of: <file-sources>. Define a file repository from which files will be copied when creating a virtual application layer.
The order of <file-source> elements matters! When processing <dest-file> elements where <dest-file srcpath-type="srch"> then these paths will be traversed in the order specified in <file-sources>.
The <file-source> element MAY contain <src-file> elements which defined files to be copied from "src-path" and extracted to "file-repo".
For example, src-path may point to an HTTP url from which to retrieve .CAB files. These files will be downloaded to "dwnload-dir" and extracted to "file-repo".
|name||Describes the file repository.|
|src-path||Specifies the location from which files will be retrieved.|
specifies the type of the src-path. [drive | share | http | ftp]
- drive = local drive
- share = use unc path
- http = url to files base on http server
- ftp = path on ftp server
Specifies relevant connection info given the "type" attribute specified. Not used if type is drive or share.
If "type" attribute is set to http and http proxy is required then the conn-str attribute should contain:
- pxydomain is the http proxy server domain.
If conn-str value contains ONLY the value “IE”, then the proxy settings defined for IE will be used.
If "type" attribute is ftp it is formatted as follows:"usr;pwd".
|file-repo||Specifies the location from which files will be referenced when building a package. Extracted files will be placed in this location!|
|dwnload-dir||Specifies the location to which files will be downloaded in the case of type=http | ftp. If not defined %cfgpath%\downloads is used.|
Specifies locations within the extracted archive path in which to look for files when processing files to copy to package.
Each path MUST be relative to the extracted archive and should be semi-colon-delimited. Swvldf.exe will concatenate these paths with the file-repo path to define the full path to files within the archive. Order MATTERS. FIRST file found within the paths will be used.
If "." is used as a value, the "file-repo" attribute will also be added as a search path.
Path to tools used to process <file-source> files. If not specified, %cfgpath%\tools is assumed.
Default tools: cab=extract.exe, zip=[internal], http=[internal], ftp=[internal]
Useful for using existing tools on the system or when downloading tools to use as part of processing files.
If not present or set to "true", skip files that already exist in the "dwnload-dir" directory. If false, copy down all files to "dwnload-dir", every time.
|<src-file>||Child of: <file-source>. Element that defines src files to be placed in "file-repo" for use by swvldf.exe when generating a layer.|
|name||Name of the file.|
Type of the <src-file>. Supported values are [ file | cab | zip | self | mssetup | mssp | cust]
- file = standard file
- cab = MS archived cab file
- zip = zip archive
- self = self-extracting zip
- mssetup – Microsoft Setup file
- mssp = Microsoft Service pack
- cust = Defines a custom command to be executed to operate on the file in some way. (If “cust” is specified, the “cmd-line” attribute must be defined).
Defines the cmd-line to be used to handle this particular file. Examples include custom archiver (e.g. c:\temp\MyUnarchiver %fn% /extract). The following macros can be used as part of the cmd-line value:
- %src-file-path% - expands to the full path of <src-file>
- %src-file% - expands to just the name of the <src-file>
- %file-repo% - expands to the full path of the file repository path specified on parent <file-source> tag.
- %dwnload-dir% - expands to the download directory specified on the parent <file-source> tag.
- %tools-dir% - expands to the tools directory specified on the parent <file-source> tag.
- %cfgpath% - expands to the directory where the LDF resides (or will reside in the case of –x).
Specifies the location where extracted files are placed. If not specified, extracted files go to "file-repo" (of parent <file-source> element) by default.
If set to value %dwnload-dir% then the "dwnload-dir" attribute of the parent <file-source> element is used. Any valid path on the local system can be used.
If not present or set to "true", the file will be copied from "srcpath". If set to false, it will not.
Useful if file was copied to "dwnload-dir" through some other means. The file will still be processed according to the "type" (i.e. CAB files will be extracted, Zip files unzipped, etc).
|<shortcuts>||Child of: <pkg-files>. Contains shortcut definitions.|
|<shortcut>||Child of: <shortcuts>. Defines a file shortcut to be created in the layer.|
|name||Name of the file including extension (i.e. “Internet Explorer 6.lnk”). This needs to match the name of the file defined as a <dest-file> tag.|
|target-file||File name of the link's target. Must be variablized path (i.e. [_B_]PROGRAMFILES[_E_]).|
|target-args||Command line arguments passed to link's target.|
|link-file||File name of the actual link file being created. Must be variablized path.|
|desc||Description of the linked item.|
|show-mode||ShowWindow() constant for the link's target.|
|curr-dir||Working directory of the active link. Must be variablized path.|
|icon-file||File name of the icon file used for the link. File must exist in the layer and path must be variablized.|
|icon-index||Index of the icon in the icon file. Index of icon within “icon-file”.|
|<created-files>||Child of: <pkg-files>. Contains <created-file> tags.|
Child of: <created-files>. Defines a file to be created. Content of file must be placed inside the <created-file> tags. No content will create a zero-byte file.
Content should be wrapped in CDATA section.
|dest-path||Path in the layer to create the file. Must use variablized path.|
|encoding||Defines the encoding to use when saving the file. Supported Values [Ansi | Unicode | Utf-8].|
|sublayer||Sub-layer in which to create the file.|
|name||The name of the file to be created. Must match the name of the file defined as a <dest-file> tag.|
Child of: <pkg-config>. Element that contains all folder definitions for the specified Layer.
Child of: <pkg-folders>. Element that contains all folder definitions for the specified Layer.
Child of: <folders>.
Direct child of the <folders> element whose content defines the full path to a single folder path within the specified layer.
|sublayer||Specifies the sub-layer to which this folder belongs.|
|<pkg-registry>||Child of: <pkg-config>. Direct child of the <pkg-config> element that contains all registry definitions for the specified Layer.|
|<reg-entries>||Child of: <pkg-registry>. Direct child of the <pkg-registry> element that contains all registry definitions for the specified Layer.|
Child of: <reg-entries>. Direct child of the <reg-entries> element that contains all registry definitions for the specified Layer.
The content contained within <reg-entry> tags is "regedit.exe" textual format and wrapped within a "CDATA" section.
Note: if swvldf.exe -x <file> -e is specified the registry content is embedded within the <reg-entry> tag.
|sublayer||Defines the sub-layer to which the registry entries will be applied when creating the layer.|
|<reg-imports>||Child of: <pkg-registry>. Contains <reg-import> tags.|
Child of: <reg-imports>. Direct child of the <reg-imports> element that contains all registry definitions for the specified Layer.
Note: if swvldf.exe -e <file> is specified without the -d flag, then registry content for the specified is exported to the file specified by the regfile attribute.
|sublayer||Specifies the sublayer to which the registry entries belong.|
specifies an external reg file that contains registry entry definitions for the specified sublayer. The reg file must be in "regedit.exe" textual format.
|<pkg-settings>||Child of: <pkg-config>. Direct child of the <pkg-config> element that contains all Layer Metadata definitions.|
Child of: <pkg-settings>. Direct child of the <pkg-settigns> element that contains all Layer Metadata definitions.
All elements contained within the <settings> each specify a layer setting. The element name matches the Layer setting defined within the layer metadata.
If the setting is multi-valued then a parent tag with the setting name with "-entries" appended is created and all values are contained as individual values.