Naming your published applications in App-V package (may require some forward thinking)

One common mistake people tend to do when trying out the whole application package “side-by-side” functionality of App-V – i.e. running separate packages of the same application suite on a same machine – is to not be careful enough about how to name each individual application.

This can result in a situation wherein some or all of the applications from one of these packages fail to launch properly or showing up, because the name you assign for an application is decisive factor for the App-V Client; it cannot tolerate identical names or ambiguous names between different virtual applications on a same client. We all know about what a unique name for virtual application means, but what about the issues related to ambiguous naming are all about?

To fully understand the problem, let’s first look at the application naming in general when it comes to App-V OSD files.

Not known by any other name…

When you have an OSD file, or when you edit application information in the Sequencer, there’s two separate pieces of information called NAME and VERSION:

Application NAME and VERSION in App-V Sequencer

Application NAME and VERSION in OSD file

Together these two texts form a fully qualified application name for the purpose of identifying one particular virtual application from all the other virtual applications you might have. Interestingly enough, App-V Client does not internally use GUID value present in SOFTPKG –element in identifying virtual application; that one seems to serve no purpose at all. So the name and version fields define the virtual application represented by the OSD file to the client.

When such an application is then published to the App-V Client, you can see the application in the App-V Client’s management console by this very name (including the version number):

Virtual applications in the console

Note that for the actual application shortcuts – created to the user’s Start Menu or desktop by App-V Client on behalf of application itself – use only the name part instead of combining both name and version to one very long name. This design decision was likely done because usually by default the version field contains all sort of “crap” as Sequencer digs up the name and version information from the target executable. To be honest, I’m actually not being a 100% accurate here because in the past SoftGrid used to use the version field’s information too in the shortcuts it created, but that hasn’t been the case anymore for a long time now.

To illustrate, let’s consider how a well-known executable called cmd.exe stores that information in the headers:

Windows 7 cmd.exe properties

As you can see, the version number is rather long – not the longest or ugliest I have seen before, though – and so who would want to use that sort of text in their shortcut names, right?

Unless you clean it, it’s there inside the OSD (up to the 16 characters, which is the limit for VERSION –attribute in OSD per its schema) and will be shown in the console, as well as in the launch indicator (name Windows Command Process shortened to CMD to allow showing of version number in the short indicator bar):

App-V launch indicator showing version number

And when you do certain operations with the sftmime.exe command, the whole long fully qualified virtual application name is also required – and in case sensitive manner I might add!

Ok, so now we know that we have both name and version -information in each OSD file, by which the App-V Client recognizes the virtual application on a client and which also defines what the user will see as a shortcut name. In the default case that is, I should say, because you can actually customize each shortcut name by changing DISPLAY –attribute found in the SHORTCUT –element.

Not by a coincidence, this is exactly what Sequencer uses in reality to control the name of the generated shortcut:

DISPLAY attribute customizes the shortcut name

If I were to remove DISPLAY -attribute (as well as the FILENAME –attribute, which tells App-V Client what physical filename to use for a shortcut file) from the OSD file, App-V Client would name my application’s shortcuts during package import or publishing refresh with the whole name+version combination taken from the SOFTPKG -attribute! As can be seen from previous CMD.EXE example after I went and remove these attributes from OSD file:

Shortcut created without DISPLAY

So in the end, it’s the DISPLAY –attribute that is behind what defines what the Windows will show you as shortcut name. This means that you could actually customize your shortcut name(s) from what the Sequencer stores there by default, without changing the general NAME and VERSION information for that OSD file. In Sequencer, you would have to go and edit OSD’s XML tree, but with tools like our AVE you can actually click on an individual shortcut and rename it to your liking:

Selecting shortcut in AVE

Renaming shortcut display name in AVE

Maybe not so much of use for many for purely a display purposes only, but the possibility is there, either manually or otherwise and it will be needed if you have conflicting names…

Clashes in shortcut names and ambiguous references in App-V

After seeing how the name for a virtual application is formed in App-V, what does it mean to have issues in clashing naming between two different applications across the packages?

This problematic situation arises if you name two of your virtual applications too close to each other. And by close I mean messing up with what goes into name –part and version –part of that name and not being consistent naming-wise.

Let’s consider our Design Review –application used in the examples above: what I have done during the packaging process (in Sequencer) is to simplify naming of it when I chose “Autodesk Design Review” as name and “2011” as a version. Because, you know, that’s the name of the application and also its version as such… But in reality, that is not what the version of that particular application is internally; if I look at the DesignReview.exe file, it identifies itself as being version 11.0.0.86, just like almost all software products do despite their “marketing version”:

Autodesk Design Review 2011's real version number

One of my best practices has always been to clean up the name and version information into the form that can be presented to the actual end user. Usually automatically picked-up information is correct for the name –part but as we saw with the cmd.exe example, version information could pretty much be anything. And since we also noted that the version information does crop up in various places in App-V Client, it’s a good idea to do some prettying of that.

In the current context of creating problems with a careless naming with multiple package of the same application; what if I sequence this same application again but this time left the naming as-is to read “Autodesk Design Review 11.0.0.86”? All fine and dandy, it does differ in naming from my original packaging, right? So we get these:

  • Autodesk Design Review 2011 (package #1)
  • Autodesk Design Review 11.0.0.86 (package #2)

Well, not fine at all really! This does not only introduces the possibility of having ambiguous name problem when both applications has been imported into the App-V Client, but it could also mean that the one or more of the application shortcuts from some package will disappear without warning.

The reason is that while the App-V Client itself is satisfied when it comes to unique naming of virtual applications themselves, problem of having two shortcuts with the same name remains from the Windows’ standpoint if they both are targeted at the same location (say, desktop)… which is very plausible when you re-package the same application multiple times in different configurations. At the core, shortcuts created by App-V are just a simple .LNK files and naturally you cannot have two identical filenames in the same directory (which the desktop and start menu folders are, in technical sense).

When this happens, your second instance’s shortcut won’t be added to the intended location or the existing (.LNK file) instance is silently replaced, and there’s no visual telling why or even that it is has happened. And the client’s log file (sftlog.txt in C:\ProgramData\Microsoft\Application Virtualization Client) probably does not have anything in it either! But if you look at your App-V Client’s console, there’s both applications listed so you don’t suspect anything went wrong as such:

Multiple similar-sounding application names

Another issue which relates to the launch of the application from the shortcuts is this whole ambiguous reference to the name an application has. Under normal circumstances, App-V Client itself creates all shortcuts so that the parameter for sfttray.exe is fully qualified name of the application:

Parameters for the application as created by App-V Client

However, you could have a 3rd party method for creating shortcuts, like User Environment Management (UEM) solution or your own scripting, and these might refer to virtual application by using only the name –part as a parameter. If I have two applications that have the same name -part, but differ in the version –part (like my Design Review example), that would then be sfttray.exe /launch “Autodesk Design Review” as a command line.

Instead of starting the application requested, we are greeted with this error message:

Error message in App-V Client

What happens is that App-V Client looks through that list of virtual applications know to it, and sees that there are two applications called “Autodesk Design Review”. Which one to launch? There’s no telling! So the client gives up and does not even try to guess it.

And it used to be even worse that this: in some earlier App-V versions even having another virtual application’s full name as part of another one’s name –part caused this same error to appear. That is apparently now fixed in the 4.6 SP1 at least, but it’s something that users of older clients still should be aware of.

So all in all, you should be very aware of how you name your applications. If you intend to package the same application suite in multiple versions, it’s especially important to pay close attention to how the names appear both from App-V’s perspective as well from Windows perspective. And usually the names need some forward thinking (how’s your environment going to be) in addition to backward thinking (how your existing packages are).

, ,

About Kalle Saunamäki

As one of the first four Microsoft App-V MVP's, Kalle has been doing application virtualization since 2003 and virtualization in general from 2000, and is a recognized in-depth technological expert in Microsoft application virtualization community.

View all posts by Kalle Saunamäki

Subscribe

Subscribe to our RSS feed and social profiles to receive updates.

5 Comments on “Naming your published applications in App-V package (may require some forward thinking)”

  1. Nicke Källén Says:

    Isn’t the official way to start apps using NAME VERSIOn and not just NAME, so the last error shouldn’t occur (unless you of course have two apps with the same NAME and VERSION)?

    Reply

    • Kalle Saunamäki Says:

      Sure, it’s the official way (App-V Client itself uses NAME+VERSION in the parameters), but I was only referring to the case where you might have 3rd party (UEM) / manual method of creating shortcuts which only happens to use NAME part.

      And as I wrote it has been getting more relaxed, this error message was far easier to had during 4.5 times even with full NAME+VERSION combination if another app happened to match the NAME part with its NAME+VERSION. Like “Office Excel 2003” and “Office Excel 2003 11.0”.

      Reply

  2. Joey Graco Says:

    Kalle – This is a very detailed post about application naming that I learned a lot from. It’s helped me save a lot of frustration I’ve been having since getting started in application virtualization. I look forward to reading more of your posts, sounds like you have a lot of expertise. Thanks again.

    Reply

Trackbacks/Pingbacks

  1. What everyone and their mother should know about VFS in App-V, pt. 3 – A special leak-through condition for fully virtualized folders | Gridmetric Blog - 20.12.2011

    […] the way, and referring to my earlier blog article on package naming here, note how that version field for a notepad.exe is by default something that we might want to […]

  2. AVE 2.3 feature highlight pt. 1 – Creating new App-V packages | Gridmetric Blog - 13.01.2012

    […] is the recommended practice with sequencing in general, you should always verify the application name and version fields for sanity. And if the application happens to need any parameters to it or (rare, but possible) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: