What's the Difference between WScript.CreateObject, Server.CreateObject and CreateObject?

What's the Difference between WScript.CreateObject, Server.CreateObject and CreateObject?

Rate This
  • Comments 21

A reader asked me last week

I have always used Server.CreateObject in ASP scripts and WScript.CreateObject in WSH scripts, because I was unable to find any *convincing* information on the subject and therefore assumed that they were there to be used, and were in some way beneficial... but perhaps they're not?!

What exactly is the reasoning behind having additional CreateObjectmethods in ASP and WSH when VBScript already has CreateObject and JScript already has new ActiveXObject ?  (new ActiveXObject is for all intents and purposes identical to CreateObject, so I'll just talk about VBScript's CreateObject for the rest of this article.)  There are two reasons:

1)     VBScript and JScript aren't the only game in town.  What if there is a third party language which (inexplicably) lacks the ability to create ActiveX objects?  It would be nice to be able to create objects in such a language, thus the hosts expose said ability on their object models.  (Similarly, IE, WSH and ASP all have "static" object tags as well.) 

Of course, this is a pretty silly reason.  First off, no such language comes to mind, and second, why stop at object creation?  A language might not have a method that concatenates strings, but that doesn't mean that we should add one to WSH just because it comes in handy.  We need a better justification.

2)     The ASP and WSH versions of CreateObject are subtly different than the VBScript/JScript versions because they have more information about the host than the language engine posesses.  The differences are as follows:

WScript.CreateObject with one argument is pretty much identical to CreateObject with one argument.  But with two arguments, they're completely different.  The second argument to CreateObject creates an object on a remote server via DCOM.  The second argument to WScript.CreateObject creates a local object and hooks up its event handlers. 

Sub Bar_Frobbed()
 
WScript.Echo "Help, I've been frobbed!"
End Sub
Set foo = CreateObject("Renuberator", "Accounting")
Set bar = WScript.CreateObject("Frobnicator", "Bar_")

This creates a renuberator on the accounting server, a frobnicator on the local machine, and hooks up the frobnicator's events to functions that begin with the particular prefix.

Remember, in the script engine model the control over how event binding works is controlled by the host, not by the language.  Both IE and WSH have quite goofy event binding mechanisms for dynamically hooked up events -- IE uses a single-cast delegate model, WSH uses this weird thing with the string prefixes. 

Server.CreateObject creates the object in a particular context, which is important when you are creating transactable objects.  Windows Script Components, for example, are transactable objects.  This means that, among other things, you can access the server object model directly from a WSC created with Server.CreateObject , because the object obtains the server context when it is created.  Ordinary CreateObject has no idea what the current page context is, so it is unable to create transactable objects. There are many interesting facets of transactable objects which I know very little about, such as how statefulness and transactability interact, how the object lifetime works and so on. Find someone who writes a blog on advanced ASP techniques and ask them how it works, because I sure don't know.

I'll answer the question "what's the difference between WScript.CreateObject and WScript.ConnectObject?" in a later blog entry.

I answered the question "What's the difference between GetObject and CreateObject ?" in this blog entry.

 

  • PingBack from http://www.guangmingsoft.net/wordpress/index.php/146/difference-between-createobject-calls/
  • (Sorry about the title. I work for Microsoft; we like nouns .) Over a year ago now a reader noted in

  • Iam working on a project where Server.CreateObject is replaced with CreateObject all over the project. Though I know that this will improve performance in terms of Memory overload because of how the object creation happes with CreateObject, I would like to have 'visible scenarios' that i create with code to show people that '"look. here's the difference". Is it possible ?

    Can i create a simple project to simulate and see the performance differences between Server.CreateObject and CreateObject ?

    Thanks.

    Anand.

  • Sure, you could do that, but that would be the wrong thing to do.

    Doing so would answer the question "is there a perfornance difference in a fake, contrived, small, unrealistic scenario?"  Do the people you are going to show this to care about the performance of fake, contrived, small and unrealistic scenarios?

    If the question you want to answer is "what is the performance difference in the real scenario that actually matters to our business?" then find a way to measure that.

    This is almost certainly the wrong area for exploration. It is a waste of time and money to spend any time analyzing and remediating anything other than the _slowest fixable thing_.  If the difference between CO and S.CO takes up 0.1% of the total time of your application, then fixing all of them cannot speed it up by more than 0.1%.  There is probably a bigger win somewhere else; spend the time that you would have spent twiddling CreateObject calls on finding out where that bigger win is.  When you do so, you'll then have the figures to show the people who write the cheques what their return on investment is.

  • PingBack from http://kaitlin.mediaplusnews.info/createobjectwscript.html

  • @Eric: "WSH uses this weird thing with the string prefixes"

    In fact this is weird. This means one can not dynamically bind events after the COM object has been created, as the event function has to exist in the host namespace before the object creation. This is quite different from what is possible in an IE host and makes writing framework that work in both environments more difficult.

    For example, XMLHttpRequest is easier to use in synchronous mode in WSH.

    This is why almost no one use event binding in WSH.

Page 2 of 2 (21 items) 12