page is not served because it has been explicitly forbidden - extension .asp may be incorrect

Question

I'm trying to run a test version of a web using the File System (i.e. the "Cassini" web server built-in to Visual Studio 2005) rather than HTTP://localhost (IIS 5.1 on my Win XP dev PC). This web is a hodge-podge of classic ASP files written years ago and some new development in ASP.NET (VB.NET).

How can I get past this error message as it tries to go to /TestWeb/default.asp? -

Server Error in '/TestWeb' Application.
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly   forbidden.  The extension '.asp' may be incorrect.   Please review the URL below and make sure that it is spelled correctly.
Requested URL: /TestWeb/default.asp
Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082

Things I have checked and previously encountered trying to get this mess working:

1. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config (has nothing for *.asp nor HttpForbiddenHandler so nothing to comment out).
2. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config (has nothing for *.asp)
3. C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config (had a HTTPForbiddenHandler for *.asp but I commented it out as per other postings advice; seemed to have no effect for me though).
4. To get past an earlier error ("Request for the permission of type 'System.Web.AspNetHostingPermission' failed"), I had to go to "Administrative Tools > MS .Net Framework 2.0 Configuration > My Computer> Runtime Security Policy > change Local Intranet to Full Trust.
5. To get past an earlier error ("the network bios command limit has been reached") I had to "enable a hot fix" by adding the following DWORD value at the following registry key: HKLM\Software\Microsoft\ASP.NET\FCNMode and set the value to 1 (per MS KB Article 911272).

This whole web has been placed on a file server in our LAN and from my desktop VStudio2005 views it via the mapped drive letter (e.g. V:\SVNwork\myFolder\TestWeb)

Visual Studio 2005 models this as a "web site" (not a "web application project").

The remainder of this post describes some background about why I am trying this:

We tend to recreate the web site on our dev PC's which run IIS 5.1 on Win XP. Movement of new stuff into production can be awkward using WinDiff and copying files as needed.

I'm trying to implement source control over this work. I've had a heck of a time trying to configure Visual SourceSafe 2005 and local IIS to work together smoothly (interestingly, I had pretty good luck putting "web application projects" under VSS2005 so I think it's related to the awkwardness of the ASP.NET 2.0 "site" model and VSS).

Anyway, I've moved a development version of this classic ASP and ASP.NET to a common file server in our LAN. Before placing this under Subversion control as a working copy of it's equivalent imported into a repository, I just want to make sure it can work with the Cassini web server. That's where I am stuck. The ultimate goal is have this under SVN and view differences with TortoiseSVN.

Thanks for reading this far...hopefully someone can get me past this error and then I can move forward with the SVN and TortoiseSVN work.

Answer 1

Cassini doesn't, as far as I can tell, support classic ASP. An alternative would be to run a local install of Apache (since you can't/won't use IIS) which will host ASP, but is probably asking for trouble.

See also: http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx

You could also run local IIS, which will, of course, host both ASP.NET and classic ASP. Visual Studio can easily be configured to debug with a local IIS install.

Points for moving to subversion: we use the Microsoft stack (Visual Studio, ASP.NET, SQL Server) with subversion and it works very well.

Subversion comment GRRR.. bosses are fun. The svn model is known as copy/modify/merge. The repository lives in a central location - probably your file server. Using the svn client - or a Visual Studio plugin like the excellent AnkhSVN - each developer gets a LOCAL working copy,makes their changes and performs a "commit" when they're done working on a file.

SVN takes care of making sure that developers don't overwrite each others changes, provides a facility for merging changes when someone has modified a file between when you got your last copy and when you commit your changes, etc.

The whole point of a working copy is that it isolates developers from each other. The merge/commit step takes care of intergrating everyones changes. Having a central working copy that everyone works from defeats the purpose.

This is a very different approach than that used by Visual SourceSafe, which is basically a file locking mechanism. The fact that SVN is a real client-server application (where VSS is simply a disk-based "database" with no server app to administer it) provides all sorts of capabilities. We check out, modify, commit, then publish from svn to a dev server.

Also, if I remember correctly, Cassini won't server apps from a mapped drive.