The Microsoft Script Control MSScript.ocx is a simple to use component that allows you to host VBScript scripts within your own application. Althought it has been implemented as a control it is very easy to use the underlying script component without involving any UI. However, I’ve recently learnt that things are not as they seem.
Using the Script Control as a server component, especially where concurrency is important, is not a good idea. The problem is that the control is written as Appartment threaded, what this really means is that it’s running as a Single Threaded Apartments (STA). So what? Well consider the following:
Clients A and B both invoke the Script Control at time X. The Script Control contains a VB script that takes Y seconds to complete. Client A is fractionally ahead of B and starts the running the VB Script. Now since the Script Control is running on a STA only one thread can be active at any one time. Therefore B is blocked until the control has completed running the script for A. The upshot of this is that the response time for A is (Y-X) whereas for B it is (2Y-X). For N concurrent users this would mean the Nth user would have a response time of (NY-X), obviously bad news.
So as nice and easy as the MSScript.ocx is to use, I would recommend staying well away from it where concurrent access is going to be an issue.
Those adding progammability via scripting to .Net applications can use the fancy samples on gotdotnet