This time some focus on Micro Focus Desktop Containers (MFDC). Virtualising applications enables people to be very flexible with their application deployments. Customers virtualise some of their applications for a number of reasons. On some occasions it allows customers to run applications on Windows 10 that would normally not be able to run on this platform; in other situations it’s to prevent conflicts between applications, or just to make the distribution of applications easier.
Packaging applications is a specialty on its own - it requires an understanding of the Desktop Containers product but it also requires some knowledge of the application that needs to be packaged. Depending on the application you can either package it using the snapshot method or package it within an empty container. Generally this works fine but on some occasions customers want to fine-tune their application deployment and this is where knowing some tricks with Desktop Containers can be useful.
Let’s start with the basics, I assume most of you will know this but it’s key to understanding the way virtual applications work. With Desktop containers we create an isolated environment that is shown to the application as an overlay to what exists on the host, and if needed multiple overlay files can be combined. If within the application changes are made then these can be stored in a separate layer so that these changes will be maintained if the application is started again. Understanding these layers will allow us to manipulate what happens within the virtual application.
Q: I have a client application that needs different configurations to connect to different hosts?
A: You can create multiple overlay files each with their own configuration. When the application is started you specify which layers need to be started and as such you can have different configurations of a single application.
Q: Can I use a configuration file on the host to configure my virtual applications?
A: You can just put the application configuration file on the host and the virtual application can consume this. In this case the customer wanted something different. On the host they wanted to have an XML file with configuration information for several virtual applications, when the application was started the first time it needed to process the XML and auto configure itself.
To do what the customer wanted we created a little PowerShell script that would process the information in the XML and then adjust the settings within the container. After configuring the application it would start, in this case, the email application. Obviously, we added a little check within the script so that the configuration would only happen once.
Here is a short example of the PowerShell script I’ve used to demo what is possible:
[CmdletBinding()]
param ()
#-------------------------------------------------
# Start of Configuration Loop
# Verify if already configured
#-------------------------------------------------
If(!(test-path “$env:APPDATA\Test\configdone.txt”))
{
#-------------------------------------------------
# Read XML settings
#-------------------------------------------------
[xml]$ConfigFile = Get-Content “c:\MFDC\MFDC-Settings.xml”
#-------------------------------------------------
# Open and modify ini file
#-------------------------------------------------
(Get-Content “$env:APPDATA\Test\test.ini”) | Foreach-Object {
$_ -replace “Value2=.+”, “Value2=$($ConfigFile.SETTINGS.VALUE2)” `
-replace “Value3.+”, “Value3=$($ConfigFile.SETTINGS.VALUE3)”
} | Set-Content $env:APPDATA\Test\test.ini
#-------------------------------------------------
# Create file to indicate configuration is done
#-------------------------------------------------
New-Item -Path “$env:APPDATA\Test\configdone.txt” -ItemType File
}
#-------------------------------------------------
# Start application
#-------------------------------------------------
Start-Process -Filepath “cmd.exe”
The application will open the XML file that is on the Host and it uses this information to change the .ini file that is part of the virtual application. In addition to the script file a batch file is needed to start the PowerShell script.
This article first appeared in OH Magazine Issue 44, 2019.2, p39