Uri.MakeRelative() Different Results

  • Thread starter Thread starter Steve - DND
  • Start date Start date
S

Steve - DND

We're currently working on a project with v1.0 of the .Net Framework, and
are experiencing some issues with System.Uri. We have two Uri objects:

Uri uriBase = new Uri("http://localhost/VirtualDirectory/");
Uri uriDestination = new
Uri("http://localhost/VirtualDirectory/SomeFile.aspx");

When we do uriBase.MakeRelative(uriDestination) on one machine we end up
with "SomeFile.aspx", and on another machine we end up with
"../VirtualDirectory/SomeFile.aspx". Both of these are technically correct,
but it's been quite irritating since we now have to write code to deal with
both instances. Any thoughts on what is going on here? Is there some setting
somewhere to indicate how relative URLs are handled?

Thanks,
Steve
 
Even looking at the IL for the method it is strange why it does this. Are
you sure the same version of .NET is on both machines? You haven't applied
service packs to only one of the machines and you haven't accidentally
upgraded to V1.1?
 
Steve said:
We're currently working on a project with v1.0 of the .Net Framework, and
are experiencing some issues with System.Uri. We have two Uri objects:

Uri uriBase = new Uri("http://localhost/VirtualDirectory/");
Uri uriDestination = new
Uri("http://localhost/VirtualDirectory/SomeFile.aspx");

When we do uriBase.MakeRelative(uriDestination) on one machine we end up
with "SomeFile.aspx", and on another machine we end up with
"../VirtualDirectory/SomeFile.aspx". Both of these are technically correct,
but it's been quite irritating since we now have to write code to deal with
both instances. Any thoughts on what is going on here? Is there some setting
somewhere to indicate how relative URLs are handled?
Click to expand...

Are you sure that there's not a space, null, or some other easy
-to-overlook character embedded in the base URI on the machine that
you're seeing strange results on? You might get that unwittingly if
you're building up the uriBase by concatenating various bits from
configuration file or user input, for example.

Look at what happens if there's a space in the baseUri:

===========================================================
static void Main(string[] args) {
Uri uriBase = new Uri("http://localhost/VirtualDirectory/");
Uri uriBase2 = new Uri("http://localhost/VirtualDirectory /");

Console.WriteLine( "uriBase = \"{0}\"", uriBase.AbsoluteUri);
Console.WriteLine( "uriBase2 = \"{0}\"", uriBase2.AbsoluteUri);
Console.WriteLine( "uriBase2 = \"{0}\"", uriBase2.ToString());

Uri uriDestination = new
Uri("http://localhost/VirtualDirectory/SomeFile.aspx");

Console.WriteLine( "URL relative to uriBase: \"{0}\"",
uriBase.MakeRelative(uriDestination));
Console.WriteLine( "URL relative to uriBase2: \"{0}\"",
uriBase2.MakeRelative(uriDestination));
}
===========================================================

The results look similar to what you're getting:

uriBase = "http://localhost/VirtualDirectory/"
uriBase2 = "http://localhost/VirtualDirectory /"
uriBase2 = "http://localhost/VirtualDirectory /"
URL relative to uriBase: "SomeFile.aspx"
URL relative to uriBase2: "../VirtualDirectory/SomeFile.aspx"
 
Are you sure that there's not a space, null, or some other easy
-to-overlook character embedded in the base URI on the machine that
you're seeing strange results on? You might get that unwittingly if
you're building up the uriBase by concatenating various bits from
configuration file or user input, for example.
Click to expand...

I figured this out today. It turns out that I was living in my
case-insensitive Windows world, and was expecting the URI's to be treated as
such. The reason this was occurring was that my favorite to the development
site was saved with the proper casing, whereas the other developer's
favorite was saved with improper case. After I found this out it completely
made sense, since in a case-sensitive environment ala UNIX or Linux,
http://somedomain.com/VIRTUALDIRECTORY and
http://somedomain.com/VirtualDirectory are two very different locations.
After taking the Uri, and converting it to lowercase, and doing the same
with the comparison Uri everything worked as expected.

Thanks,
Steve
 
Back
Top