Share via

App-V 5: On App-V Package Modernization with the OPC (Open Package Container) or: One Package Container to rule them all!

  • Article

Much of the changes in App-V 5 revolved around moving to more integrated components (NTFS, a “real” registry, native API’s on the client, representational state transfer on the server side, etc.) – but one of the most major key developments was the modernization of the AppV Package format. The reason behind this was simple. Using this new standard based upon an open standard allows for the modernization of your legacy applications with regards to package format. This provides synergy going forward by synchronizing the packaging of legacy application with the native packaging format of your modern applications existing (or to come.)
This drastic change makes a huge difference. The package is open and human readable. No more closed, custom package format full of mystery. Pre-requisites, installation process, experience opt-in settings, configurations, and site-specific deployments can be simplified into a single-command deployment. In addition, the package format exists in an installed state that follows the principles of the open package specification outlined in the ISO standards for the Open Package Specification (OPC) - https://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51459

 

This is also clarified in the following magazine article from MSDN: https://msdn.microsoft.com/en-us/magazine/cc163372.aspx

 
The OPC Standard

The Open Package Conventions, or as it also referred to as Open Packaging Container, are a set of standards spearheaded by Microsoft to store binary data and XML metadata in a single entity leveraging Open XML and ZIP formats. OPC-based file formats combine the advantages of leaving the independent file entities embedded in the document intact and resulting in much smaller files compared to normal use of XML. With OPC, you have a package in ZIP format that can contain mandated descriptor files, content definitions by MIME type, followed by application-specific metadata and resources files. With the embedded MIME definitions it also removes many issues associated with simple document file type extensions.


 
The container could be treated as a package or a document - as in the case with Office documents. Regardless, each is technically a ZIP archive containing resources identified as parts and each part has a unique path identifier by URI and by a specified content type expressed as a MIME type to describe the actual data stored in that part. You can see this when you browse an APPV, APPX, or even a .DOCX file using a ZIP utility.


 
In addition to a hierarchy of directories and parts, OPC packages representing document types commonly use relationships to access content through associations. These Relationships are composed of four elements:

  • The identifier (ID)
  • The optional source (the package or a part within the package)
  • The relationship type (a URI-style expression that defines the type of the relationship)
  • A target (a URI to another part within the package or to an external resource)

The extension ".rels" is reserved for storing relationships metadata within "/_rels" subfolders. The subfolder name "_rels", the file extension ".rels" within such directory, and the filename "[Content_Types].xml" in any folder are the only three reserved names for files stored in an OPC package. Otherwise, it is extensible to associate additional resource type with their specific package and application standards (for example -  those resources tied to App-V i.e. StreamMap.xml, PackageHistory.xml, etc.)

Notice in an APPV package while the [Content_Types].xml is present, the .rels components are not.  AppX and AppV handles these relationships differently using its own AppXBlockMap.xml and AppXManifest.XML files. More information can be found in that excellent MSDN article I referenced earlier: https://msdn.microsoft.com/en-us/magazine/cc163372.aspx  

AppX (Modern Applications)

AppX is the OPC-compliant package format for both Modern applications and Windows RT packages (what we commonly refer to as store applications) as referenced in: https://msdn.microsoft.com/en-us/library/windows/apps/hh464929(v=VS.85).aspx  
The AppX package can be viewed with a ZIP extraction utility just like the AppV package. Like the APPV file format, the APPX package uses declarative XML to define requirements, dependencies, and relationships defined in “AppxManifest.xml” instead of a relationship resource folder.

AppV (Legacy Applications)

While the AppX package format can be generated during modern application development (https://blogs.msdn.com/b/windowsappdev/archive/2012/12/04/designing-a-simple-and-secure-app-package-appx.aspx) your existing applications can be sequenced with the App-V sequencer and deployed, managed, and serviced as App-V packages that have the binary equivalency of the Windows Store APPX format. Even better, these can be deployed to Windows 7 computers running the App-V 5 Client (where store-based modern applications cannot.) Be advised however, that while App-V 5 uses the same file format as modern applications, it does not mean you can deploy or publish an App-V package as a Windows Store application. They only share the same modern package format.

That’s not all . . .

Document Formats have gone that way as well. Ever opened a DOCX or XLSX file in 7-ZIP? You can see the OPC-based layout this way! This is by no means new. This began with Office 2007. In fact, other vendors besides Microsoft have started to adapt this standard including Autodesk, Siemans, and Mathworks. There is an excellent historical reference on MSDN that introduced the OPC document format and relationships back in 2009 that is very helpful in understanding the Open Packaging standards as they apply to Office document formats here: https://msdn.microsoft.com/en-us/library/ee361919(v=office.11).aspx