The Rambling Codesmith

\trunk It's just a state of mind…

Easy Accessing to the App.Config

Categories: C# Basics

Tags: No Tags

Comments: 3 Comments

Published on: January 29, 2012

As my son comes across issues, I thought the easiest thing to do would be to throw them up in my blog so he could easily access them. Accessing custom key-value data from the App.config file is extremely easy and is only a couple of steps. Many web sites feel the need to drag on for paragraph after paragraph but lets keep it short and sweet.

Here we go…

First you must add an app.config file to your project. Just right mouse and add new item. Pick Application Configuration File like below.

The next step would be to add a reference to the System.Configuration library in your project. Do this by right clicking on the References folder in your project and click “Add Reference”

Select the System.Configuration library and click add.

You should see the library in your References folder.

Add an appSettings element to the newly created app.config file.
Add a new key value pair for the item you need to access later.

<configuration>
	<appSettings>
		<add key="WhateverName" value="WhateverValue"/>
	</appSettings>

</configuration>

To access the element from within your code, first create a reference to the System.Configuration library with a using statement. Then use the ConfigurationManager.AppSettings["WhateverKeyName"] syntax to access the element.

using System.Windows.Forms;
using System.Configuration;

namespace WindowsFormsApplication1

private void processButton_Click(object sender, EventArgs e)
		{
			string configItem = ConfigurationManager.AppSettings["WhateverName"];
		}

Love,
-Dad

Share and Enjoy:

Using Elmah 1.1 and .Net MVC3 Part 1

by Jamie Kiefner

Categories: .Net MVC

Tags: No Tags

Comments: No Comments

Published on: April 9, 2011

In creating a new MVC3 project, I was tasked with implementing an exception logging/viewing solution. I’m loving the NuGet plugin for Visual Studio 2010 and was leaning for a solution which could be implemented using the tool. I looked at three possibilities: ELMAH, Log4Net (which I have used quite a bit) and healthmonitor.

After reading Scott Hanselman’s post about ELMAH, I become intrigued and decided to give it a go. It appeared to do everything I needed (well almost… I’ll get to that later) and I really liked the ability to view the YSOD screens that the user would have viewed at the time the exception was thrown. The documentation for ELMAH (Error Logging Modules and Handlers in case you were wondering) touted several means of logging exceptions with options to save to several types of media. For example: (n)SQL dbs, loose XML files, in-memory etc. As my application sits outside our firewall and in a DMZ, I wasn’t interested in db storage for the logs. In-memory should serve my purpose along with windows event viewer.

Installation

Initial installation to the MVC framework was a snap. I just fired up NuGet and searched for ELMAH. Installation registered the ELMAH.dll and placed the necessary source in the new projects folder so I retain the ability to update the package using the NuGet tool at a later date if need be. Several registration nodes were placed in the web.conf file automatically. By default, the errorLog and mailLog modules are registered with handlers for POST,GET and HEAD.
An ignore route directive is also placed in the global.asax which allows the MVC framework to ignore the pattern used to view the ELMAH html error pages.

An <elmah></elmah> section is also created in the web.conf where you can configure the email settings via <errorMail></errorMail>. I configured the mail settings and fired up the site and was immediately able to view the error log page (/elmah.axd).

The vanilla MVC3 setup creates a default home page that contains an “About” link. This seemed like a good place to start testing the module, so I intentionally threw a divide by zero error into the Index controller and clicked the link.

An email immediatly showed up in my inbox with the exception details and the YSOD. I was also able to view the error on the /elmah.axd page.

Ok, awesome so far. But it didn’t take long to discover that I needed some filters in place. MVC throws a controller not found error everytime an improper URL is entered and my inbox really started to blow up with 404 errors mailed out. Also, it appeared to me that a single subject line or email to address was not going to cut it. For example: I would like the environment noted in the email subject. Simple filtering can be handled in the global.asax file by catching the errorMail_Mailing event as well as the errorLog_Logged event.

I could also modify the other email attributes via the filter event handler. I could see that filtering could get become long and wordy, so I will be refactoring the filter directives out to a Filter class. A portion of the filter directives will be used for logging as well as email so this will be a much cleaner solution and will keep my global.asax line count to a minimum.

Next time we’ll look at creating our custom ElmahFilters class.

Share and Enjoy:

page 1 of 1

Welcome , today is Saturday, May 19, 2012