603 - Web.config

Coordinator
Oct 19, 2013 at 12:50 AM
Edited Oct 19, 2013 at 1:11 AM
Anyone knows why web.config is required in the CSS or JS/Javascript folder in 603? Like if you delete this file in the folder mentioned, you will basically loose your CSS and Javascript in your page.

You'll have an error like this if you debug it in the browser debugger:
Caught .NET exception, source: <B>MAIN.PRG</B> 00001d7t0008 err#= 1 line= 67 File does not exist.1
File does not exist.
.NULL.
.NULL.
.NULL.
.NULL.
.NULL.
C:\inetpub\wwwroot\bootstrap\activevfp.dll message: C:\inetpub\wwwroot\bootstrap\activevfp.dll
Developer
Oct 23, 2013 at 5:50 PM
Edited Oct 23, 2013 at 5:59 PM
Hi apaustria,

In case you are still searching for the answer, I'll send what I discovered, when I was trying to activate the debugger in Ver 603, outside of the AVFPHandler. I was just waiting for someone with more ken of AVFP to reply. Anyway, I hope it helps you with your problem and/or anyone who may be thinking of making the debugger work inside the AVFPHandler.

1) All the subfolders in AVFP web site inherit the configuration information from the Web.config files, currently placed in root of AVFP .

2) Now, since we use custom handlers, we have to specify the file types, that will be allowed to be accessed directly by the browser. For all other file types, , the custom handlers must first read the files and then it will serve them to the browser.

This is currently specified in our main Web.Config file as follows
     <handlers>
      <add verb="*" path="*.avfp"
        name="AVFPHandler"
        type="AVFPHandler"/>
      <add verb="*" path="*"
        name="AVFPRESTHandler"
        type="AVFPHandler"/>
    </handlers>
3) Obviously the above will create problems in our AVFP pages which call on images/css files directly from client browsers ( e.g. <img src="images/comany-icon.png" />
). since these can only be accessed only from server side, by either AVFPHandler or AVFPRESTHandler and both these do not have the wiring to handle these type of files.

Currently, AVFP breaks this custom handler 'inheritance' by placing a web.config file with the following.
        <handlers>
            <remove name="AVFPRESTHandler" />
            <remove name="AVFPHandler" />
        </handlers>
All the files in these folders and it's subfolder would therefore, now, be able to be called directly from the avfp pages.

4) If you do not like multiple web.config files and want to remove them, then you can open them to outside world, from root web.config file too.

You just need to delete these web.config files in subfolders and change the root web.config as follows.
     <handlers>
      <add verb="*" path="*.avfp"
        name="AVFPHandler"
        type="AVFPHandler"/>
      <add verb="*" path="*"
        name="AVFPRESTHandler"
        type="AVFPHandler"/>
      <add verb="*" path="images/*.*"
        name="AVFPRESTHandlerImages"
        type="AVFPHandler"/>
      <add verb="*" path="css/*.*"
        name="AVFPRESTHandlercss"
        type="AVFPHandler"/>
      <add verb="*" path="debugger/Activate.debg"
        name="AVFPRESTHandlerDebug"
        type="AVFPHandler"/>
    </handlers>
5) This is going little off track, but would be of interest to those wondering what Activate.dbg does. It is a page that activates XXXX.exe using scripting and redirects back to calling page. This 'exe' then simulates IIS and traces the Handlers outside on IIS COM. Obviously, this is a fake IIS and allows local debugging only. What we need is hooking into VFP.application object directly.

If you think I am way off the mark, very likely, you are correct.

Thanks.

Another point.. I personally like separate Web.config files approach, since we can setup more configurations per folder.
Coordinator
Oct 25, 2013 at 11:07 PM
Titu1,

Thank you again for the explicit explanation, Titu1. Your feedback here in this forum is greatly appreciated.

I guess my frustration lies within the transition of upgrading websites from 553 to 603. First observation was the HTML folder was not included anymore (obviously it was by default that the pages are now scattered in the root as AVFP pages). At one point I think I tried to add the HTML folder and try to access but to no avail (because web.config is not present). Then my issue with the CSS/Images folder (where I discovered that web.cofig is needed)

These simple but critical information should in my opinion be in the documentation as well. Right now the documentation is mostly the for the "working" upgrade from 553 to 603 (i.e. REST;Extensionless page).

Anyway, I will try to add the explanation to the documentation (crediting you of course) with regards to the web.config. I just need to figure out how can I modify it.
Oct 27, 2013 at 3:04 AM
Yes, totally agree apaustria,

The help Titu1 brings to this site is unvaluable, He has knoledge in diferent areas, and knows how adapt and fix many things.

I hope AVFP can count with him for a long time.
Coordinator
Oct 27, 2013 at 7:44 AM
Edited Oct 27, 2013 at 7:44 AM
It looks like I put the web.config in there so the CSS would still work normally with the HTTP Handler (the mechanism that allows anything with a .avfp to work).

Regarding Documentation, I think I can add you as a Hosting Account Administrator to thetechconsult.com web site at GoDaddy where the Documentation is hosted. That way you can modify it.

I'm open to other suggestions also.

The Documentation is an HTML file so to host it directly here at CodePlex seems problematic since the HTML would have to be modified to work with how Codeplex works...
Developer
Oct 28, 2013 at 12:22 AM
Edited Oct 28, 2013 at 12:32 AM
Hi apaustria

I may have a simple solution to your following problems.
First observation was the HTML folder was not included anymore (obviously it was by default that the pages are now scattered in the root as AVFP pages). At one point I think I tried to add the HTML folder and try to access but to no avail (because web.config is not present). Then my issue with the CSS/Images folder (where I discovered that web.cofig is needed)
Just change the 'root' Web.Config from
     <add verb="*" path="*"
        name="AVFPRESTHandler"
        type="AVFPHandler"/>
(i.e. tie down all file types and folders/subfolders, to custom AVFPHandler.)

...to....
     <add verb="*" path="*."
        name="AVFPRESTHandler"
        type="AVFPHandler"/>
(i.e. tie down only the 'extentionless calls' to AVFPHandler).


What this means, I think, is that you will now be able to add a 'HTML' subfolder(?) and access those HTML files as ~/avfpRoot/htmlsubfolder/Myhome.html.

Also, other file types (i.e. css, png, gif, etc) , will continue to be handled by the default ASP handler, as is normal and would not require any separate copy of web.config.
I think this would also allow all default asp processes (debug asp worker processes??maybe??) as normal.

The only problem is if you have build anything on IIS server scripting . However, for our demo ASP does not have this problem... I think... or shall I say, I could not locate the places that need to tie down the entire avfp system to custom handlers, so not sure what could go wrong by opening avfp up to asp defaults.