VB6 - MS Scripting Runtime - scrrun.dll 'cant be loaded'

[h4fod]

Hi
Almost desperation here! I have tried unsuccessfully installing the 'Micrsoft Scripting Runtime' component in order to use File System Objects (FSO's)in my programming.

I am aware via MSDN of issues (acknowledged by them) with this ocx so downloaded and installed latest VB6 service pack 6 for this legacy application. Also installed 'Windows Script 5.7' from MSDN download centre. To no avail!

scrrun.dll does exist but only (maybe this is correct) appears as a '.dll' file in \system32 sub directory (not an .ocx file). When I select this file using vb6 component dialog box, it actually does appear ticked in the component list box as 'Microsoft Scripting Runtime. But when selected I get error dialog '..scrrun.dll could not be loaded'. I am now at a complete loss having spent 3 hours going 'round in circles'!

Any ideas please?
Many thanks in anticipation

 

[guitarzan]

In the VB6 IDE, try going to Project > References... and select "Microsoft Script Runtime".

Alternately, I believe you wouldn't need the reference if you define the variables like below:

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")

 

[h4fod]

Hi, Thanks for reply.

The component is not visible in the Proj>ref list either. Suspect that is why when I execute your code I get the error: 'library not registered'.

Incidentally, running Win XP OS with latest SP.

 

[strongm]

>issues (acknowledged by them)

Which issues?

>with this ocx

Microsoft Scripting Runtime is not an OCX

It seems as if the relevant dlls are not registered properly.

 

[h4fod]

Hi
MSDN KB ref:kb/254166 suggests problem with distrubed dll - not .ocx - excuse my lack of in depth knowledge on this. Followed frantic search to resolve problem I have.

Would have thought comprehensive scripting engine 'scripten.exe' update downloaded would have resolved this dll problem without compromising my OS. Can you advise how I can ensure the scrrun.dll file installed is correctly registered on my XP OS.

Many thanks
Mike

 

[guitarzan]

Start > Run, and type regsvr32 scrrun.dll

Should be followed by a message that "DllRegisterServer in scrrun.dll succeeded.

 

[strongm]

>kb254166

1) That's a very old document. Problems with dependency issues were fixed in VB service pack years ago.

2) You have not really had to worry about distributing the scripting components for years, since they are included in the OS

>Would have thought comprehensive scripting engine 'scripten.exe' update downloaded would have resolved this

Normally so would I - but XP SP3 has a bunch of file protection stuff that may have interfered

 

[dilettante]

Windows File Protection does its best to prevent you from overwriting system components with flawed versions. The flaws can range from older versions to versions compiled for a different version of Windows. Lots of these things are tailored code now, not generic builds for any OS.

They're meant to be serviced (updated) via Windows Update these days. Applications should never try to deploy these except to downlevel systems (Win9x), and this should be managed by having either separate packages or conditional logic in the package that checks the OS version.


Most of the time applications do not need Scripting 5.7 installed, and most of what changed is only active for scripts inside later IE versions. There is a package for installing 5.7 into an older version of Windows. From the release notes:

Why Version 5.7?
The primary reason for changing the version number from 5.6 to 5.7 is to simplify servicing and support by synchronizing the versioning to a consistent scheme based on Vista build number. The minor version increase does not indicate significant new features. The scripting feature set is substantially the same as 5.6, with only minor additions.

Almost always when you see a problem using Scripting it means you have an overly agressive (and outdated) anti-virus package installed. A secondary source can be flawed installers that have corrupted your registry.


I'd wonder more why you want to use the FSO in a VB6 program anyway.

Nothing wrong with it, but for most things the native I/O statements and functions are better, faster, stronger. The main advantage of the FSO in VB6 is to move blobs of VBScript over with less rewriting. Secondarily it supports UTF-16LE text I/O more easily than native I/O. That's about it though.

 

[h4fod]

Hi Stongm and dilettante
Many thanks for your posts. Suspect the 'law of diminishing rerturns' applies here to me fighting against a legacy app. Reason for resolving my problem to get to grips with using fso's in my programming solutions. Using tutorials which use this as primary method of managing files.

Incidentally, disabled AVAST A/virus when executing scripten.

Does this mean I will need to use the ccmmon dialog box as a means of file management and manipulation and avoid using drive box ocx's etc when developing HCI's. Can you direct me to content on Tek-Tips to pursue your reccomended alternative approach native i/o etc.

As an educator of 16-18 yrs, do you think now is the time to upskill to vb.net, or does vb6 still have milage for teaching OOP; learning overhead significant. Views appreciated - know this is 'outside' scope of post?

Again, Many thanks
Mike

 

[dilettante]

Go ahead and use the FSO if you like, it normally works just fine. There should not be any need to mess around installing scripting though, because as noted it's "in the box" already (part of Windows) for more than a decade.

Not sure what bearing any of that has on the "common dialog box" (the file Open/Save Common Dialogs?) but those are pretty standard since Win95 came out. Not sure what you mean by "drive box OCSs" - maybe the old intrinsic VB controls like DriveBox, FileListBox, etc? Those were included in VB6 mostly for compatibility when porting a VB3/4 Win3.1 program forward. When was the last time you saw a commercial program that used such an old fashioned GUI?

"Disabling" an anti-virus suite doesn't necessarily undo the damage it does. As I said before, some products are very aggressive about trashing Windows Scripting by corrupting the registry entries or removing the related libraries.

Scripting might be fine on your system though. Perhaps you aren't setting the reference properly. Don't try setting it as a "Component" library, since it isn't.


I don't think there is anything wrong with VB6, but teaching it to new students today is a little odd. Just to begin with acquiring legitimate licenses for the product isn't easy anymore. It is not free.

On the other hand there have been free "Express" editions of VB.Net for many releases now. This is a pretty mainstream programming language today and might make a better platform for teaching in 2011 than VB6. Or you might go with Java, for which there are numerous sets of free tools and of course Sun/Oracle's compilers.

 

[h4fod]

Hi Dilettante
Thank you for your very informative views - these are welcome. I will migrate to VB.net Express vertsion now given maintainability issues and 'learner experiences' associated with legacy application, despite being educationally licensed and running well as a virtualised app on XP client platforms. Yes, teaching using VB6 is to many somewhat odd but when you have a stable solution over many clients, the on costs of educator upskilling, time constraints to acquire new sklills and very limited training - prof dev. budgets (now even more tight) perhaps you can understand differences between commercial and educational environments.

Again, many thanks for your (/all) posts.

Many thanks
Mike

 

[dilettante]

Weel if you have the VB6 licenses to go around I don't think there's anything wrong with it as a language for study. People have to start somewhere, and they seldom end there.

As for "learner experiences" vs. "legacy application" I suppose you are referring to deployment related issues. Many of the issues people have with VB6 can be the same or worse using another tool like VB.Net. This has more to do with Windows maturing as a platform, with security getting better which requires that programmers follow the rules better than they used to.

And of course deployment is really a specialty all it's own.


If you want a "safe sandbox" for students to begin with you might consider Microsoft's "other Basic.Net" Small Basic. It is intentionally kept limited to make learning easier. You might take a look at Small Basic teaching Curriculum now available.