How To Make Application and Directory-Specific Configuration Settings in an ASP.NET Application

Use the Location Element in the Machine.config File

To specify settings that apply to a Web application or
directory, you can add the <location> element to the <configuration> element of a system Machine.config file. This is useful when
you centralize configuration settings in a single file. This is also useful in
Web-hosting environments to mandate specific configuration settings on
individual Web applications.

The <location> element contains two attributes, path and allowOverride. The path
configuration settings cover. To specify that the settings in the <location> element apply to the default Web site, set the path attribute to Default Web Site. To specify that
the settings apply to the application that is named MyApp in
the default Web site, set the path attribute to "Default Web Site/MyApp".


When the allowOverride attribute is false, the Web.config files in the Web application directories cannot
override the settings that you specified in the <location> element. This is a useful setting in environments where you must
restrict application developers in how they configure a Web application. The
following example shows a part of a Machine.config file that requires
authentication to access the MyApp application on the default Web site and that
cannot be overridden by settings in a Web.config file: attribute defines the site or virtual directory that the

<configuration>

  <location path=”Default Web Site/MyApp” allowOverride=”false”>
      <system.web>
          <authorization>
              <allow users=”?” />
          </authorization>
      </system.web>

  </location>
</configuration>

Use the Location Element in the Web.config File

To specify settings that apply to a specific application or
directory, add the <location> element to the <configuration> element of an application Web.config file. The <location> element typically contains a <system.web> element and other configuration elements exactly as you use
them in the Web.config file. The path attribute of the <location> element specifies the virtual directory or the file name
where the location configuration items apply. The following example shows part
of an application Web.config file that specifies custom error messages for the
forum virtual directory.

<configuration>

  <location path=”forum” >
      <system.web>
          <customErrors mode="RemoteOnly” defaultRedirect="forum-error.aspx">
              <error statusCode="404" redirect="forum-file-not-found.aspx" />
          </customErrors>
      </system.web>

  </location>
</configuration>

Changing parent window's URL from IFRAME content

If you want to control parent window's URL from a child iframe, you can't use variable destination how you would use that for frames because tag <> doesn't have this property.

Also you can't change parent.document.location variable because this variable is read-only for child iframes.

To solve this problem, you need to define a javascript function at parent window and call it from iframe window. Here's an example how to change parent window's URL:


Parent window's content:

<>iframe starts here< /b >


< src="'iframe1.html'">< / iframe>




iframe ends here

< type="text/javascript">
function change_parent_url(url)
{
document.location=url;
}
< /script >

Iframe's content:

IFRAME content

< style="font-family: arial;" href="javascript:parent.change_parent_url('http://yahoo.com');">
Click here to change parent URL < /a>

If you’ve done much ASP.NET AJAX development, you’re no doubt familiar with JavaScript alert errors similar to the one pictured above. This particular one occurs on the official ASP.NET forums in FireFox, if you try to navigate away from viewing a user profile before the Recommended Reading panels asynchronously load.

Not only is the error message of “…” completely meaningless, but it blocks your intended navigation away from the page until you’ve dismissed the alert window. Hopefully, someone at Telligent will read this, because the ASP.NET AJAX framework gives us an easy way to replace the annoying JavaScript alerts and vastly improve the usability of our applications.

Some “exceptional” code

First, we’ll need some code to throw exceptions to test with:

protected void Button1_OnClick(object sender, EventArgs e)
{
throw new Exception("AJAX Error!");
}

This throws a server side error when Button1 makes an asynchronous callback. If Button1 is clicked, we’ll get a JavaScript alert:

Handling the exception
The key to custom error handling in ASP.NET AJAX is the EndRequestEventArgs class, available when handling the endRequest event. It provides information on any error conditions that have resulted and exposes a method to let the framework know that we’ve handled the errors on our own.

I’m going to add a div, to serve as our replacement error message:

An error has occured while trying to process your request.

Next, some CSS to style the div and close button:

#Error {
top: 0px;
right: 0px;
width: 125px;
background-color: yellow;
border: solid 1px Black;
padding: 10px;
font-family: Sans-Serif;
font-size: 10pt;
position: absolute;
margin: 5px;
}
#CloseButton {
float: right;
cursor: pointer;
}

Finally, we need to add some JavaScript to tie it all together:

Sys.Application.add_load(AppLoad);

function AppLoad()
{
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequest);
Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(BeginRequest);
}

function BeginRequest(sender, args) {
// Clear the error if it's visible from a previous request.
if ($get('Error').style.visibility == "visible")
CloseError();
}

function EndRequest(sender, args) {
// Check to see if there's an error on this request.
if (args.get_error() != undefined)
{
// If there is, show the custom error.
$get('Error').style.visibility = "visible";

// Let the framework know that the error is handled,
// so it doesn't throw the JavaScript alert.
args.set_errorHandled(true);
}
}

function CloseError() {
// Hide the error div.
$get('Error').style.visibility = "hidden";
}

The crux of this method is EndRequestEventArgs.set_errorHandled(). This tells the AJAX framework to call off the dogs and prevents the JavaScript alert from being displayed. Now, clicking Button1 results in this:





We have complete control over the error display. No JavaScript alert!

source: encosia