Check List for Creating/updating a Installer

A simple checklist that i see quite helpful before one start on updating or creating a installer.

Assembly Name
Installation Path
Component Name
Parent Component
Mandatory Component?
COM component?
Requires Registration?
Install in GAC
Pre-Requisites
Supported OS
Supported .Net Platform
Special Service Pack requirement
Third Party Product Dependencies
Any Specific Requirements
Remove on Un-Install
Default Configuration (registry keys)
Shortcut Required?

Background Threads and Thread priority

Background Threads

When we create a thread, often we don’t change the IsBackground property, so by default it’s created as a foreground thread. A foreground thread and a background thread are identical in all respects, except that the foreground thread has a message pump to handle UI messages. A choice of making a thread FG (foreground) or BG (background) may affect how your application behaves when it’s terminated. A FG thread may keep the application alive if it’s not stopped from what its doing, however the managed runtime will close all BG threads cleanly without throwing any exceptions. This is true only if it’s a process shutdown. A BG thread will throw same ThreadAbortException as FG when its terminated using Abort() or due to some other error in code its executing.

Thread priority

Setting thread priorities is a tricky job and it’s not recommended to change it for fun unless the requirements dictate to do so. .net provides 5 states in thread priority

A thread can be assigned any one of the following priority values:

• Highest
• AboveNormal
• Normal
• BelowNormal
• Lowest

By default a thread is created with Normal priority. Setting thread priorities does not guarantee that the OS will not change the priorities dynamically; it’s just a recommendation from our end to the OS to run the thread on specified priority, which generally the OS honors.

Even when running two threads with same priority and one set as a FG and other as BG, the threads will be scheduled differently. I have observed that running one FG and other in BG in tight loop (no sleeps and joins in the thread) will have a drastic change in scheduling based on if the application window is in focus or not.

Following image shows that when the application is not a foreground window, both the threads are scheduled with equal time slice and we can see messages printing from both threads in succession.

The behavior changes when the application receives focus as can be seen from image below.

This can be considered normal as a foreground application received a dynamic priority boost by the OS, which allows for more CPU time slice for all the threads in the application.