Sladescross's Blog

Blogging about Sharepoint related stuff

.NET Custom Configuration Settings December 25, 2009

Filed under: .NET,Configuration,Custom,Settings — sladescross @ 11:53 pm

    <sectionGroup name=”userSettings”
        type=”System.Configuration.UserSettingsGroup, System,
              Version=, Culture=neutral,
      <section name=”MSDNSampleSettings.My.MySettings”
        type=”System.Configuration.ClientSettingsSection, System,
             Version=, Culture=neutral,
        requirePermission=”false” />
      <setting name=”Setting” serializeAs=”String”>

A few things in the above code deserve special mention:

  • The CollectionType property specifies AddRemoveClearMap, which is what gives your collection the standard behavior of an element collection in the configuration file.
  • If you specify a key, you’ll need to override GetElementKey to return the value of the appropriate property. Note that your key property doesn’t have to be a string. I could have used my Identifier property as the key.
  • Some of the methods provide a familiar name to access corresponding base class operations. For example, the Clear method executes BaseClear.


.NET Framework Resources

Filed under: .NET,Resource — sladescross @ 4:46 pm


.Net Connection Strings December 20, 2009

Filed under: .NET,Connection Strings — sladescross @ 6:29 pm,-an-overview/

Storing connection strings in configuration files

Application configuration files (web.config or app.config) can be used to hold these connection strings.  Although these files share common elements, their name and location varies according to the application’s host.  They can be used to store any number of connection strings. Before these configuration files became the norm, Universal Data Link files were the recommended way of doing it. These were referenced directly by OLEDB; one merely passed the reference to the file in the form ‘FILE NAME=<name of the file> in the Connection string.

The simplest way for the application to access the connection strings that are stored in configuration files is to use the  System.Configuration namespace

The ConfigurationManager (or WebConfigurationManager)  is used when working with configuration files on the local computer, and allows you to read in the connection string by its name.

You can use the ConnectionStringSettingsCollection to retrieve connection strings from application configuration files. It contains a collection of ConnectionStringSettings objects, each of which represents a single entry in the connectionStrings section. Its properties map to connection string attributes, allowing you to retrieve a connection string by specifying the name or the provider name.

For our application, we just want one connection string, so we create a file called <name of program> .exe.config  (where <name of program> is the name of the program you compile the following code to) and  put in:


Exception Handling Best Practice December 19, 2009

Filed under: .NET,Error Handling,Exception,HRESULT,Resource — sladescross @ 4:02 pm

As we’re talking about logging, don’t forget that you should always log Exception.ToString(), and never Exception.Message. Exception.ToString() will give you a stack trace, the inner exception and the message. Often, this information is priceless and if you only log Exception.Message, you’ll only have something like “Object reference not set to an instance of an object”.

Microsoft recommends that you should use return special values on extremely common situations. I know I just wrote the opposite and I also don’t like it, but life is easier when most APIs are consistent, so I recommend you to adhere to this style with caution.

I looked at the .NET framework, and I noticed that the almost only APIs that use this style are the APIs that return some resource (e.g., Assembly.GetManifestStream method). All those APIs return null in case of the absence of some resource.

Instead of “throw ex;“, which will throw a new exception and clear the stack trace, we have simply “throw;“. If you don’t specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks.

An HRESULT is an opaque result handle defined to be zero or positive for a successful return from a function, and negative for a failure. Generally, successful functions return the S_OK HRESULT value (which is equal to zero). But in rare circumstances, functions may return success codes with additional information e.g. S_FALSE=0×01.

HRESULTS were originally defined in the IBM/Microsoft OS/2 operating system as a general purpose error return code, and subsequently adopted in Windows NT. Microsoft Visual Basic substantially enhanced the HRESULT error reporting mechanisms, by associating an IErrorInfo object with an HRESULT error code, by storing a pointer to an IErrorInfo COM object in thread-local storage. The IErrorInfo mechanism allows programs to associate a broad variety of information with a particular HRESULT error: the class of the object that raised the error, the interface of the object that raised the error, error text; and a link to a help topic in a help file. In addition, receivers of an HRESULT error can obtain localized text for the error message on demand.

Subsequently, HRESULT, and the associated IErrorInfo mechanism were used as the default error reporting mechanism in COM.

Support of the IErrorinfo mechanism in Windows is highly inconsistent. Older windows APIs tend to not support it at all, returning HRESULTS without any IErrorInfo data. More modern Windows COM subsystems will often provide extensive error information in the message description of the IErrorInfo object. The more advanced features of the IErrorInfo error mechanisms—help links, and on-demand localization—are rarely used.

In the .NET Framework, HRESULT/IErrorInfo error codes are translated into CLR exceptions when transitioning from native to managed code; and CLR exceptions are translated to HRESULT/IErrorInfo error codes when transitioning from managed to native COM code.


Call A SQL Stored Procedure December 14, 2009

Filed under: .NET,SQL,Stored Procedure — sladescross @ 7:59 pm


Configure .NET For Fiddler December 2, 2009

Filed under: .NET,Fiddler — sladescross @ 11:20 pm

Clients that do not follow the Winlnet API will  bypass fiddler This includes .net. To ensure .net goes via Fiddler set the proxy as follows in web.config



  <proxy proxyaddress=”;   bypassonlocal=”False” autoDetect=”False” />




.NET Dependency Property November 5, 2009

Filed under: .NET,Dependency Property — sladescross @ 2:56 pm

Your first two questions are probably “What are these GetValue and SetValue functions?” and “What is this HeightProperty?”, and those are very good questions indeed. Well, GetValue and SetValue are functions you get by deriving from DependencyObject. They allow you, as you might have guessed, to get and set the values of dependency properties. The HeightProperty is the dependency property itself – the static definition part of the FrameworkElement class.

Good introduction.


Sending SMTP Email October 19, 2009

Filed under: .NET,SMTP — sladescross @ 10:20 pm

Custom Configuration for SMTP!A68482B9628A842A!138.entry


WPF Windows Events August 8, 2009

Filed under: .NET,Events,WPF — sladescross @ 11:43 am

Windows.Window events (WPF)

Loading/opening new window (application startup), events fired are:


Closing a WPF Window, the events that fire are:



WPF Traverse Up The Visual Tree

Filed under: .NET,Traverse,WPF — sladescross @ 10:42 am

DependencyObject originalSource = (DependencyObject)e.OriginalSource;

while ((originalSource != null) && !(originalSource is ListBoxItem))
originalSource = VisualTreeHelper.GetParent(originalSource);

if (originalSource != null)




Get every new post delivered to your Inbox.

Join 63 other followers