-3

c#, .net

This is a problem I looked at about 15 years ago when .net 2.0 first came out. It sounds very easy on the face of it, but I found it incredibly difficult to crack, mainly because there was so little information. I cracked it in the end but the time has come to look at the problem again and I can either try to reuse my 15yo code, or I can investigate if there is a better way to do this. I've chosen the latter, if possible, but I'm still having trouble finding anything pertinent.

My exe is C:\Program Files......................\wwww.exe.

I want to look in d:\somewhere else\xxxx.config, i.e. a random location.

In that file, I want to go to a custom section yyyyy i.e. a random section.

and I want to be able to both read and write the string value zzzzz. That this value is ultimately a string is about the only valid assumption I can make.

So, forget about well-behaved AppSettings sections in wwww.exe.config - what I'm looking for is far trickier.

I just looked at the code I wrote to do this - it is many lines - it starts with OpenMappedExeConfiguration and just grinds things out one step at a time. The final value is returned as an object.ToString(). There's got to be a better way. I was wondering if anyone has any approach that they use which they consider to be concise and elegant?

PeteH
  • 2,394
  • 1
  • 20
  • 29
  • I don't understand. You just want to read and write some data from a text file? What's wrong with using System.IO.File's methods to do this? – mason Feb 18 '19 at 17:34
  • It would be helpful if you showed the current code that's not working well and point out the problematic part. – Rufus L Feb 18 '19 at 17:35
  • Voting to close as duplicate because it sounds like you're asking how to read and write to an xml file. Please add more details if I misunderstood something here. – Rufus L Feb 18 '19 at 17:37
  • @RufusL it is an xml file but it conforms to the format of a Microsoft .NET config file. So the difference is that I'm looking for answers based on ConfigurationManager rather than those based on System.Xml. Sorry I should have said that in the question. – PeteH Feb 18 '19 at 17:42
  • I added a configuration manager duplicate as well. Does that help? – Rufus L Feb 18 '19 at 17:42
  • Thanks @RufusL, looking at that question, the accepted answer only goes a small part of the way to what I'm looking for, but I'm looking through the other answers to see if I can glean anything. It sounds like the answer to my question is "no". – PeteH Feb 18 '19 at 17:58
  • @RufusL Actually none of those answers really helped me from my start point, some of the answers were outright hacks, as System.IO and System.Xml were, but I figured out a more concise approach through trial and error. If you'd have left the question open, I'd have posted my answer. – PeteH Feb 19 '19 at 09:16
  • Great! I re-opened your question. Answer away... :) – Rufus L Feb 19 '19 at 16:03
  • @RufusL there we go. Feel free to mark it up or down as you wish. I've no doubt that it'll be no use whatever to you, but I'm hopeful it'll be useful to somebody, so I share it. I also explain why I deliberately could not include any current code in my question. – PeteH Feb 20 '19 at 13:13

1 Answers1

0

I solved this partially, but had to make the assumption that my setting lay in a certain part (appSettings) of the file. I could get away with this because, while the settings were logically user settings, each user already has their own config file.

A Microsoft config file is a specially-structured XML file, Microsoft have a dedicated assembly to work with one, System.Configuration, and I'd really have expected any contributor to have known this, certainly if they felt they knew enough to contribute at all. So suggestions based on System.Xml and worse, System.IO, just got an "F" as far as I was concerned. I took them as mostly facetious, and I'm left wondering why somebody participates in an information sharing site, if not to be helpful. But anyway, my solution relies on System.Configuration.

In pseudocode for brevity:

  • I can use ConfigurationManager.OpenMappedExeConfiguration to open any old file. This is, I guess, well-known, and returns a Configuration object which is a logical view of the file. It's funny, even if the file doesn't exist on the disk, the Configuration is non-null.
  • By assuming my setting lies in the appSettings section of the file, I can just use the resulting Configuration's AppSettings property to hone in on the relevant section. I seem to remember that my old code supported any section, which bulked the code out a lot. Again, even if the file doesn't exist physically, Configuration.AppSettings was a valid object.
  • When I have the app Settings Section property, I can look at the .Settings property to see what values are there. appSettingsSection.Settings is basically a dictionary of key.value pairs, dressed up as a (Microsoft) KeyValueConfigurationCollection. If the file doesn't exist, appSettings.Settings pointed to a perfectly valid, but empty, collection,
  • I can see if my key already exists just by doing a standard dictionary .Contains call on my ElementCollection.AllKeys property
  • Bear in mind that we're dealing with key/value pairs here. If we're working with an existing key, we simply get/set element[key].Value, whereas if we're writing a new key, we have to create a new (Microsoft) KeyValueConfigurationElement and Add it to the collection. This class has a handy constructor which just takes the (string) key and the (string) value. One of the other things my original code did was to read/write any serializable object, far more than I needed this time around.
  • If I'm writing, I need to remember last of all to Save the Configuration. If you're writing, the file is either updated or a clean one created.

That's it. I'm guessing any of the current readers already knew all this, but I hope it might be useful to future readers. I found it useful to collate this, it took a while to put the pieces together, so it will hopefully save people time at least.

The reason I couldn't share the original code, by the way, was because I don't own either the code itself, or the copyright. In my jurisdiction, it is common for the employer/client to own code written by the employee/consultant, at least while working on their time, and I was no exception. But I only have experience of the UK and the USA, so other jurisdictions might be different. And, people who aren't professionally involved in software development might be subject to different rules altogether. Lastly, I've found over the years that many software developers are ignorant of legal issues altogether.

PeteH
  • 2,394
  • 1
  • 20
  • 29