Usage of .NET Collections types in VBScript is not supported after .NET 4.5

While working with a customer, we came across a change in .NET 4.5 around usability of .NET types/classes (e.g., System.Collections.ArrayList) in VBScript. I consider it as one of the major changes in .NET 4.5 (it might have been with .NET 4.0 itself as .NET 4.5 is just an in-place upgrade to .NET 4.0, but this change has become more visible on .NET 4.5 though). To understand it better, let’s take an example of invoking a VBScript which consumes the .NET ArrayList type exposed as a COM interface:

e.g., a sample.vbs script having just a single line as shown below -

Set arList = CreateObject("System.Collections.ArrayList")

This script works fine on older Windows operating systems prior to Windows Server 2012. On a fresh or newly installed Win2K12 machine, however, the above line of script might fail with an error as highlighted below -

C:\Temp>cscript.exe Sample.vbs
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Temp\Sample.vbs(1, 1) (null): 0x80131700


And when this happens, a Windows Features popup gets displayed as below:


Now let me explain the reason of this failure. When “CreateObject()” is called, it internally invokes the COM call CoCreateInstance() to create an ArrayList object. The way CoCreateInstance() works is it first tries to look into the system registry to find the assembly which implements this ArrayList type identified by its ProgID i.e. “System.Collections.ArrayList” (in this case, the ProgID and the type name are same for ArrayList). As .NET 4.5 which is the only .NET Framework inbuilt with Win2K12 has stopped exposing .NET types as COM interfaces, the registry lookup by CoCreateInstance() just fails. However, Windows seems aware of this change, and thus tries to install .NET 3.5 which does expose .NET types as COM interfaces and shows the above popup message. Once .NET 3.5 is explicitly installed on these machines, the script starts working just fine as it works on the older operating systems.

Considering the complete Framework overhaul from .NET 2.0/3.0/3.5 (i.e. CLR v2) to .NET 4.0/4.5 (CLR v4), I think, it’s completely a design decision to stop exposing these types as COM interfaces to prevent breaking the older VBScript/native apps already in the market which are being targeted to .NET 3.5 and use these kind of .NET types. Had the .NET 4.5 exposed these types as COM interfaces, and in case the .NET 3.5 also gets installed on the machine side-by-side, the same COM interfaces (something like, “System.Collections.ArrayList”) exposed by two versions of the Framework would be conflicting to each other. And the fact that multiple versions of the .NET frameworks could/should get installed side-by-side on a machine, COM registration of the .NET types would be a bad idea, hence it has been stopped.

Having said that, there are some options as followed that might be helpful in these kinds of situations -

- Install .NET 3.5 (which is the recommended & the best option ever).

- Don’t use .NET types and rather implement your own types in VBScript/native languages (in this case, ArrayList).

- Create a managed COM object wrapper around the .NET type of interest and consume it from VBScript/native languages.

- Force cscript.exe to use .NET 4.5 by creating an activation config file as below (i.e., v4.0 for the inbuilt .NET 4.0/4.5 on Win2K12):

    • Create an activation config file with name “cscript.exe.activation_config” having the below content:

            <startup useLegacyV2RuntimeActivationPolicy="true">
                <supportedRuntime version='v4.0' />

    • Keep this file in a folder (e.g., C:\CustomConfigs) and set the below environment variable and then execute your script:

    set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=C:\CustomConfigs

    cscript.exe Sample.vbs

Having suggested the above options, in my opinion, it’s better to use .NET types going forward only in .NET based managed applications. On a side note, I’ve only tested this behavior with collection types on a fresh Win2K12, but I think it should be applicable to any new Win8/Win2K12 machines and to all the .NET types which used to be exposed as COM interfaces prior to .NET 4.0/4.5.

Comments (1)

  1. RichCode says:

    This is a great article!  I've been looking for a definitive answer as to why .Net COM interfaces are unavailable when only Framework version 4.5 is installed (and 3.5 is not).  I had no luck when searching for this information until I came across this article.

    I don't completely understand why would be a bad idea to have COM interfaces from more than one Framework registered.  After all, this is NOT a new concept!  COM supports multiple versions of a component to be installed. (e.g. Just look at how many versions of the "Microsoft ActiveX Data Objects x.x Library"  are installed! There are about 6 versions of it on my fresh install of Windows 8.1 and Microsoft Office 2013).

    It seems to me that NOT registering the COM interfaces from Framework 4.5 would break a lot of code that ran fine in previous versions of Windows.  And it doesn't seem like there is an easy solution to this problem!  I write a lot of VBA code for companies that expect the code to run out-of-the-box without the need to call in administrators from the IT department.  On a  fresh Win8/Win2K12 install (that doesn't include Framework 3.5, and hence the COM interfaces) it appears that only an Administrator has the right to install the older framework. To make matters more complicated, there is no download for the .NET Framework 3.5 for Windows 8 or Windows 8.1. You must enable the .NET Framework 3.5 in Control Panel by following the instructions provided in the following article:…/hh506443%28v=vs.110%29.aspx

    This seems pretty crazy to me!

    Is there should at least a command I can run that will register the COM interfaces from Framework 4.5?


Skip to main content