C# Programming Secrets.....

This blog contains the programming tips, obscure logic, and unnoticed clues which generally come into our mind but we are unnoticed. This blog is targeted for experienced programmers. If you have any related contents, please help me, I will public in my blog

Calling C++ Dll From C#

C++ is powerful language. Generally, C++ can do everything from lower level operations to higher level GUI controls.  There are some higher level programming languages(like C#, Java etc) which can create a very good GUI with less effort. So, generally, C++ is being used in  low level intensive processing or memory level operations which is very fast as compared to other higher level programming language. We can fully use the power of C++ pointers.

So, the general convention is we design the GUI related things in C# and the intensive processing lower level tasks are assigned to C++. We develop all the require functions in C++ and then generate a dynamic link library which contains all the methods. If you are using Microsoft Visual Studio, creating dlls is not a big deal.

After you have a dll file, I am gonna expain how this dll can be used in C#. You may have already noticed that in C# project, the C++ dlls can not be added as reference. So, we have to do something lengthy to get them work. I have studied two P/Invoke methods that are working perfectly:

Before I start the method, I have sample C++ files(Sample.h,Sample.cpp) under the project "CppProject".


#define DllExport __declspec(dllexport)
extern "C" DllExport double findSquareRoot(double);


double findSquareRoot(double value){
return sqrt(value);

Method 1:  Simple Method                   
                  (i) Create a C# file Test.cs under the project CsharpProject and include the following content:
        using System.Runtime.InteropServices;
        namespace CsharpProject
        public static extern double findSquareRoot(double value);
        class Test{                     
        private void displayRoot(double value)
         double root=findSquareRoot(value);
         System.Console.WriteLine("Square root is "+root);

      (ii)Create dynamic link library CppProject.dll from Microsoft Visual Studio.    

                (iii)Copy the dll in the bin/debug or bin/release folder of the project and compile the C# project. 
 (Note: if you get an error message "PInvokeStackImbalance was detected", then you go to Debug-> Exceptions. Then expand "Managed Debugging Assistants", and disselect "PInvokeStackImbalance". Then it will work)

Method 2: Lengthy Method:
               (i) Create a C# file Test.cs under the project CsharpProject and include the following content: 

      using System.Runtime.InteropServices;
      namespace CsharpProject

      static class NativeMethods
       public static extern IntPtr LoadLibrary(string dllToLoad);
        public static extern IntPtr GetProcAddress
             (IntPtr hModule, string procedureName);

        public static extern bool FreeLibrary(IntPtr hModule);
       class Test
        private delegate double findSquareRoot(double value);
        IntPtr pDll =           NativeMethods.LoadLibrary(@"CppProject.dll");
        IntPtr pAddressOfFunctionToCall = NativeMethods.GetProcAddress(pDll, "findSquareRoot");
        findSquareRoot squareRoot = 
                 ( findSquareRoot)
                  typeof( findSquareRoot ));
         private void displayroot(double value)
          double root=squareRoot(value);
          System.Console.WriteLine("Square root is "+root);

       (ii)Create dynamic link library CppProject.dll from Microsoft Visual Studio.    
        (iii)Copy the dll in the bin/debug or bin/release folder of the project and compile the C# project. 

How to Test?

To test, you go to Program.cs file which contains the startup Main functon, and then write the following piece of code in the Main function:
   new Test().displayRoot(12.44);
After your run, you will get the square root of 12.44 displayed in the console.

I think you got something regarding how C++ dll can be used in C# applications.

Any confusion, contact me (krishna444@gmail.com).

Thanks for reading :)

Why ThreadPool?

How to Assign Thread in ThreadPool ?

ThreadPool.QueueUserWorkItem(new WaitCallback(FunctionCall), PersonalizeDataForTherad);

How To Assign Timer Thread in ThreadPool ?

ThreadPool.RegisterWaitForSingleObject( AutoResetEventObject, new WaitOrTimerCallback(FunctionCall), PersonalizeData, TimeOut, false );

Some Points :

  • There is no way to cancel a work item after it has been queued.
  • Each process can have only one operating system thread pool.

The thread pool is created the first time you create an instance of the ThreadPool class. The thread pool has a default limit of 25 threads per available processor, which could be changed using CorSetMaxThreads as defined in the mscoree.h file. Each thread uses the default stack size and runs at the default priority. Each process can have only one operating system thread pool.

There is only one ThreadPool object per process. The thread pool is created the first time you call ThreadPool.QueueUserWorkItem, or when a timer or registered wait operation queues a callback method. One thread monitors all tasks that have been queued to the thread pool. When a task has completed, a thread from the thread pool executes the corresponding callback method. There is no way to cancel a work item after it has been queued.

The number of operations that can be queued to the thread pool is limited only by available memory; however, the thread pool will enforce a limit on the number of threads it allows to be active in the process simultaneously (which is subject to the number of CPUs and other considerations). Each thread uses the default stack size, runs at the default priority, and is in the multithreaded apartment. If one of the threads becomes idle (as when waiting on an event) in managed code, the thread pool injects another worker thread to keep all the processors busy. If all thread pool threads are constantly busy, but there is pending work in the queue, the thread pool will, after some period of time, create another worker thread. However, the number of threads will never exceed the maximum value. The ThreadPool also switches to the correct AppDomain when executing ThreadPool callbacks.

There are several scenarios in which it is appropriate to create and manage your own threads instead of using the ThreadPool. You should do so:

  • If you require a task to have a particular priority.
  • If you have a task that might run a long time (and therefore block other tasks).
  • If you need to place threads into a single-threaded apartment (all ThreadPool threads are in the multithreaded apartment).
  • If you need to have a stable identity associated with the thread. For example, you might want to use a dedicated thread to abort that thread, suspend it, or discover it by name.

What is the difference between foreground and background thread?

• Foreground threads have the ability to prevent the current application from terminating. The CLR will not shut down an application (which is to say, unload the hosting AppDomain) until all foreground threads have ended.

• Background threads (sometimes called daemon threads) are viewed by the CLR as expendable paths of execution that can be ignored at any point in time (even if they are currently laboring over some unit of work). Thus, if all foreground threads have terminated, any and all background threads are automatically killed when the application domain unloads.

Comparing the Timer Classes in the .NET Framework Class Library

Timers often play an important role in both client applications and server-based components (including Windows services). Writing effective timer-driven managed code requires a clear understanding of program flow and the subtleties of the .NET threading model. The .NET Framework Class Library provides three different timer classes: System.Windows.Forms.Timer, System.Timers.Timer, and System.Threading.Timer. Each of these classes has been designed and optimized for use in different situations. This article examines the three timer classes and helps you gain an understanding of how and when each class should be used. System.Windows.Forms.Timer
If you're looking for a metronome, you've come to the wrong place. The timer events raised by this timer class are synchronous with respect to the rest of the code in your Windows Forms app. This means that application code that is executing will never be preempted by an instance of this timer class (assuming you don't call Application.DoEvents). Just like the rest of the code in a typical Windows Forms application, any code that resides inside a timer event handler (for this type of timer class) is executed using the application's UI thread. During idle time, the UI thread is also responsible for processing all messages in the application's Windows message queue. This includes Windows API messages as well as the Tick events raised by this timer class. The UI thread processes these messages whenever your application isn't busy doing something else.
If you wrote Visual Basic code prior to Visual Studio .NET, you probably know that in a Windows-based application the only way to allow the UI thread to respond to Windows messages while executing in an event handler is to call the Application.DoEvents method. Just like with Visual Basic, calling Application.DoEvents from the .NET Framework can cause many problems. Application.DoEvents yields control to the UI message pump, allowing all pending events to be processed. This can alter the expected path of execution that I just mentioned. If Application.DoEvents is called from your code, your program flow may be interrupted in order to process the timer events generated by an instance of this class. This can cause unexpected behaviors and make debugging difficult. Programming the System.Windows.Forms.Timer class couldn't be easier—it has a very simple and intuitive programmatic interface. The Start and Stop methods essentially provide an alternate way of setting the Enabled property (which itself is a thin wrapper around Win32® SetTimer/ KillTimer functions). The Interval property, which I just mentioned, is self-explanatory. Even though you can technically set the Interval property as low as one millisecond, you should be aware that the .NET Framework documentation states that this property is only accurate to approximately 55 milliseconds (provided that the UI thread is available for processing). Capturing the events raised by an instance of the System.Windows.Forms.Timer class is handled by wiring the Tick event to a standard EventHandler delegate, as shown by the code snippet in the following example:
System.Windows.Forms.Timer tmrWindowsFormsTimer = new
tmrWindowsFormsTimer.Interval = 1000;
tmrWindowsFormsTimer.Tick += new
private void tmrWindowsFormsTimer_Tick(object sender,
  System.EventArgs e) {
//Do something on the UI thread...

The .NET Framework documentation refers to the System.Timers.Timer class as a server-based timer that was designed and optimized for use in multithreaded environments. Instances of this timer class can be safely accessed from multiple threads. Unlike the System.Windows.Forms.Timer, the System.Timers.Timer class will, by default, call your timer event handler on a worker thread obtained from the common language runtime (CLR) thread pool. This means that the code inside your Elapsed event handler must conform to a golden rule of Win32 programming: an instance of a control should never be accessed from any thread other than the thread that was used to instantiate it.
The System.Timers.Timer class provides an easy way to deal with this dilemma—it exposes a public SynchronizingObject property. Setting this property to an instance of a Windows Form (or a control on a Windows Form) will ensure that the code in your Elapsed event handler runs on the same thread on which the SynchronizingObject was instantiated.
If you use the Visual Studio .NET toolbox, Visual Studio .NET will automatically set the SynchronizingObject property to the current form instance. At first it may seem as though using this timer class with the SynchronizingObject property makes it functionally equivalent to using the System.Windows.Forms.Timer. For the most part, it is. When the operating system notifies the System.Timers.Timer class that the enabled timer has elapsed, the timer uses the SynchronizingObject.Begin.Invoke method to execute the Elapsed event delegate on the thread on which the SynchronizingObject's underlying handle was created. The event handler will be blocked until the UI thread is able to process it. However, unlike with System.Windows.Forms.Timer, the event will still eventually be raised. As you saw in Figure 2, System.Windows.Forms.Timer will not raise events that occur while the UI thread is unable to process them, whereas System.Timers.Timer will queue them to be processes when the UI thread is available.
System.Timers.Timer tmrTimersTimer = new System.Timers.Timer();
tmrTimersTimer.Interval = 1000;
tmrTimersTimer.Elapsed += new
tmrTimersTimer.SynchronizingObject = this; //Synchronize with
                                         //the current form...
private void tmrTimersTimer_Elapsed(object sender,
  System.Timers.ElapsedEventArgs e) {
// Do something on the UI thread (same thread the form was
// created on)...
// If we didn't set SynchronizingObject we would be on a
// worker thread...
As you can see, it didn't skip a beat—even when the UI thread was sleeping. An Elapsed event handler was queued to be executed at each event interval. Because the UI thread was sleeping, however, the sample application displays the five timer events (4 through 8) all at once when the UI thread wakes up again and is able to process the handlers.
As I mentioned earlier, the System.Timers.Timer class members are very similar to those of the System.Windows.Forms.Timer class. The biggest difference is that System.Timers.Timer is a wrapper around Win32 waitable timer objects and raises an Elapsed event on a worker thread rather than a Tick event on the UI thread. The Elapsed event must be connected to an event handler that matches the ElapsedEventHandler delegate. The event handler receives an argument of type ElapsedEventArgs.
Above and beyond the standard EventArgs members, the ElapsedEventArgs class exposes a public SignalTime property, which contains the exact time the timer elapsed. Because this class supports access from different threads, it is conceivable that the Stop method may be called on a thread other than the thread that is used for the Elapsed event. This could potentially result in the Elapsed event firing even after the Stop method has been called. You can deal with this by comparing the SignalTime property to the time the Stop method was called.
The System.Timers.Timer class also provides an AutoReset property that determines if the Elapsed event should fire continuously or just once. Keep in mind that resetting the Interval property after the timer has started will reset the current count back to zero. For example, if the interval is set to 5 seconds and 3 seconds have already elapsed before the interval is changed to 10 seconds, the next timer event will be 13 seconds from the last timer event.
The third timer class comes from the System.Threading namespace. I'd like to say that this is the best of all timer classes, but that would be misleading. For one thing, I was surprised to find that instances of this class are not inherently thread safe, given that it resides in the System.Threading namespace. (Obviously, this doesn't mean it can't be used in a thread-safe manner.) The programmatic interface of this class is not consistent with the other two timer classes and it's also a bit more cumbersome.
Unlike the previous two timer classes that I have just covered, System.Threading.Timer has four overloaded constructors. The following shows what they look like:
public Timer(TimerCallback callback, object state, long dueTime,
           long period);
public Timer(TimerCallback callback, object state, UInt32 dueTime,
           UInt32 period);
public Timer(TimerCallback callback, object state, int dueTime,
           int period);
public Timer(TimerCallback callback, object state, TimeSpan dueTime,
           TimeSpan period);

The first parameter (callback) requires a TimerCallback delegate that points to a method with the following signature:
public void TimerCallback(object state);

The second parameter (state) can either be null or an object containing application-specific information. This state object is passed to your timer callback function during each timer event invocation. Keep in mind that the timer callback function is executed on a worker thread, so you'll want to ensure that you have thread-safe access to the state object.
The third parameter (dueTime) allows you to specify when the initial timer event should be fired. You can specify 0 to start the timer immediately or to prevent the timer from automatically starting, you can use the System.Threading.Timeout.Infinite constant.
The fourth parameter (period) allows you to specify the interval (in milliseconds) at which the callback function should be called. Specifying either 0 or Timeout.Infinite for this parameter will disable subsequent timer event invocations.
Once the constructor has been called, you can still alter the dueTime and period settings by using the Change method. This method has the following four overloads:
public bool Change(int dueTime, int period);
public bool Change(uint dueTime, uint period);
public bool Change(long dueTime, long period);
public bool Change(TimeSpan dueTime, TimeSpan period);

Here's the code I used in the sample application to start and stop this timer:
//Initialize the timer to not start automatically...
System.Threading.Timer tmrThreadingTimer = new
                     null, System.Threading.Timeout.Infinite, 1000);
//Manually start the timer...
tmrThreadingTimer.Change(0, 1000);
//Manually stop the timer...
tmrThreadingTimer.Change(Timeout.Infinite, Timeout.Infinite);

Unlike the System.Timers.Timer class, there is no counterpart to the SynchronizingObject property that was offered by the System.Timers.Timer class. Any operations that require access to UI controls should be marshaled using the Control's Invoke or BeginInvoke methods.
Thread-safe Programming with Timers
To maximize code reuse, the sample application calls the same ShowTimerEventFired method from all three different types of timer events. Here are the three timer event handlers:
private void tmrWindowsFormsTimer_Tick(object sender,
  System.EventArgs e) {
  ShowTimerEventFired(DateTime.Now, GetThreadName());
private void tmrTimersTimer_Elapsed(object sender,
  System.Timers.ElapsedEventArgs e) {
  ShowTimerEventFired(DateTime.Now, GetThreadName());
private void tmrThreadingTimer_TimerCallback(object state) {
  ShowTimerEventFired(DateTime.Now, GetThreadName());
As you can see, the ShowTimerEventFired method takes the current time and current thread name as arguments. In order to distinguish worker threads from the UI thread, the main entry point for the sample application sets the Name property of the CurrentThread object to "UIThread." The GetThreadName helper method returns either the value of Thread.CurrentThread.Name or "WorkerThread" if the Thread.CurrentThread.IsThreadPoolThread property is true. Because the timer events for System.Timers.Timer and System.Threading.Timer execute on worker threads, it is imperative that any user interface code within these event handlers be marshaled back onto the UI thread for processing. To do this, I created a delegate called ShowTimerEventFiredDelegate:
private delegate void
  (DateTime eventTime,
  string threadName);
ShowTimerEventFiredDelegate allows the ShowTimerEventFired method to call itself back on the UI thread.
private void ShowTimerEventFired(DateTime eventTime,
  string threadName) {
  //InvokeRequired will be true when using
  //System.Threading.Timer or System.Timers.Timer (without a
  if (lstTimerEvents.InvokeRequired) {
      //Marshal this call back to the UI thread (via the form
            new object[] {eventTime, threadName});
      lstTimerEvents.TopIndex = lstTimerEvents.Items.Add(
          String.Format("—> Timer Event {0} @ {1} on Thread:
          ++_tickEventCounter, eventTime.ToLongTimeString(),
It's very easy to determine whether you can safely access a Windows Forms control from the current thread by querying its InvokeRequired property. In this example, if the ListBox's InvokeRequired property is true, the form's BeginInvoke method can be used to call the ShowTimerEventFired method again via ShowTimerEventFiredDelegate. This will ensure that the ListBox Add method executes on the UI thread.
As you can see, there are many issues you need to be aware of when programming with asynchronous timer events. I recommend that you read Ian Griffith's article "Windows Forms: Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads," from the February 2003 issue of MSDN Magazine before using either System.Timers.Timer or System.Threading.Timer.
Dealing with Timer Event Reentrance
There's another subtle issue you'll need to consider when working with asynchronous timer events, such as the events generated by System.Timers.Timer and System.Threading.Timer. The problem has to do with code reentrance. If the code in your timer event handler takes longer to execute than the interval at which the timer is raising events, and you haven't taken the necessary precautions to guard against multithreaded access to your objects and variables, then you could be in for some difficult debugging sessions. Take a look at the following code snippet:
private int tickCounter = 0;

private void tmrTimersTimer_Elapsed(object sender,
  System.Timers.ElapsedEventArgs e) {
  System.Threading.Interlocked.Increment(ref tickCounter);
Assuming your timer Interval property is set to 1000 milliseconds, you may be surprised to find out that the first message box that pops up will show a value of 5. This is because during the five seconds that the first timer event was sleeping, the timer kept on generating Elapsed events on different worker threads. Hence, the value of the tickCounter variable was incremented five times before the processing of the first timer event was completed. Notice how I used the Interlocked.Increment method to increment the tickCounter variable in a thread-safe manner. There are other ways to do this, but the Interlocked.Increment method was specifically designed for this kind of operation. One easy way to solve this type of reentrance problem is to sandwich your timer event handler in a block of code that temporarily disables and then reenables the timer, as shown in the following example:
private void tmrTimersTimer_Elapsed(object sender,
  System.Timers.ElapsedEventArgs e) {
  tmrTimersTimer.Enabled = false;
  System.Threading.Interlocked.Increment(ref tickCounter);
  tmrTimersTimer.Enabled = true;
With this code in place, message boxes will show up every five seconds and, as you would expect, the value of tickCounter will be incremented by one each time. Another option would be to use a synchronization primitive such as Monitor or a mutex to ensure that all future events are queued until the current handler has finished executing.
For a quick recap of my look at the three timer classes available in the .NET Framework, see the table below which compares these three classes. A point you may want to consider when working with timers is whether your problem can be solved more simply by using the Windows Scheduler (or the AT command for that matter) to run a standard executable periodically.
System.Windows.Forms System.Timers System.Threading
Timer event runs on what thread? UI thread UI or worker thread Worker thread
Instances are thread safe? No Yes No
Familiar/intuitive object model? Yes Yes No
Requires Windows Forms? Yes No No
Metronome-quality beat? No Yes* Yes*
Timer event supports state object? No No Yes
Initial timer event can be scheduled? No No Yes
Class supports inheritance? Yes Yes No
* Depending on the availability of system resources (for example, worker threads)
(Reference: http://msdn.microsoft.com/en-us/magazine/cc164015.aspx#)