HI,
I need to add multiple configuration files in my application. What is the easiest way to read a key value from these files? Currently I am using xmldocument class and select the node using an xpath expression. Is there any other simple way to do this in C# 2.0
I had a similar need and found this to be extremely useful and simple.
http://www.codeproject.com/KB/cs/cs_ini.aspx
It is an INI file reader and writer, you just specify the header tag and the item name and it will read or write from a file. It gives you strings and you can cast them with some try blocks.
INI is really a much simpler format than XML if you have less than fifty config options and they are not nested.
A bit of a hacky solution would be to read all of the configuration files into one in memory document then use xpath to select the right nodes.
You've tagged this as c# 2.0, do you have access to LINQ to XML? That can make your queries a lot neater.
A good way to do this could be to write a class that provides you with the information you need and serialize the object trough the XmlSerializer class. To load configuration information you can deserialize the resulting Xml back to an instance trough the XmlSerializer class.
Related
I've multiple projects with each different configurations, all these configurations must be specified in a single XML file. That isn't the app.config but is specified on a generic location.
My current project structure:
core project (with some XML)
subproject (need to access the core XML configuration in a generic way + own configuration from the same XML file)
Which .NET XML technology is the best suitable for this?
Thanks in advance
I haven't read anything in your post to suggest, that the built-in Xml functionality of the .Net framework wouldn't be up to the task.
I work with Xml on an almost daily basis and I've, as of yet, never needed any external libraries. It all depends on your project requirements of course, but you've got two projects that will use the same functionality so you could (and should) easily make an abstraction and isolation of the Xml handling for both projects, either referencing your own core\xml classes in the subproject or (my preference) in a separate dll project. A dll could serve you well in the future.
An added bonus to writing your own Xml functionality is, that you gather more intimate knowledge of the inner workings of the .Net Xml namespace, knowledge that in no way is ever wasted, whereas you would distance yourself from it by using external libraries (that are often no more than wrappers and façades for the .Net classes)
Hope this is somewhat helpful and happy coding.
The app.config file is probably the best suited for this. You can create your own configuration sections and the single configuration file for the project is accessible to all referenced assemblies, so each assembly can have its own section.
You can also have user specific configuration in user.config (see Application Settings Architecture).
If you cannot use the app.config because it needs to be in a specific location you can always load an app.config file from a different location with ConfigurationManager.OpenMappedExeConfiguration
Other alternatives:
Use the XmlSerializer to deserialize an XML into a POCO with your configuration.
The masochistic option: Use plain XDocument or XmlDocument to manually parse your configuration file on the fly.
The current solution for the problem:
With LINQ to XML I'm taken the XML element that matches an object. This XML element is below one level deeper than the root. With this way I am first 'filtering' the root tags and than converts this to string to objects with deserialization.
For example
<root>
<project1>
<somevalue>myvalue</somevalue>
</project1>
<project2/>
</root>
If I wanted everything from project1 I'm getting the string with descendants with LINQ to XML and then deserialize the string to the corresponding object(s).
I have a requirement like i need to write an entity class in C# which can hold xml data.
I want to avoid overhead of checking the well-formedness of saved xml.
I have a corresponding column with type XML. Do we have xml data type or some class which can be used as a class field to hold xml.
Thanks in advance
Update: The service using this Entity class is WCF service and in future we are making it REST compatible. Will XmlDocument or XElement work with it?
There are a number of ways, two of which are string and XmlDocument.
string would be 'easier' for fragments and not-well-formed XML, but XmlDocument can be configured with options to allow fragments; you'll have more trouble with ill-formed data though.
if you describe your object in a XSD file you can get a compiler to generate all your C# classes automatically and easily regenerate them when you make changes.
This makes XML / C# a breeze. You can go to other languages too using equivilent generators.
See the tools described here: XSDObjectGen.exe vs XSD.exe
I believe the XSD.exe tool will read in example XML and do most of the work of producing an XSD which you can refine.
If you don't need support for a fixed XML/XSD format file why can't you make any class serialize to XML by using the [Serializable] class attribute and .Net APIS to serialize/deserialize?
I have a complex graph of XML-serializable classes that I'm able to (de)serialize to hard-disk just fine. But how do I handle massive changes to the graph schema structure? Is there some mechanism to handle XML schema upgrades? Some classes that would allow me to migrate old data to the new format?
Sure I could just use XmlReader/XmlWriter, go through every node and attribute and write several thousand lines of code to convert data to the new format, but maybe there is a better way?
I have found Object graph serialization in .NET and code version upgrades, but I don't think the linked articles apply when there are major changes in the model.
Instead of writing several thousand lines of code to convert files using XmlReader / XmlWriter, you could use XSLT. We are still talking hundreds of lines of code, and perhaps slower execution speeds, but if you are good at XSLT you could get it done much faster.
The other approach would be to build a C# program that links both the old class and the new class (of course you'd need to rename the old class to avoid naming collision). The program would load OldMyClass from disk, construct NewMyClass from the values of its attributes, and serialize NewMyClass to disk. Essentially, this approach moves the task of conversion into the C# territory, which may be a lot more familiar to you.
In this case, i keep my changes in my object and recreate my xml through the XmlSerializer: http://support.microsoft.com/kb/815813
With this i load and save new xml schema based in my object.
I need to manipulate an existing XML document, and create a new one from it, removing a few nodes and attributes, and perhaps adding new ones, what would be the best group of classes to accomplish this?
There are a lot of .NET classes for XML manipulation, and I'm not sure what would be the optimal way to do it.
If it is a really huge XML which cannot fit into memory you should use XmlReader/XmlWriter. If not LINQ to XML is very easy to use. If you don't have .NET 3.5 you could use XmlDocument.
Here's an example of removing a node:
using System.Xml.Linq;
using System.Xml.XPath;
var doc = XElement.Load("test.xml");
doc.XPathSelectElement("//customer").Remove();
doc.Save("test.xml");
Use Linq to XML You can see the XDocument class here
Parsing the document with XML Style Sheets might be the easiest option if it is just a conversion process.
Here is how to use XSLT in .NET.
and
Here is an introduction to XSLT.
It confused me a bit at first, but now I pretty much use XSLT to do all my XML conversions.
If you have an official schema, you can use the XmlSerializer. Otherwise it is best to use the XmlDocument, XmlNode, XmlElement etc classes.
Otherwise it could also depend on what you are using the xml for, i.e. marking up some document, representing objects etc.
Does anyone know what advantages (memory/speed) there are by using a class generated by the XSD tool to explore a deserialized XML file as opposed to XPATH?
I'd say the advantage is that you get a strongly typed class which is more convenient to use, and also the constructor for the class will throw an exception if the XML data in the file is invalid for creating the object, so you get a minimal data validation for free.
If you don't want to write boilerplate code, and you need to check ANY values of your XML on the way through, you can't go wrong with the XSD.exe generated classes.
The two are very different; but XmlSerializer will always deserialize entire objects; with XPath you can pick and choose. I'd use XmlSerializer personally, though - harder to get wrong.
XPath, however, is a complex beast that depends on the back-end. For example, XmlDocument (mutable) will behave differently to XPathDocument (read-only, optimized for query).