Dave Kehring

Unrecognized attribute configProtectionProvider

2009-04-07T18:03:41.258-04:00

Don't you just love those days when you come to work full of energy and ideas, ready to have a productive day only to be stumped by a seemingly simple problem that ends up wasting the entire day? Today was one of those days. My only consolation is that this blog post reports the solution, hopefully saving some other poor soul their time and their sanity.

The need was simple. Write out connection strings to the app.config file of an application and encrypt them. Sound easy? Sure. There are lots of examples out there about how to do this, but there's a problem no one seems to mention. You can't just update a config file at runtime and expect those changes to stick. I ran into that problem the other day and solved it here. But there's a more sinister problem. Let me explain.

First, here's what I'm doing:

I have an array of connection strings (as strings) from an external service that I want to add to the app.config file of the current application. I write them out to the section and then save the file, taking care to make sure I tell the System.Configuration.ConfigurationManager to refresh the section, meaning it should reload the section from disk the next time it's accessed.

When this happens further along in the program on this line ...

          ConnectionStringSettings
dbConn = System.Configuration.ConfigurationManager.ConnectionStrings[DefaultDatabaseKey];

... I get this error message:

Unrecognized attribute 'configProtectionProvider'.

I did the usual searches and came up with no solutions. Some folks suggested loading two AppDomains, restarting the app, etc. I can't believe you'd have to restart an app just to pick up configuration changes! After all, I can to this now. The problem comes when I try to encrypt the section.

When you successfully encrpyt a section, a new attribute "configProtectionProvider" is added to the element. It appears that when ConfigurationManager tries to reload this section, it can't digest this new attribute.

Okay, let's just get to the solution before I waste even more of my day...

The answer turned out to be simple. Instead of telling ConfigurationManager to refresh the "connectionStrings" section, have it refresh the next level up which would be the section itself:

Oh happy day.

Configuration File Changes Won't Persist

2009-04-01T12:21:45.75-04:00

I was running into a problem when trying to modify the app.config file for an application at runtime. Specifically, I was adding connection strings to the section but further along in my code the changes were not visible. However, the configuration file was changed! How could this be? After much head scratching and research, I find the problem.

To change the app.config file I was opening the config file like this:

System.Configuration.

ConfigurationManager .OpenExeConfiguration( ConfigurationUserLevel .None);

I then add or update individual connection strings as need (that code's not important). Finally, I save the changes:

config.Save(System.Configuration.

ConfigurationSaveMode .Modified);

Further on in the code I then attempt to access the connection strings, but instead I use the ConfigurationManager class like this:

ConnectionStringSettings

dbConn = System.Configuration. ConfigurationManager .ConnectionStrings[DefaultDatabaseKey];

The problem is that the ConfigurationManager - which is a static class - already has a stored copy of the configuration file in its internals. The answer is to call RefreshSection("...") after saving changes to the config file:

config.Save(System.Configuration.

ConfigurationSaveMode .Modified);
System.Configuration. ConfigurationManager .RefreshSection( "connectionStrings" );

Code Snippet for Prism DelegateCommand

2009-02-01T10:41:42.884-05:00

Code snippets in Visual Studio are very helpful when you have to type the same old code structure again and again. I found myself doing this on a recent project and decided to create a code snippet for it. I'm using Microsofts Composite Application Guidance (a.k.a. Prism) and the Model-View-ViewModel pattern (M-V-VM). My ViewModels implement commands that are hooked into from the Xaml View. The command type is DelegateCommand<T>, a class provided by the Composite WPF library that comes with Prism. Here's my snippet:

<?xml version="1.0" encoding="utf-8"?>

<Title>DelegateCommand</Title>

<Shortcut>delcom</Shortcut>

<Author>Dave Kehring</Author>

<Description>Creates a Prism DelegateCommand.</Description>

<SnippetType>Expansion</SnippetType>

</SnippetTypes>

</Header>

<Namespace>Microsoft.Practices.Composite.Wpf.Commands</Namespace>

</Import>

</Imports>

<ToolTip>Parameter type</ToolTip>

</Literal>

<ToolTip>Command name</ToolTip>

<Default>MyCommand</Default>

</Literal>

</Declarations>

<![CDATA[

DelegateCommand<$type$> _$name$Command;

public DelegateCommand<$type$> $name$Command

{

get

{

if (_$name$Command == null)

_$name$Command = new DelegateCommand<$type$>($name$, Can$name$);

return _$name$Command;

}

public bool Can$name$($type$ param)

{

}

public void $name$($type$ param)

{

}

]]>

</Code>

</Snippet>

</CodeSnippet>

</CodeSnippets>

This produces the following example property declaration:

 DelegateCommand<object>
_SaveCommand; public DelegateCommand<object>
SaveCommand { get { if (_SaveCommand
== null)
_SaveCommand = new DelegateCommand<object>(Save,
CanSave); return _SaveCommand;
} } public bool CanSave(object param)
{ } public void Save(object param)
{ }

The code snippet creates a private DelegateCommand member and a standard property declaration with only a getter. The command is lazy-initialized. The two methods stubs are called by the DelegateCommand during runtime execution.

To use this snippet, save it in a file with the .snippet extension into %\My Documents\Visual Studio 2008\Snippets\Visual C#\My Code Snippets. Then, in Visual Studio, you simply type "delcom" to run the snippet:

Hit Tab to insert the snippet code into the IDE. Then, you provide replacement values for the DelegateCommand's type value (this is the type of the parameter passed to the command methods) and the name of the command:

Adding Intellisense to Visual Studio for Custom Configuration Sections

2008-11-20T08:57:11.987-05:00

Intellisense is wonderful. It's so useful it's actually scary because it doesn't force you to remember a lot class names, enum values, etc. This is good for productivity but bad when you need to recall something without the Visual Studio IDE!

In any case, I like to get Intellisense whenever I can. One area that I kept putting off was adding Intellisense for custom configuration sections I create. I dislike loads of tags in the section because it becomes hard to navigate. I prefer to create custom config sections. However, I don't get the benefit - out of the box - of Intellisense and schema validation. To get this, you need to create your own XSD file to support your custom config sections.

XSDs for config sections are not hard to write. In fact, its best to just take a look at the XSD file for the .NET config file which can be found in your Visual Studio installation folder. For example, on my machine for VS 2008, I navigate to:

C:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas

Here you'll find loads of XSD files for all sorts of things. The most important one however is called DotNetConfig.xsd. This contains the schema definitions for the base .NET config file. There are also supplimental files for .NET 2.0 and 3.0 config sections in DotNetConfig20.xsd and DotNetConfig30.xsd respectively.

Here's a simple example of a config section:

fileRepositories >
< fileRepository id = " MainLib " isDefault = " true " connectionString = " \\JUPITER\MainLib " />
fileRepositories >

The xsd schema (MyConfig.xsd) for this config section is:

xml version = "1.0"encoding="us-ascii"?>
   <xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema"
                     xmlns:vs=http://schemas.microsoft.com/Visual-Studio-Intellisense
                     elementFormDefault="qualified"
                     attributeFormDefault="unqualified">

xs:elementname="fileRepositories">
      <xs:complexType>
         <xs:choiceminOccurs="0"maxOccurs="unbounded">
            <xs:elementname="fileRepository">
               <xs:complexType>
                  <xs:attributename="id"type="xs:string"use="required" />
                  <xs:attributename="isDefault"type="xs:boolean"default="false"use="optional"/>
                  <xs:attributename="connectionString"type="xs:string"use="required"/>
               xs:complexType>
            xs:element>
         xs:choice>
      xs:complexType>
   xs:element>
xs:schema>

I placed this file in the ...\Xml\Schemas folder in the Visual Studio installation folder as noted above. Now, to hook this into VS, you need to add it to the xsd catalog. You do this by editing the file catalog.xml. Add the following line to the bottom of this file before the closing tag:

That's it! Now when you go into VS and edit a config file, you'll get Intellisense!

How to Unit Test Events

2008-10-06T11:35:17.269-04:00

If you have a class that contains an event, you'll want to write a unit test to test that the event gets fired at the right time and under the right conditions. The problem is that you would typically hook up an event handler in your unit test class that can run an assert to check if the event gets fired:

            
              private
              bool _fired;
[Test] publicvoid CheckVisiblityEvent()
{ _fired =false;
ImageGroupListItemViewModel vm = ImageGroupListItemViewModelFactory.Build();
vm.VisibilityChanged += new ImageGroupListItemViewModel.ImageGroupVisibilityChangedEventHandler(vm_VisibilityChanged);


vm.Visible = true;
             Assert.IsTrue(_fired);
} void vm_VisibilityChanged(object sender,
ImageGroupVisibilityEventArgs args) { _fired =true;
}

This is a bit sloppy. Instead, we could improve on this by using and anonymous method:

            [Test] publicvoid CheckVisiblityEvent()
{ bool fired =false;
ImageGroupListItemViewModel vm = ImageGroupListItemViewModelFactory.Build();
vm.VisibilityChanged += delegate(object sender,
ImageGroupVisibilityEventArgs e) { fired =true;
}; vm.IsVisible =true;
Assert.IsTrue(fired); }

More compact and easier to follow. Plus, the test code is all in one place. We can improve this even more with a lambda expression:

            [Test] publicvoid CheckVisiblityEvent()
{ bool fired =false;
ImageGroupListItemViewModel vm = ImageGroupListItemViewModelFactory.Build();
vm.VisibilityChanged += (s, e) => fired =true;
vm.IsVisible =true;
Assert.IsTrue(fired); }

Handling MouseDoubleClick on a WPF Image Control

2008-09-24T11:39:48.18-04:00

Here's a nice way to bind to mouse events to a RoutedCommand. My RoutedCommand is defined in a ViewModel (in the Model-View-ViewModel pattern):

< Image Name ="Image" Grid.Row ="0"
           Source ="{ Binding DataModel . Thumbnail , Converter ={ StaticResource
                        ImageConverter }}">
    < Image.InputBindings >
        < MouseBinding MouseAction ="LeftDoubleClick"
                            Command ="vm:ThumbnailViewModel.PreviewCommand"/>
    Image.InputBindings >
Image >

Error "The calling thread must be STA, because many UI components require this" in NUnit for WPF apps

2008-08-12T09:52:59.579-04:00

While trying to create unit tests for view models (using the Model-View-ViewModel pattern), I came across a problem while trying to execute unit tests from NUnit. The error I recevied was:

The calling thread must be STA, because many UI components require this.

A quick search on Google yielded an answer.

However, the configuration file in the post was incorrect and was noted by a commentor. For expediency, I have included the correct configuration text below:

configSections >
   < sectionGroup name = " NUnit " >
       < section type = " System.Configuration.NameValueSectionHandler " name = " TestRunner " > section >
    sectionGroup >
configSections >

NUnit >
   < TestRunner >
       < add value = " STA " key = " ApartmentState " > add >
    TestRunner >
NUnit >

Creating a Client-side Validator for the DropDownList

2007-10-23T08:34:45.348-04:00

I like using Guids. Sure, they're a bit long and difficult to decipher in a database but they have their uses. I typically use them as the primary key for database tables. I often have the need to display a list of values from a database table in a DropDownList control on a WebForm. The value of each entry is the Guid while the text value comes from a description field in each record. When the user selects an item from the DropDownList, I retreive the Guid from the SelectedValue property which is typically used to set a field on a business object, thus creating a reference. Typically the first item in the DropDownList reads "--Select One--" or "-- None --", indicating the the user must select a value (this is represented by the value for Guid.Empty). Consequently the field is "required" - a user must select a value from the list. I do this because I don't want to presume a default value (such as the first item).

The problem them becomes how to validate the DropDownList on the client side such that if the user does not select an item other than the default "--Select One--" item a message is display.

I found a post that shows how to use the CustomValidator control to validate a DropDownList. The problem with this solution is that it does not take into account when a control is embedded within other controls that are tagged with the INamingContainer interface. This interface tells ASP.NET to automatically generate unique "id" attribute values on the ensuing HTML tags generated for a control. This unique id is prepended with the id of each parent control up to the root control. For example, a DropDownList embedded in a Panel control might have the id "ctl00$ddlMyDropDown". Therefore, in the solution mentioned above, we can't simply us "document.getElementById" Javascript function to locate the DropDownList control.

A better solution is to utilize the ControlToValidate property of the CustomValidator control. When this is set at design-time ASP.NET will generate Javascript code to add this value as an attribute of the validator control in the HTML DOM. For instance, looking at the source of the page I'm working on the following code is generated:

var ctl00_MainContent_CustomValidator1 = document.all ? document.all["ctl00_MainContent_CustomValidator1"] : document.getElementById("ctl00_MainContent_CustomValidator1");
ctl00_MainContent_CustomValidator1.controltovalidate = "ctl00_MainContent_ddlFeedbackType";

The property "controltovalidate" contains the fully-qualified unique id of the target control we're validating. We can use the "controltovalidate" property in our Javascript function that is used to validate the DropDownList:

function ValidateFeedbackType(source, arguments)
{
var ddl = document.getElementById(source.controltovalidate);
if (null != ddl)
{
var value = ddl[ddl.selectedIndex].value;
arguments.IsValid = (value != "00000000-0000-0000-0000-00000000000");
}
else
{
arguments.IsValid = false;
}
}

Creating a Simple ASP.NET "Click Once" Submit Button

2007-06-25T09:09:56.113-04:00

I often run into a situation where a user tries to click a Submit button more than once on a page when processing takes more than a few seconds. To remedy this, I created a very simple control based on the standard ASP.NET Button control (System.Web.UI.WebControls.Button). I created a new WebControl and inherit from System.Web.UI.WebControls.Button to retain all of the aspects of a standard button. Next, I override the AddAttributesToRender method and include the following code:

protected override void AddAttributesToRender(HtmlTextWriter writer)
{
    base.AddAttributesToRender(writer);
    writer.AddAttribute("onclick", "this.disabled=true;"
        + this.Page.ClientScript.GetPostBackEventReference(this, ""));
}

The first line calls the base classes implementation and then the second line adds a client-side event handler for the "onclick" event of the button. When the button is clicked, it is disabled and then a postback is initiated. This is important because if you just try to disabled the button, it will not be part of the postback and its server-side processing will not fire. That's why you need to include the postback callback function for the button that can be obtained from the call to ClientScript.GetPostBackEventReference.

Error Creating ASP.NET Application

2007-05-30T13:30:52-04:00

I was tring to create an ASP.NET website using Visual Studio.NET 2003 and got the following error that in part says:

"Unable to create web project ... The two need to map to the same server location".

I found so many threads about this with few answers. Here's how I solved my problem.

I was trying to create an ASP.NET website on one of my servers from Visual Studio.NET 2003 on my development machine. The problem was that the directory location of the "Default Web Site" node in IIS on the server did not map to the location where I was trying to create the new application based on the UNC path. For example, I was trying to create the application on the following path:

\\myserver\inetpub$\myapplication

This mapped to the physical location:

G:\Inetpub

... and translates to the URL

http://myserver/myapplication

In IIS on the server I looked at the "Default Web Site" node as this is where IIS will try to create the ASP.NET application because http://myserver translates to this location. Looking at the Home Directory tab at the Local Path parameter I noticed it was pointing to the physical location

C:\Inetpub\wwwroot

So, I simply changed this path to G:\Inetpub and it worked. So this is what the message means by "the two need to map to the same server location".

Don't forget of course that I had to create a UNC share with the appropriate permissions for this to work.

Hope this saves someone some time.