Everyone needs the ability to monitor performance and track statistics inside applications. As developpers our code is a black box when running. We can't really tell how many times a loop is runs or how long an operation has taken, other then using log files. Another sexy way is to use the PerformanceCounter class. It lets your report statistics that can be viewed using the "PerfMon.exe". The bueaty is you can create custom counters to be used any way you please. Lets go over the steps to register and use some custom performance counters.

The CounterCreationDataCollection is used to store a list of counters. The first step would be to populate the collection with all your counter types. The PerformanceCounterType enumeration lets you control the type of coutner. I recommend reading the documenation to review different types you can use. Below is a example creating a collection of 2 custom performance counters.

If a user wants the ability to customize buttons on a form, or a trader needs to develop custom formulas to execute his trading strategies then use CodeDom. These types of requirements can be easily accomplished using the CodeDom namespace. The System.CodeDom namespace is very powerful because it lets you compile source code at run time. The output is an assembly that can exist in memory or saved on your disk. We can use this feature of .NET to create customizable functions in our applicationswithout the need to compile and release new version.

Lets say a user creates a C# file called Formual1.cs to perform some calculations and need to use it in our program. In order to accomplish this we should have an interface the user must implement. This will make it easier for us to execute his or her code.

I have a good amount of experience in real-time trading systems. One area of expertise is in developing GUIs that can handle real-time updates. I want to explain and show you some of the techniques I use when developing a GUI to handle this many updates.

Task:

• Create a GUI to receive real-time updates and display them in a grid.
• Use a DataTable and bind it to a Grid.
• Use a background Thread to simulate real-time updates.

Issues to be aware:

• Updates can and will be occurring faster then you GUI can handle.
• The GUI must always be responsive. Users do NOT like it when the application freezes because of updates occuring.
• Updates will not be real-time. It will appear to be real-time because of the implementation, but users should not see any noticeable delays.

I am not really going up against these guys, and not because I don't think 1 person could do it better. I just wanted to choose an interesting project to show you how easy socket communication is in .NET. The objective is to show you how to connect or listen on a socket, plus transmit and receive data.

I am organizing the solution into 3 parts: Client, Server, and Shared. The Client is a simple front-end to input messages that will be sent and display messages received. The Server will listen for client connection and route messages to the clients. The Shared project is where the standard communication engine will be developed the Client and Server will need a reference and re-use the same communication engines. The Client and Server will only need to implement specific functions unrelated to communications.

Do you run out of memory becuase everything is cached in memory and hit the limitation imposed by 32-bit machines?
Do you need to preserve objects when your application restarts?

If you answered yes, then I have a simple solution. Use serialization to cache objects to disk. When objects are added or updated to a collection then serialize it to disk and de-serialize when a retreive request is made.

I started this project called PersistentCaching and created a class called PersistentArrayList. The first step was to define methods I wanted to support, and I decided on the following: Add, RemoveAt, Clear, Item, and Count.

The answer is to use the System.Environment.UserInteractive property.

This is useful to determine if your process is running in the foreground or background. When a service is started this property returns false. Using this property you can make your program start as a service or as a windows application without the need to re-compile.

static void Main()
{
    if(System.Environment.UserInteractive)
    {
        Start();
        Console.WriteLine("Press to exit...");
        Console.ReadLine();
        Stop();
    }
    else
    {
        ServiceBase[] ServicesToRun = new ServiceBase[] { new ServiceMain() };
        ServiceBase.Run(ServicesToRun);
    }
}

Here is a working copy of my Soap messagingproject. It's allows you to inherit from the Message class to implement your own request/response messages. You can also implement the ICommandProcessor interface to handle the server side requests. This framework lets you develop custom assemblies that contain commands/processors and load them at run-time using XMLconfiguration files. I highly recommendthe commands and processors get separated into 2 difference assemblies. This is to make your client thin and light weight because it won't depend on libraries and database access the processor might be using.

I found this reviewing the AppDomain class and think it's so awsome I had to write about it. You know how many times users get an unhandled error in a application and don't record the information. I am sure this happens to everyone. I think it's good practive for everyone to listent to this event and log unhandled exceptions.

This will NOT stop your application from terminating but at a minimum you can record the error in a log file for reference.

I grabbed this example from the MSDN documentation:
public static void Main() {
    AppDomain currentDomain = AppDomain.CurrentDomain;
    currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
    try {
        throw new Exception("1");
    } catch (Exception e) {
        Console.WriteLine("Catch clause caught : " + e.Message);
    }
    throw new Exception("2");
    // Output:
    // Catch clause caught : 1
    // MyHandler caught : 2
}
static void MyHandler(object sender, UnhandledExceptionEventArgs args) {
    Exception e = (Exception) args.ExceptionObject;
    Console.WriteLine("MyHandler caught : " + e.Message);
}

In this post I will be talking about a very important aspect of the server called a session. The server will need this session to maintain client connections and process requests. When the server receives a login message the first step is to create a session object for this connection. This session object will store useful information like session ID, username, client connection, session lifetime objects, and communication details.

The session ID is a unique string assigned by the client. When the client sends a login message a GUID is created and preserved to identify the session. Every message sent by the client will contain this session ID. This guarantees the server can distinguish requests from each client that is connected.

Now that my boss decided the architecture should be Soap over TCP/IP I got started on build process.

He gave me the following requirements:
• Support asynchronous events from the server. This means the client can’t poll the server to events. The server must trigger the event on the client.
• Ability to extend the business logic on the server easily with multiple developers working on separate tasks.
• Secrurity to protect business logic. Clients are required to send user and password that will be used for security. Security must be done on the server side and check permissions before executing the business logic.