In web technology we are all quite awarw and accustomed to the postback feature of web pages. in ASP.NET 1.1 we could achieve it using any of different ways like Response.Redirect,Server.Transfer,Server.Execute,

,__doPostBack .

 

ASP.NET 2.0 introduces a completely new feature called cross page postback. Usually web pages posts back only to  itself. However in cross page postback a web page post back to another page.

 

Though both Server.Transfer and Server.Execute served this purpose, both had its limitations.I'll not discuss taht in detail here (read I also need to find out :) )

 

Corss page post back starts with setting a PostBackUrl for a button.

 

<asp:Button ID="btnCrossPage" runat="server" PostBackUrl="~/page2.aspx" Text="Click Me" />

 

just note that we do not need to add click event to this button. The client side Javascript that is generated is not the ususal __doPostback , instead its WebForm_doPostBackWithOptions function.

 

When the page posts back it creates another hidden field for the PreviousPage (__PREVIOUSPAGE ). This contains all the state of  Page1.

 

in Page2 we can always access this using PreviousPage.

 

We can also check cross page postbacks by

 

 

 

 

 

Exception Handling In Web Services

 

            Web Services are a relatively new way to achieve distributed computing. Moreover the advent of SOA has made the importance of web services  even more imminent. Because Web services provide a platform-independent of way of leveraging a specific functionality, the exceptions that occur in the Web Services must also be communicated in a platform-independent manner. To accomplish this, you need to make sure that the exceptions raised from the Web services are compliant with the SOAP specification. The standard way to raise exceptions from a Web Service is representing a SOAP fault.

 

Raising Exceptions From A Web Service

 

Handling exceptions in a Web service is no different than handling exceptions in a Web or Windows application. However, when designing exception blocks in Web services, you need to be aware of the fact that you need to communicate the exception information to the consumers of your Web service in a platform-independent manner based on the SOAP specification. To accomplish this, you should use the SoapException class that abstracts the complexities of the SOAP fault creation process. The SoapException class consists of the following properties that need to be populated before throwing the exception to the consumers.

• Message—Contents of the exception
• Code—Enum constant that specifies the type of Fault code (e.g. ClientFaultCode, ServerFaultCode)
• Actor—URL of the Web service method where the exception has occurred
• Detail—Detail element can be used to communicate more information about the exception to the callers

A Sample Implementation of a Web Service

 

[WebMethod]

public bool AddCategories(string xml)

{

try

  {

    using(SqlConnection conn = new SqlConnection())

    {

      if (ValidateXml(xml))

      {

        XmlDocument doc = new XmlDocument();

        doc.LoadXml(xml);

         ..

        ...

        // more code here        

      }

else

        throw

          RaiseException("AddCategories",

          "http://tempuri.org/CategoriesService",

 builder.ToString(),"2000","AddCategories",FaultCode.Client);

    }

    return true;

  }

  catch (SoapException soapEx)

  {

    throw soapEx;

  }

  catch(Exception ex)

  {

    EventLog.WriteEntry("Test",ex.Message);

    throw

      RaiseException("AddCategories",

      "http://tempuri.org/CategoriesService",ex.Message,

      "1000",ex.Source,FaultCode.Server);

  }

}

 

 

The above piece of code implements a error handling in a WebService. Walking through the code would make the scenario even more clear. The validateXML method validates the xml. If validated , it is ok otherwise an exception is raised using the custom method RaiseException. The RaiseException method is basically a helper method that encapsulates the code required for raising SoapException from the Web service. The last parameter of the RaiseException method is an enum constant that is defined as follows.

public enum FaultCode

{

    Client = 0,

    Server = 1

  }

Failure of the XML validation indicates that the client has supplied an invalid XML data. In this case, we should indicate this to the client application by setting the enum constant to Client. This makes it possible for us to indicate that the client application needs to check the format of the input data before invoking the Web service method again. If the Web service fails due to some other reason (for example, the non-availability of the database server), you need to set the enum constant to Server. This allows us to indicate that the Web service failed due to some problem in the server side and the client application can retry the request after a few seconds. In fact, in the catch block that catches the generic Exception, this is exactly we do.

Let us look at the code for the RaiseException method.

public SoapException RaiseException(string uri,

                                    string webServiceNamespace,

                                    string errorMessage,

                                    string errorNumber,

                                    string errorSource,

                                    FaultCode code)

{

  XmlQualifiedName faultCodeLocation = null;

  //Identify the location of the FaultCode

  switch (code)

  {

    case FaultCode.Client:

      faultCodeLocation = SoapException.ClientFaultCode;

      break;

    case FaultCode.Server:

      faultCodeLocation = SoapException.ServerFaultCode;

      break;

  }

  XmlDocument xmlDoc = new XmlDocument();

  //Create the Detail node

  XmlNode rootNode = xmlDoc.CreateNode(XmlNodeType.Element,

                     SoapException.DetailElementName.Name,

                     SoapException.DetailElementName.Namespace);

  //Build specific details for the SoapException

  //Add first child of detail XML element.

  XmlNode errorNode = xmlDoc.CreateNode(XmlNodeType.Element,"Error",

                                        webServiceNamespace);

  //Create and set the value for the ErrorNumber node

  XmlNode errorNumberNode = 

    xmlDoc.CreateNode(XmlNodeType.Element,"ErrorNumber",

                      webServiceNamespace );

  errorNumberNode.InnerText = errorNumber;

  //Create and set the value for the ErrorMessage node

  XmlNode errorMessageNode =xmlDoc.CreateNode(XmlNodeType.Element,

                                              "ErrorMessage",

                                              webServiceNamespace);

  errorMessageNode.InnerText = errorMessage;

  //Create and set the value for the ErrorSource node

  XmlNode errorSourceNode = 

    xmlDoc.CreateNode(XmlNodeType.Element,"ErrorSource",

                      webServiceNamespace);

  errorSourceNode.InnerText = errorSource;

  //Append the Error child element nodes to the root detail node.

  errorNode.AppendChild(errorNumberNode);

  errorNode.AppendChild(errorMessageNode);

  errorNode.AppendChild(errorSourceNode);

  //Append the Detail node to the root node

  rootNode.AppendChild(errorNode);

  //Construct the exception

  SoapException soapEx = new SoapException(errorMessage,

                                           faultCodeLocation, uri,

                                           rootNode);

  //Raise the exception  back to the caller

  return soapEx;

}

As the name suggests, the RaiseException method is used to raise exceptions from the Web service in the form of a SoapException object. The code shown above starts off by inspecting the value contained in the FaultCode enum parameter that is used to indicate the source of exception. If an exception occurs due to problems in the server side (for example, the database server is down), you would then set the value of FaultCode to SoapException.ServerFaultCode. After that, it creates an XmlDocument object to hold the contents of the detail element. It adds all the child elements under the detail element and then passes the detail node to the constructor of the SoapException object. Finally it returns the SoapException object back to the caller by using the return statement. If you inspect the detail element inside the SoapException object, it should look somewhat similar to the following.

<detail>

        <Error xmlns=" http://tempuri.org/CategoriesService /">

          <ErrorNumber>1000</ErrorNumber>

          <ErrorMessage>Exception Information</ErrorMessage>

          <ErrorSource>Exception Source</ErrorSource>

        </Error>

</detail>

 

Handling Exceptions on the Client Side

 

private void btnInvoke_Click(object sender, System.EventArgs e)

{

  try

  {

    Categories cat = new Categories();

MessageBox.Show(cat.AddCategories("<?xml version='1.0'?>

       <Categories xmlns='http://tempuri.org/CategoriesNamespace'>

       <Category><CategoryName>Test Category</CategoryName>

       <CategoryDescription>Test Category Description

       </CategoryDescription></Category></Categories>").ToString());

  }

  catch(SoapException soapEx)

  {

    MessageBox.Show(soapEx.Code.ToString());

    //Load the Detail element of the SoaopException object

    XmlDocument doc = new XmlDocument();

    doc.LoadXml(soapEx.Detail.OuterXml);

    XmlNamespaceManager nsManager = new

      XmlNamespaceManager(doc.NameTable);

    // Add the namespace to the NamespaceManager

    nsManager.AddNamespace("errorNS",

      "http://tempuri.org/CategoriesService");

    XmlNode categoryNode =

      doc.DocumentElement.SelectSingleNode("errorNS:Error",

                                           nsManager);

    string errorNumber = 

      categoryNode.SelectSingleNode("errorNS:ErrorNumber",

                                    nsManager).InnerText;

string errorMessage = 

  categoryNode.SelectSingleNode("errorNS:ErrorMessage",

                                nsManager).InnerText;

string errorSource = 

  categoryNode.SelectSingleNode("errorNS:ErrorSource",

                                nsManager).InnerText;

    MessageBox.Show("Error Number is" +  errorNumber);

    MessageBox.Show("Error Message is" + errorMessage);

    MessageBox.Show("Error Source is" + errorSource);

  }

  catch(Exception ex)

  {

    MessageBox.Show(ex.Message);

  }

}

 

Let us walk through the above lines of code.

We start by creating an instance of the Categories class. After that, we invoke the AddCategories method of the Categories class by passing in the required XML string as an argument. Then, we have a catch block to handle the SoapException raised from the Web service. In this block, we display the source of the exception in a message box. We do this by using the Code property of the SoapException object. The Code property will be set to Client if the exception is caused by an invalid input from the client. If the exception is caused by the Web service code (for example, the database server is down), the Code property will be set to Server.

Then we load the XML data contained in the Detail element of the SoapException object to an XmlDocument object. Similarly to the Web service code, here also we utilize the XmlNamespaceManager object to associate the namespace with the XmlDocument object. Then, we retrieve the values contained in the individual elements and assign them to local variables. Finally, we display the values contained in the local variables using message boxes.

Advantages Of Using SoapException

 

• Allows us to handle the exceptional conditions in a consistent fashion
• Based on the SOAP specification
• By explicitly raising the SoapException, it is possible to communicate more information, such as the reason for the exception, URL of the Web service method, and so on (using properties such as Actor, Code, and Detail)
• Use of FaultCode to clearly convey the cause for the exception—Due to client or server
• Use of the Detail property to give a detailed description of the exception information

  

 NB: This content has been taken from diff websites. I've just been the compiler.However I've I've also tried to add very little what I could.

Generics has been a new introduction to .NET 2005. As it is with any technology, it is helpful to ask just why it's useful. As with any new technology, it is helpful to ask just why it's useful. Folks who are familiar with C++ will find generics more freindly.However Generics has its own benifits. They are

 

1. Type Safety 

         

Suppose you have written a method that takes in objects and returns back objects when you need them. For example an user adds a String collection of type SortedList,there occurs an implict cast to Object.Similarly if a String object is retrieved from the List another phase of casting takes place at runtime, this time from object reference to String reference.This results in a lack of type safety during complile time and also incurs the overheads of unnecessary boxing and unboxing. Instead a GenericSortedList<T> is always a better option.

 

example::

 

ArrayList items = new ArrayList();
items.Add("a string");
items.Add(123);
items.Add(this);

 

whereas using Generics

 

ist<string> items = new List<string>();
items.Add("a string");
items.Add(123);  // Compile time error!!
items.Add(this);  // Compile time error!!

 

2. Binary Code ReUse

 

For maintenance purposes, a developer may elect to achieve compile-time type safety using SortedList by deriving a SortedListOfStrings from it. The problem with this approach is that new code has to be written for every type for which you want a type-safe list, which can quickly become laborious. With GenericSortedList<T>, all you need to do is instantiate the type with the desired element type as T. As an added value, generics code is generated at run time.

 

3. Performance

 

Consider the example of point (1). If type checking is done during compile time , rather than during run time ,the performance of the application improves.In addition to that, I've already mentioned that the boxing and unboxing process also results in a  loss of application performance.I've read that using Generics instead, will achieve a 20% increase in application performance.

 

 

Happy Reading....

 

 

     

Steps are as follows:

 

Step 1

Create a Solution (Class Library) with C# or VB in Visual studio .NET 2005.

 

Step 2

Add class to it. To execute a method from Sql Server 2005 store procedure we need to do the following configuration in the C# code level.

·        The method will be executed from the store procedure should implement the custom attribute Import “Microsoft.SqlServer.Server.SqlProcedure”.

·        The method will be executed from the store procedure should be in a class, that class should import the following namespaces

o       System

o       System.Data

o       Microsoft.SqlServer.Server

o       System.Data.SqlTypes

 

Step 3

Just build that dll from the project

 

Step 4

Open the Microsoft Sql Server Manager Studio

 

Step 5

Open a new query

 

Step 6

Create Assembly <Assembly Name> from <Full path of the dll> with PERMISSION_SET=Safe

 

Step 7

Create Procedure <Procedure Name>

As

External <Solution Name>.<Class Name>.<Method Name>

 

Step 8

Execute the Procedure it will return the result

 

 

N.B.:- On execution of the procedure, if you get any error message ‘clr is not enable’.

Please execute the following lines

sp_configure 'clr enabled', 1

go

reconfigure

go

 

Execute the procedure again.

 

 

Step 9

To drop the procedure execute

 

Drop Procedure <Procedure Name>

 

Step 10

To drop the assembly executes

 

Drop Assembly <Assembly Name>