open "filename.txt" for input not working

Discussion in 'ASP General' started by Seth Darr, Apr 15, 2006.

  1. Seth Darr

    Seth Darr Guest

    I'm working on migrating an Classic ASP/VB6 COM application from an NT
    Server with IIS<6 to an virtual machine running Windows Server 2003 and
    IIS 6. I've worked through most of the obvious problems resulting from
    IIS 6 prohibiting ASP and SSI etc, but I've hit a peculiar wall.

    One ASP page uses a VB6 COM object that basically reads from an .INI
    file and uses it to open another file. The existing code uses this line
    (in VB6) to do this:

    Open "UpLoad.ini" For Input As #1

    This works fine in the existing setup, but on the new box it returns a
    "File Not Found" error at this line. If I hard code a path in there
    (i.e. "C:\temp\Upload.ini") it will work, but I don't want to do that.
    So my question is, why isn't this working? It should be trying to read
    UpLoad.ini from the same directory that the .dll file is registered in,
    right? (in this case, C:\WINDOWS\System32) Is it a permissions issue?
    I've tried giving IUSR_* and SYSTEM accounts read/write access to that
    folder (against my better judgement) as well as to the folder the code
    is ultimately going to write to (that's a whole other, but perhaps
    similar, ball of wax).

    So does this ring bells for anyone? Any help would be greatly appreciated.

    -Seth
     
    Seth Darr, Apr 15, 2006
    #1
    1. Advertising

  2. Seth Darr

    Steven Burn Guest

    Try Server.MapPath() 'ing the file .......

    --
    Regards

    Steven Burn
    Ur I.T. Mate Group
    www.it-mate.co.uk

    Keeping it FREE!

    "Seth Darr" <> wrote in message
    news:Nae0g.4502$ZW3.1569@dukeread04...
    > I'm working on migrating an Classic ASP/VB6 COM application from an NT
    > Server with IIS<6 to an virtual machine running Windows Server 2003 and
    > IIS 6. I've worked through most of the obvious problems resulting from
    > IIS 6 prohibiting ASP and SSI etc, but I've hit a peculiar wall.
    >
    > One ASP page uses a VB6 COM object that basically reads from an .INI
    > file and uses it to open another file. The existing code uses this line
    > (in VB6) to do this:
    >
    > Open "UpLoad.ini" For Input As #1
    >
    > This works fine in the existing setup, but on the new box it returns a
    > "File Not Found" error at this line. If I hard code a path in there
    > (i.e. "C:\temp\Upload.ini") it will work, but I don't want to do that.
    > So my question is, why isn't this working? It should be trying to read
    > UpLoad.ini from the same directory that the .dll file is registered in,
    > right? (in this case, C:\WINDOWS\System32) Is it a permissions issue?
    > I've tried giving IUSR_* and SYSTEM accounts read/write access to that
    > folder (against my better judgement) as well as to the folder the code
    > is ultimately going to write to (that's a whole other, but perhaps
    > similar, ball of wax).
    >
    > So does this ring bells for anyone? Any help would be greatly appreciated.
    >
    > -Seth
     
    Steven Burn, Apr 16, 2006
    #2
    1. Advertising

  3. Seth Darr

    Seth Darr Guest

    Server.MapPath is only giving me the physical path of the ASP page. The path
    of the ActiveX component and the path that Open...For Input is independent of
    this. If I knew of an equivalent Server.MapPath function for opening files
    for input in VB6, I might get somewhere. But so far that has eluded me.

    "Steven Burn" wrote:

    > Try Server.MapPath() 'ing the file .......
    >
    > --
    > Regards
    >
    > Steven Burn
    > Ur I.T. Mate Group
    > www.it-mate.co.uk
    >
    > Keeping it FREE!
    >
    > "Seth Darr" <> wrote in message
    > news:Nae0g.4502$ZW3.1569@dukeread04...
    > > I'm working on migrating an Classic ASP/VB6 COM application from an NT
    > > Server with IIS<6 to an virtual machine running Windows Server 2003 and
    > > IIS 6. I've worked through most of the obvious problems resulting from
    > > IIS 6 prohibiting ASP and SSI etc, but I've hit a peculiar wall.
    > >
    > > One ASP page uses a VB6 COM object that basically reads from an .INI
    > > file and uses it to open another file. The existing code uses this line
    > > (in VB6) to do this:
    > >
    > > Open "UpLoad.ini" For Input As #1
    > >
    > > This works fine in the existing setup, but on the new box it returns a
    > > "File Not Found" error at this line. If I hard code a path in there
    > > (i.e. "C:\temp\Upload.ini") it will work, but I don't want to do that.
    > > So my question is, why isn't this working? It should be trying to read
    > > UpLoad.ini from the same directory that the .dll file is registered in,
    > > right? (in this case, C:\WINDOWS\System32) Is it a permissions issue?
    > > I've tried giving IUSR_* and SYSTEM accounts read/write access to that
    > > folder (against my better judgement) as well as to the folder the code
    > > is ultimately going to write to (that's a whole other, but perhaps
    > > similar, ball of wax).
    > >
    > > So does this ring bells for anyone? Any help would be greatly appreciated.
    > >
    > > -Seth

    >
    >
    >
     
    Seth Darr, Apr 17, 2006
    #3
  4. Seth Darr

    Steven Burn Guest

    Can't you server.mappath before supplying the AX with the name of the file?
    (i.e. pass the whole path)

    --
    Regards

    Steven Burn
    Ur I.T. Mate Group
    www.it-mate.co.uk

    Keeping it FREE!

    "Seth Darr" <> wrote in message
    news:...
    > Server.MapPath is only giving me the physical path of the ASP page. The

    path
    > of the ActiveX component and the path that Open...For Input is independent

    of
    > this. If I knew of an equivalent Server.MapPath function for opening

    files
    > for input in VB6, I might get somewhere. But so far that has eluded me.
    >
    > "Steven Burn" wrote:
    >
    > > Try Server.MapPath() 'ing the file .......
    > >
    > > --
    > > Regards
    > >
    > > Steven Burn
    > > Ur I.T. Mate Group
    > > www.it-mate.co.uk
    > >
    > > Keeping it FREE!
    > >
    > > "Seth Darr" <> wrote in message
    > > news:Nae0g.4502$ZW3.1569@dukeread04...
    > > > I'm working on migrating an Classic ASP/VB6 COM application from an NT
    > > > Server with IIS<6 to an virtual machine running Windows Server 2003

    and
    > > > IIS 6. I've worked through most of the obvious problems resulting from
    > > > IIS 6 prohibiting ASP and SSI etc, but I've hit a peculiar wall.
    > > >
    > > > One ASP page uses a VB6 COM object that basically reads from an .INI
    > > > file and uses it to open another file. The existing code uses this

    line
    > > > (in VB6) to do this:
    > > >
    > > > Open "UpLoad.ini" For Input As #1
    > > >
    > > > This works fine in the existing setup, but on the new box it returns a
    > > > "File Not Found" error at this line. If I hard code a path in there
    > > > (i.e. "C:\temp\Upload.ini") it will work, but I don't want to do that.
    > > > So my question is, why isn't this working? It should be trying to read
    > > > UpLoad.ini from the same directory that the .dll file is registered

    in,
    > > > right? (in this case, C:\WINDOWS\System32) Is it a permissions issue?
    > > > I've tried giving IUSR_* and SYSTEM accounts read/write access to that
    > > > folder (against my better judgement) as well as to the folder the code
    > > > is ultimately going to write to (that's a whole other, but perhaps
    > > > similar, ball of wax).
    > > >
    > > > So does this ring bells for anyone? Any help would be greatly

    appreciated.
    > > >
    > > > -Seth

    > >
    > >
    > >
     
    Steven Burn, Apr 17, 2006
    #4
  5. Seth Darr

    Seth Darr Guest

    Not really, the .ini's location is entirely independent of the web
    file/folder structure. I could modify the asp page to send in a path to
    the AX like you're suggesting (i.e. send in
    "C:\WINDOWS\system32\upload.ini") but the whole point of this migration
    is to have a personal copy of the production environment in work
    (unfortunately, the vm setup they gave me is more modern than the
    production environment). I can't just modify the production environment
    to match my setup without submitting reams of action plans and service
    requests etc and then I'm not so sure it's a compelling enough reason
    for them. Catch my meaning?

    So I guess what I'm looking for here is not so much an alternative
    solution/workaround in CODE as an EXPLANATION of this discrepancy and,
    hopefully, a workaround in my SYSTEM to rectify the discrepancy (i.e.
    IIS settings, server settings, etc)


    Steven Burn wrote:
    > Can't you server.mappath before supplying the AX with the name of the file?
    > (i.e. pass the whole path)
    >
     
    Seth Darr, Apr 18, 2006
    #5
  6. Seth Darr

    Steven Burn Guest

    The reason it's happening is that whilst the .dll and .ini file are in the
    same folder, the .dll is being instantiated from a completely different
    folder and thus, you need to tell it where to find the .ini file.


    --
    Regards

    Steven Burn
    Ur I.T. Mate Group
    www.it-mate.co.uk

    Keeping it FREE!

    "Seth Darr" <> wrote in message
    news:KzX0g.4729$ZW3.652@dukeread04...
    > Not really, the .ini's location is entirely independent of the web
    > file/folder structure. I could modify the asp page to send in a path to
    > the AX like you're suggesting (i.e. send in
    > "C:\WINDOWS\system32\upload.ini") but the whole point of this migration
    > is to have a personal copy of the production environment in work
    > (unfortunately, the vm setup they gave me is more modern than the
    > production environment). I can't just modify the production environment
    > to match my setup without submitting reams of action plans and service
    > requests etc and then I'm not so sure it's a compelling enough reason
    > for them. Catch my meaning?
    >
    > So I guess what I'm looking for here is not so much an alternative
    > solution/workaround in CODE as an EXPLANATION of this discrepancy and,
    > hopefully, a workaround in my SYSTEM to rectify the discrepancy (i.e.
    > IIS settings, server settings, etc)
    >
    >
    > Steven Burn wrote:
    > > Can't you server.mappath before supplying the AX with the name of the

    file?
    > > (i.e. pass the whole path)
    > >
     
    Steven Burn, Apr 18, 2006
    #6
  7. Seth Darr

    Seth Darr Guest

    At the risk of sounding like a broken record... why why why? Why does it
    suffice to specify the relative path from the executable in one environment
    and not the other? How do you find out where its being instantiated and
    subsequently control it (not through code, but system settings)? Why do hot
    dogs come in packs of 10 while hot dog buns come in packs of 12? etc.

    "Steven Burn" wrote:

    > The reason it's happening is that whilst the .dll and .ini file are in the
    > same folder, the .dll is being instantiated from a completely different
    > folder and thus, you need to tell it where to find the .ini file.
    >
    >
    > --
    > Regards
    >
    > Steven Burn
    > Ur I.T. Mate Group
    > www.it-mate.co.uk
    >
    > Keeping it FREE!
    >
    > "Seth Darr" <> wrote in message
    > news:KzX0g.4729$ZW3.652@dukeread04...
    > > Not really, the .ini's location is entirely independent of the web
    > > file/folder structure. I could modify the asp page to send in a path to
    > > the AX like you're suggesting (i.e. send in
    > > "C:\WINDOWS\system32\upload.ini") but the whole point of this migration
    > > is to have a personal copy of the production environment in work
    > > (unfortunately, the vm setup they gave me is more modern than the
    > > production environment). I can't just modify the production environment
    > > to match my setup without submitting reams of action plans and service
    > > requests etc and then I'm not so sure it's a compelling enough reason
    > > for them. Catch my meaning?
    > >
    > > So I guess what I'm looking for here is not so much an alternative
    > > solution/workaround in CODE as an EXPLANATION of this discrepancy and,
    > > hopefully, a workaround in my SYSTEM to rectify the discrepancy (i.e.
    > > IIS settings, server settings, etc)
    > >
    > >
    > > Steven Burn wrote:
    > > > Can't you server.mappath before supplying the AX with the name of the

    > file?
    > > > (i.e. pass the whole path)
    > > >

    >
    >
    >
     
    Seth Darr, Apr 18, 2006
    #7
  8. Seth Darr

    Steven Burn Guest

    So you always have to buy more buns ;o)

    > At the risk of sounding like a broken record... why why why? Why does it
    > suffice to specify the relative path from the executable in one

    environment
    > and not the other?


    Because it's a different environment? (unless the envir's are the same, the
    behaviour is rarely going to be same).

    > How do you find out where its being instantiated and
    > subsequently control it (not through code, but system settings)?


    Unless it is explicitly told otherwise, it's always being instantiated in
    the dir in which it is called (in this case, the dir of your script).

    --
    Regards

    Steven Burn
    Ur I.T. Mate Group
    www.it-mate.co.uk

    Keeping it FREE!

    "Seth Darr" <> wrote in message
    news:...
    > At the risk of sounding like a broken record... why why why? Why does it
    > suffice to specify the relative path from the executable in one

    environment
    > and not the other? How do you find out where its being instantiated and
    > subsequently control it (not through code, but system settings)? Why do

    hot
    > dogs come in packs of 10 while hot dog buns come in packs of 12? etc.
    >
    > "Steven Burn" wrote:
    >
    > > The reason it's happening is that whilst the .dll and .ini file are in

    the
    > > same folder, the .dll is being instantiated from a completely different
    > > folder and thus, you need to tell it where to find the .ini file.
    > >
    > >
    > > --
    > > Regards
    > >
    > > Steven Burn
    > > Ur I.T. Mate Group
    > > www.it-mate.co.uk
    > >
    > > Keeping it FREE!
    > >
    > > "Seth Darr" <> wrote in message
    > > news:KzX0g.4729$ZW3.652@dukeread04...
    > > > Not really, the .ini's location is entirely independent of the web
    > > > file/folder structure. I could modify the asp page to send in a path

    to
    > > > the AX like you're suggesting (i.e. send in
    > > > "C:\WINDOWS\system32\upload.ini") but the whole point of this

    migration
    > > > is to have a personal copy of the production environment in work
    > > > (unfortunately, the vm setup they gave me is more modern than the
    > > > production environment). I can't just modify the production

    environment
    > > > to match my setup without submitting reams of action plans and service
    > > > requests etc and then I'm not so sure it's a compelling enough reason
    > > > for them. Catch my meaning?
    > > >
    > > > So I guess what I'm looking for here is not so much an alternative
    > > > solution/workaround in CODE as an EXPLANATION of this discrepancy and,
    > > > hopefully, a workaround in my SYSTEM to rectify the discrepancy (i.e.
    > > > IIS settings, server settings, etc)
    > > >
    > > >
    > > > Steven Burn wrote:
    > > > > Can't you server.mappath before supplying the AX with the name of

    the
    > > file?
    > > > > (i.e. pass the whole path)
    > > > >

    > >
    > >
    > >
     
    Steven Burn, Apr 18, 2006
    #8
  9. Seth Darr

    Seth Darr Guest

    I finally stumbled upon the solution that I was looking for on this: running
    the www service in IIS 5.0 Isolation mode
    (http://www.microsoft.com/technet/pr...2ba-39fc-4332-bdb7-a0d9c76e4355.mspx?mfr=true)

    From the article:
    "You must use IIS 5.0 isolation mode for applications that conflict with
    worker process isolation mode until the applications are modified.

    The following application characteristics conflict with worker process
    isolation mode:

    [...]

    • Requires Dllhost.exe: Applications that must be run in a Dllhost.exe
    environment can be run only in IIS 5.0 isolation mode because Dllhost.exe is
    not available in worker process isolation mode."

    In other word, ActiveX dlls. Works like a champ now. Maybe now the dreams
    will stop.

    Thanks, though, Steven, for your help.

    -Seth


    "Steven Burn" wrote:

    > So you always have to buy more buns ;o)
    >
    > > At the risk of sounding like a broken record... why why why? Why does it
    > > suffice to specify the relative path from the executable in one

    > environment
    > > and not the other?

    >
    > Because it's a different environment? (unless the envir's are the same, the
    > behaviour is rarely going to be same).
    >
    > > How do you find out where its being instantiated and
    > > subsequently control it (not through code, but system settings)?

    >
    > Unless it is explicitly told otherwise, it's always being instantiated in
    > the dir in which it is called (in this case, the dir of your script).
    >
    > --
    > Regards
    >
    > Steven Burn
    > Ur I.T. Mate Group
    > www.it-mate.co.uk
    >
    > Keeping it FREE!
    >
    > "Seth Darr" <> wrote in message
    > news:...
    > > At the risk of sounding like a broken record... why why why? Why does it
    > > suffice to specify the relative path from the executable in one

    > environment
    > > and not the other? How do you find out where its being instantiated and
    > > subsequently control it (not through code, but system settings)? Why do

    > hot
    > > dogs come in packs of 10 while hot dog buns come in packs of 12? etc.
    > >
    > > "Steven Burn" wrote:
    > >
    > > > The reason it's happening is that whilst the .dll and .ini file are in

    > the
    > > > same folder, the .dll is being instantiated from a completely different
    > > > folder and thus, you need to tell it where to find the .ini file.
    > > >
    > > >
    > > > --
    > > > Regards
    > > >
    > > > Steven Burn
    > > > Ur I.T. Mate Group
    > > > www.it-mate.co.uk
    > > >
    > > > Keeping it FREE!
    > > >
    > > > "Seth Darr" <> wrote in message
    > > > news:KzX0g.4729$ZW3.652@dukeread04...
    > > > > Not really, the .ini's location is entirely independent of the web
    > > > > file/folder structure. I could modify the asp page to send in a path

    > to
    > > > > the AX like you're suggesting (i.e. send in
    > > > > "C:\WINDOWS\system32\upload.ini") but the whole point of this

    > migration
    > > > > is to have a personal copy of the production environment in work
    > > > > (unfortunately, the vm setup they gave me is more modern than the
    > > > > production environment). I can't just modify the production

    > environment
    > > > > to match my setup without submitting reams of action plans and service
    > > > > requests etc and then I'm not so sure it's a compelling enough reason
    > > > > for them. Catch my meaning?
    > > > >
    > > > > So I guess what I'm looking for here is not so much an alternative
    > > > > solution/workaround in CODE as an EXPLANATION of this discrepancy and,
    > > > > hopefully, a workaround in my SYSTEM to rectify the discrepancy (i.e.
    > > > > IIS settings, server settings, etc)
    > > > >
    > > > >
    > > > > Steven Burn wrote:
    > > > > > Can't you server.mappath before supplying the AX with the name of

    > the
    > > > file?
    > > > > > (i.e. pass the whole path)
    > > > > >
    > > >
    > > >
    > > >

    >
    >
    >
     
    Seth Darr, Apr 19, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. tea-mad brit

    Form Require Hidden Input Not Working

    tea-mad brit, Jan 17, 2006, in forum: HTML
    Replies:
    5
    Views:
    1,587
  2. Replies:
    4
    Views:
    674
    Walter Roberson
    Sep 9, 2005
  3. Replies:
    1
    Views:
    501
    Patrice
    Jun 20, 2007
  4. Daniel Rudy
    Replies:
    5
    Views:
    1,281
    Jukka K. Korpela
    Aug 23, 2008
  5. Kurda Yon
    Replies:
    3
    Views:
    1,634
    Harlan Messinger
    Oct 10, 2008
Loading...

Share This Page