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).
Related
I have a project where I am mining metadata, specifically attributes and custom xml documentation comments, from a particular dll that is created in another C# project. The mining is aimed at finding all methods with particular attributes and/or documentation comments in the dll. I use Assembly.LoadFrom and GetTypes (and additional processing) to find all of the attributes, and I parse the generated XML documentation file to access the custom documentation comments. I have the functionality working fine, but there is a lot of extra overhead needed to get things to work.
The project being mined does not need to execute, but needs to be compiled in order to have a dll from which I can extract the attributes and to generate the XML document. Unfortunately, this target project depends, directly or indirectly, on 10 other projects. These additional projects provide exactly zero benefit other than allowing the target project to compile. But I have to pull these additional 10 projects into my solution just because.
Is it possible to perform some sort of partial compilation of the project in question without having the projects upon which it depends in the solution? Can I get the type information (from which I mine attributes) and the XML documentation some other way?
We are a group of C#/.NET 4.5 developers working on the same application.
The application has a set of configurations related to each developer machine, like the connection string to the DB, network related settings (proxies, IPs, credentials) and a LOT MORE.
Because the application has grown we are incurring in a lot of environment related configurations like for example:
If this is MyPC then load the connection string for my PC.
If this is the XDeveloperPC then specify proxy’s settings.
Also if new developers leaves or join the group, then the process to update the file becomes a total head ache. Maintaining the file has become very hard and is a possible source of bug and errors.
I was thinking in having specific app.config files related to each developer environment like:
app_MyPC.config
app_XDeveloperPC.config
And when the application builds or executes then specify which one to load as if it where the default app.config of the application. Then, when the application or any class or method refers to a given configuration (like the connection string) is access to this configuration file as if it where accessing to the app.config default file.
I would not want to create a Configuration class that builds immediately when the application starts because then I should have references from every place to this class and the application is quite large, with a bunch of projects and dlls.
I rather prefer to hear some opinions and what do you think should be the best way to achieve this.
Is it possible to achieve this?
How?
Do you know a better approach?
FYI, please note that .NET only loads one config file for the whole application. You could try multiple config files something as like specified here,
Multiple App.Config Files in .NET Class library project
Hope this helps...
You can specify sections of app.config to be loaded from another file. See this answer
However, you might have to customize the above solution, the app.config files and the way configs are organized.
Another approach is to use a custom settings file instead of app.config. This will need some code change to use the config file. This config can either be an XML or a JSON file (JSON is easy to deal with). You can use an inheritance model wherein generic settings come from one file, specific settings come from another file and so on. Also, you can load settings from such file at runtime and change application behavior on the fly.
If you decide to use custom config file, and if you already have lot of code written considering App.config file, you can abstract the app.config calls to a method and let that method deal with where to pull the settings value from. That way you can minimize the code change and keep everything tidy.
Maybe you can use the machine.config file (C:\Windows\Microsoft.NET\Framework\your Framework version\Config\machine.config)
I've always used my own format of configuration files which is XML and then I just deserialise the XML into an object in my project or just read it into an XML document.
This seems alot easier to read and access the information I need.
I've had a look at the ConfigurationManager class this morning and it seems a bit overly complicated just to read a config file.
Is there any argument as to why I should use ConfigurationManager?
It is just a built-in mechanism in .NET which is already implemented for you, so you don't need any extra code (probably except for wrapping it in your own IConfig to separate concerns).
There is a GUI for editing .NET configuration files which sometimes comes in handy.
ASP.NET application, for instance, automatically restart when web.config has been changed, while you would need some custom logic to have the same behaviour with your own config files.
The ConfigurationManager is used internally and you're not obligated in any way to use it, and I used to do what you do. Nowadays it depends, if it is a file a user is supposed to change I might still do my own configuration, otherwise the file is added as an embedded resource and I use the ConfigurationManager to read it, because I don't think there is another way of reading those files. The thing is, use whatever mechanism you feel like, ConfigurationManager provides a bit more encapsulation though and out of the box utils classes.
For my application, I need to serialize data to file using XML, so I read Introducing XML Serialization on MSDN. One thing that concerns me is under the Security Considerations for XmlSerializer Applications section it reads:
The XmlSerializer creates C# (.cs)
files and compiles them into .dll
files in the directory named by the
TEMP environment variable;
serialization occurs with those DLLs.
A user may have multiple instances of my application running at the same time. My concern is that the 2 different instances will be serializing to different XML files, however, the XmlSerializer class in application instance 2 could over write the DLLs generated by the XmlSerializer class in application instance 1. Should this be a concern, or are temp/unique file names used for these DLL names?
FYI: I need to use XML instead of binary serialization as we need to edit values in the files by hand sometimes.
Thanks
Should this be a concern, or are temp/unique file names used for these DLL names?
The names are unique, you don't need to worry about that
If your app is going to make extensive use of XML serialization, you might want to pre-generate the serialization assembly using Sgen.exe. This will avoid the overhead of generating it at runtime, and the assembly name will be fixed (YourAssembly.XmlSerializers.dll)
The following questions are about XML serialization/deserialization and schema validation for a .net library of types which are to be used for data exchange.
First question, if I have a custom xml namespace say "http://mydomain/mynamespace" do I have to add a
[XmlRoot(Namespace = "http://mydomain/mynamespace")]
to every class in my library. Or is there a way to define this namespace as default for the whole assembly?
Second question, is there a reason behind the always added namespaces
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
even if there is no actual reference to any of the namespaces? I just feel they add noise to the resulting xml. Is there a way to remove them an only have the custom namespace in the resulting xml?
Third question, are there tools to support the generation of schema definitions (e.g. for all public [Serializable] classes of an assembly) and the validation of xml against specific schemas available?
If there are, would you recommend XML Schema from W3C or RELAX NG?
Just to add - the "xsi" etc is there to support things like xsi:nil on values later on - a well-known pattern for nullable values. It has to write the stream "forwards only", and it doesn't know (when it writes the first bit) whether it will need nil or not, so it assumes that writing it unnecessarily once is better than having to use the full namespace potentially lots of times.
1) XmlRoot can only be set at the class/struct/interface level (or on return values). So you can't use it on the assembly level. What you're looking for is the XmlnsDefinitionAttribute, but I believe that only is used by the XamlWriter.
2) If you're worried about clutter you should avoid xml. Well formed xml is full of clutter. I believe there are ways to interract with the xml produced by the serializer, but not directly with the XmlSerializer. You have much more control over the XML produced with the XmlWriter class. Check here for how you can use the XmlWriter to handle namespaces.
3) XSD.exe can be used to generate schemas for POCOs, I believe (I've always written them by hand; I may be using this soon to write up LOTS, tho!).
Tools,
- xsd.exe, with a command line like
xsd /c /n:myNamespace.Schema.v2_0 myschema_v2_0.xsd
I put the schema in a separate project.
liqudXML which is useful if there are several schemas, or you want full support of the schema features (DateTimes with offsets, positive/Negative decimals,), and cross platform generation.