Change in MapPath in ASPNET2?

[Mark Olbert]

I'm running into a repeatable oddity in porting a bunch of ASPNET1.1 websites to ASPNET2. Calls like this:

MapPath("/path/fromroot")

result in exceptions under ASPNET2, but worked fine under ASPNET1.1.

Changing the calls to:

MapPath("~/path/fromroot")

makes them work again under ASPNET2.

Is this a design change? Or perhaps an artifact of using the "bundled" webserver in VS2005? I used to debug on a test server that
was separate from my development machine. Now, under VS2005, I do everything on the development machine.

- Mark

 

[Steven Cheng[MSFT]]

Hi Mark,

Thanks for posting.

AS for the Server.MapPath function, I think the code logic of it should not
have been changed from ASP.NET 1.1 to 2.0. What's the detailed exception
message you get when call the Mappath function with the "/path/fromroot"
value or is this a machine or application specific issue?

As for "/path/fromroot" and "~/path/fromroot", they're two definite
different path. The former path start from the IIS web site's root while
the latter start from the ASPNET application's application root. Therefore,
it may result different results. Is it possible that some other code logic
in the application which use the Mappath's result cause the problem?

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Mark Olbert]

Steven,

I posted elsewhere that the problem is in the way the silly testing server embedded in VS2005 handles websites. It runs all sites in
what amounts to a virtual directory of the server, for example:

Website destined to be the site for www.scef.us

Runs under embedded development server as http://local:1114/scef

See the problem? It should be running as http://local:1114, not http://local:1114/scef.

This is a big problem for anyone developing "root" websites under VS2005.

- Mark

 

[Steven Cheng[MSFT]]

Thanks for your response Mark,

As for the VS buildin test server, it is actually provided by the .NET
framework 2.0 in the framework dir

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

named "WebDev.WebServer.EXE". And as you mentioned, vs 2005 ide do by
default treat each ASP.NET website project as a sub virtual dir under the
root site when running them in test server. Like:

http://localhost:xxxx/ApplicationName/xxx

However, the VS 2005 ide also allow us to use the customized external test
server. You can right click your website's node in solution explorer and
choose properties menu. In the "Start options" setting, it is "use default
web server" by default, we can change it to "use custom server". For the
"Base Url", we can input the custom server's configured url we want to use,
such as
"http://localhost:7001/"

For the custom server, we can just use the WebDev.WebServer.EXE which can
be launched externally from command line. For example, the following
command just start the Test Server which point to my vs 2005 ASP.NET
website project's project folder and configure it as Root applcation(rather
than a sub virtual directly under root):

webdev.webserver /port:8088
/path:"D:\users\stcheng\workspace\whidbey\websites\TestWebSite" /vpath:"/"

this will match the custom server's "Base Url" we configured in the ASP.NET
project above.

In addition, here is a blog article from ScottGu which have more detailed
description on this:

http://weblogs.asp.net/scottgu/archive/2005/11/21/431138.aspx

Hope this helps.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Mark Olbert]

Steven,

It does help, but (and this is certainly not your issue) I think it's pretty dumb of MS to have released something that has such a
gotcha in it.

- Mark

 

[Steven Cheng[MSFT]]

Thanks for response.

Yes, currently it would be a limitation of the VS 2005 ide which will make
our work a bit more complex.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)