.NET Questions and Solutions

Symptoms
When an unhandled exception is thrown in a Microsoft ASP.NET-based application that is built on the Microsoft .NET Framework 2.0, the application unexpectedly quits. When this problem occurs, no exception information that you must have to understanding the issue is logged in the Application log.
However, an event message that is similar to the following may be logged in the System log:
Event Type: Warning
Event Source: W3SVC
Event Category: None
Event ID: 1009
Date: 9/28/2005
Time: 3:18:11
PM User: N/A
Computer: IIS-SERVER
Description:
A process serving application pool ‘DefaultAppPool’ terminated unexpectedly. The process id was ‘2548’. The process exit code was ‘0xe0434f4d’. Additionally, an event message that is similar to the following may be logged in the Application log:
Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 9/28/2005
Time: 3:18:02 PM
User: N/A
Computer: IIS-SERVER
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_web_7437ep-9, P5 0.0.0.0, P6 433b1670, P7 9, P8 a, P9 system.exception, P10 NIL.
Resolution
This problem occurs because the default policy for unhandled exceptions has changed in the .NET Framework 2.0. By default, the policy for unhandled exceptions is to end the worker process.
In the Microsoft .NET Framework 1.1 and in the Microsoft .NET Framework 1.0, unhandled exceptions on managed threads were ignored. Unless you attached a debugger to catch the exception, you would not realize that anything was wrong.
ASP.NET uses the default policy for unhandled exceptions in the .NET Framework 2.0. When an unhandled exception is thrown, the ASP.NET-based application unexpectedly quits.
This behavior does not apply to exceptions that occur in the context of a request. These kinds of exceptions are still handled and wrapped by an HttpException object. Exceptions that occur in the context of a request do not cause the worker process to end. However, unhandled exceptions outside the context of a request, such as exceptions on a timer thread or in a callback function, cause the worker process to end.

Symptoms
This article describes the Microsoft Application Blocks for .NET topic “Exception Management Application Block Overview.”
The Exception Management Application Block provides a simple, extensible framework for handling exceptions. Without affecting your application code, you can do the following: Log exception information to the event log by using only one line of application code.Extend the application block by creating your own components that log exception details to other data sources or notify operators.You can use the Exception Management Application Block as a building block in your .NET Framework-based application.
Resolution
“Exception Management Application Block Overview” contains the following sections: Introduction
The Exception Management Application Block is an exception management framework that you can use as a building block in your own .NET Framework-based application. If you use this block, you reduce the quantity of custom error handling code that you must create, test, and maintain. You may also make your application more robust and easier to debug.
The Exception Management Application Block helps you to do the following: Manage exceptions in an efficient and consistent way.Isolate exception management code from business logic code.Handle and log exceptions by using minimal custom code.What Does the Exception Management Application Block Include?
The Exception Management Application Block is made up of three Microsoft Visual Studio .NET projects, full source code, and comprehensive documentation.Downloading and Installing the Exception Management Application Block
A Microsoft Windows Installer file that contains the Exception Management Application Block projects, source code, and comprehensive documentation is available.
The install process creates a Microsoft Application Blocks for .NET menu on your Programs menu. An Exception Management menu appears on the Microsoft Application Blocks for .NET menu. The Exception Management menu includes options to start the documentation and to start the Exception Management Application Block Visual Studio .NET solution.Using the Exception Management Application Block
This section discusses how to use the basic features of the Exception Management Application Block. For additional information about these topics, and other related topics, see the documentation that is included with the Exception Management Application Block download.
The topics that this section discusses include: Publishing ExceptionsReferencing the Exception Management Application BlockConfiguring the Exception Manager Application Block
You control the behavior of the Exception Management Application Block by using the following standard .NET Framework-based XML application configuration files: Web.config (for an ASP.NET application)Appname.exe.config (for a Windows-based application)You can also apply configuration settings at the computer level by using the Machine.config file.Extending the Exception Management Application Block
You may be satisfied with the functionality of the default publisher. The default publisher writes exception details to the Windows event log. However, you may want to develop your own custom publishers to log exception details to alternative locations or to notify operators (possibly through Microsoft Windows Management Instrumentation [WMI]), that an exception has occurred. This section discusses how to extend the functionality of the Exception Management Application Block.Internal Design
This section discusses the main elements of the Exception Management Application Block. The main elements of the Exception Management Application Block are as follows: The BaseApplicationException classThe ExceptionManagerSectionHandler classThe ExceptionManager classThe ExceptionManagerInstaller classThe DefaultPublisher classThe IExceptionPublisher interfaceThe IExceptionXmlPublisher interface

Symptoms
You experience out of memory exception errors on a Web server that has Microsoft ASP.NET 1.1 installed. ASP.NET 1.1 is installed as part of the Microsoft .NET Framework 1.1 and the Microsoft .NET Framework 1.1 Service Pack 1 (SP1).
Resolution
This problem occurs because the MobileCapabilities object does not expire from the cache as expected. You can use an instance of the MobileCapabilities object to read the capabilities of the requesting browser and device.

Symptoms
A NullReferenceException error may occur in the Microsoft .NET Framework version 1.1 when one of the following conditions is true: You use reflection to obtain a default value of a parameter out of a method that uses a default null value for a parameter.You use reflection to invoke a method that uses a default null value for a parameter.
Resolution
To resolve this problem, obtain the latest service pack for the Microsoft .NET Framework 1.1. For more information, visit the following Microsoft Web site:
http://www.microsoft.com/downloads/details.aspx?FamilyId=A8F5654F-088E-40B2-BBDB-A83353618B38(http://www.microsoft.com/downloads/details.aspx?FamilyId=A8F5654F-088E-40B2-BBDB-A83353618B38)

Symptoms
If you use the CommandBuilder object to explicitly get commands for the DataAdapter object as follows:

da.InsertCommand = cb.GetInsertCommand and then run the following Visual Basic .NET code

cb.DataAdapter = Nothing or the following Visual C# .NET code

cb.DataAdapter = null; the commands that you add to the DataAdapter are deleted, and you receive the following error message:

An unhandled exception of type ‘System.NullReferenceException’ occurred in app_name.exe
Additional information: Object reference not set to an instance of an object.
Resolution
CommandBuilder deletes the commands that it generates when it is disassociated from a DataAdapter. CommandBuilder and DataAdapter are linked; when they are unlinked or disassociated, the commands are nulled. This problem does not affect commands that you build from the beginning (from scratch).

Symptoms
This article describes the undocumented change in behavior of the HttpServerUtility.Transfer method call from the Microsoft .NET Framework 1.0 to the Microsoft .NET Framework 1.1.
For more information, visit the following Microsoft Developer Network (MSDN) Web site:
http://msdn2.microsoft.com/en-us/library/aa332847(VS.71).aspx(http://msdn2.microsoft.com/en-us/library/aa332847(VS.71).aspx)
Resolution
The HttpServerUtility.Transfer method contains two parameters. The first parameter is a URL path of the new page on the server to execute.The second optional parameter indicates whether the Form and the QueryString values can pass from the calling page to the page that the user is being transferred to.

HttpServerUtility.Transfer(String, Boolean); In the .NET Framework 1.0, if the second optional parameter of the HttpServerUtility.Transfer method is not specified, the second parameter is set to false.
In the .NET Framework 1.1, if the second optional parameter of the HttpServerUtility.Transfer method is not specified, the second parameter is set to true.
The “Parameters” section of the “HttpServerUtility.Transfer Method (String, Boolean)” topic in MSDN states the following:
path
The URL path of the new page on the server to execute.
preserveForm
If true, the QueryString and Form collections are preserved. If false, they are cleared. The default is false.
The following is the correct information:
path
The URL path of the new page on the server to execute.
preserveForm
If true, the QueryString and Form collections are preserved. If false, they are cleared. In the .NET Framework 1.0, the default value of the preserveForm parameter is false. In the .NET Framework 1.1, the default value of the preserveForm parameter is true.