As usual, the examples I find for this either don't work, or don't apply.

I want to store, essentially, a text file, within my app.config file, and access it programmatically.

Here's a simplified version:

<?xml version="1.0" encoding="utf-8" ?>
    <section name="PostScript" type="" />
    <!--   User application and configured property settings go here.-->
    <!--   Example: <add key="settingName" value="settingValue"/> -->

My big long
text file
goes here.

Two questions:

1. What goes in the "type" attribute, which I've colored red?
2. How would I retrieve the "prolog" element from the "PostScript" section of this file?

Note: this is read-only, I do not need to change/set the values in the customSection as so many examples assume.

Recommended Answers

All 4 Replies

OK... Maybe I can weigh in on this one.

Using what VERY LITTLE I currently know about XML (learning more every day), it appears that the type attribute specifies a type that's outlined in a particular XML schema. So, you could have an XML schema that defines a type, and then you'd use the type="xs:foo_my_schema" to tell the parser that's what your type is.

What does that mean? I dunno. I'll reiterate that I don't know a whole lot about XML, and I know especially less about XML Schemas. (haven't found a good book on it yet, really) But, maybe this link will help:

I at least was able to use it to discern what the type= bit is used for. I'm guessing that if you don't use a schema, it's optional.

Here's what I've learned.

1) You have to add the System.Configuration class as a reference, not just a "using" namespace declaration.

2) The "type" does indeed need to match a schema, in this case Microsoft's, and they have only 3 values, all related to a NameValue organization. Mine isn't, mine is Element-Node-Element.

3) You can add a custom type, but then you have to create a class to provide the handler for the type

4) All of this is ridiculous, because you can simply use an XmlTextReader to do a forward-only, read-only pass through any XML file, including the config.

So, I'll re-visit and really figure this all out when I need an application that can get/set its own complex configuration settings. For now, I just stored everything under the appsettings section as key-value pairs, which you can access directly.

I personally think .NET 2.0 over-complicated the Configuration aspect.

I'm really dreading having to fool with configuration for some reason. I can understand C# well enough, but I'm having a tough time with XML. I'm just hoping that when the need finally does arise for me to really use an app.config file, I'll have a little more knowledge under my belt regarding the topic.

It isn't too bad, as long as you don't break their strict rules. If you do break the rules, like I was wanting to do, they provide all sorts of "helpful" classes etc., which are anything but.

I'm putting more and more into .config as time goes by. I find myself thinking, "if I hard-code this, they'll sure enough want to change it, so I'll put it in the config file instead".

Not logic, of course, but folder settings, label text, filenames, all the database connection strings, etc.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.