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 <connectionStrings> 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:

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"?>

<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

  <CodeSnippet Format="1.0.0">

    <Header>

      <Title>DelegateCommand</Title>

      <Shortcut>delcom</Shortcut>

      <Author>Dave Kehring</Author>

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

      <SnippetTypes>

        <SnippetType>Expansion</SnippetType>

      </SnippetTypes>

    </Header>

    <Snippet>

      <Imports>

        <Import>

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

        </Import>

      </Imports>

      <Declarations>

        <Literal>

          <ID>type</ID>

          <ToolTip>Parameter type</ToolTip>

          <Default>int</Default>

        </Literal>

        <Literal>

          <ID>name</ID>

          <ToolTip>Command name</ToolTip>

          <Default>MyCommand</Default>

        </Literal>

      </Declarations>

      <Code Language="csharp">

        <![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:

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]
public void 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;
}

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

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

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>

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>

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.