.Net Solutions

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

2008-07-14T23:49:00.000-07:00

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

2008-07-06T21:01:00.000-07:00

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>

2008-07-06T20:46:00.000-07:00

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

Explicit Support for Service-Oriented Development

2008-06-12T23:09:00.000-07:00

Creating applications in a service-oriented style is becoming the norm. For this to happen, the platforms on which those applications are built must provide the right support for creating service-oriented software. Achieving this is one of WCF’s most important goals.

Thinking of an application as providing and consuming services is hardly a new idea. What is new is a clear focus on services as distinct from objects. Toward this end, WCF’s creators kept four tenets in mind during the design of this technology:

n Share schema, not class. Unlike older distributed object technologies, services interact with their clients only through a well-defined XML interface. Behaviors such as passing complete classes, methods and all, across service boundaries aren’t allowed.

n Services are autonomous. A service and its clients agree on the interface between them, but are otherwise independent. They may be written in different languages, use different runtime environments, such as the CLR and the Java Virtual Machine, execute on different operating systems, and differ in other ways.

n Boundaries are explicit. A goal of distributed object technologies such as Distributed COM (DCOM) was to make remote objects look as much as possible like local objects. While this approach simplified development in some ways by providing a common programming model, it also hid the inescapable differences between local objects and remote objects. Services avoid this problem by making interactions between services and their clients more explicit. Hiding distribution is not a goal.

n Use policy-based compatibility. When possible, determining which options to use between systems should rely on mechanisms defined in languages such as WSDL and WS-Policy. The ability for a client to consume a service is based on the intersection of what the client supports and what the service supports.

Service-oriented applications are the successor to the multi-tier applications of the last decade. As the architectural style continues to spread, this approach is becoming the default for a large share of new software. WCF is the foundation for service-oriented applications built on the .NET Framework, which makes it a mainstream technology for Windows-based software.

Building AJAX Enabled File Uploading System with Progress Bar Using ASP.NET 2.0

2008-05-21T22:18:00.000-07:00

Uploading files using ASP.NET Framework 1.0 / 2.0 / 3.0 is pretty easy. Without much error handling, all we need is a couple of lines of code to upload a file to the web server. AJAX is playing a greater role these days in every webpage that pops up. Uploading files using ASP.NET AJAX is not a straight forward one. Those who do know about AJAX, it is used to update some portions/sections of a web page without affecting other sections. In other words, if you do want to refresh your web page on a button click but you still want to update the content of your web page, then you should use AJAX.

In this article we will see how to upload files using ASP.NET and AJAX. We will also see how we can display a message, "Please wait … Upload in progress," during an upload is taking place. Displaying a "Wait message" always helps the user to know what is really going on; otherwise, users will have to wait and will not be sure what is going on until the upload is done.

Common Aspects

In order to use AJAX in ASP.NET we need to have a minimum of ASP.NET 2.0 Framework and AJAX Extensions 1.0 for ASP.NET.

In order to upload a file using AJAX, we are in need of the following main Web Server controls:

1. FileUpload Server Control

2. Button Server Control

Apart from the above, we need to specify the usual AJAX tags ScriptManager, UpdatePanel and ContentTemplate so that during run time the ASP.NET AJAX will know which section of the web page needs to be updated. Let us take a look at the code which uses the above:

Listing 1

1 <html>

2 <head>

3    <title>File Uploadtitle>

4 head>

5 <body>

6 <form id="form1" runat="server">

7    <asp:ScriptManager ID="ScriptManager1" runat="server"/>

8    <asp:UpdatePanel ID="UpdatePanel1" runat="server">

9        <ContentTemplate>

10           <asp:FileUpload ID="myFile" runat="server" />

11           <asp:Label ID="lblMsg" runat="server">asp:Label>           

12           <asp:Button ID="btnUpload" runat="server" Text="Upload">

13        ContentTemplate>

14   asp:UpdatePanel>

15 form>

16 body>

17 html>

In the above code Line 7, 8 and 9 are the ones which specify which part of this web page needs to be updated. The FileUpload control and the Button control are within the AJAX UpdatePanel control.

You might think that when the user clicks the submit button, the page will be submitted to the server. Well, this is not true. The above code will not work. The reason is that FileUpload control does not work with asynchronous post backs, and therefore does not work from within an AJAX UpdatePanel. In simple words, the FileUpload control is not posted back to the server.

Triggers

To resolve the above issue, we need to use the Trigger code block. Triggers allow us to force a post back. For an upload to happen, we need to access the FileUpload control in the server. In the following code snippet you can see how to include the Triggers block. We are invoking a PostBackTrigger. The control that will be forced to post back is “btnUpload.” Triggers block can be found in Lines 9, 10 and 11.

Listing 2

1 <html>

2 <head>

3    <title>File Uploadtitle>

4 head>

5 <body>

6 <form id="form1" runat="server">

7    <asp:ScriptManager ID="ScriptManager1" runat="server"/>

8    <asp:UpdatePanel ID="UpdatePanel1" runat="server">

9       <Triggers>

10           <asp:PostBackTrigger ControlID="btnUpload" />

11       Triggers>

12       <ContentTemplate>

13           <asp:FileUpload ID="myFile" runat="server" />

14           <asp:Label ID="lblMsg" runat="server">asp:Label>           

15           <asp:Button ID="btnUpload" runat="server" Text="Upload"

OnClick="UploadFile" />

16        ContentTemplate>

17   asp:UpdatePanel>

18 form>

19 body>

20 html>

The above code is now capable of doing a postback to the server. All we need is to write the usual code that we write for file upload inside the server side method UploadFile. This is the method which is invoked when the submit button “Upload” is clicked. The code will look like the following (written in C#).

Listing 3

Displaying a "Please Wait …" Message during an Upload

To display the "Please Wait … Message" we need to use the UpdateProgress control. The UpdateProgress control that we will be using for our upload will be as follows:

Listing 4

<asp:UpdateProgress ID="UP" runat="server" AssociatedUpdatePanelID="UpdatePanel1">

<ProgressTemplate>

<asp:Label ID="lblWait" runat="server" Text="Please wait..">asp:Label>

ProgressTemplate>                         

asp:UpdateProgress>

Each time the submit button is clicked the web page will be posted back to the server. You would think that you will see the message, “Please wait.” Well again, we need to look at one more aspect before we can see the “Please wait” message during a file upload.

We need to write a client side JavaScript function that will change the visibility of the UpdateProgress during the post back. The JavaScript will look like:

Listing 5

<script language="javascript" type="text/javascript">

function showWait()

{

    if ($get('myFile').value.length > 0)

    {

        $get('UpdateProgress1').style.display = 'block';

    }

}

script>

The function showWait will have to be invoked during the form submission. In our scenario that would be the OnClientClick event for the button control.

Listing 6

<asp:Button ID="btnUpload" runat="server" Text="Upload"

OnClick="UploadFile" OnClientClick="javascript:showWait();"/>

The complete code listing for both AJAX File Upload and Please Wait message is as follows:

<%@ Page Language="C#" AutoEventWireup="true"%>

<html>

<head>

<script runat="server">

protected void UploadFile(object src, EventArgs e)

{

    if (myFile.HasFile)

    {

        string strFileName;

        strFileName = myFile.FileName;

       myFile.PostedFile.SaveAs(Server.MapPath(".") + "//" + strFileName);

    }

}

script>



<script language="javascript" type="text/javascript">

function showWait()

{

    if ($get('myFile').value.length > 0)

    {

        $get('UpdateProgress1').style.display = 'block';

    }

}

script>

    <title>File Uploadtitle>

head>

<body>

<form id="form1" runat="server">

    <asp:ScriptManager ID="ScriptManager1" runat="server"/>

    <asp:UpdatePanel ID="UpdatePanel1" runat="server">

        <Triggers>

            <asp:PostBackTrigger ControlID="btnUpload" />

        Triggers>

        <ContentTemplate>

            <asp:FileUpload ID="myFile" runat="server" />

            <asp:Label ID="lblMsg" runat="server">asp:Label>           

            <br />

            <asp:Button ID="btnUpload" runat="server" Text="Upload"

                OnClick="UploadFile" OnClientClick="javascript:showWait();"/>          

            <asp:UpdateProgress ID="UpdateProgress1" runat="server"

                AssociatedUpdatePanelID="UpdatePanel1">

                <ProgressTemplate>

                    <asp:Label ID="lblWait" runat="server" BackColor="#507CD1"

                        Font-Bold="True" ForeColor="White"

                        Text="Please wait ... Uploading file">asp:Label>

                ProgressTemplate>

            asp:UpdateProgress>

        ContentTemplate>

    asp:UpdatePanel>

form>

body>

html>