ایجاد برنامه Adobe Reader 9 در ThinApp
ThinApp is very easy to use and if you have ever used some type of application capturing tool before they feel very much the same – although the quality of them varies. So if you have used Vertias WinInstallLE or Citrix Application Package it is very similar. The difference is that the output is a self-contained .EXE.
Most packaging systems have a four step process:
- Pre-analyze the clean environment (Pre-Scan)
- Install the Application Software (Install)
- Capture the Differences (Post-Scan)
- Output Package to default location (Build)
In the pre-scan and post-scan stages, ThinApp creates its own virtual registry and file system to capture all the changes being made. There is a snapshot taken both before and after, and by comparing the two, ThinApp can then begin the build process.
There are some things you cannot do with ThinApp (and application virtualization in general), and the following are situations that are best avoided in this recording or capturing process:
- If you want to run an application on both Vista and XP, it’s best to use Windows XP as the target as there may be software which is the default in Vista — but not in XP – and this could create a dependency problem.
- Don’t package a 64-bit application and expect it to run on a 32-bit virtual desktop. The application still needs to make calls to a 64-bit processor.
- Locate and download Acrobat Reader N installation package.
- Run the ThinApp Setup Capture program and Click Next to the Welcome Screen
- Click next to the information warning about the significance of having a clean PC.
- ThinApp will start the initial pre-scan of the virtual desktop
- At the end of this analysis, minimize the ThinApp Window and trigger the install of Acrobat
Tip: Most application packages allow for a nifty hidden advantage. During this recording process it is possible at the end of the install to load the application and modify the settings. If you do this before the post-analysis, these modifications (in our case to Acrobat Reader 9) will become global defaults for all users who access the ThinApp. This is handy as some application vendors do not support Microsoft GPOs and sometimes are very tight-lipped about the registry locations for various options that might not be desirable in your environment.
For example, I like to load Acrobat Reader and accept the Adobe Acrobat EULA on behalf of my end users. I also like to enable the option to “Restore last view settings when reopening documents” in Edit, Preferences, Documents and Open Settings.
Once you have finished with the installer, close the application, and restore the ThinApp Setup Capture window. Click next and this will trigger the post-scan phase. After the scan has completed, Thin-App will list the “User-accessible entry points”. These are EXEs that the user can trigger or have loaded once the main application has loaded.
The problem with most application recorders and packagers is that they quite frequently get confused. They often cannot detect the difference between an installer .EXE and the application it is installing. In contrast, ThinApp makes a good job of this. However, I noticed that this dialog box didn’t include all the executables. Also, I found I was able to deselect all the .EXEs and just enable the core Adobe Acrobat Reader 9 .exe, as shown in Figures 1A and 1B. This meant I had to change the primary data container from the default of Adobe AIR.dat.
| Figure 1A: Before (click to enlarge) | Figure 1B: After (click to enlarge) |
 |
 |
This generated a second dialog box that warned me that this might be unwise.
Figure 2: Warning dialog box
However, being the curious kind of chap I am, I carried on and found the application could work without these other executables. It’s worth saying my testing and validation won’t be anywhere near as rigorous as yours — or will it?
The general point I want to make about this dialog box is that every single application will produce different results – and I think you would have to know the application very well before considering deviating from these defaults. For example, the default, shown in Figure 1A, didn’t include A3DUtility.exe. Why not? I doubt anyone in VMware OR Adobe could answer that question. My best bet is to ask Adobe what A3DUtilty.exe does, if it’s required for the main reader to work — and what the implications would be if it wasn’t included.
In the next window, shown in Figure 3, you can control how the ThinApp will be built.
- Figure 3: Building the ThinApp (click to enlarge)
You can encode Active Directory restrictions that can limit who can run the application. For this to work your VM must be in a domain. The idea is to restrict the portability of VMs such that if a ThinApp leaks out of your organization no one will be able to run without first authenticating to your private, internal and firewalled domain.
To maintain a per-user setting ThinApp allows you to save per-user settings in three different locations (User Profile, USB, Network Drive). As we saw earlier folder redirection can relocate the Application Data part of a user profile to a network location (such as the user’s home directory) so a network drive and user profile location could be effectively the same. The USB location is clearly not aimed at a virtual desktop environment but for a more stand-alone mode. This is popular amongst IT staff who can carry a memory stick of their favorite management applications. I’ve decided to stick with User Profile as I redirect this to the network anyway.
The next dialog box, shown in Figure 4, is a tough one as it is difficult to know 100% in all cases which option to select. There is something to be said for experimentation and rigorous testing.
- Figure 4: Selecting an isolation mode (click to enlarge)
Merge isolation mode is very close to how applications normally behave when they are installed to a conventional desktop. However, in our virtual desktop we can either disable or redirect many of the locations that are referred to here. The recommendation is to select this option for Microsoft Office and Windows Logo Certified applications.
The WriteCopy isolation is recommended for legacy or untrusted applications – and results in a more isolated or sandbox ThinApp. This isolation appeals to me — and don’t worry about users trying to locate local directories — I hide the A: C: and D: drives. However, I don’t regard Acrobat Reader 9 as a legacy application so I’m going to go with merged isolation mode. After all, I don’t want the isolation to be so complete that it stops the application working altogether. The reality you will have to experiment and test the application beforehand. As there are often no recommendations from the application vendors themselves, another option is using the VMware ThinApp Forums for other’s experiences.
Next select your build options. Shown in Figure 5, this allows you to set where the project files will be located (this is where you will find the ThinApp).
Figure 5: Set the location of the project files (click to enlarge)
The project location will be the destination of all the files discovered during the post-scan file, together with your ThinApp. The “Build MSI package” option will create an MSI file, which you can then use to copy the ThinApp to the system. Use this if you intend to have the ThinApp running from within the virtual desktop’s virtual disk: If you are just testing the application use theNon Compression option, which is generally much quicker. When you’re ready to build the application for a product use Fast Compression, as this reduces the time it takes to stream the application to the end-user , but takes significantly longer to build. Large applications like Microsoft Office take a couple of hours.
At the end of the post-scan, you have two choices — Build or Browse Project — as shown in Figure 6.
- Figure 6: There are two post-scan options (click to enlarge)
Browse project will allow you to modify various .INI and .INF files for advanced features such as fix file associations. Once you are finished you can return to the Build Now option.
Buried inside the ThinApp is a batch file (build.cmd) you can run to re-execute a build process located in the captures project directory. If you make changes to .INI files after the build, this allows you to rebuild the ThinApp without going through the capture process again. Once the build now process has completed, click Finish.
Finally, retrieve your ThinApp located in my case at:
C:Program FilesVMwareVMware ThinAppCapturesAdobe AIRbin
So this becomes :
C:Program FilesVMwareVMware ThinAppCapturesAcrobatReader9 in the second attempt.
Copy to a location accessible to your users’ virtual desktops. I decided to copy my redirected Start menu, as shown in Figure 7.
- Figure 7: Acrobat Reader 9 ThinApp copied to a redirected Start menu
Notice how I only took the ThinApp .EXE needed. I would recommend testing the application in View client with a test account. I would also copy the entire project to my home directory or a similar location before reverting to the snapshot on the Thin App Virtual Machine and starting on a new application.