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 (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.

Solution

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.

Comments

[John Adams]

@ztech - thanks for your answer. As you may have picked up, I don't normally work with Cassini. I'm trying it because I've had terrible times trying to wedge an ASP.NET "web site" under IIS 5.1 into VSourceSafe control. My boss thinks the SVN "working copy" folders should be on a network drive where we all have read-access but each developer has his own subfolder with full-control. Using IIS Manager (INETMGR) I tried to configure a site with the content coming from a "share located on another computer". VirtDirectory wizard finishes but it is marked as "ERROR" (red icon). Hence I tried Cassini

[3Dave]

GRRR. bosses. I've added a comment to my post above.

[John Adams]

@ztech - I understand your points about the SVN model vs. SourceSafe,etc. To clarify about the "central working copy" idea though: here the thinking was to divide up a central folder on a network share into "private" subfolders - one for each developer - partly to be reassured that "work in progress" was part of a regular backup scheme off a network drive (rather than on individual's desktop). I think part of this problem is due to IIS 5.1 does NOT allow me to put content files on a share on another computer (I see IIS 6.0 allows this though).

[3Dave]

Another option would be to have the developers check their code into a person-specific branch within SVN every night. TFS has a concept called "shelving" that allows you to store your changes overnight without affecting the main development trunk, but I'm not sure how to to that in svn. Good luck!