I just made sense of something you said in the 'Relative URL' Topic. That the way to make a local environment compatible with cheap shared hosting is to change the Home Directory path for the default web site from(probably) c:\inetpub\wwwroot
to the root of ThePhile app. In my case, E:\Webs\ThePhileCS . Then http://localhost/ will pull up my highest level default.aspx. That sounds like the simplest and most elegant solution. My global variable idea sounds trickier.

For the sake of understanding...any virtual directory whose Local Path is not set to an absolute path, will not be accessible via localhost because it will no longer point towards these web apps, right? Not to mention that I can't open one of these Solutions in VS because the absolute C:/Inetpub/wwwroot/webappfolder doesn't resolve to localhost/webappfolder as is required.
I'll be happy if this is the solution. It's a pretty serious concern for anyone trying to deploy a site...which is most of us.
FYI, I noticed the interesting behavior of how relative paths in User Controls get resolved, as opposed to relative paths set to somecontrol.NavigateURL property

I've been thinking...
For the past two years I've used Copy Project in VS.NET to deploy my site that was run as a Virtual Directory locally, and it worked without me thinking about these 'relative URL' issues. One caveat, I believe my 10 pages were all in the root project folder, so it was simpler than ThePhile.

In terms of setup, the only difference from this ThePhile app that I know of is that the virtual root(like "/thePhile/") was never prepended to any path in my pages. My URLs were like "href="search.aspx". So isn't an even simpler solution to just get rid of these virtual/app root paths from all links in ThePhile?

Seems like the two IIS configurations would handle the downstream paths successfully in there own way:

App Root locally with virtual directory: "http://localhost/ThePhile/"
App Root on shared hosting: "http://www.ThePhile.com/

and everything downstream plays nicely!
Am I right?

Thanks,
Glenn

>For the sake of understanding...any virtual directory whose Local Path is not set to an absolute path, will not be accessible via localhost because it will no longer point towards these web apps, right?

No, this isn't true. Any folder that is a virtual dir will still be a virtual dir if you change your virtual root location. The web dirs don't have to be a contiguous tree like they do in Windows.

>Not to mention that I can't open one of these Solutions in VS because the absolute C:/Inetpub/wwwroot/webappfolder doesn't resolve to localhost/webappfolder as is required.

This is a separate issue. You need to check out the .sln files to see where VS thinks the paths should be. Open it in Notepad and have a look.

> isn't an even simpler solution to just get rid of these virtual/app root paths from all links in ThePhile?

It's simple if it works. Did you notice the DB fields that have pathnames, and the pathnames in the user controls and HTML code? You can make all this work with relative names if you want, but that's the harder solution. It's probably the best solution.

>Seems like the two IIS configurations would handle the downstream paths successfully in there own way...

Yes, if you use relative pathnames and if you fixed all those areas I mentioned above. It's not terribly difficult, just time consuming.

Eric

[ME]>For the sake of understanding...any virtual directory whose Local Path is not set to an absolute path, will not be accessible via localhost because it will no longer point towards these web apps, right?

[YOU]No, this isn't true. Any folder that is a virtual dir will still be a virtual dir if you change your virtual root location. The web dirs don't have to be a contiguous tree like they do in Windows.
----
Right, it's still a virtual dir, but if I create a WebApplication1 project and I let VS create it, by default the WebApplication1 folder will be created in C:\inetpub\wwwroot\WebApplication1. Then if I change the Home Dir Local Path to E:\Webs\ThePhileCS, in order to browse to my WebApplication1, I'd have to more the real WebApplication1 folder to the E: path from the C: path, because IIS does look for the web app in the HDLPath + virtual dir local path...correct? Am I not getting something?

I think I understand what you're saying. Just look in the .sln and project files with Notepad. You can easily modify the webpath of any existing projects or solutions.

Eric

OK, I've got the same problem, I switched those around and still have the same problem. However, if I do a check on the page redirect to from the login (in the page load event) to see if the Context.User is a PhilePrincipal (which it never is) and proceed to set it again as a PhilePrincipal (just as I did in the login form), it works fine. Is there a reason it won't work on the login page (done in the click event of the button - just like in the book)? I'm just learning the .NET web stuff after being in PHP, so its quite a change for me. Perhaps I'm doing something silly?

Some code (Note that the if (!(Context.User is RLISPrincipal)) line always equates to false (Context.User is not of type RLISPrincipal):

// Load event of page redirected to from Login page
private void Page_Load(object sender, System.EventArgs e)
{
     // Put user code to initialize the page here

     if (Context.User.Identity.IsAuthenticated)
     {
        if (!(Context.User is RLISPrincipal))
    {
        IPredicateExpression filter = new PredicateExpression();
        filter.Add(PredicateFactory.CompareValue(EmployeeF ieldIndex.Username, ComparisonOperator.Equal,Context.User.Identity.Nam e));

        EmployeeCollection employees = new EmployeeCollection();
                    employees.GetMulti(filter);

        EmployeeEntity employee = new EmployeeEntity(employees[0].EmployeeNumber);

        RLISPrincipal newUser = new RLISPrincipal(employee, employee.Password);
        Context.User = newUser;
    }

    RLISIdentity id = (RLISIdentity) Context.User.Identity;
                Label1.Text = "Logged in: " + id.Name;
     }

}

// Click event of Login button on Login page
private void cmdLogin_Click(object sender, System.EventArgs e)
{
     RLISPrincipal newUser = RLISPrincipal.ValidateLogin( txtUsername.Text, txtPassword.Text );
    if (newUser == null)
    {
        txtLoginResult.Text = "Invalid Username or Password";
            txtLoginResult.Visible = true;
    }
    else
    {
        Context.User = newUser;
        FormsAuthentication.SetAuthCookie( txtUsername.Text, false );
        Response.Redirect("RLISMainMenu.aspx");
    }
}

Did you descend from the custom base page?

This is what my code looks like in Page_Load for all restricted pages:

if (!Context.User.Identity.IsAuthenticated ||
!((PhilePrincipal)Context.User).HasPermission((int )AccountsPermissions.CreateRoles))
{
  // if not, redirect to the Login page
  Response.Redirect("/WebModules/Accounts/Login.aspx?ShowError=true", true);
}

Told you. Something silly. Thanks.

OK, I got that working on my first page and all was fine and dandy. Now I create another page exactly the same way, and when I go to access my user object (PhilePrincipal), I get a null reference. Further, I added the code in that you have above, and I get an invalid cast for the PhilePrincipal cast of Context.User. I am using the baseclass and the code is virtually the same. It works on one page, but not the other. The only difference I can see between the pages is that the page that doesn't work is in a subdirectory, but I can't see how that would affect it. I'm starting to miss my PHP.

I am having the same problem. I have swapped the two around but still am unable to access the page. The Cast error has now lost me 3 evenings of my time!