Wednesday, June 30, 2010

app.config and user.config FAQ

A great tutorial and insight into the app.config file and user.config file

One of the cool new features in .NET 2.0/VS 2005 is an easy to use,
extensible API to manage application/user settings, i.e., data that
needs to be persisted across runs of a client application. You can
find more information about this feature on MSDN or in my earlier blog
posts on this topic.

While the feature is easy to use in general, we often get questions
from users trying more advanced scenarios about why a certain aspect
of the feature works in a particular way or how to customize some
behavior. The answers to these questions are generally in the MSDN
docs, but can sometimes be hard to find. I thought it would be useful
to cover this information in a FAQ for easy future reference. I will
be updating the FAQ as and when there are more questions to add.

Q: I notice there are two kinds of settings - application scoped and
user scoped. Application scoped settings seem to be read-only and I
cannot change them at runtime. Why is that?

A: There are two main types of settings that applications generally
want to store: (1) certain data like connection strings and web
references that don't change often, but should be possiblep for an
admin to change and therefore cannot be hardcoded into the application
and (2) user preferences and customization that can change any time.
Application scoped settings are useful in scenario (1) and user scoped
settings, in the latter. They are essentially read only from tche
application's point of view and aren't meant to be changed by the
user, but admins could go and edit the file if they want to. An
additional reason for this has to do with how the default
SettingsProvider stores settings - application scoped settings go in
the exe configuration file and user scoped settings in user.config
files located in the user data path. Generally, exe config files
shouldn't be written to at runtime by the application, since the user
may not have access to them (if the application is installed in
c:\Program Files\..., only privileged users have access, for example).
Even if they do, it is not usually a good idea for a user to control
changing a file that affects every other user of the application.

Q: You said user.config files go in the user data path. How can I
locate the file? Are there multiple files for an application or just

A: As mentioned before, the default SettingsProvider for client
applications (called the LocalFileSettingsProvider) stores settings in
the application configuration files. In .NET v1 and v1.1, there were
two levels of config files - machine.config and app.exe.config (where
'app.exe' is the name of the application). In v2.0, we have added two
more levels of configuration to store user specific data - one that
goes in the roaming user profile path and another in the local user
profile path. On XP, the profile directories would be something like
'c:\Documents and Settings\<username>\Application Data' and
'c:\Documents and Settings\<username>\Local Settings\Application Data'
respectively. These directories are the recommended location (per
Windows Logo requirements) for storing user specific information and
most applications (like Outlook and Visual Studio) put user data
somewhere under here.

The exact path of the user.config files looks something like this:

<Profile Directory>\<Company Name>\<App Name>_<Evidence
Type>_<Evidence Hash>\<Version>\user.config


<Profile Directory> - is either the roaming profile directory or the
local one. Settings are stored by default in the local user.config
file. To store a setting in the roaming user.config file, you need to
mark the setting with the SettingsManageabilityAttribute with
SettingsManageability set to Roaming.

<Company Name> - is typically the string specified by the
AssemblyCompanyAttribute (with the caveat that the string is escaped
and truncated as necessary, and if not specified on the assembly, we
have a fallback procedure).

<App Name> - is typically the string specified by the
AssemblyProductAttribute (same caveats as for company name).

<Evidence Type> and <Evidence Hash> - information derived from the app
domain evidence to provide proper app domain and assembly isolation.

<Version> - typically the version specified in the
AssemblyVersionAttribute. This is required to isolate different
versions of the app deployed side by side.

The file name is always simply 'user.config'.

If you want to get to the path programmatically, you can do it using
the Configuration Management API (you need to add a reference to
System.Configuration.dll). For example, here is how you can get the
local user.config file path:

Configuration config =
Console.WriteLine("Local user config path: {0}", config.FilePath);

Q: Why is the path so obscure? Is there any way to change/customize it?

A: The path construction algorithm has to meet certain rigorous
requirements in terms of security, isolation and robustness. While we
tried to make the path as easily discoverable as possible by making
use of friendly, application supplied strings, it is not possible to
keep the path totally simple without running into issues like
collisions with other apps, spoofing etc.

The LocalFileSettingsProvider does not provide a way to change the
files in which settings are stored. Note that the provider itself
doesn't determine the config file locations in the first place - it is
the configuration system. If you need to store the settings in a
different location for some reason, the recommended way is to write
your own SettingsProvider. This is fairly simple to implement and you
can find samples in the .NET 2.0 SDK that show how to do this. Keep in
mind however that you may run into the same isolation issues mentioned
above .

Q: I deployed my application using Clickonce and saved some settings,
but can't find the user.config file.

A: The path algorithm mentioned above is not used in the Clickonce
case. Instead, the local user.config file goes in the Clickonce Data
directory (the <Version> part of the path will still be included).
There is no roaming user.config file for Clickonce applications.

Q: How are my strongly typed properties serialized as settings? I
couldn't get the <insert type here> class to serialize correctly.

A: There are two primary mechanisms that ApplicationSettingsBase uses
to serialize settings - (1) If a TypeConverter exists that can convert
to and from string, we use it. (2) If not, we fallback to the
XmlSerializer. While most common types can be serialized in one of
these ways, there are some types that may not. In such cases, you have
a few different options:

* Implement a TypeConverter for the type that can convert to and
from string. The implementation can use a suitable serialization
mechanism like one of the formatters/serializers that ship in the
Framework or any custom mechanism you wish. You can then specify this
converter on the type itself or on the property in your settings
* Specify a particular SettingsSerializeAs enum value using a
SettingsSerializeAsAttribute. For example, if you wish to serialize a
setting in binary format, simply specify SettingsSerializeAs.Binary.

Q: My application has a few user scoped settings, but I notice Visual
Studio puts them in app.config. I thought they go in user.config

A: The configuration system is hierarchical and has this ordering:
machine -> application -> roaming user -> local user. When you query a
configuration section at any level, you get a merged view of the
sections declared in that level and those below it (with machine being
the lowest level and local user the highest). The section handler
defines how the merge happens and for settings, a setting value
specified in, say, local user config trumps the one specified in
application config.

So for user scoped settings, you can think of the values specified in
app.config to be install time defaults. When the settings are saved
into user.config, those values will override these defaults. This way
admins have the option of changing the defaults. Note that the
defaults can also be specified by means of a
DefaultSettingValueAttribute. The provider will use this value if no
value is specified for a setting in any level of config.

Q: Why is there a version number in the user.config path? If I deploy
a new version of my application, won't the user lose all the settings
saved by the previous version?

A: There are couple of reasons why the user.config path is version
sensitive. (1) To support side-by-side deployment of different
versions of an application (you can do this with Clickonce, for
example). It is possible for different version of the application to
have different settings saved out. (2) When you upgrade an
application, the settings class may have been altered and may not be
compatible with what's saved out, which can lead to problems.

However, we have made it easy to upgrade settings from a previous
version of the application to the latest. Simply call
ApplicationSettingsBase.Upgrade() and it will retrieve settings from
the previous version that match the current version of the class and
store them out in the current version's user.config file. You also
have the option of overriding this behavior either in your settings
class or in your provider implementation.

Q: Okay, but how do I know when to call Upgrade?

A: Good question. In Clickonce, when you install a new version of your
application, ApplicationSettingsBase will detect it and automatically
upgrade settings for you at the point settings are loaded. In
non-Clickonce cases, there is no automatic upgrade - you have to call
Upgrade yourself. Here is one idea for determining when to call

Have a boolean setting called CallUpgrade and give it a default value
of true. When your app starts up, you can do something like:

if (Properties.Settings.Value.CallUpgrade) {
Properties.Settings.Value.CallUpgrade = false;

This will ensure that Upgrade() is called only the first time the
application runs after a new version is deployed.

Update: 12/10/2005

Q: Is there a way to access settings from the configuration files if I
don't have a reference to the settings class that owns them?

A: Yes, you might sometimes require to access certain settings, but
you don't have access to the settings class itself. For example, the
default settings class generated by the settings designer in VS 2005
is internal to the assembly it is defined in. What if you need to
access some settings from a different assembly, let's say, a dll that
is loaded by your application? The settings API provides a useful
mechanism for this through the SettingsGroupNameAttribute. Usually,
the settings provider uses the fully qualified name of your settings
class as the key to isolate your settings from those belonging to
other classes. This attribute allows you to access settings with a
different key or 'group name'. So to access settings from the
application's settings class, all the dll needs to do is define its
own settings class with properties that match the other class, and
apply a SettingsGroupNameAttribute, giving it the other class' name as
the group name. A small caveat: if you want to do this in VS, make
sure you apply the attribute to the user partial class you get to by
clicking 'View Code', and not the designer owned partial class, since
any changes to the latter can get overwritten by the settings

Q: Wait, you might ask, this is a rather powerful capability. Is it a
security hole? Someone might access my settings without my knowledge
or permission!

A: Well, this isn't really a security hole for two reasons:

From a security point of view, isolation is provided at the app
domain level. The CLR recommended way of hosting untrusted code is to
load it in a separate app domain. When you create an app domain, you
can specify a unique friendly name for it and point it to an
application configuration file of your choice. The unique friendly
name ensures that the app domain gets separate user configuration
files as well. Thus, the code cannot access your settings, since it
doesn't have access to your configuration files. Conversely, any code
that has access to your configuration files can access the settings
without using the SettingsGroupNameAttribute anyway, since it can use
the low level configuration APIs to do so (this requires
ConfigurationPermission for read though, and much higher permissions
for write).
If you are really paranoid and don't want users of the
application or anyone else, including code running in the same app
domain as your settings class, to be able to read your settings
outside of your class, you can choose to encrypt the settings before
pushing them to the provider, and decrypt when you read them out. The
settings API does not provide any specific way to do this, but you can
use the crypto API in the .NET Framework. The configuration API also
has the ability to encrypt configuration sections - see this article
for more information.

Q: Does all this mean I cannot access settings in partial trust?

A: Not at all. We have done the work to ensure you can safely access
your settings in partial trust. In fact, this should 'just work' for
you in terms of reading and writing user scoped settings from your
application. The only difference is that you cannot write out an
unlimited amount of data, for obvious reasons. The number of bytes you
can write through the settings API (specifically, the
LocalFileSettingsProvider) in partial trust is restricted by an admin
controlled quota, which is specified by the IsolatedStoragePermission
class. This is just like how Isolated Storage itself works.

Q: You mentioned the configuration API a couple of times. What is this
and how is it different from the settings API? I am a little confused.

A: There is a fundamental distinction between the settings API and the
configuration API. The former provides an object model to manage
application settings. This model uses a provider based storage scheme,
so the storage aspect is abstracted away. Where the settings are
stored is a provider specific detail - it could store them in raw
files, in SQL server, in the registry or call a remote web service to
retrieve them. The default settings provider we ship happens to use
configuration to store settings, since that's the most obvious store
for settings in client applications. The configuration API is a little
more low level and lets you create and update configuration sections
in config files. So in some sense, the settings API sits on top of

So if what you want to do is store application settings and user
preferences, then the settings API is the way to go. If you really
need to implement configuration sections and/or access certain
sections in config directly, use the configuration API.

Q: Is the settings functionality available only to Windows Forms applications?

A: The settings API itself has no restrictions at all - you can use it
in any kind of application - client, web, VSTO, console, WPF etc. The
default settings provider, LocalFileSettingsProvider, uses
configuration to store settings, so it has certain limitations. For
example, ASP.NET applications do not have user.config files, so you
cannot write user scoped settings in web applications using this
provider. Ofcourse, you can use the Profiles feature in ASP.NET 2.0 to
very conveniently store user scoped settings. User.config files are
also not supported for VSTO apps (in general, where the host
application is native, like Outlook, Word or even IE). In these cases,
you will need to write your own settings provider (which is quite easy
to do, by the way, and there are good samples and docs in MSDN that
describe how to do this) to be able to read/write user scoped
settings. For the basic kinds of managed client applications like
console, Windows Forms and WPF however, the LocalFileSettingsProvider
is fully supported.

Other approaches to create single instance!167AD7A5AB58D5FE!1834.entry

Making your WPF application single instance

I used the ideas in this article. However, when bringing my
application to the top, I used my own methods. Below is the link to
the article, and the code that I used.

However, I used the following:
In my Startup.cs file I did the following:

static Mutex mutex = new Mutex(true,
public static void Main()
if (mutex.WaitOne(TimeSpan.Zero, true))
MyApp app = new MyApp
// send our Win32 message to make the currently
running instance
// jump on top of all the other windows
catch (Exception e)
{//Catch all un-handle exception from the application


And in my NativeMethods.cs I did the following:
[DllImport("User32", EntryPoint = "FindWindow")]
public static extern IntPtr FindWindow(string lpClassName, string

[DllImport("User32", EntryPoint = "BringWindowToTop")]
public static extern bool BringWindowToTop(IntPtr wHandle);

[DllImport("User32", EntryPoint = "SetForegroundWindow")]
public static extern bool SetForegroundWindow(IntPtr wHandle);

[DllImport("User32", EntryPoint = "SetFocus")]
public static extern bool SetFocus(IntPtr wHandle);

static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

public static void BringTMForeGround()
bool ret = false;
IntPtr hWnd = NativeMethods.FindWindow(null, "Title of
Application Window"); // Get Window of App2

if (hWnd == IntPtr.Zero)
FindWindowLike.Window[] list = FindWindowLike.Find(0, "Title
of Application Window", "");
if (list.Length >= 1)
hWnd = (IntPtr)list[0].Handle;
if (hWnd != IntPtr.Zero) // Check if App2 exists
ret = NativeMethods.SetForegroundWindow(hWnd);
ret = NativeMethods.ShowWindow(hWnd, 9);
ret = NativeMethods.BringWindowToTop(hWnd);
//ret = SetFocus(hWnd);
catch (Exception)

The function FindWinowLike was another class and this is whats in it:
using System;
using System.Collections;
using System.Runtime.InteropServices;
using System.Text;

namespace MyAppNamespace
public class FindWindowLike

public class Window
public string Title;
public string Class;
public int Handle;

private static extern int GetWindow(int hwnd, int wCmd);

private static extern int GetDesktopWindow();

[DllImport("user32", EntryPoint = "GetWindowLongA")]
private static extern int GetWindowLong(int hwnd, int nIndex);

private static extern int GetParent(int hwnd);

[DllImport("user32", EntryPoint = "GetClassNameA")]
private static extern int GetClassName(
int hWnd, [Out] StringBuilder lpClassName, int nMaxCount);

[DllImport("user32", EntryPoint = "GetWindowTextA")]
private static extern int GetWindowText(
int hWnd, [Out] StringBuilder lpString, int nMaxCount);

private const int GWL_ID = (-12);
private const int GW_HWNDNEXT = 2;
private const int GW_CHILD = 5;

public static Window[] Find(int hwndStart, string findText, string

ArrayList windows = DoSearch(hwndStart, findText, findClassName);

return (Window[])windows.ToArray(typeof(Window));

} //Find

private static ArrayList DoSearch(int hwndStart, string findText,
string findClassName)

ArrayList list = new ArrayList();

if (hwndStart == 0)
hwndStart = GetDesktopWindow();

int hwnd = GetWindow(hwndStart, GW_CHILD);

while (hwnd != 0)

// Recursively search for child windows.
list.AddRange(DoSearch(hwnd, findText, findClassName));

StringBuilder text = new StringBuilder(255);
int rtn = GetWindowText(hwnd, text, 255);
string windowText = text.ToString();
windowText = windowText.Substring(0, rtn);

StringBuilder cls = new StringBuilder(255);
rtn = GetClassName(hwnd, cls, 255);
string className = cls.ToString();
className = className.Substring(0, rtn);

if (GetParent(hwnd) != 0)
rtn = GetWindowLong(hwnd, GWL_ID);

if (windowText.Length > 0 && windowText.StartsWith(findText) &&
(className.Length == 0 || className.StartsWith(findClassName)))
Window currentWindow = new Window();

currentWindow.Title = windowText;
currentWindow.Class = className;
currentWindow.Handle = hwnd;


hwnd = GetWindow(hwnd, GW_HWNDNEXT);


return list;

} //DoSearch

} //Class


Monday, June 28, 2010

What is in the bitmap header

from -


The header consists of the following fields. Note that we are assuming
short int of 2 bytes, int of 4 bytes, and long int of 8 bytes. Further
we are assuming byte ordering as for typical (Intel) machines. The
header is 14 bytes in length.

typedef struct {
unsigned short int type; /* Magic identifier */
unsigned int size; /* File size in bytes */
unsigned short int reserved1, reserved2;
unsigned int offset; /* Offset to image data, bytes */

The useful fields in this structure are the type field (should be
'BM') which is a simple check that this is likely to be a legitimate
BMP file, and the offset field which gives the number of bytes before
the actual pixel data (this is relative to the start of the file).
Note that this struct is not a multiple of 4 bytes for those
machines/compilers that might assume this, these machines will
generally pad this struct by 2 bytes to 16 which will unalign the
future fread() calls - be warned.

The image info data that follows is 40 bytes in length, it is
described in the struct given below. The fields of most interest below
are the image width and height, the number of bits per pixel (should
be 1, 4, 8 or 24), the number of planes (assumed to be 1 here), and
the compression type (assumed to be 0 here).

typedef struct {
unsigned int size; /* Header size in bytes */
int width,height; /* Width and height of image */
unsigned short int planes; /* Number of colour planes */
unsigned short int bits; /* Bits per pixel */
unsigned int compression; /* Compression type */
unsigned int imagesize; /* Image size in bytes */
int xresolution,yresolution; /* Pixels per meter */
unsigned int ncolours; /* Number of colours */
unsigned int importantcolours; /* Important colours */

The compression types supported by BMP are listed below :

* 0 - no compression
* 1 - 8 bit run length encoding
* 2 - 4 bit run length encoding
* 3 - RGB bitmap with mask

Only type 0 (no compression will be discussed here.

How to find the image format of an image in C#

from stackoverflow -
using(Image img = Image.FromFile(@"C:\path\to\img.jpg"))
if (img.RawFormat.Equals(System.Drawing.Imaging.ImageFormat.Jpeg))
// ...

Proper way to rethrow an exception in c#

just do "throw;" don't do "throw ex" or something like that.

Monday, June 14, 2010

How to get a specific version or get a specific label from TFS to a different location

Create a new workspace and specify that workspace to have a different location

Unhandled exception in BackgroundWorker

I was using the BackgroundWorker in WPF and had an unhandled exception
there and needed a better way to deal with this error. This is how I
did it:
I used the RunWorkerCompleted event. In this event, if the e.Error !=
null, I set a string value ErrorMessage to the message, and I call a
function ErrorOccurred which then raises an event that my calling
application caught. Below is my code:

My main Class

This code is just put together and probably won't work, but should
give you the general idea. This is my Window that calls the
background worker. I have two events, Finished and Error. If the
Error occurs, I do something, if its finishes successfully I do
something else.
public partial class MainWindow : Window
private DoWork Worker = new DoWork();

public MainWindow()
Worker.Finished += new FinishedEventHandler(Worker_Finished);
Worker.Error += new ErrorEventHandler(Worker_Error);

void Worker_Finished(object sender, EventArgs e, List<Response> rList)
//do something when finished
void Worker_Error(object sender, EventArgs e, string errorMessage)
//do something if error

private void btnWork_ItemClick(object sender, ClickEventArgs e)
if (!Worker.IsBusy())

This is my Worker class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel;
using System.Windows;

namespace MyNamespace
// A delegate type for hooking up when the backgroundworker is
finished. It returns the Response object
public delegate void FinishedEventHandler(object sender, EventArgs
e, List<Something> rList);
public delegate void ErrorEventHandler(object sender, EventArgs e,
string errorMessage);

public class DoWork

public BackgroundWorker worker;
List<Response> ResponseList;// = new List<Response>();
string ErrorMessage;

// An event that clients can use to be notified whenever the
// elements Backgroundworker is finished
public event FinishedEventHandler Finished;
public event ErrorEventHandler Error;

protected virtual void WorkCompleted(EventArgs e)
if (Finished != null)
Finished(this, e, ResponseList);

protected virtual void ErrorOccurred(EventArgs e)
if (Error != null)
Error(this, e, ErrorMessage);

/// <summary>
/// Main calls are
/// IsBusy, DoWork and CancelWork. It has a event called
/// that is raised when the work is completed
/// </summary>
public CheckResponse()
// Create a Background Worker
worker = new BackgroundWorker();

// Enable support for cancellation
worker.WorkerSupportsCancellation = true;
worker.DoWork +=
new DoWorkEventHandler(worker_DoWork);
worker.RunWorkerCompleted +=
new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);

/// <summary>
/// when the work is completed return anobject and set r to its value
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void worker_RunWorkerCompleted(
object sender, RunWorkerCompletedEventArgs e)
if (e.Error != null)
ErrorMessage = "An error occurred. " + e.Error.Message;
ResponseList = (List<Response>)e.Result;
/// <summary>
/// </summary>
/// <param name="sender"><param>
/// <param name="e"></param>
private void worker_DoWork(
object sender, DoWorkEventArgs e)
e.Result = Some call that returns a List
catch (Exception ex)
throw new Exception(ex.Message);

/// <summary>
/// Returns the status of the Backgroundworker. if its busy or not
/// </summary>
/// <returns></returns>
public bool IsBusy()
return worker.IsBusy;
/// <summary>
/// Can be called to cancel a backgroundworker
/// </summary>
public void CancelWork()
/// <summary>
/// If the backgroundworker is not busy it starts the worker.
/// </summary>
public void DoWork()
if (!worker.IsBusy)

Friday, June 11, 2010