Showing posts with label root. Show all posts
Showing posts with label root. Show all posts

25 August 2009

Yet another way to determine root paths in ASP.NET

How many times I have tried to find the root path of an ASP.NET page or a handler (ASHX) in order to call another URL I can hardly count. When working with WMS and WFS services and connected documents - when you call all kind of weird 'services' - it's something that needs to be done often. I decided to put a few in what seems to become my trade mark - extension methods. I created the following extensions to HttpContext
using System;
using System.Web;

namespace LocalJoost.Utilities.Web
{
  public static class HttpContextExtensions
  {
    public static string FullRootPath( this HttpContext context )
    {
      return context.Request.Url.AbsoluteUri.Split(
        new[] { context.Request.Url.AbsolutePath },
        StringSplitOptions.RemoveEmptyEntries)[0];
    }

    public static string FullApplicationPath(this HttpContext context)
    {
      return string.Concat(context.FullRootPath(), 
        context.Request.ApplicationPath);
    }
  }
}
In the Page_Load of an aspx page you can, for instance, use the methods as described below:
var r = Context.FullRootPath();
var a = Context.FullApplicationPath();
r will contain something like "http://localhost:3974" and a "http://localhost:3974/YourTestSite". Maybe there are simpler ways, but these work very well for me.

07 July 2009

Using the "global" prefix to prevent namespace clashes

I was running into a snag into the situation in which the compiler was accidentally took my local namespace when I wanted it to use the root namespace of CSLA. I had defined a dll "LocalJoost.Utilities.Csla" with the following code:
using Csla;
using Csla.Validation;

namespace LocalJoost.Utilities.Csla
{
  public static class LocalJoostCommonRules
  {
    public static bool NotNull(object target, RuleArgs args)
    {
      args.Description = string.Format("{0} is required", 
        args.PropertyName);
      var value = global::Csla.Utilities.CallByName(
       target, args.PropertyName, CallType.Get);
      return value != null;

    }
  }
}
and although I had referenced the Csla.dll nicely, it did not compile. The compiler errorred out telling me that "The type or namespace name 'Utilities' does not exist in the namespace 'LocalJoost.Utilities.Csla' (are you missing an assembly reference?)" Well of course does the namespace "LocalJoost.Utilities.Csla.Utilities" not exist: I wanted it to use "Csla.Utilities". I had created myself a nice namespace clash. Or kludge, whatever you want to call this. In stead of searching from the root of the namespace, the compiler started to search relatively from my namespace. Turns out this is very easy to fix: there is a .NET directive "global" that is the .NET equivalent of starting an URL with a "/". I changed my code to
using Csla;
using Csla.Validation;

namespace LocalJoost.Utilities.Csla
{
  public static class LocalJoostCommonRules
  {
    public static bool NotNull(object target, RuleArgs args)
    {
      args.Description = string.Format("{0} is required", 
        args.PropertyName);
      var value = global::Csla.Utilities.CallByName(
       target, args.PropertyName, CallType.Get);
      return value != null;
    }
  }
}
and the compiler was happy again. And so was I, incidently.