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:

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):

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:

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):

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:

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:

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:

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”:

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:

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:

However, you could have a 3^rd 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:

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).