What are the Pros and Cons of using VBScript in MSI packaging?

1. VBScript’s Maturity and Stability

Veteran IT Pros have adopted the VBScript technology because that was the best option available at that time. (PowerShell was in the early stages of its life and could have been used, but MSI didn’t know how to execute PowerShell scripts unless workarounds were applied.)

The software packaging industry is a niche branch of which not many IT Pros are aware or even invested in learning its depths.

When it came to training, most companies hired newbies and had very fast crash courses on software packaging, which were held by senior IT Pros.

However, experienced IT Pros worked in a certain manner, which resulted in these practices being passed down to the next generations of IT Pros.

Even though tools like Advanced Installer have made it simple and quick to add PowerShell scripts as custom actions, the IT Pros audience has been slow to embrace the technology, meaning it will still take some time to be completely adopted.

As a result of its simplicity and ease of use, VBScript's longevity is a plus. Furthermore, there are plenty of topics on forums, guides, and helpful materials on how to execute various tasks using VBScript, resulting in a great volume of useful scripts for the IT Pro industry.

2. VBScript as a Native Technology

Another pro would be that VBScript is a native technology; thus, it’s easy to read from the package regardless of the packaging tool you are using.

PowerShell scripts can indeed be added to the package, but these are not native, and it depends on the packaging tool that you are using.
A more in-depth article regarding this topic can be found here.

3. VBScript accessibility: easy to integrate with the MSI internal structure

One more pro is that the internal structure of MSI is easy to integrateand change with VBScript.

For example, if you want to create a dynamic custom action by passing properties, all you have to add within your script is the following:

Session.Property("CustomActionData")

And if you want to pass two properties into the script, add the following code:

strArgs = Session.Property("CustomActionData")
arrArgs = Split(strArgs, ";", -1, 1)
path1 = arrArgs(0)
path2 = arrArgs(1)

To set a property in an MSI with VBScript, insert this code:

Set WShell = CreateObject("WScript.Shell")
DISKID = WShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum\0")
Session.Property("DISKID") = DISKID

With the above code, you are setting the DISKID property with the value received from the registry.

However, you can achieve the same behavior with PowerShell scripts, but you may realize that each packaging tool has a distinct take on the topic, which means that each custom action is defined differently.

Let’s take a look at how Advanced Installer manages the custom actions via PowerShell scripts.

To get and set your property using Advanced Installer, use the following commands:

$propValue = AI_GetMsiProperty YOUR_PROP

AI_SetMsiProperty YOUR_PROP <VALUE>

These actions have the AI_ prefix, meaning that these are Advanced Installer custom actions.

But when you are using VBScript, you will see the same structure no matter what packaging tool you are using, making it more accessible for you to use.

4. Logging

The last pro we are going to discuss is the logging ability that VBScript offers.

When you place a custom action, and perform verbose logging, if the script runs into any errors you will receive the exact line where the script has failed.

For example, we intentionally added an incorrect line to our VBScript, and the verbose logging showed us exactly where everything went wrong:

1. Security threat in VBScript

The major con that we can see at the moment when it comes to VBScript is security. We are constantly asked on our support channel why a particular installer worked on one machine but failed on another.

We discovered that different antivirus programs are blocking VBScript files for various reasons. Since VBScript is an old scripting language, it is not validated in the same way that PowerShell is, which can lead to different security breaches.

2. Easily readable code

Depending on the circumstances, having the code easy to read might be both a pro and a con.

For example, if you want to add a registration method directly to your package, it makes no sense to have the code readable by the user since it could mean that your registration algorithm will be easily bypassed.

3. Not Developer Friendly

While useful for IT Pros, from a developer perspective VBScript just doesn’t make sense. MSI can run native C++ DLLs as well as .NET C# custom actions. These can be easily developed and added to the installer. Not to mention that .NET provides a broader set of functions for manipulating the system to the developer's liking.