S h o r t S t o r i e s

// Tales from software development

Visual Studio: The problem with Settings GenerateDefaultValueInCode

with one comment

When you use Visual Studio to create your application’s configuration settings, each setting has several properties associated with it. The Name, Value, and Scope properties will be familiar to anyone who’s used the Settings editor but do you know exactly what GenerateDefaultValueInCode does and whether you should set it to True or False ?

As its name suggests, when GenerateDefaultValueInCode is set to True the Settings Designer generates code to return the value specified in the editor when the runtime configuration file doesn’t have an entry for the setting.

At first this might seem like a useful feature but I’ve come to the conclusion that it’s a liability and often hides configuration issues in deployed code. You might think that you’d quickly spot this type of configuration problem but I spent a couple of hours yesterday debugging a .NET Remoting application before guessing that it was probably a configuration file setting issue. It was a guess because nothing in the exception stack trace clearly indicated what the problem was.

In this particular example, the code consisted of the following components:

Vitality.PAS.Interface – A .NET remotable class that implements an interface to a data store
Vitality.PAS.InterfaceServer – A class that creates a server remoting channel for the Interface class
Vitality.PAS.InterfaceService – A Windows Service that hosts the Server class
Vitality.PAS.TestApp – A test program that acts as a client for the Interface

The management of the configuration settings is a little bit confusing. For example, the TestApp’s configuration file needs the settings used by the client side code in the Interface component. The Service component’s configuration file needs all the settings used by the InterfaceServer component and the settings used by the server side code in the Interface component.

Because GenerateDefaultValueInCode was set to True for all these projects the code worked even though the configuration files were not correctly set up. However, because the values generated in the code were those that were specified during development the deployed code was not behaving as expected.

It would have been possible to get the code to work as required by correctly setting up the various configuration files but the fact that the code doesn’t fail when configuration file settings are missing seems like bad practice. So, I changed GenerateDefaultValueInCode to False for each setting in all four projects.

Advertisements

Written by Sea Monkey

January 26, 2010 at 8:00 am

Posted in Development

Tagged with

One Response

Subscribe to comments with RSS.

  1. This feature feels out of place in that it’s “generating code” by default that you may not be aware of. A side effect of our wiz-bang feature-packed IDE’s abstracting away as much as possible.

    At least I’m glad I found the property and it saves me from having to write funky code to default values! Most settings are database-bound, but undocumented hackflags go in the config file. I was afraid distributing an update to existing customers with new (non-existant settings) would stop them dead.

    I will remember this though for projects that may rely exclusively on settings saved in-project.

    oSquat

    May 30, 2014 at 9:55 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: