In this new series, we’re going to highlight some of the new features that we introduced in Application Virtualization Explorer (AVE), version 2.3, released in December last year (gosh, sounds like a long time ago when said like that!).
First feature I’d like to discuss about is the ability to create completely new App-V packages solely within AVE, something that previously couldn’t be done. In the past, should you had the need for even a simple App-V package, you had to resort into using Sequencer for that as AVE was only able to make edits to already-existing sequence.
And let’s face it: for simple packages – and by simple I now refer to a scenario wherein you don’t need to perform installation monitoring or anything like that – going through all the usual hassle of:
- Starting up and logging in to a separate packaging workstation (usually virtual machine) in a clean state, starting up the Sequencer
- Walking through the wizard (especially now in 4.6 SP1, where wizard is long and bit too convoluted to my taste)
- Having to do monitoring of the changes to the system to capture even something as simple as one or few files and registry entry
- Defining the application entry points
- And then finally making sure everything matches up what you expected through various screens in Sequencer’s UI
…is a bit too much work, don’t you think? I mean, all the contemporary packaging tools allow you to work solely in the UI without forced wizard-based operation, but not the Sequencer. That’s what the packagers are used to using in traditional MSI / installer world too…
I guess it needs to be said at this point that by no means I am trying to downplay the Sequencer for what it is good for: capturing complex sequences wherein there is a lot of content added to the system. But what I am trying to illustrate here is the fact that when you do not have the need for that heavy-handed operation it would be nice to have an alternative.
And that alternative now is exactly what we built for AVE 2.3: an ability to quickly create an empty App-V package that you could fill up with your original content by manual means. And to just give you few examples of what those scenarios might be, out of the usual context of doing “repackaging” of the vendor installations:
- Software vendors or internal developers doing their own software packages directly to App-V format according to the spec. Granted, we have had Virtualization Encoder –product for many years now for this purpose as well; it is command-line based and can take a template as an input, which makes it even more suitable for software build process, but for some needs the GUI –based package construction is better (if there isn’t formalized build/packaging process, for instance).
- Packaging of simple applications not needing proper installation. I personally have seen a lot of applications distributed on the Internet, maybe not coincidentally them in many cases being open source variety, as a ZIP files or other archives without any real installers. If these applications’ installation procedure is simply 1) create a folder, 2) unzip the archive to the folder, 3) create shortcut manually; then why would we need to do any sort of monitoring for them? We don’t!
And having been in the software business for some time now, I know that the customers will think of many more use cases for that sort of functionality that we couldn’t even being to anticipate for!
A practical example of doing complete application package end-to-end with AVE
Now, with AVE 2.3 you could easily accommodate these two (and more!) example scenarios by building up a completely customized package from scratch, without having to resort to App-V Sequencer. As an example, I’m going to do a complete packaging of one of my favorite open-source graphical tools, Inkscape, which is a good example also in that it was (still is?) very notorious at some point messing up with Sequencer’s monitoring by doing lot of I/O during installation (which filled up Sequencer’s active monitoring binary log very quickly and into very big in size, causing massive slowdown).
For the purpose, we will download the 7-zip package of the application and use that since Inkscape is one of those before-mentioned applications not needing an actual installation:
Note that you could of course do the same in Sequencer, but I challenge you to do it in the same timeframe what is possible with AVE. And I’m doing this from my own workstation, not on a separate packaging machine where the Sequencer lives in perfect isolation harmony in a clean system ;-)
After downloading the 7Z file, we simply uncompress it into some temporary folder somewhere on the system, doesn’t really matter wherein as long as we can find it. In my case it’s uncompressed into temporary folder on the desktop (hey, desktop is the logical place for all the working files, right? Right?):
Next logical step would of course be to start AVE and to begin creating the actual App-V package out of the content we now have lying around the disk. When AVE is opened, we can invoke Create -> Empty App-V package –functionality from the File –menu:
This will open up the basic package creation properties screen we can use to, first, name our package and, secondly, to select if we target it for 32-bit or 64-bit systems.
Selecting 32-bit package equals what you would get out of running Sequencer on a 32-bit Windows (and likely a package that works both in 32-bit and 64-bit environments), whereas selecting 64-bit here would result package that is marked internally as being 64-bit and thus only safe to use on 64-bit client systems as well. To understand more on the bitness –related issues, see this earlier blog posting if you haven’t read it already.
By default we will use the package name for the package’s internal root directory name (the so-called “asset directory”) as well, which is the one that will be mounted on the root of the client’s virtual (“Q:”) drive. If you want to, you can customize it to your liking (like, setting an explicit 8+3 format name). However, to conform with how the Sequencer 4.6 SP1 started doing things, AVE will also auto-generate a random short name version for the folder if you leave it to long and/or default (it’s just not displayed in this screen yet, but you can check it up later on from AVE’s UI). This ensures that there’s almost a zero possibility of clash of short names on the virtual drive, which wouldn’t necessarily be the case if we just use the default NTFS short name algorithm.
It takes only a few seconds to initialize the empty package after pressing Accept –button, and we can start adding content to our otherwise empty new package. Since we have the Inkscape files ready and waiting on the disk, by far easiest method of putting those files into sequence is to “suck” the whole directory structure with AVE’s import –functionality. To do so, simply select the context menu from the root directory from the Virtual Files & Folders –view (open by default) and choose Import directory from it:
From the folder selection dialog, choose the extracted folder (the selected folder itself will be added to the package, not just the contents of it):
After a while (AVE will copy the files into user’s temporary directory for the lifetime of the opened package, so it takes variable time depending on how good I/O you have for your disk(s)) the imported directory shows up in the directory tree which indicates that it was imported in full. In the screenshot below it is shown in an expanded sate to display its contents:
As we sure would like to publish an application from the package in addition to having the actual content of it, we can now locate the main executable from the directory tree, which is inkscape.exe –file in this case. By selecting it and again opening the context-menu, we can choose Publish this file –command which will allow us to create a new published application i.e. OSD out of that program:
Like 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) another working directory besides where the executable file is located, those can also be customized here. In this case, the defaults that were dug up from the .EXE file’s headers seem to be sensible:
When Publish –button is pressed, AVE creates a new application out of the selected binary and the focus is automatically switched to the Package Configuration –screen, wherein you can now select the newly minted application for further editing:
One very obvious addition would be a shortcut to our application; otherwise nothing will show up on an App-V Client machine where the package is deployed to. This can be done by pressing down either On desktop or On Start-menu –selection inside the Publishing settings (application) –section of the page, and choosing Create new shortcut –command (or if wanting to establish the shortcut in some nested folder structure, first selecting and creating new folder and navigating back there to add new shortcut):
The name of the shortcut is by default the name of the published application itself, which in our case is what is needed too:
Now we have an entry point available for the application, and should we need any other customization(s) like limitation of the operating system visibility (by default not limited) or changing the streaming path, these could be done now. But since for our simple purposes this is all that is really needed, we can go saving out our brand new App-V package of the Inkscape program.
Saving newly created package has to be done again from the File –menu, using Save package as –functionality:
In the save setting dialog, unless we want to customize settings further, there’s nothing else that needs to be set except the save directory itself i.e. the directory package files will be written to. I will use the one where the extracted Inkscape source directory was stored as well, and after hitting Save –button AVE will start encoding the package to the disk:
By default new packages are all in latest and greatest App-V package format, 4.6 (which include the 4.6 SP1 version as well), but if you are still using any older versions like perhaps 4.5 then you can change the format before saving and the resulting package will be fully compliant with that version’s Sequencers and Clients. This is, btw, yet another strong point in using AVE; you are not tied to any specific version of App-V as AVE is able to process App-V packages in all past and present formats.
When the save is completed, we can see that the resulting package data is actually quite big (over 200 MB), but we could have trimmed it down by using internal compression for the SFT file. Regardless of the size, we now have a fully functioning App-V virtualized application, ready to be deployed to our clients and all without ever touching App-V Sequncer!
15.01.2013 at 16:38
Hi Kalle,
Will you be doing a new version of AVE for App-V 5?
I’ve been in this business for many years, and I see App-V 5 as a big step backwards for experienced sequencers/packagers. There were many scenarios over the years where I could rely on “advanced” features of the technology, e.g creating my own OSDs – with or without scripting inside.
15.01.2013 at 17:55
For sure, our currently stated App-V 5 supporting release will be in Q1/2013.
And yes, I agree that in some regards 5.0 makes it harder for us packagers, although in Microsoft’s vision all the customization you likely did with OSDs in the past are domain of machine and user config file in 5.0.