Pre-compilation Tool. ASP.NET 2.0 delivers a new application deployment utility that enables both developers and administrators to precompile a dynamic ASP.NET application prior to deployment. This precompilation automatically identifies any compilation issues anywhere within the site, as well as enables ASP.NET applications to be deployed without any source being stored on the server (one can optionally remove the content of .aspx files as part of the compile phase), further protecting your intellectual property.

ASP.NET Compilation Tool (Aspnet_compiler.exe) 

The ASP.NET Compilation tool (Aspnet_compiler.exe) enables you to compile an ASP.NET Web application, either in place or for deployment to a target location such as a production server. In-place compilation helps application performance because end users do not encounter a delay on the first request to the application while the application is compiled.

Compilation for deployment can be performed in one of two ways: one that removes all source files, such as code-behind and markup files, or one that retains the markup files.

aspnet_compiler [-?] [-m metabasePath | -v virtualPath [-p physicalPath]] [[-u] [-f] [-d] [-fixednames] targetDir] [-c] [-errorstack] [-nologo] [[-keyfile file | -keycontainer container ] [-aptca] [-delaysign]]

The ASP.NET Compilation tool can be used in two general ways: for in-place compilation and compilation for deployment, where a target output directory is specified.

Compiling an Application in Place

The ASP.NET Compilation tool can compile an application in place, that is, it mimics the behavior of making multiple requests to the application, thus causing regular compilation. Users of a precompiled site will not experience a delay caused by compiling the page on first request.

Note that if you are using an impersonated account, both the account and the logon user account must have write access to the target for precompilation to succeed.

When you precompile a site in place, the following items apply:

·          The site retains its files and directory structure.

·          You must have compilers for all programming languages used by the site on the server.

·          If any file fails compilation, the entire site fails compilation.

You can also recompile an application in place after adding new source files to it. The tool compiles only the new or changed files unless you include the -c option.

Compiling an Application for Deployment

You compile an application for deployment (compilation to a target location) by specifying the targetDir parameter. The targetDir can be the final location for the Web application, or the compiled application can be further deployed.

Using the -u option compiles the application in such a way that you can make changes to certain files in the compiled application without recompiling it. Aspnet_compiler.exe makes a distinction between static and dynamic file types, and handles them differently when creating the resulting application.

Static file types are those that do not have an associated compiler or build provider, such as files whose names have extensions such as .css, .gif, .htm, .html, .jpg, .js and so on. These files are simply copied to the target location, with their relative places in the directory structure preserved.

Dynamic file types are those that have an associated compiler or build provider, including files with ASP.NET-specific file name extensions such as .asax, .ascx, .ashx, .aspx, .browser, .master, and so on. The ASP.NET Compilation tool generates assemblies from these files. If the -u option is omitted, the tool also creates files with the file name extension .COMPILED that map the original source files to their assembly. To ensure that the directory structure of the application source is preserved, the tool generates placeholder files in the corresponding locations in the target application.

You must use the -u option to indicate that the content of the compiled application can be modified. Otherwise, subsequent modifications are ignored or cause run-time errors.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Web Site Administration Tool

One of the new features for web developers in Visual Studio 2005 is a graphical administration tool for configuring common application and security settings for your web sites. The Web site Administration tool allows you to perform the following configuration tasks:

Configure application security, including authentication and authorization settings

Manage users and roles for your application

Create or manage application settings

Configure SMTP e-mail settings

Take an application temporarily offline, to allow reliable updates of content and data

Adjust debugging and tracing settings

Define a default custom error page

Select providers for use with site features such as membership

The Web Application Administration tool is available with all versions of Visual Studio 2005, and from Visual Studio 2005 Express Edition. To open the administration tool from a web site project, select ASP.NET Configuration from the Website menu.

Web Site Configuration

Web site configuration settings are stored in an XML file named Web.config, which is located in the root folder of the Web site. The Web Site Administration Tool lets you change your site configuration without having to manually edit the Web.config file. The first time that you use the Web Site Administration Tool to administer a specific Web site, if no Web.config file exists, the Web Site Administration Tool creates one. By default, the Web Site Administration Tool also creates a database in the App_Data folder of the Web site to store application services data, such as membership and roles information. For most settings, changes that are made in the Web Site Administration Tool take effect immediately and are reflected in the Web.config file. The Web Site Administration Tool features a tabbed interface that groups related configuration settings within each tab. The tabs and the configuration settings that the tabs manage are described in the following sections.

Security Tab

Use the Security tab to manage access rules to help secure specific resources within the Web site and to manage user accounts and roles.

You can specify how the Web site is used—either from the Internet (publicly) or from an intranet (on a local area network). This in turn indicates the type of authentication mode that the Web site will use. Internet Web sites use the ASP.NET membership system, where you define individual user accounts. ASP.NET uses a security system to restrict access to specific user accounts or the roles to which the user accounts belong. Intranet Web sites use Windows authentication, where users are identified by their Windows logon information.

Application Tab

Use the Application tab to manage a variety of settings related to the Web site, including the following:

Application settings, which are name/value pairs that you want to store centrally and access in code from anywhere in the Web site.

SMTP settings, which determine how your site sends e-mail.

Debug and trace settings.

Offline and online settings, which take the Web site offline (shut it down) to perform maintenance or to bring a new Microsoft SQL Server Standard edition database online.

Provider Tab

Use the Provider tab to test or assign providers for membership and role management for the Web site. Database providers are classes that are called to store application data for a particular feature. By default, the Web Site Administration Tool configures and uses a local Microsoft SQL Server Standard Edition database in the App_Data folder for the Web site. Instead, you can choose to use a different provider, such a remote SQL Server database, to store membership and role management.

Considerations

The following sections provide some considerations for working with the Web Site Administration Tool.

Restarting the Application When Saving

Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. This requires the Web site to which the change applies to be restarted. Because this will cause currently active sessions in the Web site to be lost, you should make configuration changes to a staged or development version of the Web site before publishing these changes to the production server.

Saving Your Settings

Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. For settings for which the Web Site Administration Tool interface has a dedicated Save button, leaving the Web Site Administration Tool idle or allowing the Web Site Administration Tool to time out before you click Save will cause your configuration settings changes to be lost.

Time Out

As a security measure, the Web Site Administration Tool times out after a period of inactivity. Any settings that did not take effect immediately and were not saved will be lost. If the Web Site Administration Tool has timed out, close your browser, and then reopen the Web Site Administration Tool in a new window.

The Web Site Administration Tool manages only some of the configuration settings that are available to the Web site. Many other settings require direct modification of configuration files either manually, by using the MMC Snap-In for ASP.NET, or programmatically, by using the ASP.NET Configuration API.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Normally when you link a file that file will always display inside of the browser because the browser loads it and automatically determines the content type based on the file extension. So when you click on a link like a jpg image the browser knows it's an image and will display that image. You can of course always use the browser short cut menu and use the Save Target As option to save the file to disk.

If you want to do this automatically when a link is clicked from the server side, you have to send the file back yourself rather and add a couple of custom headers to the output. The way to do this is to use Response.Transmit() to explicitly send the file from your ASP.NET application and then add the Content Type and Content-Disposition headers.

Check out this link for futher details and code snippet.

One new, important feature in ASP.NET 2.0 is the ability to read/edit the configuration files in local machine or remote machine. In ASP.NET 1.x, editing of the configuration files was not supported. Only option to edit a configuration file is to treat the configuration file as an xml file and update that xml file. The major drawback in this method is that you need to treat all the sections in the configuration file as XML Node, which is not strongly typed. Hence, you can do only string manipulation to update any configuration settings in that file. However, in ASP.NET 2.0 you have strongly typed API’s to read/edit the configuration files.   

This article series describes the various options available in ASP.NET 2.0 to read/edit the configuration files. The various options available to read/edit the configuration files are

1) Using ASP.NET Microsoft Management Console(MMC)

2) Using Web Site Administration Tool

3) Using Configuration API’sIn the first part of this article, I have explained about

Using ASP.NET Microsoft Management Console (MMC)

In ASP.NET 2.0, you can manage configuration file from IIS itself i.e. the configuration management API is integrated with IIS itself. This feature is available as Microsoft Management Console (MMC), which can be accessed from the properties settings of any website in. Using this console, administrator can modify both machine.config file and web.config file

A new ASP.NET tab is included in the IIS site properties window, In this tab, you can specify the version of asp.net for that web application. In previous release, if you want to change the aspnet.version for a web application, you need to use command line utility aspnet_regiis, which comes with .NET Framework. Now you can do this from IIS itself. If you want to edit machine.config, you can press Edit machine.config file button. Similarly, if you want to edit web.config file, you can press edit configuration. Both this button will invoke a separate window, which has option for editing various sections in config file as mentioned below.

1) General Tab – which contains the list of all the connection Strings with facility to Manage and add new. It also contains the App Settings section and displays both the Key and value.

2) Custom Error Tab – Custom Error Mode “Remote Only”, “On”, and “Off” option. Default redirect URL property with List of Inherited Custom errors and Local errors.

3)  Authorization Tab – Contains the various Inherited and Local Authorization roles with Allow / Deny options.

4) Authentication – Contains the properties to set the Authentication Mode and Cookie information in case of Forms Authentication. Also contains the Provider section to Configure Membership Providers and Role Providers.

5) Application Tab – Contains Common compilation, page and runtime settings like default language, default theme etc. Contains Globalization settings like encoding request and response information and identity settings.

6) State Management Tab – Contains the Session state settings like session mode, cookieless mode and SQL server settings in case of SQLServer session mode.

7) Locations Tab- contains the list of Locations and allow to add and manage the locations

One of the much requested feature in.Net Framework 1.1 is to update the .config file programmatically which has been included in .NET 2.0 as Configuration class. Other then Configuration class, now you have an option to edit the configuration file using MMC snap in and a web admin page. Even you can customize this web admin page for your application. With all these options, configuration is made simpler in .Net Framework 2.0.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Using Configuration API - Encryption

Encrypting an entire section of a configuration file is straightforward with the 2.0 configuration API. There are several configuration areas where sensitive information may appear, for instance, the <connectionStrings> section may contain database usernames and passwords, the <identity> section will contain a username and password when you need the runtime to impersonate a fixed identity. You may even keep a password for a third party web service in appSettings or a custom section. Whenever secrets like these appear, consider encrypting the section instead of leaving the secrets and passwords in plain text.

Note: there are sections that may contain passwords that you cannot encrypt, namely the <processModel> section. You can still use the Aspnet_setreg.exe tool to store a password for this section securely.

The following section of code shows how easy it is to protect (encrypt) and unprotect (decrypt) an entire configuration section. (Note: you do not need to unprotect a section in order to read configuration settings from the section. The runtime will read the encrypted data and perform the decryption necessary for your application to read the plain text values. The Unprotect method call is here to demonstrate how to return a section to unencrypted form).

protected void toggleEncryptionButton_Click(object sender, EventArgs e)

{

    Configuration config;

   config = WebConfigurationManager.OpenWebConfiguration("~");

    ConnectionStringsSection section;

    section = config.GetSection("connectionStrings")

                    as ConnectionStringsSection;

    if (section.SectionInformation.IsProtected)

    {

        section.SectionInformation.UnprotectSection();

    }

    else

    {

        section.SectionInformation.ProtectSection(

                "DataProtectionConfigurationProvider"

            );

    }

    config.Save();

    WriteMessage("connections protected = " +

                    section.SectionInformation.IsProtected);

}

If we were to examine our web.config file after toggling encryption to on, we’d notice the configuration API has added some additional information:

<?xml version="1.0"?>

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

  <protectedData>

    <protectedDataSections>

      <add name="connectionStrings"

           provider="DataProtectionConfigurationProvider"

           inheritedByChildren="false" />

    </protectedDataSections>

  </protectedData>

  <appSettings configSource="appSettings.config"/>

  <connectionStrings configSource="connections.config"/>   

  <system.web>

    <compilation debug="true" />

    <authentication mode="Windows"/>

    <identity impersonate="true"/>

  </system.web>

</configuration>

In addition, we’d find our connectionStrings.config file would contain a cipherValue instead of plaintext connection strings. (Note: we do not need to use an external configuration source to take advantage of encryption, the configuration API would have happily encrypted the connection strings section if it lived inside of web.config).

<connectionStrings>

<EncryptedData>

  <CipherData>

   <CipherValue>AQAAANCMnd8BF....</CipherValue>

  </CipherData>

</EncryptedData>

</connectionStrings>

At runtime, the configuration API will decrypt sections on the fly. We can still use WebConfigurationManager.ConnectionStrings to return connection strings usable by our application.

To understand what we are seeing in the configuration file, we first need to realize that the runtime turns to a configuration encryption provider for encryption and decryption work. The two providers shipping in .NET 2.0 are the DataProtectionConfigurationProvider and the RSAProtectedConfigurationProvider (you can also implement your own protected configuration provider if need be). We can specify the provider we want to use in the string passed to the ProtectSection method, as seen in the earlier source code snippet. In our example we are using the DataProtectionConfigurationProvider.

The DataProtectionConfigurationProvider uses the Windows Data Protection API (DPAPI) underneath the covers. This provider a machine-specific secret key for encryption and decryption work. Because the DataProtectionConfigurationProvider relies on a machine-specific key, you can only decrypt cipher text that was encrypted on the same machine.

If you need to move configuration files with encrypted sections from machine to machine, you’ll need the RSAProtectedConfigurationProvider. The RSAProtectedConfigurationProvider, as the name would imply, uses RSA public key encryption.

You can work with the RSAProtectedConfigurationProvider from the command line tool aspnet_regiis, which includes options to create a keypair (-pc), export a keypair (-px), import a keypair (-pi), grant access to a keypair (-pa), remove access (-pr), and more. Command line arguments also allow you to specify which encryption provider to use.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

If you want to register a script from server-side code and the script is not changed dynamically based on some logic and should not be executed directly after an async. postback, you can do it from your Page object. If you have a custom control that should register a script and you will always display the control, and the script should not be changed based on some logic between postback, you can use the Register method of the Page object (Use the ClientScript property of the Page object to get access to them.). If you have your control inside of an UpdatePanel, and need to register the script during an async. postback and the script will be changed based on some logic, then you need to use the ScriptManager's Register methods. But if the control is inside of an UpdatePanel from the start and the client-side script should always be the same, you can use the register methods of the Page object (as long as you should not register a client-side script that need to be executed after a postback).

Assume you have the following Page:

<body>
    <form id="form1" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server" />
        <div>
            <asp:UpdatePanel ID="UpdatePanel1" runat="server">
                <ContentTemplate>
                    <uc1:WebUserControl ID="WebUserControl1" runat="server" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>
    </form>
</body>

There is a User control inside of the UpdatePanel, the User Control have a TextBox with the Id TextBox1 and a Button that will do a postback. The Page_Load of the User control have the following code:

protected void Page_Load(object sender, EventArgs e)
{
   ScriptManager.RegisterClientScriptBlock(this, typeof(Page), "myKey", "alert('" + TextBox1.ClientID + "');", true);

   Page.ClientScript.RegisterClientScriptBlock(typeof(Page), "myKey2", "alert('" + TextBox1.ClientID + "');", true);
}

When the page is first loaded, two alerts will be displayed, one register by the ScriptManager and one register with the Page object. If we press the button located in the User Control, an async. postback will take place and only the script Registered by the ScriptManager will be executed, but the script for register with the Page object still exists on the page but will not be executed because it's not part of the partial update.

If you set the Visible property of the User control to false, the two registered script will still be executed because they are located in teh Page_Load method of the User control. But if you move the code to the CreateChildControl of the User Control, they will not be registered until the control is visible. If you have another control inside of the UpdatePanel that should display the User control (you add the control dynamically), only the script registered with the ScriptManager will be executed and the script register by using the Page object will not be added.

So if you want a script to be registered for a control located in the UpdatePanel, and the Script should always be updated, then use the ScriptManager. If you add a control dynamically during an async. postback, you also need to use the ScriptManager. If you don't add a control dynamically, you can register static scripts in the Page_Load of the control by using the Page object, but if the script code need changes during an async. postback, you should use the ScriptManager.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Administration and Management

ASP.NET 2.0 is designed with administration and manageability in mind. We recognize that while simplifying the development experience is important, deployment and maintenance in a production environment is also a key component of an application's lifetime. ASP.NET 2.0 introduces several new features that further enhance the deployment, management, and operations of ASP.NET servers.

Configuration API. ASP.NET 2.0 contains new configuration management APIs, enabling users to programmatically build programs or scripts that create, read, and update Web.config and machine.config configuration files.

ASP.NET MMC Admin Tool. ASP.NET 2.0 provides a new comprehensive admin tool that plugs into the existing IIS Administration MMC, enabling an administrator to graphically read or change common settings within our XML configuration files.

Pre-compilation Tool. ASP.NET 2.0 delivers a new application deployment utility that enables both developers and administrators to precompile a dynamic ASP.NET application prior to deployment. This precompilation automatically identifies any compilation issues anywhere within the site, as well as enables ASP.NET applications to be deployed without any source being stored on the server (one can optionally remove the content of .aspx files as part of the compile phase), further protecting your intellectual property.

Health Monitoring and Tracing. ASP.NET 2.0 also provides new health-monitoring support to enable administrators to be automatically notified when an application on a server starts to experience problems. New tracing features will enable administrators to capture run-time and request data from a production server to better diagnose issues. ASP.NET 2.0 is delivering features that will enable developers and administrators to simplify the day-to-day management and maintenance of their Web applications.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

ASP.NET 2.0 eliminates this problems with a built in site navigation feature which provides a consistent way for the user to navigate your website. The new site navigation system allows defining all the links at a central location file usually an XML file and display those links in lists or navigation menus in each required page using navigation-based server controls.

• Connection:  This indicates the SqlConnection instance that the transaction instance is associated with
• IsolationLevel: This specifies the IsolationLevel of the transaction

The following are the methods of this class that are noteworthy:
Commit()   This method is called to commit the transaction
Rollback()  This method can be invoked to roll back a transaction. Note that a transaction can only be rolled back after it has been committed.
Save()       This method creates a save point in the transaction. This save point can be used to rollback a portion of the transaction at a later point in time. The following are the steps to implement transaction processing in ADO.NET.

• Connect to the database
• Create a SqlCommand instance with the necessary parameters
• Open the database connection using the connection instance
• Call the BeginTransaction method of the Connection object to mark the beginning of the transaction
• Execute the sql statements using the command instance
• Call the Commit method of the Transaction object to complete the
  transaction, or the Rollback method to cancel or abort the transaction
• Close the connection to the database

The following code snippet shows how we can implement transaction processing using ADO.NET in our applications.

string connectionString = ...; //Some connection string
SqlConnection sqlConnection = new SqlConnection(connectionString);
sqlConnection.Open();

SqlTransaction sqlTransaction = sqlConnection.BeginTransaction();

SqlCommand sqlCommand = new SqlCommand();
sqlCommand.Transaction = sqlTransaction;

try
{
  sqlCommand.CommandText = "Insert into Employee (EmpCode, EmpName) VALUES (1, 'Joydip')";
  sqlCommand.ExecuteNonQuery();
  sqlCommand.CommandText = "Insert into Dept (DeptCode, DeptName, EmpCode) VALUES (9, 'Software', 1)";
  sqlCommand.ExecuteNonQuery();
  sqlTransaction.Commit();
  //Usual code
}

catch(Exception e)
{
  sqlTransaction.Rollback();
  //Usual code
}

finally
{
  sqlConnection.Close();
}

The next piece of code illustrates how we can use the “using” statement for the above code. According to MSDN, the "using" statement, "defines a scope, outside of which an object or objects will be disposed. A using statement can be exited either when the end of the using statement is reached or if an exception is thrown and control leaves the statement block before the end of the statement".

using (SqlConnection sqlConnection = new SqlConnection(connectionString))
{
    SqlCommand command = connection.CreateCommand();
    SqlTransaction transaction = null;
   
    try
    {
        sqlConnection.Open();
        transaction = sqlConnection.BeginTransaction();
       
        command.Transaction = transaction;
        
        command.CommandText = "Insert into employee (empID, empName) values (1, 'Swaps');
        command.ExecuteNonQuery();
       
        command.CommandText = "Insert into dept (deptID,deptName,empID) values (9,'Software',1)";
        command.ExecuteNonQuery();
       
        transaction.Commit();
    }
    catch(Exception ex)
    {
        transaction.Rollback();
        throw ex;
    }
    finally
    {
        sqlConnection.Close();
    }
}

The Microsoft's ADO.NET version 2.0 added a lot of new features to its earlier counterpart to add more flexibility and ease of use. As far as transactions are concerned, a new namespace called System.Transactions has been introduced that promises a significantly improved support for distributed transactions. It contains a class called TransactionScope that can run a set of statements. It can also determine whether the objects in the scope have support for transactions. If the transaction has completed successfully, the changes are committed to the database else it is rolled back. We need to specify whether the transaction block is complete by making a call to the TransactionScope.Complete method explicitly, else, the transaction would be rolled back when the transaction instance would be discarded by the implicit Dispose method.
The following piece of code illustrates what we have learnt so far in this section.

bool IsConsistent = false;
using (System.Transactions.TransactionScope transactionScope = new System.Transactions.TransactionScope())
{
      SqlConnection sqlConnection = newSqlConnection(connectionString);
      string sqlString = "Update emp set empName = 'Joydip Kanjilal' where empID = 9";
      SqlCommand cmd = newSqlCommand(sql, cn);
      sqlConnection.Open();
      cmd.ExecuteNonQuery();
      sqlConnection.Close();
      transactionScope.Consistent = IsConsistent;
}
               
TransactionScope also has support for distributed transactions. We can implement transactions for multiple database connections using it. The following piece of code shows how we can implement transactional support for multiple databases using the TransactionScope class.

using (TransactionScope transactionScope = new TransactionScope())
{
   using (SqlConnection codesDatabaseConnection = new SqlConnection(codesDatabaseConnectionString))
   {
      SqlCommand sqlCommandCodes = codesDatabaseConnection.CreateCommand();
      sqlCommandCodes.CommandText = "Insert Into codes (codeID,codeText) values (1,'Test')";
      codesDatabaseConnection.Open();
      sqlCommandCodes.ExecuteNonQuery();
      codesDatabaseConnection.Close();
   }

   using (SqlConnection statesDatabaseConnection = new SqlConnection(statesDatabaseConnectionString))
   {
      SqlCommand sqlCommandStates = statesDatabaseConnection.CreateCommand();
      sqlCommandStates.CommandText = "Insert into States(stateID,stateName) values (1, 'Test')";
      codesDatabaseConnection.Open();
      sqlCommandStates.ExecuteNonQuery();
      statesDatabaseConnection.Close();
   }

   transactionScope.Complete();
}

Points to be noted

It should be noted that the SqlTransaction object returned by the BeginTransaction () method has to be assigned to the Transaction property of the Command object; else an InvalidOperationException will be thrown by the application when the first query is executed. Likewise, the Connection instance should be open by invoking the Open method on it prior to starting a new transaction; else an InvalidOperationException would be thrown. In order to improve the performance of applications, we should try to keep the transactions (the transaction units/blocks that contain the statements to be executed in a batch as a whole) as short as possible. This will help minimize the lock contention and hence increase throughput. Further, we should analyze whether or not we actually require a transaction for a batch of statements. Try not to unnecessarily have transactional statements in you code as it might have a performance drawback due to the reasons stated above.

Conclusion

The usage of transactions guarantee the execution of a batch of statements sequentially in its entirety or roll them back hence preserving the database integrity and data consistency. In a nutshell, in order to work with transactions, invoke the BeginTransaction() method of the appropriate database connection instance and then call either the Commit() or Rollback() method on the returned transaction object reference depending on the circumstances. However, it should be noted that transactions hold locks and may cause contention issues; they should be as short as it is possible. Hence, this is a major performance drawback in using transactions in our code. But, if used properly, it can facilitate the design and implementation of robust applications with data security and consistency.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Web Event Providers

Web event providers provide the interface between Microsoft ASP.NET's health monitoring subsystem and data sources for the events ("Web events") fired by that subsystem. ASP.NET 2.0 ships with the following Web event providers:

·          EventLogWebEventProvider, which logs Web events in the Windows event log.

·          SqlWebEventProvider, which log Web events in Microsoft SQL Server and Microsoft SQL Server Express databases.

·          SimpleMailWebEventProvider and TemplatedMailWebEventProvider, which respond to Web events by sending e-mail.

·          TraceWebEventProvider, which forwards Web events to diagnostics trace.

·          WmiWebEventProvider, which forwards Web events to the Microsoft Windows Management Instrumentation (WMI) subsystem.

The Microsoft .NET Framework's System.Web.Management namespace includes a class named WebEventProvider that defines the basic characteristics of a Web event provider. It also contains a WebEventProvider-derivative named BufferedWebEventProvider that adds buffering support. SqlWebEventProvider derives from BufferedWebEventProvider and improves performance by "batching" Web events and committing them to the database en masse. BufferedWebEventProvider is prototyped as follows:

public abstract class BufferedWebEventProvider : WebEventProvider

{

       // Properties

        public bool UseBuffering { get; }

        public string BufferMode { get; }

      // Virtual methods

       public override void Initialize (string name, NameValueCollection config);

       public override void ProcessEvent (WebBaseEvent raisedEvent);

       public override void Flush ();

    // Abstract methods

    public abstract void ProcessEventFlush (WebEventBufferFlushInfo flushInfo);

}

SqlWebEventProvider

SqlWebEventProvider is the Microsoft Web event provider for SQL Server databases. It logs Web events in the provider database, using the schema documented in "Data Schema," and it uses the stored procedure documented in "Data Access." Knowledge of the database schema is hidden in the stored procedure, so that porting SqlWebEventProvider to other database types requires little more than modifying the stored procedure. (Depending on the targeted database type, the ADO.NET code used to call the stored procedure might have to change, too. The Microsoft Oracle .NET provider, for example, uses a different syntax for named parameters.)

The ultimate reference for SqlWebEventProvider is the SqlWebEventProvider source code, which is found in SqlWebEventProvider.cs. The sections that follow highlight key aspects of SqlWebEventProvider's design and operation.

Provider Initialization

Initialization occurs in SqlWebEventProvider.Initialize, which is called one time—when the provider is loaded—by ASP.NET. SqlWebEventProvider.Initialize processes the connectionStringName and maxDetailsEventLength configuration attributes. Then, it calls base.Initialize to process other supported configuration attributes such, as useBuffering, and throw an exception if unrecognized configuration attributes remain.

SqlWebEventProvider.Initialize reads the connection string identified by the connectionStringName attribute from the <connectionStrings> configuration section, and caches it in a private field. It throws a ConfigurationErrorsException if the attribute is empty or nonexistent, if the attribute references a nonexistent connection string, or if the connection string doesn't use integrated security.

Data Access

SqlWebEventProvider performs all database accesses through the stored procedure named aspnet_WebEvent_LogEvent (Table 7-2). That stored procedure is a simple one consisting of a single INSERT statement that initializes the fields of the new record with the input parameters generated by SqlWebEventProvider.FillParams

Processing Web Events

When a Web event is raised, the Web events subsystem calls the ProcessEvent method of each Web event provider mapped to that event type. If buffering is not enabled, SqlWebEventProvider.ProcessEvent records the Web event in the provider database, by calling the helper method WriteToSQL. If buffering is enabled, SqlWebEventProvider.ProcessEvent buffers the Web event by calling the base class's ProcessEvent method. The following is the source code for SqlWebEventProvider.ProcessEvent, with diagnostic code removed for clarity:

public override void ProcessEvent(WebBaseEvent eventRaised)

{

     if (UseBuffering)

         { base.ProcessEvent(eventRaised); }

     else

         { WriteToSQL(new WebBaseEventCollection(eventRaised), 0, new DateTime(0)); }

}

If buffering is enabled, the Web events subsystem calls the provider's ProcessEventFlush method to flush buffered Web events. ProcessEventFlush's job is to read buffered Web events from the event buffer, and commit them to the database. SqlWebEventProvider.ProcessEventFlush calls WriteToSQL to log the buffered events. as follows:

public override void ProcessEventFlush (WebEventBufferFlushInfo flushInfo)

{

      WriteToSQL(flushInfo.Events, flushInfo.EventsDiscardedSinceLastNotification, flushInfo.LastNotificationUtc);

}

SqlWebEventProvider.WriteToSQL contains the logic for recording Web events in the provider database. WriteToSQL calls FillParams to generate the parameters written to the database, and then calls the stored procedure aspnet_WebEvent_LogEvent to write the parameters to the provider database. WriteToSql is capable of writing one Web event or multiple Web events, and it contains built-in logic for delaying retries for at least 30 seconds (or the number of seconds specified by the commandTimeout configuration attribute) after a failed attempt to write to the database.

Differences Between the Published Source Code and the .NET Framework's SqlWebEventProvider

The published source code for SqlWebEventProvider differs from the .NET Framework version in the following respects:

·          Declarative and imperative CAS checks were commented out. Because the source code can be compiled standalone, and thus will run as user code rather than trusted code in the global assembly cache, the CAS checks are not necessary.

·          The published version includes a derived event type called MyWebBaseEvent that is used for manipulating events in the provider. The .NET Framework provider uses the base WebBaseEvent class directly, because the .NET Framework provider is able to call internal WebBaseEvent methods.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

When displaying data in a grid, there are instances when you would want the data column not to be visible to the client and still require it for further processing. This can be achieved by simply setting the column’s visibility property to False.  This can be done in versions prior to ASP.NET 2.0, but how do you achieve this in ASP.NET 2.0?

The GridView of ASP.NET 2.0 has replaced the DataGrid and the scenario mentioned above just does not work in ASP.NET 2.0.

When the column’s visibility property is set to False, the GridView does not bind the data to the column.  When you try to retrieve data from the hidden column, you get an empty string.

Result?  You start debugging your application and end up being lost in the web.

I hope the solution mentioned below saves some of your precious development time.

Add the GridView’s RowCreated event and set the cell’s visibility property to False.

Public Sub myGridView_OnRowCreated(ByVal sender As Object, ByVal e As _
       Web.UI.WebControls.GridViewRowEventArgs) Handles myGridView.RowCreated
  'Hide the cell of the column you do not want to display as each row gets
  'created, eventually leading to the entire column being hidden.
  e.Row.Cells(0).Visible = False
End Sub

The GridView’s RowCreated event gets called after the data is bound to the grid.  So the first column is hidden only after it is databound.  It is possible to hide the other columns by changing the cell index.

 Hope this is usefull to you.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/