Developer .NET UPDATE, February 18, 2003

Developer .NET UPDATE—brought to you by the Windows & .NET Magazine Network.
http://www.winnetmag.com


THIS ISSUE SPONSORED BY

Microsoft ASP.NET Connections & Visual Studio Connections

http://www.devconnections.com

Windows & .NET Magazine Connections

http://www.winconnections.com
(below DEVELOPER .NET PERSPECTIVES)

SPONSOR: MICROSOFT ASP.NET CONNECTIONS & VISUAL STUDIO CONNECTIONS
Microsoft ASP.NET Connections + Visual Studio Connections + SQL Server Magazine Connections equals the largest gathering of Microsoft product architects and independent Tech gurus, delivering four days of hard-core drill-down sessions that you will not find anywhere else.
The Microsoft product team delivers over 35 cutting-edge sessions on the latest product releases. In addition, you can choose from over 100 in-depth sessions presented by our world-class speakers, authors, and consultants who share real-world solutions that will save you months of trial and error.
Visit our expo hall to see the latest technology and have a chance to win a Harley Davidson among other cool give-always. After an intense day of sessions unwind at events like "Microsoft Unplugged," where no question is out of line, or march in the Mardi Gras Parade to the House of Blues for a night to remember.
Register early and get three power-packed events for the price of one. May 6-9, 2003, in New Orleans. For more details, call 800-438-6720 or visit our Web site at

http://www.devconnections.com

February 18, 2003--In this issue:

1. DEVELOPER .NET PERSPECTIVES

  • Application Configuration Settings

2. ANNOUNCEMENTS

  • Join the HP & Microsoft Network Storage Solutions Road Show!
  • Try Windows & .NET Magazine!

3. NEW AND IMPROVED

  • Bring COBOL to .NET

4. CONTACT US

  • See this section for a list of ways to contact us.

1. DEVELOPER .NET PERSPECTIVES

(contributed by Robin Sanner, [email protected])

  • APPLICATION CONFIGURATION SETTINGS

  • Nearly every application has configuration settings associated with its installation. Developers store these application settings in several locations. Back in the days of Windows 3.1, developers typically stored application settings in a text-based .ini file. More recently, some developers have started placing application settings in either the system registry or a database.

    When you create an application, you typically get to specify where to store its configuration settings. Whether you store them in an .ini file, the registry, or a database is a matter of preference.

    Developers still commonly use traditional .ini files for applications because they can configure the files in Notepad. In addition, .ini files don't require any special code to install.

    The registry is a common choice because it has the necessary APIs to support realtime detection of changes to the configuration data at the individual setting level and provides security of this data through the typical Windows ACL mechanism. Because the registry is part of the OS, you never have to worry about whether the registry is available when the application is initializing. However, you must consider the experience level of the people who will be using the application and hence changing their own registry parameters. Editing the registry improperly can have serious consequences.

    Another location for application settings is a database. Using a database is convenient for applications that have many settings. However, you usually need to include registry settings so that the application can locate and connect to the database. In addition, when you place configuration settings in a database, you must make sure the database is available to all the application's users, which can be challenging if they're running the application on remote machines.

    In many ways, the Windows .NET Framework is bringing developers full circle--developers started with storing settings in a local application-specific file, then began storing them centrally in the registry and databases, and are now going back to local application-specific storage. The Framework encourages developers to use a .config file for storing application settings. The .config file is similar to the traditional .ini file in that the .config file is application-specific and is stored locally. However, the .config file is more powerful than an .ini file. Unlike an .ini file, the .config file is written in XML, is highly structured, and is a configuration tool.

    The major advantages of using .config files are that all the application's configuration settings are in one location and you don't need to write any code to install the settings. You simply need to place the file in the appropriate location. In addition, because the .config file is written in XML, you can use powerful APIs to search and configure the file's data.

    Every type of application in the Framework can have a .config file, but not all applications will have one. The name of an application .config file depends on the type of application. Web applications and Web services have the filename web.config. In Visual Studio .NET 2002, the web.config file is the only application configuration file that Visual Studio .NET automatically generates and prepopulates with information. The prepopulated information in the web.config file deals with the operation of the Web site and is outside the scope of this column.

    Windows applications have a .config file named APP.exe.config, where "APP" is the executable's name. Visual Studio .NET has the interesting feature that if you have a file named "app.config" (in this case, the filename is literal) in a Windows application project, it will copy and rename the file to APP.exe.config when you compile the project.

    To create a .config file for an application, you simply add a new XML file to your Visual Studio .NET project. You can name the file either app.config or APP.exe.config, where "APP" is the executable's name.

    A .config file consists of various configuration sections. The default configuration sections are specified in the <configSections> section of the machine.config file. (The machine.config file is used for machine-level configuration of the Framework and is automatically created when you install the Framework.) The configuration section that's used for custom application settings in the application .config file is named <appSettings>. You can also configure the <appSettings> section to be in a different .config file that has a custom name, which is useful for making sure that custom application settings are preserved, even if the software is reinstalled.

    An example of an <appSettings> configuration section follows. This sample section contains two custom application settings named "connectionString" and "timeout":

    <configuration>

    <appSettings>
    <add key="connectionString" value=
    "server=MyServer;trusted_connection=yes;database=TestDB" />
    <add key="timeout" value="60" />
    </appSettings>
    </configuration>

    Note that the <appSettings> section consists of two <add> nodes, each of which has two attributes. The attribute named "key" is the name of the setting and the attribute named "value" is the value of the setting.

    Next week, I'll continue looking at .config files. I'll examine how to retrieve the settings as well as detect configuration-setting changes while the application is running.


    SPONSOR: WINDOWS & .NET MAGAZINE CONNECTIONS

    REAL-WORLD TECHNICAL TIPS HERE FOR YOU
    Chock full of "been there, done that" information from experts who use Microsoft technology in the real world. Get the latest tips on Exchange 2000, Exchange 2003, AD basics to advanced, security, wireless networks, Windows 2000, Windows Server 2003, Windows XP, IIS, Group Policy, and more.

    Microsoft is sending its "Scripting Guys"--members of its TechNet Script Center who are also responsible for the "Scriptomatic" tool. Don't miss your chance to attend this special one day pre-conference and enhance your scripting skills firsthand from the experts who know Microsoft scripting technologies the best.
    For security-minded IT pros, we provide in-depth coverage from the world's top gurus on Windows security: "Keeping Up with Service Packs and Security Patches," "Identity Management with PKI," "Implementing Security with Group Policy," "Securing Wireless LANs," and "Managing AD Security with ADSI and WSH." Other sessions will show you how to defend your networks by planning your own "Hack Attack", how to use event Logs to identify intruder activity, how to make IIS a Secure Web Server, and more.
    Don't miss this exclusive opportunity to interact first hand with Windows & .NET Magazine writers you trust: Minasi, Russinovich, Hill, Wells, Deuby, Moskowitz, and more. May 18 - 21 in Scottsdale, AZ. Early registrants save $300, so visit us today at

    http://www.winconnections.com

    2. ANNOUNCEMENTS
    (brought to you by Windows & .NET Magazine and its partners)

  • JOIN THE HP & MICROSOFT NETWORK STORAGE SOLUTIONS ROAD SHOW!

  • Now is the time to start thinking of storage as a strategic weapon in your IT arsenal. Come to our 10-city Network Storage Solutions Road Show, and learn how existing and future storage solutions can save your company money--and make your job easier! There is no fee for this event, but space is limited. Register today!
    http://www.winnetmag.com/roadshows/nas

  • TRY WINDOWS & .NET MAGAZINE!

  • Every issue of Windows & .NET Magazine includes intelligent, impartial, and independent coverage of security, Active Directory, Microsoft Exchange Server, and more. Our expert authors deliver how-to content you simply can't find anywhere else. Try a sample issue today, and find out what more than 100,000 readers know that you don't!
    http://www.winnetmag.com/rd.cfm?code=fsei203xup

    3. NEW AND IMPROVED
    (contributed by Sue Cooper, [email protected])

  • BRING COBOL TO .NET

  • Fujitsu Software released NetCOBOL for .NET 1.1, a compiler that lets you bring existing COBOL code into the Windows .NET Framework, mix it with other languages' code, create new code to take advantage of all the Framework classes, and use Visual Studio .NET tools. New features include IntelliSense support, code outlining, class-view and object-browser support, improved performance of generated code, pointer-item support, support for sequential files that are larger than 4GB, and an external file-handler interface. For more information about NetCOBOL for .NET 1.1, go to http://www.netcobol.com/products/windows/netcobol.html.
    http://www.fujitsu.com

    4. CONTACT US
    Here's how to reach us with your comments and questions:

    • ABOUT DEVELOPER .NET PERSPECTIVES -- [email protected]
    • ABOUT THE NEWSLETTER IN GENERAL -- [email protected] (please mention the newsletter name in the subject line)
    • TECHNICAL QUESTIONS -- http://www.winnetmag.com/forums
    • PRODUCT NEWS -- [email protected]
    • QUESTIONS ABOUT YOUR DEVELOPER .NET UPDATE SUBSCRIPTION? Email Customer Support -- [email protected]
    • WANT TO SPONSOR DEVELOPER .NET UPDATE? [email protected]
    • This weekly email newsletter is brought to you by Windows & .NET Magazine, the leading publication for Windows professionals who want to learn more and perform better. Subscribe today.
      http://www.winnetmag.com/sub.cfm?code=wswi201x1z

      Receive the latest information about the Windows and .NET topics of your choice. Subscribe to our other FREE email newsletters.
      http://www.winnetmag.com/email

    Hide comments

    Comments

    • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

    Plain text

    • No HTML tags allowed.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Lines and paragraphs break automatically.
    Publish