Getting started with ThinApp SDK and PowerShell

With the recently leased version of the ThinApp SDK I though it was time to give a brief introduction on how to install the ThinApp SDK and how to use it with PowerShell.

First you need to download the ThinApp SDK from VMware.com. You need a free My VMware account to access the SDK download page.

To prepare your environment extract the ThinAppSDK.dll and ThinAppSDKSrvr.exe to a permanent location. This location has to permanent as you will register the ThinApp SDK from this location. The SDK only works if both files are available on the specified location.


To register the ThinApp SDK you have to run the following command from an elevated command promt:

After that you can start using the SDK. As the SDK is a COM object you can basically use it with any scripting or programming language you want. I am myself a big fan of PowerShell and think it is easy to use so I am going to use PowerShell for all of my examples.

What doe the ThinAppSDK.dll and the ThinAppSDKSrvr.exe do?

ThinAppSDK.dll is the DLL that implements the ThinApp SDK objects like ThinApp.Management. It is a 32-bit DLL, if you create a ThinApp.Management object from a 32-bit process Windows will load ThinAppSDK.dll into that process (if the DLL was registered correctly with regsvr32). However, it’s not possible to load a 32-bit DLL into a 64-bit process. So if you try to create a ThinApp.Management object from a 64-bit process, ThinAppSDK.dll cannot be loaded directly into that process.

That’s where ThinAppSDKSrvr.exe comes in. Windows will detect this situation and will automatically launch ThinAppSDKSrvr.exe. Since ThinAppSDKSrvr.exe is a 32-bit application, it can load ThinAppSDK.dll just fine. Windows will then “forward” ThinApp SDK calls (e.g. the GetThinAppType method call) from the 64-bit process to ThinAppSDKSrvr.exe, which will in turn forward it to ThinAppSDK.dll. The result will be passed back from ThinAppSDK.dll to ThinAppSDKSrvr.exe via Windows to the 64-bit application. This might sound complicated, but it all happens behind the scenes, you shouldn’t have to worry about it.

Source: http://communities.vmware.com/message/1595702#1595702

Now we need to start PowerShell, if you haven’t PowerShell installed yet grab it here. After PowerShell is launched we can create a connection to the ThinApp SDK COM object, which is called ThinApp.Management.

With this command we create a new object called $ta. Please note that name $ta, and all of the following $-variable names in this guide, are choosen by me. You can name the variables whatever you want to. To see what we can do with this object we can list all methods and properties using the following line:

As you can see there are three methods available:

  • GetThinAppType
  • OpenPackage
  • RefreshDesktop

GetThinAppType
With the method GetThinAppType you are able to check if a file is ThinApp package and what type of package. You have to specifiy the file you want to check inside the brackets.

As result you get a number that describes the type of package.

ThinApp package types:
0 – not a ThinApp package
1 – ThinApp main data container
2 – ThinApp entry point
3 – ThinApp MSI
4 – ThinApp compressed MSI
5 – ThinApp legacy MSI

RefreshDesktop
The RefreshDesktop method is needed when you register a ThinApp package using the SDK. If a ThinApp package contains file type associations a refresh of the desktop is needed for the associations to be applied.

There is no parameter needed to execute the desktop refresh. Just launch the method without any parameter.

OpenPackage
OpenPackage is the most powerful method of the bunch. With this method you can open a ThinApp package. To open a package just specify the ThinApp package you want to open inside the brackets.

When you run the command you get the InventoryName, MainDataContainer, MSIVersion, ThinAppType and ThinAppVersion of the specified ThinApp package.


While these information itself are also helpful you can do much more when you create a new object based on your ThinApp package. This can be done using the following command while specifying your ThinApp package in the usual manner:

When you just run $tap on your PowerShell command line you see the same information as you have seen just opening the package. To see what the object $tap now can do just run:

Which results in:

As you can see there are many methods which can be used with our new ThinApp package object.

  • AppSync – Start AppSync process
  • AppSyncUpdateAvailable – Check if an AppSync update is available
  • GetOptionalAppLinks – Search a path for optional AppLink packages which are used within the loaded Thinapp package
  • GetOptions – Get settings out of the package.ini, like CompressionType, Sanboxname, AppSync and so on
  • GetRequiredAppLinks – Same as GetOptionalAppLinks but for required AppLink packages
  • GetShortcutList – Get a list of entry points
  • GetVFileSystemObject – With this method you can access the virtual file system
  • GetVRegistrySystemObject – With this method you can access the virtual registry
  • Install – Install the ThinApp MSI package on the local machine
  • MacroToPath – Show the real folder (C:\Program Files) behind a macro folder (%ProgramFilesDir%)
  • PathToMacro – Check if local folder (C:\ProgramData) is represented by a macro folder (%Common_AppData%)
  • Register – Register the ThinApp package on the local machine
  • RetriveIcon – Extract an icon out of an entry point or data container
  • Uninstall – Uninstall the ThinApp MSI package on the local machine
  • Unregister – Unregister the ThinApp package on the local machine
  • UnregisterEx – Undocumented

Covering every single one of these methods would go beyond the scope of this article. But I’ll give you two examples:

Example 1: Retrive AppLink configuration
The first example will show you how to retrive the configured AppLinks for your ThinApp package.

We are creating our ThinApp object (line 1), loading our package as additional object (line 2) and then retrive the AppLink configuration using the GetOptions method. With the Where-Object statement I filter the results so that just the optional and required AppLink options are listed (line 3).

Example 2: Force an AppSync update
In this example I will show you how to trigger an AppSync update without starting the application itself.

As usual we create our two object (line 1 and 2). Then we get the AppSync URL out of the options and save it in a variable (line 3). Thereafter we check if an AppSync update is available (line 4) and if this is the case we update the package (line 5).

I hope with this introduction I could provide a taste of the things possible with the ThinApp SDK in combination with PowerShell. If you want to learn more download the ThinApp SDK and get started with it. After downloading and extracting the SDK you will also find a PDF documentation on the SDK called ThinAppAPI.pdf – give it a look.

7 comments » Write a comment

    • Thanks and nice to see there is some more ThinApp and PowerShell related stuff out there. I wrote a similar script, which I am going to blog about soon, as your repository script. But I just read out the ThinApp runtime version as this was a customer requirement some weeks ago.

  1. i only recently learned about thinapp. cant find an answer to my primary 2 questions. hoping you might be able to answer me as you are an obvious user, if not expert with using it.
    1. what does it require to ‘play back’ a ‘thinapp’ package? in other words, can i take a thinapp built exe to a ‘normal’ windows xp computer and have the exe run? or must it be run only within a vmware ‘playback environment’? if so, what exact vmware playback environments are required?
    2. suppose that just as the ‘Perl’ programming community has cpan.org which is a clearing house of prewritten code modules users may use as a library. suppose a similar public ‘thinapp repositories’ become prevalent. say for example, to allow someone to download and use a ‘portable web browser’ or a ‘portable opensource compiler’ etc… how would the end user, who might download such a thinapp – know for sure, in advance of running it – just how ‘sandboxed’ the thinapp actually is? is this merely a matter of reviewing the thinapp’s package .ini file to see the ‘isolationmode’ settings? and if not to their liking, these can be reset by the end user to force a more sandboxed environment than the original author intended?
    thanks for explaining this to me.
    sincerely,
    greg

    • Hi Greg, (1) I don’t really know what you mean with the “playback environment” but ThinApp packages are very portable, this in fact is one of the key benefits of application virtualization. You can run ThinApp packages on different operating system. So if you used one system to create a ThinApp application you not only can use the package on this system but you should be able to run this on virtually any Windows based computer. (2) With the ThinApp SDK you can check the isolation modes of packages. You could implement a script which gives the end user user a report of the virtual file system and the applied isolation modes. With the help of the ThinApp API you are also able to change the isolation modes. To use the ThinApp API you have to compile the script accessing the API into the package and therefore it could a bit cumbersome to realize such a functionality but it would be possible from a technical point of view.

  2. so it sounds like the thinapp created ‘exe’ does not require a specialized (what i call ‘playback environment’) runtime environment – it sounds like the thinapp created ‘exe’ has all that is needed to allow the app to run.

    do you mind if i ask one question that delves a little deeper into whats required to ‘run’ the thinapp?

    lets suppose on a reference windows xp SP3 machine, i install thinapp, and i then capture the install for an app that actually requires windows xp SP3 to both install and run. i make a thinapp program for program-x that would normally require windows xp SP3 to install and run on. if i take that thinapp created *.exe, to a windows xp SP2, SP1, or sp0 pc – will that thinapp exe run? or in this case, will the thinapp only run on a windows xp SP3 operating system?

    ive read about how thinapp is not able to virtualize a ‘device driver’. the company i work for produces a software that optionally may use a device driver that allows their user mode software to read a value from a usb handheld hid. is the idea that if i wanted to create a thinapp version of our software, that if the true operating system had the device driver installed to it as a seperate atomic installation. then we changed our program installer so that it did not attempt to install the device driver when the install is recorded by thinapp (technically, our current installer writes an *.ocx file to system32, then runs regsvr32 to register the driver with the operating system – we could change the installer to bypass this step for the purpose of having thinapp snapshot our apps installation in a manner where it doesnt try to capture a device driver installation). in this scenario, where the runtime operating system actually has the device driver installed, but the thinapp exe only tries to use such a device driver that is on the underlying operating system – do you know if that is possible?

    finally, suppose one creates a ‘thinapp’ version of microsofts venerable ‘notepad.exe’ program. just so i understand one last aspect of thinapp usage… once someone typed in text into the thinkapp notepad, they woudl want to save what theyve typed. at some point they would do ‘file – save as’. im unclear here as to what such a ‘thinapp’ deployed ‘notepad’ ‘file – save’ as dialog box would actually reveal to the user? for example, i can imagine that one would have to preconfigure the installer for notepad to create a specific folder thats expressly configured to be used by the thinapp notepad for saving and or reading files from. in other words, i would imagine file save as woudl not allow the user to browse to any folder on the computer – but instead only to any such preconfigured folder thats been setup for the thinapp exe to read/write to. i can imagine this can be a limiting feature of thinapp exes? is my take on this correct – or am i musunderstanding this aspect?

    your answers here are very much appreciated, as i am trying to evaluate if there may be some benefit to seeing if it might offer us advantages to deploy our software to a commercial user base using this technology. many of the advantages thinapp offers – makes this a very desirable software distribution vehicle (eg, no install, completely pre-configured environment, merely click-to-run). the only issues in our case would be that our app does use a device driver, and the issue of what folders our app would be able to read/write to.

    thanks again. look forward to your insights.

    greg

Leave a Reply

Required fields are marked *.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">