FileSystemObject compatibility Unexpected error (32810)


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: FileSystemObject compatibility Unexpected error (32810)

  1. #1
    willy van den Driessche Guest

    FileSystemObject compatibility Unexpected error (32810)


    The primary interface of the fileSystemObject has changed from version 5.0.0.3715
    to 5.1.0.5010. Since I use some of the objects of the old DLL in the public
    interface of some of my objects,
    ( see also : http://users.skynet.be/wvdd2/File_Se...searching.html
    )

    I am now forced to use the old version of the DLL on all our development
    machines. If I use the more recent version, I am not able to debug or even
    compile my app (for those who care : Unexpected error (32810)).

    Unfortunately for me, Numega DevPartner Studio uses (and installs) the new
    scrrun.dll which means I am out of luck. I could either compile my app or
    use devpartner studio but not both.

    With some hard thinking, I figured VB just needed the old typelibrary and
    didn't care about the version of the installed and registred DLL - as long
    as the version was not lower than the objects described in the typelibrary.
    So I copied the old DLL to scrrun.cmp and registred the new DLL. But the
    error remains. Aargh.

    Any help or even glimpses of ideas is really appreciated,

    Van den Driessche Willy.



  2. #2
    Rob Teixeira Guest

    Re: FileSystemObject compatibility Unexpected error (32810)



    If I'm not mistaken, that's a low-level COM SCode value for "type mismatch".
    Looks like you're hosed there. While you *can* reference a typelibrary of
    a different version, eventually, the typelibary needs to match the physical
    implementation of the library itself.

    Typically, this sort of thing isn't supposed to happen. For example, newer
    versions of DirectX still expose the old interfaces (you just can't use the
    newer features from those interfaces). I haven't compared the filesystemobject
    of these versions, so I can't tell you specifically what to look for though.

    -Rob

    "willy van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
    >
    >The primary interface of the fileSystemObject has changed from version 5.0.0.3715
    >to 5.1.0.5010. Since I use some of the objects of the old DLL in the public
    >interface of some of my objects,
    >( see also : http://users.skynet.be/wvdd2/File_Se...searching.html
    >)
    >
    >I am now forced to use the old version of the DLL on all our development
    >machines. If I use the more recent version, I am not able to debug or even
    >compile my app (for those who care : Unexpected error (32810)).
    >
    >Unfortunately for me, Numega DevPartner Studio uses (and installs) the new
    >scrrun.dll which means I am out of luck. I could either compile my app

    or
    >use devpartner studio but not both.
    >
    >With some hard thinking, I figured VB just needed the old typelibrary and
    >didn't care about the version of the installed and registred DLL - as long
    >as the version was not lower than the objects described in the typelibrary.
    > So I copied the old DLL to scrrun.cmp and registred the new DLL. But the
    >error remains. Aargh.
    >
    >Any help or even glimpses of ideas is really appreciated,
    >
    >Van den Driessche Willy.
    >
    >



  3. #3
    Willy Van den Driessche Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    > If I'm not mistaken, that's a low-level COM SCode value for "type
    mismatch".
    > Looks like you're hosed there. While you *can* reference a typelibrary of
    > a different version, eventually, the typelibary needs to match the

    physical
    > implementation of the library itself.
    >
    > Typically, this sort of thing isn't supposed to happen. For example, newer
    > versions of DirectX still expose the old interfaces (you just can't use

    the
    > newer features from those interfaces). I haven't compared the

    filesystemobject
    > of these versions, so I can't tell you specifically what to look for

    though.

    Well actually they are still compatible, much in the way DirectX is. I just
    can't understand it.
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3c2cbd26$1@147.208.176.211...
    >
    >


    >
    > -Rob
    >
    > "willy van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
    > >
    > >The primary interface of the fileSystemObject has changed from version

    5.0.0.3715
    > >to 5.1.0.5010. Since I use some of the objects of the old DLL in the

    public
    > >interface of some of my objects,
    > >( see also :

    http://users.skynet.be/wvdd2/File_Se...searching.html
    > >)
    > >
    > >I am now forced to use the old version of the DLL on all our development
    > >machines. If I use the more recent version, I am not able to debug or

    even
    > >compile my app (for those who care : Unexpected error (32810)).
    > >
    > >Unfortunately for me, Numega DevPartner Studio uses (and installs) the

    new
    > >scrrun.dll which means I am out of luck. I could either compile my app

    > or
    > >use devpartner studio but not both.
    > >
    > >With some hard thinking, I figured VB just needed the old typelibrary and
    > >didn't care about the version of the installed and registred DLL - as

    long
    > >as the version was not lower than the objects described in the

    typelibrary.
    > > So I copied the old DLL to scrrun.cmp and registred the new DLL. But

    the
    > >error remains. Aargh.
    > >
    > >Any help or even glimpses of ideas is really appreciated,
    > >
    > >Van den Driessche Willy.
    > >
    > >

    >




  4. #4
    Aidan Coughlan Guest

    Re: FileSystemObject compatibility Unexpected error (32810)


    I got this error today when I moved a VB project developed & unit tested on
    a WIN2K machine to WINNT4-SP6 - the project did not compile & i got the "Unexpected
    error 32810" error. I found that by selecting the 'No Compatability' option,
    it would compile ok. Unfortunately this means renaming your component if
    you are to obey the traditional rules for breaking compatability.

    ps. had a look at your web site & found a few usefull tips. Any comments
    on experiences with cross-platform development/deployment on Windows NT and
    Win2K versions with VB ?

  5. #5
    Willy Van den Driessche Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    >
    > I got this error today when I moved a VB project developed & unit tested

    on
    > a WIN2K machine to WINNT4-SP6 - the project did not compile & I got the

    "Unexpected
    > error 32810" error. I found that by selecting the 'No Compatibility

    option,
    > it would compile ok. Unfortunately this means renaming your component if
    > you are to obey the traditional rules for breaking compatibility.


    Breaking compatibility will (IMHO) always solve this error but unfortunately
    it is not always an option. For my specific problem, breaking compatibility
    also solves the problem.
    I only have the problem on my own machine which has a newer scrrun.dll.
    Since I have a separate immutable compilation machine, no client will ever
    experience any problem. Our app (compiled from the compilation machine)
    also runs without any problems on my own machine. It is just when I want to
    compile on my own machine (for test programs or to test intermediate
    versions) that I ran into troubles. I have currently fixed this by
    registering the older version of scrrun.dll.

    Does your problem also include scrrund.dll (or mscal.ocx ?) ?

    [For Rob : I'm sure that scrrun.dll was not developed in VB since they
    trusted their craftsmanship to keep it compatible :-( ]

    >
    > ps. had a look at your web site & found a few useful tips. Any comments
    > on experiences with cross-platform development/deployment on Windows NT

    and
    > Win2K versions with VB ?


    Have one separate immutable (don't install anything on it once you start
    deploying) compilation machine. In your case that machine would mean : run
    Win NT (always the lowest version). You could also use a Win2K machine but
    you'd have to upgrade some components on the Win NT machine.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html
    "Aidan Coughlan" <acoughlan@westpiersoft.ie> wrote in message
    news:3c330d85$1@147.208.176.211...



  6. #6
    Aidan Coughlan Guest

    Re: FileSystemObject compatibility Unexpected error (32810)


    >Does your problem also include scrrund.dll (or mscal.ocx ?) ?
    >[For Rob : I'm sure that scrrun.dll was not developed in VB since they
    >trusted their craftsmanship to keep it compatible :-( ]
    >


    Yes, I **think** scrrun.dll is involved in my specific issue too. The project
    uses FSO, requiring scrrun.dll - was originally compiled on Win2K (with latest
    version of scrrun), then moved to a WinNT-SP6 machine (with earlier version
    of scrrun). When I tried to compile/or run it in VB on the NT machine it
    refused to even start to run giving the 'Unexpected error 32810' message.
    If I recall correctly, commenting out the FSO code in the project allowed
    it to compile ok, as did breaking compatability which is what I did in the
    end. The interface for my project has not changed, so I would have preferred
    to keep compatability, but cest la vie. In this instance I can live with
    it.

    ps. I have borrowed a dedicated NT4 machine for compilation & another one
    for testing - it does seem to have sorted the issues I was having across
    NT4/WIN2K versions.

  7. #7
    Rob Teixeira Guest

    Re: FileSystemObject compatibility Unexpected error (32810)


    Matt's Power tools come to the rescue again!
    Hey Matt, mind sending that tlb to my email? Can't see any attachments here.

    -Rob

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >(Note that this is not an official MS response, I got here on my own
    >starting with a request from Willy)
    >
    >The new typelib version is woefully incompatible with the old one. The
    >following has changed:
    >1) The new version has four sets of enum/alias-to-enum pairs which were
    >straight enums in the earlier version.
    >2) Besides this, the type ordering has changed.
    >
    >A typelib must increment its minor version to reorder its types, and should
    >never reorder an unguided type without changing the major version. Neither
    >of these things were done correctly.
    >
    >I've attached an scrrun.fixed.tlb that I modified with the typelib editor
    >from my book (http://www.PowerVB.com) to line up correctly with the original
    >typelib. I've also included the .LEH (Library Edit History) script I
    >recorded while doing this if you want to see the changes I made. You can

    use
    >this with the EditTLB.exe version in the latest book udpates to see the
    >steps I took to fix the typelib.
    >
    >Registering scrrun.fixed.tlb (a reference to 'TypeLib Information' plus
    >TLI.TypeLibInfoFromFile("Fullpath for scrrun.fixed.tlb").Register in the
    >debug window) on your dev box should fix up all of the problems. I would
    >strongly recommend not breaking compatibility and binding to the damaged
    >version of the typelib as you'll just hit the same problem again down the
    >road if an official fix is provided. -Matt



  8. #8
    Matthew Curland Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    (Note that this is not an official MS response, I got here on my own
    starting with a request from Willy)

    The new typelib version is woefully incompatible with the old one. The
    following has changed:
    1) The new version has four sets of enum/alias-to-enum pairs which were
    straight enums in the earlier version.
    2) Besides this, the type ordering has changed.

    A typelib must increment its minor version to reorder its types, and should
    never reorder an unguided type without changing the major version. Neither
    of these things were done correctly.

    I've attached an scrrun.fixed.tlb that I modified with the typelib editor
    from my book (http://www.PowerVB.com) to line up correctly with the original
    typelib. I've also included the .LEH (Library Edit History) script I
    recorded while doing this if you want to see the changes I made. You can use
    this with the EditTLB.exe version in the latest book udpates to see the
    steps I took to fix the typelib.

    Registering scrrun.fixed.tlb (a reference to 'TypeLib Information' plus
    TLI.TypeLibInfoFromFile("Fullpath for scrrun.fixed.tlb").Register in the
    debug window) on your dev box should fix up all of the problems. I would
    strongly recommend not breaking compatibility and binding to the damaged
    version of the typelib as you'll just hit the same problem again down the
    road if an official fix is provided. -Matt


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3c2cbd26$1@147.208.176.211...
    >
    >
    > If I'm not mistaken, that's a low-level COM SCode value for "type

    mismatch".
    > Looks like you're hosed there. While you *can* reference a typelibrary of
    > a different version, eventually, the typelibary needs to match the

    physical
    > implementation of the library itself.
    >
    > Typically, this sort of thing isn't supposed to happen. For example, newer
    > versions of DirectX still expose the old interfaces (you just can't use

    the
    > newer features from those interfaces). I haven't compared the

    filesystemobject
    > of these versions, so I can't tell you specifically what to look for

    though.
    >
    > -Rob
    >
    > "willy van den Driessche" <Willy.van.den.driessche@skynet.be> wrote:
    > >
    > >The primary interface of the fileSystemObject has changed from version

    5.0.0.3715
    > >to 5.1.0.5010. Since I use some of the objects of the old DLL in the

    public
    > >interface of some of my objects,
    > >( see also :

    http://users.skynet.be/wvdd2/File_Se...searching.html
    > >)
    > >
    > >I am now forced to use the old version of the DLL on all our development
    > >machines. If I use the more recent version, I am not able to debug or

    even
    > >compile my app (for those who care : Unexpected error (32810)).
    > >
    > >Unfortunately for me, Numega DevPartner Studio uses (and installs) the

    new
    > >scrrun.dll which means I am out of luck. I could either compile my app

    > or
    > >use devpartner studio but not both.
    > >
    > >With some hard thinking, I figured VB just needed the old typelibrary and
    > >didn't care about the version of the installed and registred DLL - as

    long
    > >as the version was not lower than the objects described in the

    typelibrary.
    > > So I copied the old DLL to scrrun.cmp and registred the new DLL. But

    the
    > >error remains. Aargh.
    > >
    > >Any help or even glimpses of ideas is really appreciated,
    > >
    > >Van den Driessche Willy.
    > >
    > >

    >




  9. #9
    Mattias Sjögren Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    Matt,

    >I've attached an scrrun.fixed.tlb


    I don't think this server allows binary attachments. I don't see
    anything attached to your message.


    Mattias

    ===
    Mattias Sjögren (VB MVP)

  10. #10
    Matthew Curland Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    Sorry. Not sure if I forgot the attachment or if it didn't take. I've thrown
    the zip file on http://www.PowerVB.com/scrrun. If you want to see the
    changes that were made, start the EditTLB tool with:
    edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /a
    or
    edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /s scrrun.fixed.tlb
    to regenerate the typelib. -Matt

    "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
    news:3c3b5e9c@147.208.176.211...
    > Matt,
    >
    > >I've attached an scrrun.fixed.tlb

    >
    > I don't think this server allows binary attachments. I don't see
    > anything attached to your message.
    >
    >
    > Mattias
    >
    > ===
    > Mattias Sjögren (VB MVP)




  11. #11
    Willy Van den Driessche Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    > Sorry. Not sure if I forgot the attachment or if it didn't take. I've
    thrown
    > the zip file on http://www.PowerVB.com/scrrun. If you want to see the
    > changes that were made, start the EditTLB tool with:
    > edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /a
    > or
    > edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /s scrrun.fixed.tlb
    > to regenerate the typelib. -Matt


    So, I was a little too late :-)
    http://users.skynet.be/wvdd2/General.../thanks_matthe
    w.html

    Thanks again Matthew !
    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



  12. #12
    Matthew Curland Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    Thanks, Willy. That's the best public 'thank you' I've ever had.

    I discussed this with the scripting folks and wasn't really happy where I'd
    left this. The problem is that compiling against the modified typelib makes
    the compatibility file load, but fails to enable loading the final product
    when 5.1 is installed. I collected code from various parts of my typelib
    editing tools and made a proper fix for this problem, which is posted at the
    site mentioned earlier (http://www.PowerVB.com/scrrun). The command line
    tool (MigrateScripting.exe) takes a single command line argument, which is
    the file to fix. It takes any typelib (standalone or resource) which is
    bound to the 5.0 libraries and changes it to bind against the 5.1/5.6
    library. Simply run the tool once against your compatibility file (or any
    other Dll, Exe, or Tlb that references the 5.0 typelib) and all will be
    well.

    Of course, you'll have the same problem in reverse if you install the
    finished bits on a system with the 5.0 scrrun.dll installed. (I didn't make
    any attempt to move the other direction). The only way to support binding to
    both is to not reference any of the unguided Scripting enums.

    I'm sure Microsoft will pick this up at some point and attach legal
    disclaimers and an official Q number to it. In the meantime, this should
    take care of the problem. -Matt

    "Willy Van den Driessche" <Willy.Van.denDriessche@skynet.be> wrote in
    message news:3c3ba0af$1@147.208.176.211...
    > > Sorry. Not sure if I forgot the attachment or if it didn't take. I've

    > thrown
    > > the zip file on http://www.PowerVB.com/scrrun. If you want to see the
    > > changes that were made, start the EditTLB tool with:
    > > edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /a
    > > or
    > > edittlb /t scrrun.dll /l scrrun.5.1.0.5010.leh /s scrrun.fixed.tlb
    > > to regenerate the typelib. -Matt

    >
    > So, I was a little too late :-)
    >

    http://users.skynet.be/wvdd2/General.../thanks_matthe
    > w.html
    >
    > Thanks again Matthew !
    > --
    > Van den Driessche Willy
    > For a work in progress :
    > http://users.skynet.be/wvdd2/index.html
    >
    >




  13. #13
    willy van den Driessche Guest

    Re: FileSystemObject compatibility Unexpected error (32810)


    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >Thanks, Willy. That's the best public 'thank you' I've ever had.
    >
    >I discussed this with the scripting folks and wasn't really happy where

    I'd
    >left this. The problem is that compiling against the modified typelib makes
    >the compatibility file load, but fails to enable loading the final product
    >when 5.1 is installed. I collected code from various parts of my typelib
    >editing tools and made a proper fix for this problem, which is posted at

    the
    >site mentioned earlier (http://www.PowerVB.com/scrrun). The command line
    >tool (MigrateScripting.exe) takes a single command line argument, which

    is
    >the file to fix. It takes any typelib (standalone or resource) which is
    >bound to the 5.0 libraries and changes it to bind against the 5.1/5.6
    >library. Simply run the tool once against your compatibility file (or any
    >other Dll, Exe, or Tlb that references the 5.0 typelib) and all will be
    >well.
    >
    >Of course, you'll have the same problem in reverse if you install the
    >finished bits on a system with the 5.0 scrrun.dll installed. (I didn't make
    >any attempt to move the other direction). The only way to support binding

    to
    >both is to not reference any of the unguided Scripting enums.
    >
    >I'm sure Microsoft will pick this up at some point and attach legal
    >disclaimers and an official Q number to it. In the meantime, this should
    >take care of the problem. -Matt
    >


    Matthew,

    Just wanted to let you know :

    I took scrrun.fixed.tlb and registered the type library.
    I unregistered the old scrrun.dll (5.0.0.3715)
    I took the new scrrun.dll (5.1.0.5010), put in the System32 directory and
    registred it.
    I applied MigrateScripting.exe to my troubling DLL [BBLCore.DLL] (in fact
    my CMP). (the one that exposes the types from scrrun.DLL in public interfaces)
    I forced a recompile of BBLCore.DLL. It worked.
    I didn't touch any components built on top of BBLCore.DLL
    I ran the application : it worked.
    I forced a recompile of all components (referencing the scrrun.fixed.tlb
    typelib for all components) of the app on my dev machine. It worked.

    The bottom line : it works flawlessly.

    It's hard to have it any simpler than that.

    Thank you very much and see you,
    Van den Driessche Willy


  14. #14
    Joe \Nuke Me Xemu\ Foster Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    "willy van den Driessche" <Willy.van.den.driessche@skynet.be> wrote in message <news:3c3efaba$1@147.208.176.211>...

    > Matthew,
    >
    > Just wanted to let you know :
    >
    > I took scrrun.fixed.tlb and registered the type library.
    > I unregistered the old scrrun.dll (5.0.0.3715)
    > I took the new scrrun.dll (5.1.0.5010), put in the System32 directory and
    > registred it.
    > I applied MigrateScripting.exe to my troubling DLL [BBLCore.DLL] (in fact
    > my CMP). (the one that exposes the types from scrrun.DLL in public interfaces)
    > I forced a recompile of BBLCore.DLL. It worked.
    > I didn't touch any components built on top of BBLCore.DLL
    > I ran the application : it worked.
    > I forced a recompile of all components (referencing the scrrun.fixed.tlb
    > typelib for all components) of the app on my dev machine. It worked.
    >
    > The bottom line : it works flawlessly.
    >
    > It's hard to have it any simpler than that.


    Ick... Why are you using FileSystemAbomination, anyway? If you need
    to work with files > 2GB, roll your own components which won't break
    every time Microslop releases a new mutation of their Virus Broadcast
    System into the wild!

    --
    Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  15. #15
    Willy Van den Driessche Guest

    Re: FileSystemObject compatibility Unexpected error (32810)

    > Ick... Why are you using FileSystemAbomination, anyway? If you need
    > to work with files > 2GB, roll your own components which won't break
    > every time Microslop releases a new mutation of their Virus Broadcast
    > System into the wild!


    I like the FSO for several reasons. The first and foremost is that it
    relieves me of having to remember some file API calls and whether they are
    supported on this or that OS. The objects are clear and intuitive to use
    and the resulting code is highly readable. There are faster alternatives
    but for my app, speedy file access is not crucial. Robust file access is.

    The FSO writers got it wrong with their version upgrade. I don't blame
    them. After all, there are way too few tools that can actually verify
    compatibility. In C++ (which I presume the component was written in) you're
    pretty much on your own. What we need (now if possible) are some tools that
    allow us to verify VB typelib compatibility, .NET assembly compatibility,
    Webservice functionality compatibility, Delphi package compat, Java package
    compat, VC++ DLL compat ... etc. Tools that say: "yes" or "no". Until
    those tools are available (and also built into the environment like in VB)
    there will be more such things to happen. It's 'only' syntactical
    compatibility we are checking and maybe not a 100% full proof, but at least
    we automate automatable things.

    So it's not the stupid, not the Microsoft, not the Borland, ... developers
    that are to blame (although when I do something like that it helps to know
    they do it too). We are all ready to make the same kinds of errors.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center