PassMark Logo
Home » Forum

Announcement

Collapse
No announcement yet.

Folder for index files and ASP.NET search page.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Folder for index files and ASP.NET search page.

    I've got Zoom working in an ASP.NET application by putting the files generated by the Indexer in a folder named "Zoom", along with an ASPX file that uses the Zoom Search ASP.NET control. This works, but I'd prefer to put the index files in the App_Data folder and the ASPX file in another folder along with the rest of my pages. This doesn't appear to work, since the page that includes the ASP.NET control apparently has to be in the same folder as the index files.

    Is there any way to put the index files in a different folder than the search page and point the ASP.NET control to the folder containing the index files? By setting a property, for instance?

  • #2
    The ASP.NET server control expects the index files to be in the working directory. I am not aware of any setting in IIS to change this per application, but if you can do that, it might work.

    Having said that, I don't quite see the need to move these files around as you suggested. Generally, we try to minimize factors that can lead to confusion and broken setups, as there are already so many other things to look out for when hosting server controls. Could you clarify why you needed to move these files to your other folders, it would help us see what may benefit our users more.
    --Ray
    Wrensoft Web Software
    Sydney, Australia
    Zoom Search Engine

    Comment


    • #3
      I want to move the index files to the App_Data folder because that is the intended folder for various data store files (like a local database or indexed search results). By default, files in the App_Data folder are not viewable over the web. It's part of the default ASP.NET folder structure, see also here. Themes go in one folder, pages go in another, and data goes in App_Data.

      The current implementation of the ASP.NET server control requires me to put local data (the index files) in the same folder as the search page, which by default makes the index files viewable over the web (which compromises security as people can simply download them and view whatever data is within them) and just messes up the file and folder layout, among others. If I could set an optional parameter on the control pointing it to a local file path, I'd be able to put the index files wherever I want. By default it could simply point to the working directory, making it backwards compatible with the current version.

      Comment


      • #4
        That all makes sense. The "App_Data" folder scheme was apparently introduced in ASP.NET 2.0.

        Having said that, it's (typically Microsoft) not particularly special and a little unusual in the world of web applications - preventing files from being downloaded can be achieved just as well via the web.config file in IIS. In this case, you just need to block access to all *.zdat files in the folder.

        The trouble for us is that we develop a package which must work on so many different platforms (PHP, ASP, ASP.NET, JS, and CGI). And naturally, the more singular the design, the better it is to both develop and provide support for (and also not confuse users by having drastically different instructions and requirements per platform).

        So that's why we expect files in the same folder at the moment. We may change this in the next version because we do want to provide a better ASP.NET solution (though I can already half anticipate a large group of users getting confused and putting the files in the wrong folders already). Or perhaps, as you suggested, we just need to provide an option to point the control at the location of the index files. We'll put this in our list of things to consider for V7.

        In the meantime, take a look at using the web.config file to block access to *.zdat files in the same folder.
        --Ray
        Wrensoft Web Software
        Sydney, Australia
        Zoom Search Engine

        Comment

        Working...
        X