What I was doing was to use it to write event entries in windows event log as part of the exception handling in an ASP.NET web application.  Nothing fancy.  It worked fine on my PC, but it didn’t write anything to the event log when Logger.Write is executed. No exception was thrown from that line of code either.  The program just went through as if that line of code was skipped.

It turned out to be a permission issue. When I debug the application in Visual Studio, it was running under my windows account credential which had permission to create Event Source in the system.  However, when the application was deployed to the server, it was running under the default account which was “NT Authority\Network Service” in my case.  By default, that account doesn’t have permission to create new Event Source in the system.  It does have permission to write event entries though.  So, when Logger.Write was executed, it couldn’t proceed because the Event Source wasn’t there, and the program didn’t have permission to create one.  Actually, it makes sense to not throw any exception on this line, because people like me usually use this to log exceptions, and if the logging process itself throws exceptions, there is probably nowhere else we can handle and/or log them.

Now, how this can be resolve?  The solution is quite simple.  As long as the Event Source is created ahead of time, it will be no problem.  What I did was to create required Event Source(s) on server through CMD.exe.  Here is a sample command:

eventcreate /ID 1 /L Application /T information /SO "My Event Source" /D "My Event Source is created."

This command will create an event entry in the Application log.  If the Event Source doesn’t exist, it will be created during the process.  This is only required when the application is deployed to the server first time.  So, I usually do it manually on server.  However, if that’s not the case, you can build it into the installation package, and when the application is installed, the Event Source is created as well.  Of course, you can use .NET to create Event Source in your installer too.

This pattern works, but sometimes it is tricky to generate a meaningful message.  The problem is that the exception can be thrown anywhere in your application, and the exception message may not always be appropriate or meaningful to end-users.  If you blindly display all exception messages you finally get, users may see something like “Object reference not set to an instance of an object” which doesn’t mean much to them.  So, in the final step of exception handling (where the program displays error messages or redirect users to an error page), you will see all kinds of exceptions which include .NET originated exceptions, exceptions raised by the program on purpose, and custom exceptions.  Some of them are appropriate to show to users, while others aren’t.  So, the question is how you can distinguish among them.

A lot of people suggest that if the original .NET exception message isn’t meaningful to users, and you can’t provide more specific message either, then a generic message such as “An error has occurred…  Please contact the technical support team for help” can be used.  I agree too.  You may do this where you know an exception can be thrown, and re-throw the exception with customized message (whether specific or generic) and with the original exception embedded as the inner exception of the new exception.  However, you don’t want to just put try/catch blocks in every piece of your code, and catch and re-throw every exception the program may possibly encounter.  It’s labor intensive and inefficient.  Also, there will always be something you can’t think of or look over, so there are still chances you can get unexpected exceptions in the end.

So, my solution is to let the program only catch and re-throw .NET originated exceptions when they are predictable and additional meaningful information can be provided, and let all other exceptions bubble up to the top tier.  Then in the final step of exception handling, identify the exceptions that are re-thrown, and retrieve the error message directly from these exceptions; use a generic error message for all other exceptions.  The question is how to identify these exceptions that are re-thrown.  For this purpose, I usually create a custom exception class which is inherited from System.Exception.  Use this class whenever I need to throw new exceptions or re-throw .NET originated exceptions.  So, in the final step, I check the type of the exception, and decide whether to use it as the error message or use a generic one instead.

Here is the custom exception class:

The ExceptionBase class has two constructors which give you the options to create an instance of exception with customized error message and with/without inner exception.

Here is how to use it in code:

Or

The central location I handle all exceptions is in global.asax, and here is what it looks like:

One note for this is that ASP.NET may put a wrapper exception (HttpUnhandledException) around the original exception.  In the code above, it is simply removed because it doesn’t contain any useful information.

You can also create more custom exception classes based on the ExceptionBase class to improve consistency in your application, and the code above will still work.  One example is:

This way the error messages for one type of exception are consistent across the application.

Here are a few things you will need to have on your computer to continue.

1. Windows Virtual PC 2007.  This is required, if you would like to connect the Device Emulator to your local network.  The software can be downloaded from Microsoft website.
2. Microsoft Visual Studio 2008.
3. Microsoft Device Emulator (which comes with VS2008).

With all the above requirements available on your computer, you can follow the steps below to configure your Device Emulator.

1. Start VS 2008 IDE.
2. On the menu, go to Tools >> Device Emulator Manager
   

   Start Device Emulator Manager

3. Right-click on a device you would like to use, and choose Connect option.
   

   Connect to A Mobile Device

4. After the device is connected, right-click on the connected device again, and choose Cradle.
   

   Cradle the Connected Device

5. Go to the device window.  On the menu, choose File >> Configure
   

   Configure Device

6. Go to the Network tab, and select the options as shown in the screen shot below.  And then click OK to close the window.
   

   Choose Network Card

7. In the device window, on the menu, choose File >> Reset >> Soft.  And wait until the device is restarted.
8. Now you need to configure the internet connection in the mobile device.  (The process could be different depending on what device you have picked.)  Normally, you would find the Settings option in the main menu, and then go to the Connections section to choose/define an internet connection.  Here below I use the device I chose as an example.
9. Choose Settings >> Connections >> Advanced >> Select Networks, and then choose My ISP for both Internet and Private Network connections.
   

   Choose Settings

   

   Choose Connections

   

   Choose Advanced Settings

   

   Choose My ISP

10. After confirming all these changes, you can now visit your mobile web application or internet using this Device Emulator.  Task accomplished!
    

    Your Mobile Website

[Path to The Siebel Application Bin folder]\srvrmgr.exe /g [Siebel Application Server Name] /e [Target Siebel Environment] /s [Siebel Application Server Name] /u [User Name] /p [User Password]

run task for component EIM with config=”[Config File].ifb”,Process=”[Process Name]“

The first command starts the srvrmgr program, and the second one ticks off the EIM process.  The configuration file ([config File].ifb) specifies all the parameters needed by the EIM interface in order to complete the process.  One of the important parameters we need to set in the .ifb file is the BATCH, which is the identifier for the group of data being handled during the current process.  Normally, we set it to a fixed number or a range of numbers (for example, 500-600).  So, when the EIM process runs, only the data with a batch number equal to the BATCH or falling in the range specified in the .ifb file will be processed.  If in the EIM tables there are some records which are not ready to be processed at this moment, they can be skipped by identifying themselves with a different batch number.  This is helpful when you are managing multiple data importing tasks which share the same set of EIM tables, and run at different time.

However, we soon realized that it would be getting harder and harder to manage these .ifb files and to make sure these EIM processes don’t interfere with each other.  For example, one of our custom applications needs to import data into Siebel using EIM interface upon users’ requests.  The data importing process is exactly the same for all these requests, except for the data needed to be imported.  Multiple users need to be allowed to submit their requests at the same time, and their requests should be handled separately.  If we were going to do it in the old fashion, we would need to have a .ifb file for each of their requests, and use different batch numbers in these .ifb files.  It is not realistic, or it is something we want to do either.

The solution is actually very simple.  We took the BATCH setting out of the .ifb file, and instead we set it in the command line.  This was not documented in the Siebel EIM Admin Guide, but after our testing it was proved to be a working solution.  The command will look like the following now:

[Siebel Application Bin folder]\srvrmgr.exe /g [Siebel Application Server Name] /e [Target Siebel Environment] /s [Siebel Application Server Name] /u [User Name] /p [User Password]

run task for component EIM with config=”[Config File].ifb”,Process=”[Process Name]“,BATCH=[Batch Number]

This way the application can choose a BATCH number unique to the user’s request, construct the command, and then execute it to tick off the EIM process, and all these requests can share the same .ifb file.

To manage the batch numbers among different applications, we reserved a range of batch numbers for each application.  For example, from 500 to 549 will be used only by application A, and from 550 to 599 will be used only by application B.  Within each application, a batch number is assigned to each request based on the request identifier and the range of batch numbers reserved for the application.  In our case, the request ID is an auto-incrementing integer, and the equation for calculating the batch number is:

[Batch Number] = [Request ID] % [Total Number of Allocated Batch Numbers] + [The Lowest Batch Number]
(Where % stands for the modulus operator)

For example, if the allocated batch numbers are from 500 to 549, and the current request ID is 1034, the batch number for this request will then be:

534 = 1034 % (549 – 500 + 1) + 500

This way the adjacent requests would have different batch numbers, and the batch numbers are used in a cycle.  In our case, we will never have more than 50 users submitting their requests at the same time, but if this was for a larger user base, we could allocated a bigger range of batch numbers.

So, we finally were able to manage all users’ requests using limited batch numbers and a single .ifb file without the requests being interfered by each other.  Task accomplished!

In my case, the FileUpload only works when it is visible when the page is first time loaded (not a postback).  It will not work (Request.Files.Count returns 0) when it is hidden originally and then made visible during later AsyncPostBacks.  Maybe ASP.NET is confused, because I am also changing the submit button’s postback type between full postback and aysnc postback.  The submit button is used by other things, and I only want it to fire a full post back when files need to be uploaded, and in all other cases, I want it to fire async postback and only do partial update on my page.

I spent many hours trying many different solutions I saw on the internet, but none of them worked for me.  However, I found an important hint which led me to the final working solution.  That is the Enctype attribute of the Form.  I learned that the Form.Enctype has to be “multipart/form-data” when files need to be uploaded.  I think this is set automatically for you in normal cases, but it isn’t set up correctly in my case.  So, I manually set it to “multipart/form-data” in OnInit of my user control, and it solves the problem.

I did some research online, and people are saying that the Parameter Sniffing could be the cause.  I tried to avoid it according to this post, but it didn’t make much difference as far as how long it takes for the Stored Procedure to complete.

After trying many different things, I finally found out the problem.  The Stored Procedure was dynamically created from user-defined query using SQL Server Management Object within our .NET web application.  We also allow users to define parameters (such as @Param1) in their Queries.  Since we don’t know the maximum length of the string parameter, we used varchar(MAX) for all string type parameters.  That’s the cause of this problem.  Once I changed the varchar(MAX) to varchar(200), the Stored Procedure started running much faster and the Execution Plan looks very similar to the simple Query now.  Problem solved.

Just for curiosity, I compared some other scenarios.  I found out that varchar(MAX) doesn’t always make a huge difference in performance.  The Stored Procedure I had problem with had a target table in a remote database (Linked Server) and the version of the remote SQL Server is 2000 where varchar(MAX) is not supported.  I am surprised that I didn’t get any exception when I run the query.  I am not sure what SQL Server does in the back end to make this unsupported data type to work, but apparently it slows down the query execution.

In order to get away from code being escalated to MSDTC (Microsoft Distributed Transaction Coordinator), I decided to use single SqlConnection per TransactionScope.  Also, to maximize code reusability, we ended up with the following development pattern.  For simplicity reason, error handling is not added in the example below.

public static void CreateOrder(Order myOrder)
{
    using (TransactionScope scope =
            new TransactionScope(TransactionScopeOption.RequiresNew))
    {
        using (SqlConnection cn = DB.GetConnection())
        {
            cn.Open();
            SqlCommand cmd = new SqlCommand();
            cmd.Connection = cn;

            InsertOrderTransaction(myOrder, cmd);
        }
        scope.Complete();
    }
}

internal static void InsertOrderTransaction(Order myOrder, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrder";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@CustomerID", myOrder.CustomerID);
    // ...

    myOrder.ID = Convert.ToInt64(cmd.ExecuteScalar());

    InsertOrderTransactionPostProcessing(myOrder, cmd);
}

As you can see, the method InsertOrderTransaction takes the Order object and a SqlCommand instance. It assumes that the SqlConnection has been established for the SqlCommand in the calling method. It doesn’t care if the SqlCommand needs to be executed within a transaction or not. It simply executes a SQL statement or a Stored Procedure. In its calling method CreateOrder, it defines the TransactionScope and defines and opens a SqlConnection. It can call multiple transactional methods (in this case InsertTransaction) and keep them all in one transaction. However, you don’t have to define a TranscationScope in the calling method if you are not dealing with multiple SQL operations. You can also add pre-processing and post-processing functions if needed.

internal static void InsertOrderTransactionPostProcessing(Order myOrder, SqlCommand cmd)
{
    if (myOrder.OrderItems != null)
    {
        foreach (OrderItem myItem in myOrder.OrderItems)
        {
            myItem.OrderID = myOrder.ID;
            InsertOrderItemTransaction(myItem, cmd);
        }
    }
}

internal static void InsertOrderItemTransaction(OrderItem myItem, SqlCommand cmd)
{
    cmd.CommandText = "dbo.spCOrderItem";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("@ItemID", myItem.ItemID);
    // ...
    myItem.OrderItemID = Convert.ToInt64(cmd.ExecuteScalar());
}

One thing you have to be aware of is that TransactionScope may not be a good choice if these operations take too long to complete. The reason is obvious. Transaction may result in temporary locking on certain objects (such as tables) in your database. If the transaction needs 5 minutes to complete, it may lock a table for that long and your users may be unable to access data in the table for that long. If anything goes wrong at the very last second in the transaction, it may take another 5 minutes for the database to roll back previous operations in this transaction, and make the table inaccessible to your users for even longer. So in cases like this, one transaction may need to be broken into multiple segments.