SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    Bangarang! Karloff's Avatar
    Join Date
    Mar 2003
    Location
    Manchester, United Kingdom
    Posts
    236
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    MS Scripting Hell

    A'ight, usually after a long night flipping pages in SDK references and typing all sorts of word combos into Google, writing, re-writing code and more, I resolve to whimpishly crying out for help. This time I have more than one question, though all in the same context: scripting components.
    1. There are basically 2 component types in the MS scripting world relevant for server-side processing, these being .sct, and .wsc. For one, I cannot find any information on their difference or intended difference? For another matter, I accidentally registered the .sct extension with HomeSite editor - now I lost the document types binding for its context menu where I could easilly register/unregister etc. the component. Does anyone know how I can set those context menu bindings again?
    2. On my Win 2000 Pro machine, I have the latest SDK's installed on just about any ASP complimentary technology. So too, I have the Windows Scripting 5.6. However, although all reference documentation and un/official websites showcase the use of script components using following XML compliant code

      Code:
      <?XML version="1.0"?>
      
      <component id="Error">
      <registration progid="Framework.Utility.Error.1.0"
       classid="{2154c700-9253-11d1-a3ac-0aa0044eb5f}"
       description="Error Component"
       version="1.00"
      />
      
      <public>
      <method name="getErrLang" />
      </public>
      
      <implements type="ASP" />
      
      <script language="JScript">
      <![CDATA[
      /* JScript code here... */
      ]]>
      </script>
      
      </component>
      Yet, I haven't been able to call an instance of such a component or been able to register it. Following error is always raised upon trying to register the WSC: No scriptlet defined in file. Pretty annoying I think as the old <scriptlet> definition is not XML compliant but works perfectly as shown here:

      Code:
      <scriptlet>
      
      <registration progid="Framework.Utility.Error.1.0"
       classid="{2154c700-9253-11d1-a3ac-0aa0044eb5f}"
       description="Error Component"
       version="1.00"
      />
      
      <implements id="Automation" type="Automation">
       <method name="getErrLang" />
      </implements>
      
      <script language="JScript">
      /* JScript code here... */
      </script>
      
      </scriptlet>
      Does anyone have a clue what is going on there? I find it pretty annoying knowing that I have the propper script engine running and haven't made any mistakes in the markup. I merely want to use the revised and showcased usage of XML compliant component definitions as they allow more freedom and are more concise IMO (packaging, resources etc.).
    3. As some alert follower of my rambling might have noticed, the first code example implemented the ASP interface handler so the component has access to ASP objects such as Response, Request et al. The second example, the model I am forced to use currently, implements the Automation handler which does not expose ASP objects. If I try and implement the ASP handler there, following error is returned upon registration: Cannot create interface handler : ASP. Grrrr... I know that the MS documentation is quirky and shows things you sometimes cannot practically do, but hey, this many problems are too much methinks. Anyone know howcome this is (and no, the problem doesn't relate to the former buggy and leaking interface handler implementation for ASP in scripting components that has been fixed with 5.6)? And yes, I know binding the component to one interface handler sort of defies the purpose of COM reusability - also, passing ASP objects as a reference to the component seems to perform better on first tests I have done. Still, I am curious...
    4. To quote MS reference docs:
      Using script components, you can create COM components for a variety of tasks, such as performing middle-tier business logic, accessing and manipulating database data, adding transaction processing to applications, and adding interactive effects to a Web page using DHTML Behaviors.
      Well blimey, but I cannot seem to find out how I can define @transaction directive in my script components. I have virtually seeked all the web for script component implemenation with COM+ transaction services to no avail. All I can find is the same line from MS in a different docs (Scripting 5.6 docs, IIS 5 docs et al). I assume, though I haven't given it a try yet as I just came back home, I could declare my ASP page to be transactional as usual and make handle the OnTransactionAbort, and OnTransactionCommit events as well as oContext.setAbort and oContext.SetComplete methods within the scripting component. However, that looks extremely messy to me (what if I forget to include the @transaction directive in one of my ASP pages that instanciates a transactional component? I could also try whether script components can be adminstered using the component services admin tool where I could set the transaction support. Hmm... Well either way, any pointers or experiences will be much appreciated.
    5. On a somewhat different matter now, is anyone aware of what is happening to WSH.NET? I only know of DSH 1.1, but would prefer a MS solution even if in beta status. The thought behind using a .NET WSH implementation is that VB.NET supports object pooling and I would love to dabble around to see whether .NET scripts can be pooled too.
    Okay, sorry for posting these off beat questions. I know they aren't the usual 'Help, my ASP page won't run' and I have posted similar questions on some appropriate mailing lists - so I shall keep this thread updated as answers (hopefully) come my way

    p.s. following up on my previous thread and WSC performance: if anyone is interested to know: includes run faster no matter what; VBScript classes or JScript objects instanciated from include libs run a tad slower than sub/function calls and faster than WSC instanciated objects; passing ASP objects to WSC's performs better than implementing the ASP interface handler in your script component; WSC's implementing the ASP interface handler and used as a DAO perform negligably less well than VB6 COM components (only on Win 2000 though).

    I started moving my include libs collection to script components some 2 months ago. After some hassle and yet unresolved questions (see above questions), I have concluded - for myself that is - that script components do have substantial advantages over defacto most commonly used include model. While these advantages do not necessarilly compensate for the performance loss incurred by instanciating script component objects, they definately outway the ease of use and potentially offer great advantages for highly configurable frameworks. The idea is, using script components you can construct your web application framework using a true MVC or pull MVC design pattern and virtually achieve the same code reuse and separation from the presentation layer as in .NET. As for the website itself, I do not know many large sites that do not rely on a multi-level caching mechanism or even distributed fragment caching - let's face it, all that is dynamic about dynamic websites is that little static fragments get merged from all over (or the complete HTML page chunck) prior to serving. So I don't have any second thoughts about employing script components as my applications also rely on caching for unbeatable performace. I wouldn't use large include libs, script components or compiled COM's on the live site except if absolutely necessary. Thus, a small site that need not worry too much about performance and scalability, the script components offer a neat way to introduce the site developers to OO/pattern based architectures and n-tier models while leaving all doors open to easilly upgrading their app to compiled COM's or moving it to .NET once .NET matures. For large sites, script components still remain favorable for the framework itself e.g. the content aggregation framework, the asset abstraction classes, the publishing framework etc. All that with good ol' ASP classic which was and still is labeled as a messy scripting solution - I for one love it! Another considerable advantage is that you can create type libraries for your script components and use these for binding WSC events to VB6 apps or, if nothing else, having IntelliSense et al enabled for your script libs in Visual Studio... nifty

    Cheers,
    Karl


    I'm desperately trying to figure out why Kamikaze pilots wore helmets. - George Carlin

  2. #2
    Bangarang! Karloff's Avatar
    Join Date
    Mar 2003
    Location
    Manchester, United Kingdom
    Posts
    236
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A colleague just tested my XML compliant script components (see code example #1) on a beta Win 2003 Server and they registered fine and worked fine in the ASP pages. He also tried registering them on a Win 2000 Server machine which, as he assured me, also has the 5.6 scripting engine installed, and they didn't work.

    Am I missing something here? Did anyone get to run an XML compliant WSC on their Win 2000 box? As I said, I am 100% sure the scripting engine is updated as I have tested it against the Execute() method which only became available with the latest release.

    Edit: Oh, and the ASP interface handler also worked fine on Win 2003...
    Last edited by Karloff; Apr 24, 2003 at 13:12.
    Karl


    I'm desperately trying to figure out why Kamikaze pilots wore helmets. - George Carlin

  3. #3
    Bangarang! Karloff's Avatar
    Join Date
    Mar 2003
    Location
    Manchester, United Kingdom
    Posts
    236
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Seems like I will be answering my own questions over the weekend

    Either way, I just found out why the XML conforming script components did not register on either Win 2000 Pro boxes. I found the answer on MSDN's Scripting.Scriptlets Newsgroup as posted by Torgeir Bakken:
    <!--StartFragment-->WSC files from Win2k usually works fine on WinXP. Your component on my WinXP Pro installation:

    ---------------------------
    RegSvr32
    ---------------------------
    DllRegisterServer and DllInstall in C:\WINDOWS\System32\scrobj.dll succeeded.
    ---------------------------
    OK
    ---------------------------

    I would think you have a problem with your WSH installation...


    1)
    Check the version on the file scrobj.dll in the System32 folder. It *must* be 5.6.0.6626 or better!

    If it is not, some 3rd party program have degraded the dll.

    2)
    If the version is ok, then it may not be registered properly.

    From Start/Run, type

    regsvr32 %SystemRoot%\system32\scrobj.dll


    You should now get this message box:
    ---------------------------
    RegSvr32
    ---------------------------
    DllRegisterServer in C:\Windows\system32\scrobj.dll succeeded.
    ---------------------------
    OK
    ---------------------------


    Just to be sure, do the same check for scrrun.dll and vbscript.dll (should also be 5.6.0.6626 or better).
    My machine had the right versions but it seems like the scrobj.dll was not registered properly. Registering it again solved the problems and I could register the XML conforming script components. Also, the implements type ASP interface handler worked like a charm again.

    ---------------------------------------------------------------
    While I still did not find out how I can restore the context menu for .sct filetypes, I did write a simple WSH application that can batch register/unregister script components and optionally generate the type libs So that's no hassle anymore. Further, somewhere at MSDN I read that .sct extensions are usually used for HTC components (thus client side contrary to my first statement) while .wsc extensions are used for server scripting components... whatever .

    Summary: Questions 1 through 3 have been solved. Question 5 isn't really that important. Now question 4 remains and I would really appreciate any info about script components and transaction services.

    Cheers,
    Karl


    I'm desperately trying to figure out why Kamikaze pilots wore helmets. - George Carlin

  4. #4
    Santos L Halper Zenith's Avatar
    Join Date
    May 2002
    Location
    Finland
    Posts
    641
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is like the longest post I've ever seen. I don't have enough coffee to read even half of it [img]images/smilies/smile.gif[/img]

  5. #5
    The doctor is in... silver trophy MarcusJT's Avatar
    Join Date
    Jan 2002
    Location
    London
    Posts
    3,509
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1) Copy & paste the following into notepad, save with a .reg extension, and doubleclick to restore the registry entries. Please note that I exported it from my WinXP registry, but I don't see why there should be any difference for Win2K - I'm quietly confident that it will work...
    Code:
    Windows Registry Editor Version 5.00
    
    [HKEY_CLASSES_ROOT\.sct]
    @="scriptletfile"
    "Content Type"="text/scriptlet"
    
    [HKEY_CLASSES_ROOT\scriptletfile]
    "FriendlyTypeName"=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\
      00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\
      32,00,5c,00,73,00,63,00,72,00,6f,00,62,00,6a,00,2e,00,64,00,6c,00,6c,00,2c,\
      00,2d,00,38,00,31,00,39,00,32,00,00,00
    @="Windows Script Component"
    
    [HKEY_CLASSES_ROOT\scriptletfile\AutoRegister]
    @="C:\\WINDOWS\\System32\\scrobj.dll"
    
    [HKEY_CLASSES_ROOT\scriptletfile\CLSID]
    @="{06290BD2-48AA-11D2-8432-006008C3FBFC}"
    
    [HKEY_CLASSES_ROOT\scriptletfile\DefaultIcon]
    @="C:\\WINDOWS\\System32\\scrobj.dll,0"
    
    [HKEY_CLASSES_ROOT\scriptletfile\ScriptHostEncode]
    @="{06290BD4-48AA-11D2-8432-006008C3FBFC}"
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell]
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Generate Typelib]
    @="&Generate Type Library"
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Generate Typelib\command]
    @="\"C:\\WINDOWS\\System32\\RUNDLL32.EXE\" C:\\WINDOWS\\System32\\scrobj.dll,GenerateTypeLib \"%1\""
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Register]
    @="&Register"
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Register\command]
    @="\"C:\\WINDOWS\\System32\\REGSVR32.EXE\" /i:\"%1\" \"C:\\WINDOWS\\System32\\scrobj.dll\""
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Unregister]
    @="&Unregister"
    
    [HKEY_CLASSES_ROOT\scriptletfile\Shell\Unregister\command]
    @="\"C:\\WINDOWS\\System32\\REGSVR32.EXE\" /u /n /i:\"%1\" \"C:\\WINDOWS\\System32\\scrobj.dll\""
    NOTE: if your copy of Win2K is NOT installed at C:\WINDOWS\ you will need to search & replace the paths in the registry info above

    2), 3) Pass!

    4) AFAIK, just like the Option Explicit command, transaction mode needs to be set right at the top of the ASP page and can't be set anywhere else, so if you can't do it in plain ASP, I'd be very surprised if you *COULD* do it from within a component, whether compiled or not. I suspect that this is because transaction mode is enabled during the page parsing stage, not during the second (processing) stage, which is when an attempt to enable transactional support from a component would occur.

    However, the ADO.Connection object (and perhaps others) has direct support for transactions, and this operates independently of ASP page-leve transactions. Look up BeginTrans, CommitTrans, and RollbackTrans in your ADO docs for more info...

    5) No idea.


    PS - Interesting info you post on the performance differences...
    MarcusJT
    - former ASP web developer / former SPF "ASP Guru"
    - *very* old blog with some useful ASP code

    - Please think, Google, and search these forums before posting!

  6. #6
    Bangarang! Karloff's Avatar
    Join Date
    Mar 2003
    Location
    Manchester, United Kingdom
    Posts
    236
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cheers for the 1) - I had english context menu items on my german OS. Of course it only required a quick translation and is working fine again.

    4) Yes, but transaction mode is set using the <%@ transaction="required" %> at the top of the page. I wouldn't be able to use this directive in a WSC so I was wondering how else I can set the transaction value?

    Thanks for your answers!
    Karl


    I'm desperately trying to figure out why Kamikaze pilots wore helmets. - George Carlin

  7. #7
    The doctor is in... silver trophy MarcusJT's Avatar
    Join Date
    Jan 2002
    Location
    London
    Posts
    3,509
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My point is that you CAN'T enable page-level transactions from within a WSC (or any other component) because this must be enabled at the initial code parsing stage (by the ASP ASAPI application), rather than during code execution, which is when WSC would act.

    However, ADO's transaction support is independent of ASP's, so depending what you wanted to do, it might be sufficient.
    MarcusJT
    - former ASP web developer / former SPF "ASP Guru"
    - *very* old blog with some useful ASP code

    - Please think, Google, and search these forums before posting!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •