403 - Forbidden

[kcunningham]

I am setting up a new build on a Win2K3 machine and getting a 403-Forbidden when trying to access the web project file. I have read these forums and tried a couple suggestions but nothing seems to work and some of the posts are really old and may or may not pertain to my version of Visual Build.

This is a summary of the setup:
1. Running Visual Build 5.4
2. Web Project location is in a non-default location, 2 deep. For example, E:\Projects\RootWeb\MyWebApp -> http://localhost/RootWeb/MyWebApp.
3. I have mapped a virtual directory to the above path.
4. I have made all files writable.
5. I have verified that the .csproj mapping exists in IIS.
6. I can build the solution fine if I open up the solution manually.
7. I have opened up the ACLs for Everyone, VS Developers, NETWORK, NETWORK SERVICE, *_USR.
8. VS.NET 2003, .NET 1.1 SP1
9. Not doing any versioning manipulation of any files within VisualBuild (i.e. Versions tab)

Are there any other things I should try?

Visual Build Professional 5.4
Registered to: xxxxxxxx ( removed )
Windows Version: 5.2.3790.0.0
Install path: C:\Program Files\VisBuildPro
cmax20u.dll version 2.1.0.21
SftTree_IX86_U_45.dll version 4.5a
unins000.exe version 51.13.0.0
VisBuildBld.dll version 5.4.0.2
VisBuildCmd.exe version 5.4.0.2
VisBuildCore.dll version 5.4.0.3
VisBuildDotNET.dll version 5.4.0.5
VisBuildExt.dll version 5.4.0.3
VisBuildLog.dll version 5.4.0.2
VisBuildMisc.dll version 5.4.0.3
VisBuildMS.dll version 5.4.0.3
VisBuildNet.dll version 5.4.0.2
VisBuildPro.exe version 5.4.0.5
VisBuildSvr.dll version 5.4.0.3

Kevin

[kinook]

I'm not sure exactly how you set things up, but the following worked here:

Initial setup and test:
1) Added the Application Server role to a clean Windows 2003 install (enabling FP server extensions and ASP.NET).
2) Installed VS.NET 2003.
3) Installed VBP 5.6b.
4) Opened VS.NET and created a C# ASP.NET Web App named MyWebApp.
5) Successfully built the new project in VBP via the Make VS.NET action, specifying the sln file (C:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\MyWebApp\MyWebApp.sln) or project file (http://localhost/MyWebApp/MyWebApp.csproj).

Method #1:
6) Copied the project + source code files from c:\inetpub\wwwroot\MyWebApp to c:\Projects\RootWeb\MyWebApp.
7) Deleted the VS.NET-created MyWebApp virtual directory from IIS.
8) Created a virtual directory MyWebApp pointing to c:\Projects\RootWeb\MyWebApp (see attached project).
9) Deleted C:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\MyWebApp; created a new blank solution at the same location; added c:\inetpub\wwwroot\MyWebApp\MyWebApp.csproj to the solution.
10) Repeated #5 successfully.

Method #2:
11) Deleted the MyWebApp virtual directory from IIS.
12) Created a virtual directory RootWeb pointing to c:\projects\RootWeb.
13) Manually tweaked C:\Documents and Settings\Administrator\My Documents\Visual Studio Projects\MyWebApp\MyWebApp.sln to point to http://localhost/RootWeb/MyWebApp/MyWebApp.csproj
14) Successfully built the project in VBP via the Make VS.NET action, specifying the sln file or project file (http://localhost/RootWeb/MyWebApp/MyWebApp.csproj).

Does that work for you?

[kcunningham]

Ok, I think I know what the problem is but not sure how to fix it. There is another vdir that I forgot to mention in the previous post. So the url is really http://localhost/Rootweb/anothervdir/MyApp .

When I am setting up my environment I am certain to setup this vdir. I have verified that. Not to mention that VS.NET can find my web project fine via the solution and it build fine. But it appears the probing done through VPB doesn seem to find it.

This is the folder structure:
/RootWeb/
/AnotherVdir/
/AnotherVDir/MyApp

The Vdirs (RootWeb, AnotherVDir, Mypp) map directly on top of these.

The kicker is when I tweak the web project URL and vdirs to the 2 vdir setup it builds fine. So,

http://rootWeb/MyApp = WORKS!
http://rootWeb/AnotherVDir/MyApp = NO WORKIE!


Does this happen for you too?

Kevin

[kinook]

I didn't quite follow all of that. The bottom of this help topic describes how VBP attempts to locate web projects:
http://www.visualbuild.com/Manual/?v...olutiontab.htm

Another option is to avoid web projects altogether:
http://www.pluralsight.com/fritz/Sam...b_projects.htm

[Stuart]

I have two web projects one that compiles correctly the other does not. I am completely perplexed at why this is. I have read all the forums about 403 errors and have no success with any of the solutions. The virtual directories are both created in the same way through the build script so I know this is not the issue. I can compile both the projects through the Visual Studio 2003 IDE as well as with devenv.com.

Poking around ISS, I found out the working project sends a completly different message than the one that is broken.

Here is the IIS log file for the working and broken projects:

The working project sent the following commands to IIS
time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer)
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /FPWebApplication_web_2_0/vs-162371276429733858_tmp.htm - 200 0 256 177 0 HTTP/1.1 localhost Microsoft-Visual-Studio.NET/7.10.3077 - -
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /_vti_inf.html - 200 0 2008 262 0 HTTP/1.1 localhost Mozilla/2.0+(compatible;+MS+FrontPage+4.0) - -
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /FPWebApplication_web_2_0/_vti_bin/shtml.dll/_vti_rpc - 405 1 4253 412 0 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /_vti_inf.html - 200 0 2008 262 0 HTTP/1.1 localhost Mozilla/2.0+(compatible;+MS+FrontPage+4.0) - -
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /_vti_bin/shtml.dll - 200 0 506 387 109 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:30:36 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /_vti_bin/shtml.dll - 200 0 522 435 0 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:30:55 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /FPWebApplication_web_2_0/get_aspx_ver.aspx - 404 0 3232 190 18843 HTTP/1.1 localhost Microsoft-Visual-Studio.NET/7.10.3077 - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /FPWebApplication_web_2_0/vs-133433776429733858_tmp.htm - 200 0 257 177 0 HTTP/1.1 localhost Microsoft-Visual-Studio.NET/7.10.3077 - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /_vti_inf.html - 200 0 2008 262 0 HTTP/1.1 localhost Mozilla/2.0+(compatible;+MS+FrontPage+4.0) - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /FPWebApplication_web_2_0/_vti_bin/shtml.dll/_vti_rpc - 405 1 4253 412 0 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /_vti_inf.html - 200 0 2008 262 0 HTTP/1.1 localhost Mozilla/2.0+(compatible;+MS+FrontPage+4.0) - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /_vti_bin/shtml.dll - 200 0 506 387 32 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:31:05 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 POST /_vti_bin/shtml.dll - 200 0 522 435 15 HTTP/1.1 localhost MSFrontPage/4.0 - -
19:31:23 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /FPWebApplication_web_2_0/get_aspx_ver.aspx - 404 0 3232 190 18141 HTTP/1.1 localhost Microsoft-Visual-Studio.NET/7.10.3077 - -

while the one that fails sends this to ISS
19:31:51 127.0.0.1 - W3SVC1 SSMITH 127.0.0.1 80 GET /FPUserAdmin_web_2_0/FPUserAdmin.csproj - 403 0 2319 73 16 HTTP/1.1 localhost - - -

I am using clear case dynamic view for my builds

[kinook]

Which version/SP of Windows are you running? Try unzipping and running (from a Command Prompt) the attached test program on each project. To determine the values to pass, open the .sln file in a text editor and extract the name and URL from the Project line:

For instance,
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MyWebApp", "http://localhost/MyWebApp/MyWebApp.csproj", "{87215A73-B136-4ED2-9F93-1E16563ACD3F}"

would translate to
TestVirDir "http://localhost/MyWebApp/MyWebApp.csproj" "MyWebApp" > output.txt

Then post or send to support@kinook.com the output file for each project. Thanks.

[SteveC]

I'm evaluating VBP and this has come up for me as well. Was this problem ever resolved?

I'ved used VBP at 2 other jobs but only for VC6 and VB6. I wanted to see how well it worked for .NET before recommending a purchase.

[kinook]

There have been changes since v5 related to how the Make VS.NET action maps web project URLs to local filenames, and it worked in our testing. Attached is an updated version (v6.1 code) of the mentioned test program. Call it like

TestVirDir "http://localhost/dir/projfile.csproj" > output.txt

and post or send output.txt, along with the info from Help | About | Install Info, the .bld and .sln file, and a build log file. Thanks.

[kinook]

Forgot the attachment.

[SteveC]

All of the requested files are in the attached zip.

Note: the test program you sent threw an exception every time for me. The output.txt that I'm sending was piped from stderr.

Thanks.

[kinook]

It seems as though your user account doesn't have the necessary rights to access the IIS metabase (via the DirectoryEntry class), which the action needs to access to resolve the project's HTTP path to a local path.

The code that I suspect is failing is approximately:

using System.DirectoryServices;

DirectoryEntry root = new DirectoryEntry("IIS://localhost/W3SVC");
foreach (DirectoryEntry site in root.Children)
{
// ...
}

I do get that error when running the test program off of a network path, but not locally (with an admin user on a plain vanilla Win2K SP4+VS 2003 virtual machine). I'm not exactly sure which permission controls this (anybody out there know?).

[SteveC]

I was running it from a network drive. It worked when I copied it to the server. Sorry about the confusion.

The output is attached.

[kinook]

So where is the .csproj file actually located?

[SteveC]

Sorry, cut and paste hiccuped. The actual location is here:

C:\Healthvision\Clinical_Apps\ObjectSource\Web\HEA LTHvision\webroots\carevision\secure\WebApps\bin\H EALTHvision.AutoPrint.Admin

[kinook]

Looks like we weren't processing nested virtual directories properly. The main download has been updated with a patch for this issue (VisBuildDotNET.dll version 6.1.0.1).