Asp.Net client / server debugging issue

I have loaded / reloaded / booted /rebooted and basically gone nuts for the last few days.

Home Network. 4 computers, Linksys Router. The two important computers have Windows XP Pro (SP2) .. Visual Studio .NET 2003. All latest updates SP's .. whatnot's

Web Server running Windows 2000 server, with IIS 5.0 and SQL Server 2000. This is where my Web App source is and where I want to run / debug things from.

I have loaded IIS, .Net 1.0 (sp3), .Net 1.1 (sp1).
I have inserted my VS CD and updated the components on the server, as well as installing Server components and Debugging from the CD.

I have run aspnet_regiis -i and registered the dll.

I can now .. finally run vs.net on my computer and actually create a new web app. I can even run this app (without debugging) and it appears just fine.

Whenever I try to debug it .. it says "Error while trying to run project: Unable to start debugging on the web server. Access is denied. Yes, I have integrated Windows Authentication checked.

I have read, that I need to have my user account registered in the "Debugger Users" and "VS Developers" group.

Here is the rub. I am running a WorkGroup and not a domain. Each workstation has it's own users defined. When selecting a user .. which user should I select?? The users group on the win2k server is a "local" group and does not contain the user I logged on to my XP station. What user does VS.NET logon as? I have tried "everyone" and that has made no difference.

When I first started I couldn't create a page, or run a page (debugged or not). I know I am close but still no resolution.

That looks similar to the error message I always get when I try to debug. The work-around I use:

I right-click on the module that contains the user-interface and select debug. Try it--pretty simple and it can't hurt.

cudabean

Burrick, did you find the solution to this problem?

A terrible problem. I wouldn't wish this one upon my worst enemies. :(

Of the many possibilities, try deleting the bin folder, and rebuilding the solution.

Make sure all the 'appropriate' permissions are set on the virtual directory.

Yeah, it seems to be a widespread problem with many causes :(

your deletion idea didn't do the trick, darn. Im logged in as an administrator & debugger so i have the appropriate permissions.

No, no, I meant... execute, read, write, script source access, everything (in the VD's properties).

If that all fails, backup your content, delete the virtual directory and actual directory... restart IIS, create the VD again, set full permissions on everything you can think of, copy the content over again, and try running it. You can then start filtering down from there.