Interop: Using .NET from VBScript

I knew that at least some parts of .NET can be used from VBScript, but I thought it
would be very complicated, so I postponed research/work on this topic to the future.
But today a link from Michael Harris sent me to
http://blog.opennetcf.org/afeinman/PermaLink,guid,aa53e23d-b8e5-4015-b00a-0c8ea9bc6dfe.aspx
where I saw that using .NET components could be as easy as:

    set coll = CreateObject("System.Collections.Queue")
    coll.Enqueue "Bob"
    coll.Enqueue "Joe"
    WScript.Echo coll.Dequeue()
    WScript.Echo coll.Dequeue()
  

Therefore I would like to ask

• Do you use .NET from VBScript?
  
• Where can I get more information?

EHvbs:

I found the following article on DevX (click to read the full article): VBScript: Microsoft's Orpaned Language

"Microsoft is fully committed to evolving implementations of both JScript and VBScript to a level where each language is functionally equivalent. So don't feel that you need to commit to one just to ensure that you are investing in a language that has a future."

If that statement is true, Microsoft is keeping the future of VBScript well-hidden. The most telling stroke against VBScript is that with two cumulative releases of the .NET framework and Visual Studio now behind us, there's still no sign of a VBScript.NET. There's a JScript.NET—has been since the early beta releases—but no VBScript.NET.

Does VBScript Have a Future?
I once believed that VBScript would rapidly become the script lingua franca of the Internet. After all, VBA, another cut-down version of Visual Basic, found its way not only into the Microsoft Office suite as the primary macro language, but also into a host of other commercial products. Because VBA and VBScript are fundamentally similar and therefore attractive to the same large universe of developers, one might rationally assume that VBScript would make an equally successful transition into Web products as VBA did in desktop products. But that didn't happen. If functional equivalence with JScript were a goal, Microsoft could have created a VBScript.NET. At one point, they had a third-party company create a proof-of-concept VBScript.NET, according to David Simmons of SmallScript Corp.—but Microsoft has apparently made a unilateral decision not to bring the language along into the .NET family. Unless rectified quickly, that omission represents a hard stop for VBScript, whereas VBA's future looks a bit more stable for the short term, if not for the long term.
From all appearances, VBScript is on a path to extinction. And with all due respect to VBScript, that's probably a good thing. In spite of the broad industry support for JavaScript, Microsoft probably could have garnered equally wide support for VBScript if it had ported the language to other platforms early in its lifecycle. However, as that didn't happen, there's little reason now for Microsoft (or its customers) to maintain the fiction that VBScript has any serious future as a Web language. I interpret VBScript's absence from .NET as Microsoft's tacit agreement that VBScript has no future. In my opinion, the lack of client-side support and the absence of VBScript.NET should serve as warning signs to developers or organizations using or planning to use VBScript.
Of course, VBScript aficionados are perfectly free to ignore these warning signs and continue to use this familiar language; but unless Microsoft has some sudden radical VBScript epiphany, those who do should be prepared for heartache and frustration down the road. By the way, if you want to buy the domain name VBScript.NET, it's for sale.

 
 
//edit: MSDN Blogs says the following:
 

 Back then I spent a lot of time working with the VB .NET language designers to see if these ideas from VBScript would work in VB .NET, thereby giving VB .NET a better backwards compatibility story with VBScript.



Regrettably, by and large, they don't.  (I may go into details in future blogs as to some of the crazy ideas we had for making VBScript work in the .NET world.) Based on that experience, I absolutely 100% disagree that fracturing VB into a FOURTH variant -- VB6, VBScript, VB.NET and the proposed VBScript.NET -- is a good way to achieve the laudable goal of lessening the VB learning curve.  We can improve VB without fracturing it into yet another variant. 

Hi Snipah,

thanks for your quick and inspiring response. But I'm more interested in technical
(not 'political') information. Some (a lot of) my tasks/problems are to be solved by
using VBScript - with no regards to Microsoft's decisions about the future of VBScript.

But if I want to solve my problems in a good (if not the best) way, I have to keep up
with new technologies like .NET. If you care to read my posting to the "sort list" topic,
I think you will agree, that "using .NET components from VBScript" deserves further
studies.

And that is my problem at hand: How do I get reliable information / sample code?
Has anybody out there some experience / links / tutorials /articles to share?

I totally agree with you on this subject, thus i did some dig work for future readers...
 
 
External Link: www [dot] pinvoke [dot] net - Do Interop the Wiki way (a new page about .NET, wikipedia style)
 

ORIGINAL Marvels of COM .NET interop @ Compact Framework Musings. Alex Feinman's web log
[...]
From the System.Collections namespace we have:

• Queue
  
• Stack
  
• ArrayList
  
• SortedList
  
• Hashtable

I'd say it makes a rather nice addition to the existing VB script (and javascript as well) toolset. But wait, there is more...
System.IO namespace is represented by two useful classes:

• StringWriter
  
• MemoryStream

Finally, there are System.Text.StringBuilder and System.Random classes.
Why would I be interested in StringWriter (or StringBuilder)? Because frankly, VBScript memory allocator sucks. Anyone who ever tried to build a large string concatenating small ones knows that after 65536 characters performance drops drastically. Concatenating first 65536 characters one by one takes about 1.5 sec on my 3.5 GHz machine. Appending the next 65536 takes about 4 sec. The following 65536 characters take 33 sec. And you don't want to know what happens after that. Well, in case you do, appending together the string representations of numbers 1 through 100000 takes over 2 minutes.
Of course I decided to check if I could do it faster with StringWriter. But there was a catch. If you check the lsit of methods of the StringWriter class in the Visual Studio object browser, or rather the TextWriter class, from which StringWriter derives all of the Write methods, you would notice that Write() has 17 overloads, and WriteLine() has 18. Obviously you would want to use a particlular overload. How do you choose one. As it happens, the .NET framework deals with this problem in a straightforward, if inelegant way. If you have 18 overloaded methods called Write, they are exposed as Write, Write_2, Write_3 ... Write_18. How do you find out which one is which? If you look into the class browser (or Ildasm), the order of the overloads is reverse to what you see. E.g. for StringWriter we have:

• System.IO.TextWriter.Write(string, params object[]) // Invoke as Write_17
  
• System.IO.TextWriter.Write(string, object, obejct, object) // Invoke as Write_16
  
• System.IO.TextWriter.Write(string, object,object) // Invoke as Write_15
  
• System.IO.TextWriter.Write(string, object) // Invoke as Write_14
  
• System.IO.TextWriter.Write(object) // Invoke as Write_13
  
• System.IO.TextWriter.Write(string) // Invoke as Write_12
  
• System.IO.TextWriter.Write(decimal) // Invoke as Write_11
  
• System.IO.TextWriter.Write(double) // Invoke as Write_10
  
• System.IO.TextWriter.Write(float) // Invoke as Write_9
  
• System.IO.TextWriter.Write(ulong) // Invoke as Write_8
  
• System.IO.TextWriter.Write(long) // Invoke as Write_7
  
• System.IO.TextWriter.Write(uint) // Invoke as Write_6
  
• System.IO.TextWriter.Write(int) // Invoke as Write_5
  
• System.IO.TextWriter.Write(bool) // Invoke as Write_4
  
• System.IO.TextWriter.Write(char[], int, int) // Invoke as Write_3
  
• System.IO.TextWriter.Write(char[]) // Invoke as Write_2
  
• System.IO.TextWriter.Write(char) // Invoke as Write

This means that if we want to write a string into a stringwriter, we would call:
s = “Bob“
Set wrt = CreateObject("System.IO.StringWriter")
wrt.Write_12 s
To test the performance of a StringWriter as compared to concatenating a VB string I ran the following script:
'stringtest.vbs
WScript.Echo Now
s = ""
for i = 1 to 100000
s = s & CStr(i)
next
WScript.Echo Now

set wrt = CreateObject("System.IO.StringWriter")
for i = 1 to 100000
s = CStr(i)
wrt.Write_12 s
next
s = wrt.GetStringBuilder().ToString()
WScript.Echo Now
And here are the results:
8/28/2005 1:02:14 AM
8/28/2005 1:04:07 AM
8/28/2005 1:04:08 AM
As you can see, concatenating a VB string took nearly 2 minutes, while .NET string was only a second.
But wait, there is more...
Let's take a look at the StringBuilder class. The most important feature of it (at least in the context of what we are doing here) is formatting. There are 5 AppendFormat methods:

AppendFormat ( System.IFormatProvider provider , System.String format , params object[] args )
AppendFormat ( System.String format , params object[] args )
AppendFormat ( System.String format , System.Object arg0 , System.Object arg1 , System.Object arg2 )
AppendFormat ( System.String format , System.Object arg0 , System.Object arg1 )
AppendFormat ( System.String format , System.Object arg0 )

Let's see if we could easily use one of them:
'sbtest.vbs
set sb = CreateObject("System.Text.StringBuilder")
sb.AppendFormat_5 Nothing, "{0} is a {1} number" & vbCrLf, Array(1, "loneliest")
sb.AppendFormat_5 Nothing, "{0} is a {1} number" & vbCrLf, Array(2, "happiest")
WScript.Echo sb.ToString()
Prints:
1 is a loneliest number
2 is a happiest number
 
We have formatting! In VBScript.
[...]

I'd like to bump this topic to get some newer perspectives on this subject (Its been a year...). I've been searching for a way to access DirectX through scripting for months now without any good results. The closest I came was with DirectAnimation, but with IE7 this method has gone the way of thre Dinosaur (Microsoft chose to disable this component instead of patch it.). I was hoping a new method would be available through the .NET approach, but as we've seen thus far, documentation is hard to come by to say the least.

P.S. To comment on the StringBuilder topic (probably pointless to do so by now), manipulating arrays is MUCH faster than concatenating strings. With the introduction of the JS.Array object we could simply use Push() and then Join to make the final string. Its a linear growth, not exponential like normal concatenation.

Personally, I do concatenation by using Dictionary objects.

 set oCat = createobject("Scripting.Dictionary")
 oCat.Add oCat.Count,"Some Text"
 oCat.Add oCat.Count,"Some More Text"
 oCat.Add oCat.Count,"And Some Additional Text"
 wscript.echo Join(oCat.items,"a character of my choosing")
 

 
I have found that this is, performance-wise, on-par with using pure arrays, with the additional bonus of not having to use any external code/libraries, etc.
But regardless of whether you use Dictionaries or Arrays, you will still see about a 250x improvement over straight string concatenation.